Identifying users

Analytics tools rely on cookies to recognize returning users — but cookies are unreliable. They expire, get cleared, and reset across browsers and devices. If you rely only on cookies, you'll badly overcount users and underestimate retention.

This chapter covers how analytics tools actually identify users, why cookies aren't enough, and the three identifiers you need to think about: user ID, device ID, and session ID.

#The cookie problem

When a user lands on your site for the first time, their analytics SDK drops a cookie containing a generated device ID. Every subsequent event from that browser carries the same device ID, so the tool can stitch them into one user's activity.

That works fine until the cookie disappears. It disappears for many reasons:

• Cookies expire (typically after a few months to a year, depending on the browser)
• The user clears their cookies manually
• The user switches browsers or devices
• The user uses incognito/private browsing
• The user is on Safari, where Intelligent Tracking Prevention caps first-party cookies at 7 days

When the cookie disappears, the next visit looks like a brand-new user. Your "new users" chart inflates, your "returning users" chart deflates, and your retention curves show users churning at 7-day intervals — not because they actually left, but because their cookies expired.

For SaaS products this is doubly painful, because users stay logged in to your app longer than tracking cookies last. A user might genuinely be a customer of 18 months, but Amplitude sees them as a brand-new visitor every couple of months.

#The fix: user ID

When a user does something that proves their identity — signs up, logs in — you tell the SDK who they are by passing a user ID. From that point forward, events get associated with that ID, not just the cookie.

The user ID should be your application's internal user ID (the one in your database). Not email, not username. Email and username can change; internal IDs shouldn't.

Once a user ID is attached, the SDK can recognize the same person across:

• Cookie expirations (their next event re-asserts the user ID, stitching the activity)
• Devices (logging in on a phone after using a laptop both carry the same user ID)
• Browsers (the user ID gets re-asserted on login)

This is what unlocks real retention analysis, cohort analysis, and any kind of cross-session user-based reporting.

#The three identifiers

Three IDs travel with most analytics events. You should understand what each does.

User ID. Your internal user ID. Set when the user authenticates. Persists across sessions and devices.

Device ID. Identifies the specific browser/device. Auto-generated by the SDK and stored in a cookie. Persists across sessions on the same device until the cookie expires.

Session ID. Identifies the current session. Auto-generated. Resets after a period of inactivity (typically 30 minutes).

Most analyses don't care which is which — events tagged with the same user ID are all the same user, full stop. But two scenarios make the distinction matter.

#Anonymous-to-identified merging

A user arrives, browses for 10 minutes anonymously (events tagged with device ID, no user ID), then signs up. The moment you call setUserId(), what happens to the earlier anonymous events?

In Amplitude (and most platforms): the events keep their device ID. When you query by user ID, those earlier events are also attributed to that user, because the SDK keeps a mapping of device ID → user ID. So the user's full timeline — anonymous and identified — appears under their profile.

The catch: this only works for events that happened on the same device before sign-up. If a user browsed your site on their phone yesterday and signed up on their laptop today, the phone's events don't merge into the laptop's user profile. The phone session stays anonymous forever (or until that user signs in on the phone too).

#Multi-device behavior

When a user signs in on a new device, the new device's events get tagged with their user ID right away. Going forward, queries by user ID return events from both devices.

But pre-signin events on the new device stay anonymous. There's no retroactive merge.

This is fine for most reporting — you care about identified activity. It only matters if you want to attribute a user's first-touch to a session that happened on a different device pre-signin. Most teams don't.

#The order rule

When a user signs up or signs in, set the user ID before tracking the auth event. Otherwise the auth event itself gets recorded under the old anonymous device, and your sign-up events look like they're firing from anonymous users.

// Correct order
amplitude.setUserId(user.id);
amplitude.track("Sign-up completed", { method: "email" });

This is the same principle as setting user properties before tracking — covered in Event-based tracking explained. Identity and state get established first; the event captures the snapshot.

#Resetting on sign-out

When a user signs out, you want subsequent activity in that browser to look like a fresh anonymous user — not like the person who just logged out. Otherwise, if someone else uses the same computer (or the user browses your marketing site), their actions get attributed to the wrong identity.

The SDK provides a reset() method that clears the user ID and generates a fresh device ID. Call it on sign-out, but after tracking the sign-out event itself — otherwise the sign-out gets attributed to the new anonymous user, not the person who actually left.

// Correct order
amplitude.track("Sign-out completed");
amplitude.flush();         // ensure the event sent
amplitude.reset();         // sever identity

#Server-side events need IDs too

When you track events from your server (e.g., revenue events from a Stripe webhook), you have to provide the user ID explicitly — your server doesn't have access to the browser's cookies. You'll often want to provide the device ID and session ID too, so server-side events get attributed to the user's active browsing session in Amplitude.

The mechanics of getting device and session IDs from the browser to your server are covered in Authentication tracking and Stripe revenue tracking.

#What to take away

1. Cookies aren't enough. Set a user ID the moment a user authenticates.
2. Order matters. User ID first, then track events.
3. Reset on sign-out. With tracking and flush before reset.
4. Three IDs, one model. User ID identifies the person, device ID the browser, session ID the visit.
5. Same-device anonymous events merge automatically. Cross-device anonymous events don't.