Identity Resolution

Method

Stitching the records left before someone logged in to the records left after, so the two belong to one person and one journey.

Why it exists

Somebody clicks an ad, spends twenty minutes reading the product pages, checks pricing, leaves, comes back the next day and signs up. To a human that's one person visiting twice and converting. To the data it isn't. Everything before signup is attached to a temporary value planted in the browser, everything after is attached to an account id, and unless something connects them you have one anonymous visitor plus one brand-new account.

At Pagedeck the gap first showed up in an ad performance review. Ravi asked how many signups the week's campaign had produced and the dashboard said zero. The ad click lived on the anonymous side and the signup lived on the account side. Neither number was wrong; there was simply no way to put them together.

The same gap hid how long people took to convert and which screens they revisited before deciding. The longer a product takes to think about, the more of the useful evidence sits ahead of signup — and all of it was pooled into a nameless crowd.

There's only one way out. At the moment someone logs in, record which anonymous value they were carrying a second earlier. Identity resolution takes that pair and joins the two records into one thread.

How to run it

The join happens exactly once, at login or signup. Sending the account id and the anonymous value together at that moment is the whole method; everything else is setup and cleanup.

  1. Plant an anonymous value on the first visit. Generate a random value in the browser or app and attach it to every record leaving that device. You don't know who the person is, but you know it's the same device.
  2. Record pre-login behavior against that value. This is where events — single lines describing one action — accumulate: which ad brought them in, how many times they opened the pricing page.
  3. Send both values together right after login or signup succeeds. Analytics tools usually call this the identify call. Skip this one line and nothing else you did matters, because the join never fires. It also has to run on the success path only — firing it on a failed login attaches the anonymous history to an account that person may not own.
  4. The tool ties the two values to one person, either by moving past records over to the account or by keeping a mapping table and merging at query time. Which approach your tool uses decides whether historical numbers get recalculated or stay as they were.
  5. Record later behavior against the account id. Logging out returns the person to an anonymous value, and the next login attaches that value to the same account.
  6. Repeat step 3 on each new device. Someone who signed up on a laptop and later logs in on a phone gets the phone's anonymous value attached to the same account.

Teams mixing client-side tracking, where the device sends events directly, with server-side tracking, where the server records them, have one more thing to line up. Server-sent records carry no anonymous value, so the front end has to pass it back and the server has to include it. Otherwise the two paths never converge on one person.

When it fits and when it doesn't

It pays off most in products with a long stretch of consideration before signup. If people arrive and pay the same hour, the anonymous window is a few minutes and there isn't much to stitch. For a product like Pagedeck, where someone circles back for two weeks first, most of the evidence lives in that window. Attribution — deciding which touchpoint gets credit for a conversion — doesn't work at all without the connection.

Four limits are worth knowing.

  1. Visits that end without a login stay anonymous forever. The method attaches a past to an account; it doesn't work out who an account-less visitor was.
  2. Clearing the stored value breaks the chain. Wiping browser data, using a private window, or reinstalling an app produces a fresh anonymous value with no link to what came before.
  3. One device shared by two people joins the wrong records. A colleague logging into a shared laptop inherits the previous person's anonymous history, and nothing in the data marks the moment it went wrong.
  4. The join changes what the data is. Records that identified nobody now point at an account, which puts them close to personally identifiable information (PII). Retention windows and access rules can't stay where they were for anonymous data.

How it sounds at work

"The campaign reported three signups but the dashboard shows zero. I don't think identity resolution is wired up."

Diagnosing that anonymous records and account records are running on separate tracks.

"Add the identify call when signup completes. It has to send the account id and the anonymous id together."

A request to implement step 3.

"It only fails in the app — reinstalling generates a new anonymous id."

Describing a case that ran into limit 2.

Whenever Pagedeck opens a new acquisition channel, Ravi and Mia check the same two things in the same order. First, that the anonymous value is being planted. Second, that the identify call fires on the signup screen. Miss either one and that channel's results don't exist as numbers, which usually gets discovered a month later when someone asks why the channel looks dead.

The identify call once sat after the welcome email rather than immediately after signup. Anyone whose email failed to send never got joined, so accounts kept appearing with no idea where they came from. That's why the tracking plan — the document stating which actions get recorded and how — pins down where this call goes, not just that it exists.

What people get wrong

People expect the join to bring back all of history. "Stitching the anonymous window" sounds like that. How far back it actually reaches varies by tool: some merge only queries run after the join, others move past records to the account but leave already-computed metrics untouched. Turn the join on without knowing which you have and you'll spend weeks trusting a dashboard where yesterday's numbers and today's follow different rules.

The second is assuming login alone handles it. An account id exists once someone logs in, so the connection feels like it should follow. The line that pairs the two values is separate work, and if it's missing for six months there's no recovering the pre-signup window — nothing in the anonymous records says whose they were.

Easily confused with

TermWhat it isHow it differs
User identifierOne unique value attached to recordsThe identifier is the raw material; the join is the operation on two of them. Anonymous values and account ids are both identifiers, and identity resolution builds the bridge between them

Where to go next

Last updated 2026-09-16