In Segment, how does an anonymousId get linked to a userId, and what breaks it?

## Where the anonymousId comes from The first time a visitor loads a page carrying Segment's browser library, the library mints a random `anonymousId` and persists it client-side (in the browser's cookie/local storage under an `ajs_anonymous_id` key). Every `page` and `track` call from then on carries it. That is what makes pre-login behaviour analysable at all: you cannot know who the visitor is, but you can tie their pageviews, searches and add-to-carts to one another. On mobile, the equivalent identifier is generated and stored by the mobile library; on server libraries there is no automatic value at all, which turns out to matter enormously (see below). ## The link is made by sending both ids together When the user logs in or signs up, you call `identify(userId, traits)`. The library attaches the existing `anonymousId` alongside the new `userId`, and that single message — *"these two identifiers are the same person"* — is the stitching signal. Afterwards the library caches the `userId` too, so subsequent calls continue to carry both. An important nuance for an interview: **Segment forwards the pair; it does not impose a merge.** Each destination applies its own identity model to that message. Some merge the anonymous profile automatically on seeing both ids. Some require an explicit `alias` call. Several vendors have reworked their identity handling over the years, so the correct answer for any given destination is "check that destination's current documentation", not a blanket rule. Segment's own profile layer (the product has been renamed over time — Personas, then Unify/Engage) does a further, richer resolution across identifiers such as email and phone, with rules about how many of each identifier a profile may accumulate, precisely so a shared value like a support email does not collapse thousands of people into one profile. ## Failure one: no reset on logout `analytics.reset()` clears the cached `userId` and traits and issues a fresh `anonymousId`. If you do not call it when a user logs out, the browser keeps the previous `userId` and keeps sending it. On a shared or kiosk machine, the next visitor's browsing is attributed to the person who logged out. This is not a cosmetic error: it corrupts per-user funnels, poisons any audience built from behaviour, and in a B2B account it can attribute one customer's activity to another. The symptom in the warehouse is a user whose events continue at implausible volume and from implausible contexts after their session should have ended, often with a device or IP that changes underneath a constant `userId`. ## Failure two: server-side calls with no anonymousId Server libraries do not have the browser's storage. A server-side `track` that supplies only a `userId` is fine for a logged-in user, but a server-side call made **before** login — an event from a checkout service, say — either has no id at all (the API requires a `userId` or an `anonymousId`) or invents a new one, creating a fresh anonymous profile that will never join the real one. The fix is to plumb the browser's `anonymousId` through to the server (read it from the cookie, pass it in your API call) and send it explicitly on the Segment call. This is the most common structural mistake in a hybrid client/server instrumentation, and it produces the maddening symptom that client-side and server-side events for the same user never appear in the same funnel. ## Failure three: identifying too late If the only `identify` fires after an email confirmation step at the end of onboarding, everything before it lives under the anonymous identifier. Destinations that stitch on `anonymousId` will recover it; destinations that do not will simply never attribute the funnel's early steps to the user. The guidance is to identify as soon as you have a stable id — at login, at signup submission, on session restore from a token — and to re-identify on every page load of an authenticated session so that a page loaded in a fresh tab is not anonymous. ## Cross-device is a different problem One browser's `anonymousId` says nothing about the same person's phone. Cross-device stitching is only deterministic once the same `userId` appears on both devices, which means it depends on the user logging in on each. Anything beyond that is probabilistic and belongs to a profile layer, not to the SDK. ## Operational checks A short list worth running on any Segment implementation: does logout call `reset()`; do server events carry the browser's `anonymousId`; does `identify` fire on session restore, not just at login; are there `userId` values with wildly implausible event counts; and does the ratio of anonymous to identified events for logged-in journeys match expectations. Each of those maps directly to one of the failure modes above.