You can identify users with an opaque ID, mask page text and form values in session replay, and exclude sensitive regions from recordings. Configure these controls before collecting production data, then verify the result with synthetic users in a test environment.

This guide covers the browser SDK and replay controls. URLs, event properties, profile attributes and external processing need their own review.

Use a pseudonymous ID

Choose a stable, opaque identifier generated for the user. Keep the mapping between that ID and the person's identity in your own systems. Avoid an email address, account number or another recognizable personal identifier as the ID.

With the JavaScript package, you can initialize Userorbit without supplying a name or email:

import userorbit from "userorbit-js";

await userorbit.init({
  accountId: "YOUR_ACCOUNT_ID",
  userId: "usr_demo_7f4c2a",
});
JavaScript

Replace YOUR_ACCOUNT_ID with your workspace's installation value. The user ID above is synthetic; your application should supply the correct opaque ID for each signed-in user.

If the SDK is already initialized and the user signs in later, call:

await userorbit.identify("usr_demo_7f4c2a");
JavaScript

Name and email are optional. Only add profile attributes that serve a defined purpose and have been approved for collection. Review every integration that can populate the profile, including server-side calls.

A pseudonymous ID remains linkable to a person. It does not make the activity anonymous. Userorbit can associate anonymous activity with a later identified user. Also, omitting name or email from a new call does not delete values already held in an existing profile or integration state.

When the user signs out, call:

await userorbit.logout();
JavaScript

When initializing for the next signed-in user, explicitly supply that user's opaque ID. Do not assume logout() creates a fresh anonymous identity or stops an active replay: the SDK retains its stored distinct ID, and initializing without a user ID can reuse it. For shared browsers or anonymous activity after sign-out, agree and verify the full account-switching and recording lifecycle with Userorbit before production. reset() is not a replacement for sign-out; it can retain the current identity and attributes while refreshing SDK state.

See the User identity API reference for the identity methods.

Open the replay privacy controls

An owner or administrator manages the recording configuration. Confirm that Session Replay is available for your workspace before proceeding.

  1. Select the intended workspace.
  2. Open Analytics, then Replays, and confirm the intended project.
  3. Select Recording settings.
  4. Scroll to Privacy.

If Recording settings is missing, ask a workspace owner or administrator to check your access and the controls available in your deployed version. Resolve that before relying on a particular recording configuration.

These settings control new recordings. They do not rewrite existing recordings or remove previously collected profile data.

Choose a privacy mode

For a sensitive application, begin with Mask everything and explicitly block the regions that must not be captured. Validate the result before relaxing any controls.

  • Mask everything masks page text and form values, subject to explicit unmasking described below.
  • Selective masking records interface text, masks form values and attempts to redact the selected PII types from page text.
  • Record everything can record visible text and form values. Password inputs and configured masked selectors remain protected. This mode is unsuitable for a workflow that requires general text and input masking.

With Selective masking, the PII to redact from page text options are Email addresses, Phone numbers, Payment card numbers and IP addresses.

Detection is pattern-based. Phone matching is heuristic, payment-card matching checks candidate numbers, and the IP matcher covers IPv4 addresses. Do not assume these options recognize every format, IPv6 address, name, postal address, bank account number, balance or financial detail. Mask or block those regions explicitly.

Audit .uo-unmask in your application. Text inside an element with this class can bypass both broad text masking and selective PII redaction, including the text-masking selector check. Remove it from sensitive regions and their ancestors before relying on masking.

Mask text or exclude whole regions

Use the selector fields under Privacy to target stable elements in your application's HTML. Both fields accept comma-separated CSS selectors.

Always mask these elements replaces matching text and form values with asterisks. For example:

.uo-mask, [data-uo-mask], .customer-name, [data-private]
CSS

Your developers could mark a sensitive value like this:

<span data-private>Synthetic customer name</span>
HTML

The data-private attribute works here because it is explicitly included in the selector field. Do not add .uo-unmask to this element or an ancestor.

Do not record these elements blocks matching regions, replacing them with an empty box in the replay. For example:

img, video, .payment-details, [data-sensitive-region]
CSS
<section data-sensitive-region>
  Synthetic payment details
</section>
HTML

The recorder also recognizes the built-in .uo-block class for blocking a region. The default blocked selector field contains img, video; preserve those entries if you add selectors and still want images and videos excluded. Editing a field replaces its previous list.

Review the configuration, then select Save settings. Start a new test session after saving. Check dynamically loaded content and changed screens, not just the first page.

Review data outside replay text

Replay masking is applied by the browser recorder before replay upload. It is not a general-purpose filter for everything your application sends.

Data surface What to review
URLs and page metadata Keep sensitive values out of paths, query strings, fragments, page titles and referrers. These can be collected separately from replay text.
Identity and event properties Approve an explicit set of fields. Do not send credentials, payment details, personal free text or unnecessary identifiers through profile attributes or custom events.
Error tracking Review error messages, context and page URLs if error tracking is enabled. Replay masking does not provide blanket redaction for these payloads.
IP and location processing The IP addresses checkbox redacts matching page text. It does not disable request-IP processing or the separate derivation of location information.
AI and other integrations Review enabled analysis and integrations with Userorbit, including the data they use, processing locations and access. Replay masking alone does not determine which external services process data.

Avoid enabling the SDK on sensitive routes until their collection requirements have been agreed and verified. If replay must be disabled for an integration, the SDK supports this initialization option:

await userorbit.init({
  accountId: "YOUR_ACCOUNT_ID",
  userId: "usr_demo_7f4c2a",
  sessionReplay: { enabled: false },
});
JavaScript

This disables replay for that SDK instance. It does not disable all analytics or other Userorbit features, and it is not a deletion mechanism.

Validate before collecting production data

Use synthetic values that resemble your real workflows without identifying a real person. Include names, account-like values and financial details in the test so you can verify explicit masks and blocked regions.

  1. Start a fresh test session with the approved ID and attributes. Confirm that the expected pseudonymous user appears and that unnecessary personal fields have not been supplied.
  2. Exercise the sensitive workflows, including forms, validation errors, modals and content loaded after the initial page.
  3. Inspect the replay. Confirm that intended text is masked and excluded regions contain no readable content. Check that useful interaction context remains understandable.
  4. Have your engineers inspect outgoing requests using the browser's developer tools. Review URLs, metadata and event payloads separately; a masked replay does not prove those fields are clean.
  5. Test sign-out and a different user signing in on the same browser. Check attribution and ensure the previous identity is not carried into the next session.
  6. Record the approved configuration and repeat the checks after changes to the application, SDK or privacy settings.

Agree access, retention and deletion arrangements with your team before production. For recording volume and retention behavior, see Configure Session Replay privacy and retention. For assisted infrastructure setup, see Self-hosting Userorbit: preparation, deployment and handover.

If sensitive data has already been collected, tightening the configuration protects future captures. Handle the existing data through the appropriate removal process with your workspace administrator and Userorbit support.

Was this helpful?