How AdPix identifies visitors

Three layers, not one#

The AdPix identity graph always has this shape, and it does not change:

anonymous → site user → global user.

• Anonymous is a random id kept in the browser (__sov_did and __sov_aid). Every event that happens before the visitor signs in attaches to it.
• Site user is the same person, but only within one property. When a real signal turns up — a login, an email, a phone number, a CRM client id — the anonymous id is linked to a site user.
• Global user is the same person across every property and every domain in your organization. This is the layer that lets you follow one person from an ad to a purchase on a different domain — provided that domain is listed in the stream's cross-domain settings.

Between the layers sit edges. Every edge is a piece of evidence, and every piece of evidence carries a confidence.

Deterministic versus probabilistic#

This is the only distinction you need to hold on to, because every behaviour of the system follows from it.

A deterministic signal means the visitor told you something — either by signing in through the browser, or through the client id your CRM sends server-side. A probabilistic signal means the system inferred it from a browser fingerprint.

What happens to events from before the sign-in#

This is the part that gets misread most often. Events recorded before identification are not rewritten. The event row in the analytical store is left exactly as it was.

Instead, at read time an override table is joined onto the events and returns the real global user. So the visit that was anonymous yesterday shows up under the visitor's name today — after they signed in — without a single byte of raw data changing.

Two practical consequences:

• The journey from the first anonymous visit to the purchase is complete.
• Channel attribution stays correct, because the first touch was never erased.

What you control#

Auto-identify on forms is on by default — when a form carrying a filled email or mobile field is submitted, that value is taken as a deterministic signal. Only that field is read; passwords and every other field never are.

If you would rather be explicit, call it yourself:

ap('identify', 'user_8421', { email: 'ali@example.com' });

ap('identify', 'user_8421', { phone: '09121234567' });

The phone number is normalised to the international format with the property's default calling code before it is hashed, so 09121234567 and +989121234567 reach the same user.

Once a night, everything is reconciled#

A nightly job recomputes the connected components over every edge and merges duplicate global users into one. The oldest id wins.

Every merge is written to the merge history and is reversible — if two people turn out to have been joined by mistake, they can be split back out. An identity's version only ever increases and is never reused, so downstream consumers can always tell that something changed.

The identity model is a frozen surface; changing it takes a written architecture decision, not a patch.

Where you see this in the console#

No screen is called "the identity graph". You see its effects elsewhere — the user count on Home, the length of a journey in the Path report, and the conversion rate that becomes more truthful once identification is live on your site. If you have not installed the tag yet, start at install the measurement tag.

Frequently asked questions#

Related#