Identity resolution / user stitching

Gluing someone's anonymous browsing before signup onto their real account after it, so the data reads as one person, not two.

connect the visitor to their account laterlinking anonymous visits to a logged-in usermerging anonymous and signed-in datahow does it know it was the same personuser stichingidentity stitchinganonymous id to user id mappingprofile merging across devices

See it

Live demo coming soon

What it is

Every analytics tool hands a fresh browser an anonymous id (a cookie or device id) and starts logging against it. The moment that person logs in, you tell the tool 'this anonymous id is user 8412', and it links the two histories. Skip it and your data shows a stranger who clicked an ad and vanished, plus a user who was born fully formed at signup.

Four different jobs hide behind that one sentence, and it pays to keep them apart: setting a user id on the current session, attaching traits to a profile, aliasing one identifier to another, and merging two profiles that already have history. Most SDKs expose something called 'identify', but the signature and the semantics are not the same across Segment, Amplitude, Mixpanel and PostHog: some merge on identify, some want an explicit alias call, some changed behavior between major versions (Mixpanel's simplified id merge, for one). Read the docs for the exact SDK and version you have installed and follow that, rather than pattern-matching from a blog post about a different tool.

Reach for it when signups all report as 'direct' traffic, when funnels collapse at the login step, or when someone browses on a phone and buys on a laptop. Deterministic stitching uses something the person actually gave you (a login, an email hash) and is the only kind worth trusting. Probabilistic stitching guesses from IP address, user agent, and timing, which is fine for ad reach estimates and terrible for anything you would make a decision on.

Gotcha: in several tools a merge is effectively permanent, and undoing one ranges from a support ticket to impossible. Call identify on a shared kiosk or a family tablet and you can fuse two humans into a single profile. Two more traps: whether old anonymous events get backfilled onto the profile or only events after the call are attached depends entirely on the tool, so verify it with a test user instead of assuming, and forgetting the SDK's reset call on logout means the next person at that machine inherits the previous account.

Ask AI for it

Wire up identity resolution in my app's analytics. First, tell me which analytics SDK and exact version is installed in this project, then follow that SDK's own documented flow rather than a generic one. Implement four things in its terms: keep the anonymous id from the first pageview, perform the documented anonymous-to-known transition on signup and on login before any other event fires in that session, set stable traits (email, plan, account id) on the profile, and call the SDK's logout or reset function so a shared device does not inherit the profile. Do not call alias unless that specific SDK's docs say it is required for this flow, since a stray alias can duplicate or corrupt profiles. Send the same user id from server-side events. Show me the exact call sites, the order they must run in, the doc pages you relied on, and how to verify the merge worked with one test account.

You might have meant

user vs session vs pageviewcross domain trackingcdpevent trackingfirst party analytics