Identity graph architecture: how to build a first-party identity graph

Think of three layers. Nodes are identifiers you have observed. Edges are claims that two nodes belong together. Clusters are the groups of nodes you treat as one person or one household. Most mistakes come from storing clusters without the edges that justify them.

Each edge should be a row you can audit. The record below is our recommended minimum, not a standard format. It shows a deterministic link between a login and a hashed email, created under consent, with a review date.

The hash in to_node is the UID2 documentation's own worked value for user@example.com, which we reproduced locally (UID2 normalisation and encoding). The openrtb_mm field copies the AdCOM code, so the same edge can explain a bid request later.

Deterministic matching links two identifiers only when they share an exact key, such as a login or a normalised email hash. Probabilistic matching scores the likelihood that two records belong to the same person from weaker signals, such as name, postcode, IP address and timing. Both are legitimate. They answer different questions and carry different risks.

The trade-off is public. LiveRamp's documentation says its graph favours "accuracy and precision over reach" and that probabilistic graphs "may produce higher reach" with more false positives (LiveRamp, RampID methodology). ID5 says it uses machine learning on consented signals to link identifiers to people and households (company claim) (ID5 technology page, accessed 9 November 2026).

The standard model for scoring record pairs dates from Fellegi and Sunter in 1969 (Journal of the American Statistical Association, 1969). For each field you estimate two probabilities. The m value is the chance the field agrees when the records are a true match. The u value is the chance it agrees by coincidence. Agreement adds log2(m/u) to the score, and disagreement adds log2((1-m)/(1-u)).

Pair A agrees on last name and postcode but not on IP, so it scores 6.57 + 5.49 - 1.32 = 10.74. Pair B shares only an IP range, so it scores -4.31 - 3.29 + 9.23 = 1.63. With a link threshold of 8, Pair A becomes an inferred edge with mm 5 and Pair B does not.

The m and u values here are illustrative; in production you estimate them from your own data. The open-source Splink library, maintained by the UK Ministry of Justice, implements this model and reached version 5.0.0 on 18 September 2026 (Splink on GitHub).

A first-party resolution pipeline runs the same eight steps whether you build it or buy it. Managed services such as AWS Entity Resolution offer rule-based, machine-learning and data-provider matching, and normalise inputs by default (AWS Entity Resolution user guide).

1. Ingest with consent attached. Each record arrives with its consent string or opt-out flag and its jurisdiction. Records without a usable permission go to a quarantine table, not into the graph.
2. Normalise. Trim spaces, lowercase emails, apply provider rules such as removing dots and plus suffixes in gmail.com addresses, and format phones in E.164 (UID2 normalisation rules).
3. Pseudonymise. Hash direct identifiers at the edge of your system and keep raw values in a separate, locked store. Under GDPR Article 4(5), pseudonymised data is still personal data if the extra information to re-identify it exists (GDPR, EUR-Lex).
4. Block. Generate candidate pairs only within blocks, such as the same hashed email or the same postcode and surname initial. Comparing every record with every other does not scale.
5. Score. Apply deterministic rules first, then the probabilistic model to the remaining candidates.
6. Cluster with guardrails. Build connected components from accepted edges, but cap component size and refuse merges that rely only on network signals. One shared IP can join thousands of devices.
7. Assign a stable person ID. Keep the ID of the largest prior cluster when clusters merge or split, so downstream systems do not see a new person every night.
8. Translate and publish. Generate partner IDs (UID2 tokens, EUID tokens, RampIDs, ID5 IDs) for the nodes allowed to carry them, and publish to activation, measurement and the clean room.

Identity graphs have two very different workloads. Building the graph is a batch job over every edge. Serving it is a lookup that must answer in milliseconds inside a bid or a page load. Most teams separate the two.

Keep the edge table as the source of truth. Clusters and serving keys are derived data, so you can rebuild them after a model change or a deletion. A retailer with a loyalty programme, for example, can rebuild its households nightly from login and address edges while its ad server reads a cache that is at most one day old.

Consent belongs on the edge, not on the profile. A person can agree to measurement on one site and refuse personalised ads on another. If you store a single flag per person, you will either over-use or under-use data.

The consent standards name the graph operations directly. The TCF Global Vendor List defines three features that vendors must disclose: "Match and combine data from other data sources", "Link different devices" and "Identify devices based on information transmitted automatically". They are Features 1, 2 and 3 in version 184 of 5 November 2026 (GVL v3). In the US, the GPP string carries state opt-outs instead. The field-level details are in GPP and TCF implementation for engineers.

Client-side tools enforce some of this for you. With Prebid's User ID module and a TCF consent module, nothing is written to cookies or local storage if consent for Purpose 1 is missing. A change in consent data refreshes every ID submodule (Prebid.org, User ID module). Prebid's activity controls can also block enrichEids, which adds IDs to requests, and transmitEids, which sends them to a bidder (Prebid.org, activity controls).

Opt-outs must flow the other way too. When a person opts out of UID2, publishers calling the token endpoints get an opt-out response, DSPs receive opt-outs through a webhook, and advertisers see them through the identity map endpoint (UID2 user opt-out). Your graph needs the same path. Mark the node, drop it from partner translation, and delete the edges that relied on it.

Your person ID stays internal. Partners see an ID they recognise, and each one is built differently. The table summarises what each provider documents; capability claims are the providers' own.

EID sources are those listed by Prebid's User ID module (Prebid.org). Scale claims differ in kind. LiveRamp says it maintains PII on 245 million individuals in the US (company claim) (LiveRamp). ID5 says its graph covers over 1.3 billion individuals and 770 million households (company claim) (ID5, accessed 9 November 2026). Neither figure is independently audited.

