Userorbit can record activity before a person signs in and associate later activity with a stable application user ID. The distinction matters when checking reports, targeting experiences, and reviewing privacy requirements.

Anonymous visitors

When the SDK starts without an explicit user identity, it looks for a saved browser identity. If none exists, it generates an ID and stores it in the browser's localStorage under userorbit_distinct_id.

This allows the SDK to recognize that browser again while the stored identity remains available. It is not a guarantee of recognizing one person across devices, browsers, private browsing sessions, or cleared storage.

“Anonymous” here means the SDK has not identified the visitor with your application user ID. Their activity can still include URLs and other data that identifies them. Treat collection and consent requirements separately from whether identify() has been called.

A previously identified browser can retain its stored identity. Leaving userId out of a later initialization does not guarantee a new anonymous visitor.

Identified people

After authentication, call identify() with your stable application user ID:

await userorbit.identify("usr_demo_1042", {
  attributes: { plan: "business" },
});
JavaScript

The ID should identify the same person consistently. Names and email addresses are optional profile fields; use an opaque internal ID when possible.

Userorbit can then use supplied profile attributes for audience rules and display the identity alongside analytics activity. An identified user is not automatically eligible for every tour, checklist, survey, or announcement. Publication, targeting, frequency, and other delivery rules still apply.

Activity before sign-in

The browser SDK has a transition from an anonymous identity to a supplied user ID. This supports connecting the current anonymous browser activity with identification.

Do not assume that identifying someone retroactively links every earlier event across every browser and device. Verify the flow that matters to your product: start in a fresh test browser, perform a known action, identify the test person, perform another action, and inspect the resulting identity and reports.

Account switching and sign-out

For a person who switches customer accounts within your application, update the active account attributes with another identify() call. These attributes describe the person’s current context; they do not create an independent company identity.

Call logout() on your application's sign-out path. It clears SDK configuration, but it does not erase the saved distinct ID or guarantee that an active replay stops. The public reset() method reinitializes with the existing user ID and attributes. Neither method is a data-deletion request.

Test a second person's sign-in on the same browser before using this flow in production. If you need to begin a fresh, unlinked anonymous identity after sign-out, confirm the supported approach with Userorbit.

Choose the minimum useful profile

Use a stable ID and a small set of fields needed for targeting or analysis, such as a subscription tier. Do not send credentials, payment details, free-form customer content, or personal fields merely because they are available in your authentication session.

See User identity API reference for method examples and Protect personal data with pseudonymous IDs and replay masking for masking and data-minimization guidance.

Was this helpful?