ID graph

Every event your site or server sends raises the same question: which person does this belong to? A browser answers it badly. A cookie names one browser on one device, and nothing more. The same person browses on a phone, buys on a laptop and later appears in your customer database, and to a cookie those are three strangers.

That costs you in three places. An ad platform cannot match a purchase to the click that caused it when the click landed on another device. A consent choice made on the phone does not hold on the laptop. A backend system that knows the person by email cannot reach the profile the browser built. The ID graph fixes this by keeping one profile per person and tying every browser, device and backend call that presents the same identifier to it. Every app you install then receives the full picture of the person, not a slice of one browser.

This page explains the model. It does not cover the calls themselves. For those, see Standard events and User data.

Three records

The graph keeps three kinds of record. Each site has its own graph by default. A storage link makes sites of one team share one graph, so a person identified on one site is known on the other.

A visitor profile asks the registry who owns an identifier, then links to that person profile. From then on the two exchange state in both directions.

A visitor profile is one browser on one device. The tag stores an anonymous id (anon_…) in a first-party cookie on your domain, and everything that browser does lands on this profile. It exists from the first visit.
A person profile is one person. It holds the identifiers the person owns, the latest value of every trait, their consent and their purchases, plus the list of visitor profiles linked to it. It is created the first time a visitor presents an identifier.
The identifier registry records, for each email, phone number or custom id, which person profile owns it. An entry is written once and never changes hands.

From anonymous to identified

A visitor passes through four stages. The first two happen on one device. The third creates the person profile, and the fourth is where the graph pays off.

1Anonymous
First visit. The tag sets a first-party cookie with an anon_… id.
Page views, traits and purchases collect on the visitor profile.
Nobody knows who this is yet.
2Identified
The visitor signs up / fills a form. identify() stores the email as a trait.
The profile now says who this is, on this device.
A trait alone does not link devices.
3Linked
alias() with the email, from this browser.
The registry marks the email as owned. A person profile is created and receives everything from stages 1 and 2.
4Converged
The same email on another device or from a backend reaches the same person profile.
Changes anywhere reach every linked device.

Visitor profile: exists from the first visit, one per browser
Person profile: none yetcreated at first link, shared by all devices
Registry entry: email not claimedemail belongs to this person, permanently

Stages 1 and 2 live on one device. The link in stage 3 creates the person profile and copies the device's history into it. From stage 4 on, the person profile is the shared source for every device.

Anonymous. The tag sets the cookie on the first visit. Page views, traits and purchases collect on the visitor profile. Qinto does not yet know who this is, and if the visitor never identifies, it never will. A visitor profile that never presents an identifier is never promoted to a person.
Identified. The visitor signs up or logs in, and your site calls identify with traits such as an email, a name or a plan. The traits are stored on the visitor profile. An email or phone sent as a trait stays a trait. It does not link devices, because a form field is not proof that the browser belongs to that person.
Linked. Your site calls alias with the email from this browser. The graph looks the email up in the registry. If nobody owns it, a person profile is created and the email is written into the registry as owned by that person. The visitor profile links to the person profile and copies in everything it collected in stages 1 and 2, purchases made before identification included. A backend identify or alias call that names the email also creates the person and claims the email, but it cannot find this browser. Only an alias call from the browser brings its history along. A backend track never creates a person. It fails for an identifier the site has never seen, so bind the identifier with identify or alias before you send a purchase from a webhook.
Converged. Every later appearance of that email reaches the same person profile. A new device that presents it joins the person. A backend call that names it lands on the person. A change made anywhere flows to every linked device.

The difference between stages 2 and 3 is the one most people miss:

Call	What it does	Links this browser
`identify` with an email trait	Stores the email as a trait of this visitor	No
`alias` with the email	Claims the email for this visitor’s person profile	Yes
A server `identify` or `alias` addressed by the email	Reaches the person who owns the email, or creates one. No browser is involved	No
A server `track` addressed by the email	Reaches the person who owns the email. Fails if nobody owns it yet	No

Cross-device merge

When the same identifier shows up on a second device, that device does not get a second person. It joins the first.

The phone creates the person profile. The laptop joins it by presenting the same email and receives the traits the phone contributed. A backend call that names the email lands on the same person, and its new trait reaches both devices. The purchase stays on the person profile.

