An identity graph is a data structure that maps all known identifiers for a single person — email addresses, phone numbers, device IDs, cookie IDs, loyalty numbers, and CRM records — to determine which records belong to the same individual. Each identifier is a node, each confirmed link between two identifiers is an edge, and each connected cluster of nodes is one person. The graph decides which identifiers match; the unified customer profile is the readable result built on top of it.
The identity graph is the data structure that identity resolution builds and maintains — resolution is the process, the graph is what it produces. In customer data platforms, the identity graph is the engine behind customer data unification and the basis for a true customer 360 view, because it is what connects anonymous browsing to a known customer across channels, devices, and touchpoints.
Identity Graph Example: One Customer, Five Identifiers
A worked example shows how a graph turns scattered identifiers into one person. Over a month, a single customer generates five identifiers in five systems:
| # | Event | Identifier captured | Link created | Match type |
|---|---|---|---|---|
| 1 | Anonymous visit on a phone | Cookie c-81f2 | None yet — a single orphan node | — |
| 2 | Logs in on the same phone | Email maria@example.com | Cookie c-81f2 ↔ email | Deterministic (authenticated login) |
| 3 | Installs the app and signs in | Mobile ad ID MAID-7k3 | MAID ↔ email | Deterministic (authenticated login) |
| 4 | Joins the loyalty program in store | Loyalty ID L-55190 + phone | Loyalty ID ↔ email, phone ↔ loyalty ID | Deterministic (form submission) |
| 5 | Browses on a laptop at home, not logged in | Cookie c-a0c7 | Cookie c-a0c7 ↔ cookie c-81f2 | Probabilistic (same home IP, overlapping sessions), confidence 0.82 |
After event 4, the graph holds one cluster of five identifiers anchored by the email, all joined by high-confidence deterministic edges. Event 5 adds a probabilistic edge: the laptop cookie joins the cluster only if the 0.82 score clears the threshold the business set for that use case. Ad targeting might accept it; a consent-sensitive service email should not. That is why good graphs store the confidence and evidence on every edge, not just the fact of the link.
How Identity Graphs Work
An identity graph continuously ingests identifiers from multiple sources and evaluates whether they belong to an existing person or represent a new individual.
Identifier collection is the starting point. Every customer interaction generates identifiers: a website visit produces a cookie ID and potentially a device fingerprint, a purchase generates a transaction ID linked to an email address, a mobile app session creates a device ID, and a support call logs a phone number. The identity graph collects these identifiers from every available source and stores them as nodes in a graph structure.
Link creation connects identifiers that belong to the same person. When a customer logs into a website from their phone, the identity graph can link the mobile device ID to the email address used for authentication. When that same customer later makes a purchase using the same email, the transaction data is linked to the existing profile. Over time, the graph accumulates a rich web of connections between identifiers, building a comprehensive view of each individual.
Profile unification merges the data associated with linked identifiers into a single customer profile. Once the graph determines that cookie ABC, email user@example.com, and device ID XYZ all represent the same person, all behavioral data — browsing history, purchase records, email engagement, app usage — is consolidated into one unified profile.
Graph maintenance keeps the identity graph accurate over time. This includes handling identifier changes (new email addresses, new devices), resolving conflicts (two profiles that were incorrectly merged), managing identifier expiration (cookies that expire, devices that are sold), and incorporating new data sources as they become available.
Deterministic, Probabilistic, and Transitive Matching
Identity graphs use three approaches to determine whether different identifiers belong to the same person.
Deterministic matching links identifiers based on exact, known connections. When a customer logs in with email user@example.com on both their laptop and phone, the graph can definitively link those device IDs to that email address. Deterministic matches are high-confidence connections based on authenticated events — logins, form submissions, purchases with verified contact information. The accuracy rate approaches 100% for person-level credentials, but deterministic matching alone cannot connect anonymous identifiers to known profiles until an authentication event occurs.
Probabilistic matching uses statistical models and machine learning to infer connections between identifiers when no definitive link exists. These models analyze signals like IP addresses, browser configurations, location patterns, behavioral similarities, and timing correlations to estimate the probability that two identifiers belong to the same person. For example, if a laptop and a phone consistently access the same accounts from the same IP address at the same times of day, a probabilistic model might assign a high confidence score to the link — even without a shared login event.
Transitive matching connects identifiers through chains of existing links rather than direct evidence. If the graph has already linked identifier A to B with high confidence, and separately linked B to C, it can infer that A and C represent the same person — even with no direct match between A and C. Transitive matching is what turns a set of pairwise matches into a fully connected profile, but it also concentrates risk: a single weak link in the chain can merge unrelated people into one incorrect profile.
Most production identity graphs combine all three approaches. Deterministic matches form the high-confidence backbone of the graph, probabilistic matching extends reach by connecting identifiers that lack direct authenticated links, and transitive matching stitches those matches into larger connected clusters. The key is maintaining clear confidence scores at each step so downstream systems can make appropriate decisions based on match quality.
Types of Identity Graphs: First-Party vs Third-Party
Identity graphs differ on two axes: who builds and owns the graph, and what entity each cluster represents. The ownership axis matters most when choosing one, because it decides who controls the matching logic and where the PII lives.
A first-party identity graph is built from a company’s own customer records — logins, purchases, loyalty sign-ups — inside its own infrastructure or its CDP. A third-party identity graph is built and maintained by an external data provider that aggregates identifiers across many companies and licenses matches back to brands. Examples include LiveRamp’s RampID, Experian’s digital graph (which absorbed the cross-device company Tapad), and TransUnion’s graph built on its Neustar acquisition. Third-party graphs extend reach beyond a company’s own customers, mainly for advertising, but the brand owns neither the matching logic nor the underlying data.
| Dimension | First-party identity graph | Third-party identity graph |
|---|---|---|
| Built from | The company’s own authenticated customer data | Identifiers aggregated across many companies and data sources |
| Who owns the logic and data | The company (or its CDP, under its control) | The data provider; the brand licenses access |
| Main strength | Accuracy, ownership, durability | Reach to people the brand has never met |
| Typical use | Personalization, service, analytics, AI agents | Audience onboarding, ad targeting, measurement |
| Main risk | Limited to known customers | Opaque matching, licensing cost, privacy exposure |
Most enterprises run both: the first-party graph owns the customer profile, and a third-party graph or a data onboarding service extends it for paid media.
On the entity axis, the default graph clusters identifiers into people, but the same structure models households (people sharing an address or streaming account, used for suppression and household-level measurement) and B2B accounts (contacts mapped to the companies they work for, used for account-based marketing).
First-party identity graphs built on consented, authenticated data are more durable, more accurate, and more compliant than graphs relying on cross-site tracking. That holds even though Chrome kept third-party cookies — Google confirmed in April 2025 that it would maintain its current approach — because Safari and Firefox block them and privacy regulations keep tightening. Organizations that encourage authenticated interactions — account creation, loyalty program enrollment, app downloads — generate the deterministic signals that make the best first-party data graphs. Collecting zero-party data through preference centers and surveys adds voluntarily shared attributes.
Protecting personally identifiable information (PII) within identity graphs is critical. Every identifier linkage potentially creates a more complete profile of an individual, making identity graphs high-value targets for data breaches and subject to strict regulatory requirements under GDPR, CCPA, and other privacy frameworks. For a practical walkthrough, see how to implement identity resolution and privacy compliance with an identity graph in a CDP.
How CDPs Build Identity Graphs
Customer data platforms use identity graphs as a core architectural component, and the sophistication of a CDP’s identity graph directly determines the quality of its customer profiles.
When a customer clicks an email link and lands on the website, a CDP with real-time graph updates links that email engagement to the subsequent browsing session immediately, instead of waiting for the next batch cycle. Cross-channel stitching applies the same logic across marketing channels, customer service systems, point-of-sale terminals, mobile apps, and web properties — a CDP’s identity graph might connect a customer’s in-store loyalty card, online account, mobile app profile, and email address into a single view, so personalization stays consistent regardless of channel.
Conflict resolution is the harder problem: the graph sometimes suggests two distinct profiles should merge, or that an already-merged profile should split. Two family members sharing a device is the classic failure case, which is why advanced CDPs use machine learning to score merge confidence and flag ambiguous matches for review rather than merging automatically. All of this has to hold up at scale — enterprise identity graphs can contain billions of identifier nodes and trillions of edges, and real-time personalization at that scale means serving precomputed unified profiles rather than traversing the full graph on every request.
Identity Graphs in the AI Era
As AI-driven personalization and agentic marketing become central to customer engagement, identity graphs take on new importance. AI agents need accurate, real-time identity graphs to understand who they are interacting with, what that person has done across all channels, and how to personalize the next interaction.
An incomplete or inaccurate identity graph means the AI agent sees a fragmented view of the customer — leading to irrelevant recommendations, redundant outreach, or missed opportunities. The quality of the identity graph directly constrains the quality of AI-driven customer experiences.
For CDPs that maintain identity graphs within the same platform as their activation and AI decisioning layers, the graph can be queried and updated in real time as AI agents interact with customers — creating the closed feedback loops that enable continuous learning and optimization. Warehouse-native architectures trade some of this immediacy for governance and data residency; CDC and streaming pipelines narrow, but do not erase, the latency gap with same-platform graphs.
Common Identity Graph Failure Modes
Identity graphs fail quietly. A bad merge throws no error — it produces a profile that looks complete and is wrong, and the damage surfaces later as a message sent to the wrong person, a suppression that did not hold, or a deletion request that missed half the records. Five failure modes recur often enough to design against from the start.
Over-merged identities from transitive chains. One shared identifier — a corporate office’s NAT’d IP address, a shared store terminal, a household streaming login — becomes a hub node that transitive matching chains through, collapsing several real people into one profile. Every individual step is valid, so the graph reports high confidence while the profile holds three people’s purchase history and contradictory preferences. Fix: cap chain depth, refuse to traverse identifiers classified as shareable, and require a deterministic anchor before committing a merge that grows a cluster past a size threshold.
Stale edges that never expire. Identifiers change hands. Phone numbers get reassigned, devices are resold, cookies expire, work email addresses leave with the employee. A graph that only adds edges and never retires them accumulates links that were true once, and each stale edge keeps pulling someone else’s behavior into the profile. Fix: stamp every edge with a timestamp and an evidence type, decay confidence on edges that go unconfirmed, and re-verify at the next authenticated event instead of treating the original match as permanent.
Consent modeled downstream instead of in the graph. When consent is enforced only in the activation layer, the graph merges first and checks permission afterward — data collected under one consent state gets unified into a profile governed by another, and a revocation shuts off a channel without unwinding the linkage that produced it. In a regulated industry, the order of those two operations is what an auditor asks to see. Fix: carry consent state and jurisdiction as attributes on the identifier node, and make them a condition of the merge rather than a filter applied after it.
Fragmentation from unnormalized identifiers. The opposite failure. The same person exists three times because the email arrived as USER@Example.com, user@example.com, and user+shop@example.com, or because phone numbers carry inconsistent country codes and formatting. These are data quality defects that no matching algorithm can recover from, and they inflate profile counts while starving each fragment of history. Fix: canonicalize values at ingestion (case-folding, trimming, one canonical phone format), hash the canonical join keys before matching runs, and treat plus-addressing as a policy decision recorded on the profile rather than a separate identity.
No audit trail behind merge decisions. A graph that stores only its current state cannot explain why two records are joined, which makes an incorrect merge nearly impossible to unwind and a subject access request impossible to answer with confidence. Data lineage for identity is not a reporting nicety — it is what lets a team reverse a bad match without rebuilding the cluster by hand. Fix: log every merge and split with the rule, the evidence, and the timestamp that triggered it, and keep that history queryable for as long as the profile exists.
FAQ
What is the difference between an identity graph and identity resolution?
An identity graph is the data structure; identity resolution is the process that builds and maintains it. The graph is the map of identifiers and their links that represents each customer. Identity resolution covers the matching algorithms (deterministic and probabilistic), the rules for merging and splitting profiles, and the ongoing upkeep of identifier links. Think of the graph as the product and identity resolution as the process that creates and updates it.
What is the difference between deterministic and probabilistic identity matching?
Deterministic matching links identifiers through an exact, verified connection; probabilistic matching infers a link from statistical signals. A shared login email is deterministic — near-certain, but it needs an authenticated event. Probabilistic models score signals like IP address, device characteristics, and behavior, extending reach at the cost of uncertainty. Most graphs use deterministic links as the backbone and probabilistic links, filtered by a confidence threshold, to extend coverage.
How do CDPs build and maintain identity graphs?
CDPs build identity graphs continuously: every incoming identifier is matched against the existing graph and either joins a profile or starts a new one. Sources include websites, apps, CRM, email, and point-of-sale systems. The CDP links matched identifiers, merges their data into unified profiles, and flags ambiguous matches. Maintenance runs alongside — deduplication, splitting bad merges, and expiring stale identifiers — so the graph stays accurate in real time.
Who are the main third-party identity graph providers?
The best-known third-party identity graphs come from data and adtech companies such as LiveRamp (RampID), Experian (including Tapad), TransUnion (including Neustar), and Epsilon. They aggregate identifiers across many companies and license matches to brands, mostly for audience onboarding, ad targeting, and measurement. They complement rather than replace a first-party graph: the brand’s own graph owns the customer profile, while a third-party graph extends reach for paid media.
Related Terms
- Entity Resolution — The broader matching discipline that identity graphs apply specifically to customer identifiers
- Golden Record — The single authoritative profile created when an identity graph merges all matched records
- Data Governance — Policies and controls that ensure identity graph data is accurate, compliant, and properly managed
- Real-Time CDP — CDP architecture that updates identity graphs in milliseconds as new events arrive
- Consent Management — Systems that track user consent, determining which identifiers can be linked within the graph
This article is also available in: アイデンティティグラフとは？CDPにおける仕組みと構築方法