The Userorbit browser SDK can store state in the browser and send data before a person is identified by name or email. Use this reference to review a web installation's data collection. The fields present depend on the features you enable, the values your application supplies and the SDK version in use.

Browser storage used by the SDK

The following entries cover the core identity, analytics and replay paths. They are not a complete cookie or storage inventory for every widget, portal or integration.

Storage entry Location Purpose
userorbit_distinct_id localStorage Stores the distinct ID and whether it has been identified. The ID may be generated for an anonymous visitor or supplied by your application.
userorbit-js localStorage Caches SDK configuration and state, which can include the person and attributes supplied to the SDK.
userorbit_session localStorage Stores the analytics session ID, start time and last activity time.
userorbit_window_id sessionStorage Stores the identifier used to distinguish the browser tab for replay.
uo-replay-sample:<sessionId> localStorage Remembers whether the analytics session passed replay sampling.
userorbit_events, userorbit_anon_events, userorbit_user_props localStorage Holds queued analytics events and profile updates. Entries depend on activity and are removed as queues empty.

Local storage belongs to the site's origin. Do not assume identity or session state is automatically shared between different subdomains. Browser storage is also separate from Userorbit's server-side retention policy.

These entries do not all have a fixed time-based expiry. Analytics sessions use an inactivity timeout, but that does not mean every associated local storage value is deleted at that time. Browser settings, site code and SDK actions can affect what remains. Review the actual entries in a synthetic browser session when preparing your storage inventory.

If local storage is unavailable, some SDK queues can use page memory. This is a fallback, not a configurable cookieless mode or a guarantee that the SDK sends no data. Replay also needs a browser-tab identifier, which may be unavailable when session storage is blocked.

Data that can be sent

Data category Examples Collection boundary
Identity and profile Distinct ID, optional email/name, supplied attributes An opaque ID avoids sending a direct identifier as the ID, but remains linkable through your own records. Existing profile values can still be present.
Analytics events Event name, timestamps, session and tab IDs, browser and operating-system metadata Events and metadata are separate from replay's text-masking controls.
Page and session context Page URL, path, title and referrer Values can be sent by page-view and session tracking. Avoid private values in any part of the URL or page title.
Session replay Page structure and changes, interaction events, initial URL and viewport When recording is eligible, the browser applies configured replay masking/blocking before uploading replay data.
Error tracking Error message, context, stack information and page URL Review these fields if your application enables the error-tracking methods. Replay masking does not sanitize all error payloads.
Request-derived location City, country, region and time zone where available The service can derive location from request IP information. The replay page-text IP mask does not disable this processing.

Replay's built-in error diagnostics are narrower than optional error tracking: they record an allowed error name and its source, such as a browser error or unhandled rejection. Do not treat that limited diagnostic format as a promise about data supplied through separate error-tracking methods.

If replay AI analysis is used, evidence extracted from a recording is sent to the selected model for analysis. Review this feature and other enabled integrations separately with Userorbit, including their processing locations and access arrangements.

Identity changes and sign-out

identify() is not the starting point for all collection. The SDK can generate an anonymous ID and perform enabled analytics and replay work before your application calls it.

Calling logout() clears SDK configuration, but does not guarantee a new anonymous identity or stop an active replay. The stored distinct ID can be reused when the SDK is initialized without an explicit user ID. When initializing for another signed-in person, supply that person's correct opaque ID and test the complete switch. reset() refreshes state while retaining identity and attributes; it is not an anonymous reset.

See Protect personal data with pseudonymous IDs and replay masking for identity examples and masking checks.

Collection controls have different scopes

sessionReplay: { enabled: false } in initialization disables replay for that SDK instance. It does not disable every Userorbit feature or remove data already sent. The SDK also exposes analytics and in-app feature options, but these are not a single consent or all-data opt-out switch.

If your application must wait for a consent choice, arrange that decision before loading and initializing the relevant integration. Review all installation paths, including tag managers and framework components, so another path does not start it earlier. Verify consent withdrawal and any activity already in progress with Userorbit before relying on a production implementation. Do not use logout() or reset() as an assumed consent-withdrawal API.

Verify your installation

Use a test account with synthetic values. Inspect browser storage before initialization, after anonymous activity, after identification and after sign-out. Check outgoing requests alongside replay playback, because masked replay text does not prove that URLs, profiles or event payloads are free of personal data.

Record the feature configuration, allowed fields and SDK version used for the review. Repeat it after integration changes. Keep private browser storage, request bodies and credentials out of support screenshots and shared logs.

Was this helpful?