The phone calls alias with the email. Nobody owns it, so a person profile is created and the phone’s visitor profile pushes its state into it.
The laptop calls alias with the same email. The registry already names an owner, so the laptop’s visitor profile links to that person. In the same step it receives the traits and consent the phone contributed, so the laptop now knows the city trait it never saw itself. The purchase stays on the person profile. Purchases flow up to the person and are read there. They are never copied back to a device.
Your backend sends a trait and names the person by the email, with no cookie involved. The registry routes the call to the same person profile.
The new trait merges into the person profile and reaches both devices. Reads on either device now return the person-level answer.

Devices never talk to each other. Every change goes up to the person profile, and the person profile sends the merged result back down to each linked device. A device that was offline when a change happened catches up the next time it contributes anything.

Not everything travels. Some data describes the person and converges. Some data describes one browser and stays there.

Data	Scope	Why
Identifiers, traits, custom properties	Person	They describe who the person is
Consent choices	Person	A choice made on one device holds on the others
Purchases	Person	Revenue belongs to the person, whichever device paid. Devices do not receive them back
Location and network of the connection	Device	A phone on mobile data says nothing about the laptop
Click ids and campaign captures	Device	The click landed in one browser, and the ad platform matches on it
App context	Device	Device-local. Has its own page.

What the graph stores for you

Besides the traits and events you send, the graph fills parts of each profile on its own.

Attribution. An app declares in its manifest which query parameters and cookies it needs, such as fbclid, gclid or the utm_* parameters. When a visitor lands on a page that carries one, the tag captures it and stores it on the visitor profile with the time it was seen and the window the app declared. The app reads it back later, for example to attach a click id to a purchase it sends to an ad platform. You write no code for this. See Manifest.
Consent. The consent call, or a consent app, saves the visitor’s choices in five categories (necessary, functional, analytics, marketing, salesOfData) plus a choice per app. Saves merge, so a banner can send one toggle at a time. The graph stores the current state and a history of changes on the visitor profile, and the current state converges on the person profile, so a choice made on the phone applies on the laptop.
Custom properties. Any trait that is not one of the eight standard traits (first_name, last_name, email, phone, country, state, city, postal_code) is kept as a custom property under the name you sent. Custom properties converge like standard traits. Sending null clears one.
App context. Apps can keep their own notes on a visitor profile, private to the app or shared with the other apps on the site. Context is device-local. It is described on its own page.

Rules the graph follows

An identifier has one owner, forever. The first person profile to claim an email, phone or custom id keeps it. Repeating alias is safe. An identifier that already belongs to someone else does not move.
A known identifier means joining, not conflict. A visitor profile that is not yet linked and presents an owned identifier joins the owner. This is the normal returning-visitor and second-device case.
Conflicts are set aside, not merged. A conflict happens only when a visitor profile already belongs to one person and presents an identifier that a different person owns. That identifier is left out of the person profile. The visitor keeps its person, and the other person keeps the identifier. A lookup by that identifier lists the person who tried to claim it as a related person.
Two person profiles are never merged. If a person claimed an email on one device and a phone number on another before the two were ever seen together, they hold two person profiles. Presenting both later picks one and leaves the other intact.
Priority is email, then phone, then custom id. When several identifiers arrive at once, the visitor joins the person of the highest-priority identifier that already has an owner. Only when none has an owner does the highest-priority one create the new person.
Shared devices are not special. The graph has no notion of a shared computer. If two people alias their own emails from the same browser, and the second email has no owner yet, it is added to the first person’s profile. If it already belongs to another person, it is set aside as a conflict.

How long data is kept

Data	Kept for
Events that are not purchases	Not stored in the graph. They reach your apps and stop there. Use EdgeLake to keep and query them.
Trait and consent history on a visitor profile	90 days. The current value of every trait always survives.
Current traits, identifiers and purchases on a person	Indefinitely
A visitor profile	About 400 days after that device’s last activity, the cookie lifetime
A visitor profile with no identifiers, traits or custom properties	About 30 days
Identifier registry entries	Permanently

When a visitor profile expires, the person profile keeps everything that device contributed.