The identity graph has become the centerpiece of every enterprise CDP pitch. Connect your emails, device IDs, cookies, and phone numbers into a unified data structure. Resolve anonymous visitors across devices. Build a single view of every customer. The technology is real, the use cases are legitimate, and the marketing around it is wildly disproportionate to what most teams actually need.
One popular CDP blog dedicates 14 minutes to explaining how to build one in five steps. Every CDP vendor treats it as table stakes. But an identity graph is a specific piece of infrastructure designed for a specific problem: linking records that have no shared identifier. If your customers log in and give you an email address, you don't have that problem. You have a simpler one.
What an identity graph is and how it connects customer identifiers
An identity graph is a data structure that maps multiple customer identifiers to a single profile. Think of it as a network where each node is an identifier (an email, a device ID, a phone number, a browser cookie) and each edge is a relationship ("these two identifiers belong to the same person").
A customer visits your website anonymously on their phone. The graph creates a node for their mobile device ID. Later, they open your app on a laptop and browse without logging in. That's a second node: a desktop cookie. When they finally log in with their email address, a third node links to the first two. The graph now connects three identifiers into one customer profile.
This is different from a standard database table. A relational database stores rows: one row per customer, with columns for email, phone, and account ID. A graph database built for this purpose stores relationships between identifiers. It answers the question "which identifiers belong to the same person?" rather than "what do we know about this customer?"
The graph structure matters because identifiers multiply fast. A single customer might generate 5-10 anonymous identifiers before logging in: mobile cookies, desktop cookies, ad click IDs, app install IDs. The graph can hold billions of these nodes and resolve lookups in milliseconds. Flat database tables can't model these many-to-one relationships efficiently.
How identity graphs work: nodes, edges, and resolution algorithms
Under the hood, the graph runs on two linking strategies that determine its accuracy and scope.
Deterministic linking creates edges between identifiers that share an exact match. Same email in two systems? Same person. Same phone number across three devices? Same person. These links are 99%+ accurate because the match is exact.
Probabilistic linking creates edges based on statistical inference. Two sessions from the same IP range, with the same browser version, visiting the same pages within 20 minutes? The model assigns a confidence score (e.g., "82% likely the same person") and creates an edge if the score exceeds a threshold. These links are 70-85% accurate, and that gap creates real problems. (For a deeper comparison, see our guide on deterministic vs. probabilistic matching.)
The resolution pipeline runs in stages:
Identifier collection. Every touchpoint (website, mobile app, POS system, call center) feeds identifiers into the graph.
Edge creation. Deterministic matches fire immediately. Probabilistic models score and link remaining pairs.
Component resolution. A graph algorithm (connected components) groups all linked identifiers into clusters. Each cluster gets a single virtual ID.
Profile delivery. Downstream tools (CRM, marketing, analytics) receive the resolved virtual ID so they can join records to the same customer.
Continuous maintenance. New identifiers arrive, old edges expire, consent changes propagate, and false links get corrected.
Each stage requires engineering resources. This infrastructure needs a storage layer (typically a graph database or warehouse tables), compute for resolution algorithms, and a data engineer to maintain confidence thresholds and handle edge cases like household deduplication.
When you actually need an identity graph: cross-device tracking, anonymous stitching, massive scale
These graphs solve three problems that other approaches cannot.
Cross-device anonymous stitching. A retailer with 10 million monthly visitors and a 2% login rate generates 9.8 million anonymous sessions per month. Those sessions happen across phones, tablets, laptops, and in-store kiosks. Without this infrastructure, each session is an island. The graph links pre-login browsing to post-login purchases, enabling attribution and ad retargeting that actually works.
Graph-powered marketing at scale. Ad platforms (Meta, Google) use these graphs to match your customer list against their user base. When you upload 100,000 emails for a lookalike audience, the ad platform's graph matches those emails to device IDs, cookie pools, and account logins. The more identifiers it can link, the higher your audience match rate. This only matters at volumes where a few percentage points of match rate translate to meaningful ad spend efficiency.
Enterprise deduplication. A company with 50 million customer records across 30 systems, accumulated over 20 years through acquisitions, has duplicate records that can't be resolved by a simple email match. john.smith@gmail.com and j.smith@gmail.com might be the same person or two different people. Probabilistic models trained on historical merge data can resolve these ambiguities at scale.
These are genuine use cases. They all share a common trait: the records being matched lack a reliable shared identifier. The graph exists to bridge that gap.
When you don't need an identity graph and what to use instead
Here is the test: look at your core tools (CRM, billing, support, email). Does every customer record have an email address? If yes, your identity problem is already solved. The missing piece isn't a graph. It's data connectivity.
A 40-person SaaS company doesn't track anonymous visitors across devices. Their customers sign up, log in, and provide an email. That email exists in Stripe, in HubSpot, in Intercom, and in Mailchimp. The customer graph that CDPs want to sell you is a web of edges connecting identifiers that don't share a key. Your identifiers already share a key. The graph is redundant.
The infrastructure cost of building a customer graph you don't need is significant:
Component | What it costs | What it does |
|---|---|---|
Graph database or warehouse | $500-$5,000/month | Stores identifier nodes and relationship edges |
Resolution algorithms | $50,000-$150,000/year via CDP | Links identifiers using probabilistic models |
Data engineer | $150,000+/year | Tunes thresholds, handles false merges, maintains pipeline |
For a team where every customer has a known email, the alternative is connecting tools directly and matching on that email. The outcome is the same: every tool agrees on who the customer is. The cost is not.
When customers already have a shared identifier across your tools, the identity resolution problem reduces to a data sync problem. Not "which identifiers belong together?" but "why don't these tools share data about the same person?" That's a connectivity problem, not an identity problem.
How to unify customer data across tools without building an identity graph
The graph-based approach centralizes identifiers in a dedicated database, resolves them into profiles, then pushes those profiles outward to every tool. For teams with known customers, the reverse approach works better: connect the tools directly and let the shared identifier do the linking.
With Oneprofile, this looks like: connect Stripe and HubSpot, pick email as the matching key, map the fields you want to sync (subscription status, plan name, MRR), and data flows. Within 15 minutes, your CRM shows current billing data for every contact. No graph database, no resolution algorithms, no warehouse compute.
Property-level change tracking means each field syncs independently. When a customer upgrades in Stripe, only plan_name and subscription_status update in HubSpot. The lifecycle stage your sales rep set manually stays untouched. This precision is what enterprise graph platforms promise at the profile level. Oneprofile delivers it at the field level, using the matching key your tools already store.
For teams that do outgrow key-based matching (high anonymous traffic, consumer e-commerce with millions of pre-login sessions, cross-device ad attribution), graph-based resolution becomes the right tool. But that threshold is higher than CDP vendors suggest. If your customer count is under 100,000, your login rate is above 50%, and your tools share an email for every contact, you're not there yet.
Start by connecting the tools. If you eventually need graph-based resolution, you'll know: the matching key will stop being enough. Until then, the email address does the work that graph databases, probabilistic algorithms, and six-figure CDP contracts are designed to replicate.
What is an identity graph?
An identity graph is a data structure that links customer identifiers (emails, device IDs, phone numbers, cookies) into a single profile. It's used to recognize the same person across devices, channels, and sessions.
What is an identity graph database?
An identity graph database stores identifiers as nodes and their relationships as edges. It's optimized for fast lookups and profile stitching, unlike relational databases that store flat rows.
Do I need an identity graph for marketing?
Only if you track millions of anonymous visitors across devices. If your customers log in and share an email, direct tool-to-tool sync on that email gives you unified data without graph infrastructure.
How is an identity graph different from a CRM?
A CRM stores contact records. An identity graph links identifiers across systems to resolve who each contact is. For small teams, syncing tools on a shared key like email achieves the same outcome.
Can I build an identity graph without a warehouse?
Enterprise identity graphs require a warehouse for storage and compute. But if your records share a common identifier, you can skip the graph entirely and sync tools directly on that key.