RampID has four types, shown by its first two letters: maintained (XY), derived (Xi), placeholder (Xc or Xm) and household (hY) (LiveRamp). Store the type with the node, because a derived RampID may later become a maintained one. LiveRamp's advice is to overwrite the old value and keep the data you attached to the device. The LiveRamp clean room profile covers its collaboration products.

When the IDs reach a bid request, they travel in user.eids. The example below shows one authenticated ID per provider. The inserter is the publisher, and the mm values follow AdCOM. IDs are placeholders.

One rule from the implementation guide matters most. An ID that arrived with mm 3, 4 or 5 keeps that match method when you forward it. This holds even if your own link came from a cookie sync (OpenRTB implementation guide, section 7.12). Cookie sync mechanics are covered in Prebid Server cookie sync, and the rest of the bid request in OpenRTB 2.6 explained.

Privacy controls are cheaper to design in than to bolt on. These are the ones we would not ship without.

• Separate keys from data. Raw emails and phones sit in a vault with its own access list. The graph only ever sees hashes. UID2 applies the same idea with secret salts kept in its core service (UID2 glossary).
• Purpose on every edge. Store allowed uses on each edge and check them at read time, not only at ingest.
• Expiry by design. Edges from cookies and device IDs expire. LiveRamp keeps devices for 90 days (LiveRamp); choose and document your own windows.
• Minimum audience size. Release audience counts and segments only above a threshold, the idea behind k-anonymity.
• Deletion that reaches derived data. A deletion removes edges, rebuilds the affected cluster, refreshes the serving store and stops partner translation.
• Access logs. Log who read which cluster and why. This is your evidence when a regulator or a partner asks.

Regulators are still refining the rules on hashing. The European Data Protection Board consulted on Guidelines 01/2025 on pseudonymisation until 14 March 2025 (EDPB). Treat a hashed email as personal data unless your counsel says otherwise.

Third-party cookies remain in Chrome, but the Privacy Sandbox APIs are on their way out. For the Topics API, the removal plan moved. The owners first planned removal in Chrome 150. In June 2026 they proposed a stub in Chrome 152 and a staged rollout of the removal. On 24 September 2026 they reported that removal had reached 1% of Chrome 153 Stable users with no breakage. They asked to reach 100% after 15 October 2026 (blink-dev, "Intent to Deprecate and Remove: Topics API"). We could not confirm full rollout on 9 November 2026.

Our page on identity after Privacy Sandbox still shows the earlier Chrome 150 target for the Topics API; treat that milestone as out of date until the page is revised. The practical lesson is the same either way. A first-party graph does not depend on a browser API, which is why the identity and privacy hub treats it as the base layer, with partner IDs on top.

1. Hashing before normalising. User@Example.com and user@example.com produce different hashes. Normalise first, every time.
2. Base64-encoding the hex string. UID2 expects Base64 of the 32 raw bytes, a 44-character string. Encoding the 64-character hex text gives an invalid value (UID2).
3. Treating IP as a deterministic key. Shared networks join strangers. Use IP only as one weighted field, and label the result mm 5.
4. Unbounded transitive closure. If A links to B and B links to C, you may not want A linked to C. Cap cluster size and review the largest clusters weekly.
5. Dropping the match method on the way out. Forward the incoming mm, as the OpenRTB guidance requires.
6. One consent flag per person. Consent varies by site, purpose and law; store it per edge.
7. Opt-outs that stop at the CRM. Push them to the serving store and to partner translation the same day.
8. Treating a new RampID as a new person. LiveRamp may re-key a device; overwrite the ID and keep the history.

The RTB architecture hub links the bidder and bid request pages that consume these IDs, and first-party data strategy for publishers covers how to collect the inputs.

1. IAB Tech Lab, OpenRTB 2.6 specification, sections 3.2.27 (EID) and 3.2.28 (UID) (accessed 9 November 2026). https://github.com/InteractiveAdvertisingBureau/openrtb2.x/blob/main/2.6.md
2. IAB Tech Lab, openrtb2.x releases, 2.6-202606 (11 June 2026). https://github.com/InteractiveAdvertisingBureau/openrtb2.x/releases
3. IAB Tech Lab, OpenRTB 2.x implementation guide, section 7.12 "ID Match Method Guidance" (accessed 9 November 2026). https://github.com/InteractiveAdvertisingBureau/openrtb2.x/blob/main/implementation.md
4. IAB Tech Lab, AdCOM 1.0, "List: ID Match Methods" and "List: Agent Types" (accessed 9 November 2026). https://github.com/InteractiveAdvertisingBureau/AdCOM/blob/main/AdCOM%20v1.0%20FINAL.md
5. Unified ID 2.0, "Normalization and encoding" (updated 5 November 2026). https://unifiedid.com/docs/getting-started/gs-normalization-encoding
6. Unified ID 2.0, "How the UID2 token is created" (updated 5 November 2026). https://unifiedid.com/docs/ref-info/ref-how-uid-is-created
7. Unified ID 2.0, "Glossary" (salt, salt bucket) (accessed 9 November 2026). https://unifiedid.com/docs/ref-info/glossary-uid
8. Unified ID 2.0, "User opt-out" (updated 5 November 2026). https://unifiedid.com/docs/getting-started/gs-opt-out
9. Unified ID 2.0, "Unified ID 2.0 overview" (updated 5 November 2026). https://unifiedid.com/docs/intro
10. European Unified ID, "EUID overview" (updated 2 November 2026). https://euid.eu/docs/intro