User Identifier

Behavioral records accumulate one event at a time. A row saying somebody pressed a button, a row saying a document was saved, stacked in time order. Each row carries when and what, but with no who attached those rows can't be joined. The story of one person signing up, creating a document, and cancelling three weeks later stays scattered across three unrelated rows.

Early on this slot got filled with a single value stored in the browser. The trouble is that one person uses several devices. Arriving from a work computer, a home laptop, and a phone produces three values and three people in the table.

The gap surfaced at Pagedeck. Ravi reported 340 new users last month and Sofia said it didn't reconcile with the contract side. The number of accounts actually created was 210, and the difference was devices: someone signing up at work and returning from home was being counted as a new person. Deciding what counts as one person and carrying that value on every record is what this concept is for.

Two kinds of identifier get used together.

The anonymous identifier covers the period before an account exists. It's generated the first time a browser or app runs and stored on that device. The path where someone clicks an ad, views the pricing page three times, and then signs up survives because of this value.

The account identifier is what gets used after login. It's the number the server issued when the account was created, and it stays the same across devices.

Records carry both. Before login only the anonymous value rides along; from login onward the account value rides with it. At that moment, everything previously accumulated under the anonymous value gets joined to the account, a process called identity resolution.

Choosing what serves as the account identifier is where teams most often go wrong. Three conditions apply.

1. It can't change. Use a value the user can edit and the records split in two the moment they edit it.
2. It can't collide. The instant two people hold the same value, two people's behavior merges into one history.
3. It can't identify a person. Names and contact details are personally identifiable information (PII), and pushing them into analytics tools expands what has to be governed.

An internally issued account number satisfies all three. An email address satisfies the first two and fails the third, and it breaks the first as well the moment a user changes addresses.

For a product several people share, carry an organization identifier as well, because contracts and billing attach to the team rather than the individual. With only a user identifier, one team growing from one seat to nine looks the same as nine new teams arriving.

Know where it breaks, too. Clearing cookies, reinstalling an app, or browsing privately generates a fresh anonymous value. Pre-signup records therefore always overstate the number of people, and since that error can't be removed, it gets read with the overstatement in mind. The practical rule is to compare pre-signup figures only against other pre-signup figures, never against account counts.

Every analysis that follows one person over time rests on this value. Funnel analysis, which reads how many drop out at each step, and retention analysis, which reads how many come back in later weeks, both collapse if people can't be joined. A session — one visit from arrival to exit — is built by cutting the events joined under one identifier at time gaps.

Experiments require it too. When two variants are split between people, the same person has to keep seeing the same variant. Re-split on every visit and one person alternates between variants, which makes the experiment unreadable — and the failure is silent, since the results still arrive looking like results.

Privacy work uses it as well. When a user asks for their records to be deleted, this value is how they get found. If nobody has written down where the identifier lands and what sits under it, a deletion request can't be answered.

Which is why what serves as the identifier, and which records carry it, gets written into the tracking plan — the document specifying which events get instrumented under which names and properties. Without it, one screen sends the account number and another sends an email address, and the inconsistency only becomes visible months later when a funnel refuses to reconcile.

"It's 210 new users, not 340. They were being counted per device."

Naming the error of reading anonymous identifiers as people.

"Instrument the identifier as the email address and records break for anyone who changes theirs."

A mutable value can't serve as an identifier.

"Team-level metrics need the organization identifier carried alongside."

A user identifier alone can't count the unit that pays.

After confirming the gap between 340 and 210, Pagedeck fixed three things: the account number became the account identifier, a join was added at login to attach the anonymous history, and every event started carrying the organization number.

A month later new-user counts matched created accounts within 2 percent. Past records couldn't be repaired, though, because there was no way to know which anonymous value had belonged to which account. So last quarter's numbers don't get compared against the new basis; the date the basis changed is marked on the chart instead.

The most common reading is that the count of identifiers is the count of users. Analytics tools display unique values, so it looks that way. But that count is closer to a count of devices and browsers. One person becomes three, and someone who clears cookies becomes four. Left uncorrected, traffic reads higher than it is, conversion rates divided by that number read lower than they are, and budget set from those rates permanently penalizes the channels whose users own the most devices.

Believing an email address is a convenient identifier is the second mistake. It's human-readable, which makes debugging easy, and the same value works across tools. But the moment PII scatters across analytics tools and logs, the duty to find and delete it scatters with it. And a user who changes addresses splits into two people. Keeping an internal number as the identifier and storing the email only where it's needed leaves far less cleanup behind.