.svg)
How to Fix Fragmented User Identity in Amplitude (When Users Don't Log In by Email)
The short version: User identity fragments in Amplitude when one real person shows up as several separate users — usually because their anonymous, pre-login activity never gets stitched to their known account. It's especially common when users don't log in by email (phone-number auth, for example), because the identifier Amplitude normally leans on isn't there. The fix is to set a stable, consistent user ID as early as you can and use Amplitude's Aliasing API to merge anonymous device IDs with the known user — so pre- and post-login behavior resolves to one person instead of many.
The symptom: one person, counted as many
Your user counts look inflated, your funnels leak between steps for no clear reason, and user-level analysis just feels off — the same person seems to appear multiple times. That's fragmented identity. Amplitude is faithfully recording behavior; it just doesn't realize that several of the "users" it's tracking are actually the same human before and after they logged in.
Left unfixed, it undermines everything downstream: retention curves, funnels, cohorts, and attribution all assume one row per real user. When identity fragments, every one of those reports inherits the error.
How Amplitude identifies users (the 60-second version)
Amplitude ties every event to one of two IDs:
- Device ID — generated automatically, anonymous. It's how Amplitude tracks someone before you know who they are.
- User ID — the stable identifier you set once a user is known (signs up, logs in).
When you set a User ID on a device that already has anonymous activity, Amplitude normally merges that anonymous history onto the known user. That's identity resolution working as intended. It breaks when the User ID is set inconsistently, set too late, or never set with a stable value — and that's exactly what non-standard login models tend to cause.
Why non-email logins break it
Most Amplitude setups quietly assume an email-based signup where a clean, unique identifier is available at the right moment. Phone-number auth (and other non-email models) breaks that assumption: the identifier you'd key on isn't where the default setup expects it, so a user's anonymous pre-login sessions never get connected to their known account. The result is fragmentation — anonymous "users" splitting off from the real, identified person.
It's one of the more subtle Amplitude configuration mistakes, because nothing looks broken — events fire, dashboards populate — but the user counts underneath are wrong.
A real example
A business-formation platform we worked with logs users in by phone number, not email. In Amplitude, that atypical auth model was causing anonymous sessions to fragment from known users, making user-level analysis unreliable before any reporting could even begin.
The fix was a dedicated identity resolution document with two solutions — the Aliasing API as the primary approach and a fallback method — designed specifically for the phone-number model. A practical detail that saved a round-trip: access to the Aliasing API was confirmed with the client's Amplitude account manager up front, before it became a blocker. (Full story in the Bizee case study.)
The fix: stitch anonymous activity to the known user
Three moves resolve most fragmentation:
- Set a stable user ID as early as possible. The moment you can reliably identify someone, set a consistent User ID — and use the same value every time (not one that changes between sessions or platforms). The earlier and more consistent it is, the less anonymous history is left stranded.
- Use the Aliasing API to merge IDs. For non-standard auth, aliasing lets you deliberately connect anonymous device IDs to the known user, so pre-login behavior resolves onto the right person rather than floating off as a separate "user."
- Confirm Aliasing API access before you build. Availability can depend on your Amplitude plan, so check with your account manager early — it's a cheap step that prevents a late surprise.
Because a User ID is set through the SDK, fragmentation often traces back to how that's implemented — worth reviewing alongside the common Amplitude SDK issues if your identity looks off.
How to diagnose it in your own project
- Check total users vs. reality. If Amplitude's user count is well above your known account count, fragmentation is likely.
- Look at a single known user. Pull up one real user you can verify and see whether their pre- and post-login activity sits on one profile or several.
- Audit when and where User ID is set. Confirm it's set as soon as identity is known, with a stable value, on every platform.
- Watch for multi-platform gaps. The same person on web and mobile should resolve to one user; if they don't, your ID strategy isn't consistent across SDKs.
Why it's worth fixing first
Identity is the layer everything else sits on. Get it wrong and your funnels, retention, and cohorts are quietly built on double-counted users — which is why resolving it is a prerequisite for a trustworthy single source of truth for product data, not an optional cleanup.
Not sure if your identity model is sound?
If your user numbers don't add up and you're not sure whether identity is the cause, a Data Stack Audit pinpoints where identity is fragmenting and maps the fix — especially valuable if you're on a non-email auth model.
Frequently asked questions
Why does one user show up as multiple users in Amplitude?
Because their anonymous, pre-login activity isn't being stitched to their known account. Amplitude tracks unknown users by an anonymous device ID and known users by a user ID; if the user ID isn't set early and consistently, the two never merge and one person is counted as several.
Why does phone-number login cause identity problems in Amplitude?
Default setups tend to assume an email-based signup that provides a clean identifier at the right moment. Phone-number (and other non-email) auth breaks that assumption, so anonymous sessions don't connect to the identified user — fragmenting one person into multiple "users."
What is the Aliasing API in Amplitude?
It's a mechanism for deliberately linking IDs so that anonymous device activity is merged onto a known user. It's particularly useful for non-standard authentication models where the default identity resolution doesn't stitch sessions correctly. Access can depend on your plan, so confirm it with your Amplitude account manager.
How do I know if my Amplitude identity is fragmented?
Compare Amplitude's total user count against the number of real accounts you know you have — a large gap is a red flag. Then inspect a single known user to see whether their pre- and post-login activity lives on one profile or is split across several.
Does fragmented identity affect my other reports?
Yes. Funnels, retention, cohorts, and attribution all assume one record per real user, so fragmented identity distorts all of them. That's why it's worth fixing before you trust any downstream analysis.
That's the identity resolution post. Links to verify: the three internal blog URLs (config mistakes, SDK issues, single source of truth), the Bizee case-study link, and the Data Stack Audit service page.
That clears the Bizee-derived angles I'd flagged. Still open whenever you want them: the Hypothesis Bank blog (needs the lead-magnet URL) and the Statsig analytics/session-replay angle. Want one of those next, or something new?
.png)
