---
title: "How Amplitude decides who's who - and where the user counts leak"
canonical_url: https://ampl.webclat.com/blog/amplitude-identity-resolution
description: "How Amplitude's device_id, user_id, and Amplitude ID fit together, what merges retroactively, what can't be undone, and the instrumentation rules that keep user counts honest."
source: Webclat | Amplitude Solutions (official Amplitude partner, independent consultancy)
---

# How Amplitude decides who's who - and where the user counts leak

Every chart inherits the identity layer's decisions. Here is how Amplitude's ID model actually behaves per its own docs - including the merge that happens retroactively, the one that can't happen at all, and the logout call that quietly manufactures new users.

## What are the three identifiers?

Amplitude tracks people through three IDs. You set one, the SDK sets one, and Amplitude derives the third:

| Identifier | Who sets it | What it is |
| --- | --- | --- |
| device_id | The SDK | On web, a random UUID (persisted in cookies by default); on mobile, the IDFV or a generated string. |
| user_id | You | Your stable identifier for a known user - Amplitude's docs say many products use a username or an internal unique identifier, and that the value should not change. |
| Amplitude ID | Amplitude | Derived from the other two: once Amplitude receives a device ID, a user ID, or both, it generates the Amplitude ID and associates the collected identifiers - preferring the user ID, because multiple people can share a device. |

> All three definitions: Amplitude's 'Track unique users' doc (link in Sources).

## How does anonymous-to-identified merging work?

Retroactively, and by device. Per the docs: Amplitude assumes previous anonymous events on a device belong to a single user until it receives an event with a user ID - then it applies the same Amplitude ID to the anonymous events and the identified event. Your pre-signup funnel joins up with the post-signup user automatically, on that device.

Cross-device stitching follows from the user ID: the docs' own example has a user's ID appearing on a new device, and Amplitude assigning the same Amplitude ID regardless of the device ID. Set the same user_id everywhere a person logs in and their journey is one journey.

A myth worth killing while we're here: third-party posts often claim the retroactive merge only reaches back within the same session, or that Amplitude offers selectable identity-resolution modes. We could not ground either claim in Amplitude's documentation - we treat both as unverified and you should too.

## What can't be merged - and what can't be undone?

The hard rule, straight from the docs: Amplitude can't merge user IDs. Give an existing person a new user_id and they are, permanently, a different unique user. This is why user_id choice is a one-way door and why 'we'll switch from emails to internal IDs later' is a plan to fork every active user.

There is one escape hatch - the User Mapping API can merge two user IDs (and unmap them again) - but it is API-only, and the docs note that the user properties on each event remain those of the original user who fired it. The automatic device-based merge, meanwhile, has no documented undo.

Billing feels this too. Amplitude's MTU guide counts anonymous users by device ID and known users by user ID, merges an anonymous user into their identified self as a single MTU when they log in - but a person who stays anonymous on a second device, or who carries two unlinked user IDs in a month, counts more than once. Identity hygiene is literally a line item.

## The three instrumentation rules that follow

- Choose a user_id that never changes. The docs demand a stable value; our field recommendation (judgment, and consistent with the docs' stability requirement) is your internal user ID, not an email - emails change, and a changed user_id is an unmergeable new person.
- Never assign anonymous users a user_id - the docs say this outright. Let the device-based merge do its job at login.
- Decide logout behavior deliberately. Browser SDK 2's reset() sets user_id to undefined AND regenerates the device_id - the user 'appears to Amplitude as a new user.' Right for shared machines and privacy requests; if you call it on every logout of a personal device, you manufacture anonymous users (and, on MTU-billed contracts, cost) daily. That trade-off framing is our judgment; the reset() behavior is documented.

## Where this fits in a bigger identity strategy

This post is deliberately Amplitude-specific. Cross-tool identity stitching - warehouses, CDPs, the generic version of this problem - lives with our parent studio at webclat.com. Here, the practical takeaway is narrower: audit what your instrumentation actually does at signup, login, logout, and cross-device, because Amplitude's rules are mechanical and your user counts are downstream of all four moments.

## FAQ

### Can I change a user's user_id in Amplitude later?

Not by re-instrumenting: Amplitude's docs state it can't merge user IDs, so a new user_id is a new person. The API-only User Mapping endpoint can merge two user IDs after the fact (and unmap them), with the caveat that each event keeps the user properties of whoever originally fired it. Plan the user_id as a one-way decision.

### Should I call reset() when a user logs out?

Only deliberately. reset() clears the user_id and regenerates the device_id, making the person appear as a brand-new anonymous user - documented behavior. That's correct for shared or public devices and privacy flows; on personal devices it fragments identity and inflates tracked-user counts. Decide once, document it, and apply it consistently.

### Does identity resolution affect what Amplitude costs?

On MTU-billed contracts, directly: Amplitude's MTU guide counts anonymous users by device and known users by user_id, and a person split across an un-logged-in device or two unlinked user IDs counts more than once. On event-billed plans the effect is indirect but real - fragmented identities distort every per-user metric you buy the tool to compute.

## Sources

- [Amplitude docs: Track unique users (identifiers, merging, user_id guidance)](https://amplitude.com/docs/data/sources/instrument-track-unique-users)
- [Amplitude docs: Browser SDK 2 (reset() behavior, device_id persistence)](https://amplitude.com/docs/sdks/analytics/browser/browser-sdk-2)
- [Amplitude docs: User Mapping API (merge/unmap)](https://amplitude.com/docs/apis/analytics/user-mapping)
- [Amplitude docs: MTU guide (how identity affects billing counts)](https://amplitude.com/docs/admin/billing-use/mtu-guide)
- [Amplitude docs: Portfolio (cross-project identity)](https://amplitude.com/docs/admin/account-management/portfolio)

In practice: Identity resolution health is one of the ten dimensions our free scored audit checks - with the merge behavior tested, not assumed. (https://ampl.webclat.com/services/amplitude-audit)