Identity resolution is the process of connecting every identifier a person or company leaves across your systems into one unified profile. It takes emails, phone numbers, device IDs, cookies, and account records, then decides which of them belong to the same real-world identity.
You will also hear it called ID resolution or identity matching. The names all point at the same job: recognizing that three fragmented records are one customer. That link then has to stay alive as new data arrives.
I have spent years inside B2B databases where the same buyer existed five times under five spellings. Honestly, most “data problems” I get called in for turn out to be identity problems. So this guide covers how the matching works, how B2B differs from B2C, and what vendors hide behind match rates. It ends with the mistakes that quietly poison databases.
What Does Identity Resolution Actually Mean?
Identity resolution means deciding which records, events, and identifiers refer to the same person or company, then maintaining that link over time. Salesforce defines it as connecting identifiers across devices and touchpoints into one unified customer profile. That framing matches what I see in practice.
The confusion starts because every system sees a different slice of the same human. Your CRM sees a contact with a work email. The email platform sees a subscriber. Meanwhile, your website sees an anonymous cookie that filled out a form once. Without a matching layer, those are three strangers.
It helps to separate the technique from the discipline. The technique underneath is data matching, also called record linkage in academic work. It compares two records and scores how likely they describe the same thing. Identity resolution is the applied discipline built on top. It unifies a person’s or company’s identity across systems, devices, and channels, and keeps that identity stable as data changes.
In practice, the identifiers you resolve fall into a few families:
- Personal identifiers. Names, email addresses, phone numbers, and postal addresses.
- Digital identifiers. Cookies, mobile ad IDs, device fingerprints, and IP addresses.
- Behavioral identifiers. Logins, form fills, app sessions, and purchase events tied to an account.
- Business identifiers. Company domains, legal names, registration numbers, and corporate hierarchies.
📌 Example: In 2022 I audited a database where one buyer named Anna existed as three contacts: a work email, a personal Gmail, and a webinar signup with a typo in her surname. Marketing counted three leads. Sales counted one relationship. Identity resolution is the discipline that makes both teams see the same person.
Where Did Identity Resolution Come From?
Identity resolution grew out of record linkage, a statistical field that started in public health in 1946. Knowing that history explains why the matching math is older and sturdier than the marketing term suggests.
Halbert L. Dunn coined the phrase “record linkage” in 1946. His article imagined connecting each person’s scattered health records into one “book of life.” Then Howard Newcombe laid the probabilistic foundations in 1959, and Ivan Fellegi and Alan Sunter formalized the theory in 1969. Their decision model still underpins modern matching engines, as the record linkage entry on Wikipedia documents.
Governments ran with it first. The U.S. Census Bureau maintains a whole research program on linking records across surveys and administrative files. Businesses arrived decades later with a different problem: recognizing one shopper across a laptop, a phone, and a store.
That commercial wave, roughly the 2010s, is when “identity resolution” became the umbrella term. Cross-device advertising created identity graph vendors, and customer data platforms brought the matching in-house. Same 1969 math, new billing model.
How Does Identity Resolution Work?
Identity resolution works in four steps: collect identifiers, standardize them, match records, and assign a persistent ID. Each step sounds simple and each one hides most of the failure modes.
Step one: collect. Pull identifiers from every source that touches a customer: CRM exports, web analytics, email engagement, support tickets, billing. Coverage matters here, because an identifier you never collected can never match.
Step two: standardize. This is unglamorous data quality work. Lowercase the emails, normalize phone formats, expand “St.” to “Street,” strip legal suffixes from company names. Skipping this step is why so many matching projects underperform.
Step three: match. Compare records using deterministic rules, probabilistic scoring, or both. The same engine, pointed at one system instead of many, powers deduplication. Identity resolution just runs that comparison across every system at once.
Step four: persist. Assign the matched cluster a stable internal ID that survives email changes and cookie resets. Every future record either joins an existing identity or starts a new one.
The real design decision sits in step three: deterministic versus probabilistic matching. mParticle’s engineering-oriented overview is a good deeper read on how platforms implement both.
| Dimension | Deterministic Matching | Probabilistic Matching |
|---|---|---|
| How it links records | Exact joins on shared identifiers like email or login | Statistical scores across many partial signals |
| Precision | Very high; links are near-certain | Tunable; depends on the threshold you set |
| Coverage | Lower; needs the same identifier on both sides | Higher; can link records with no shared key |
| Data required | Authenticated events or clean shared keys | Names, locations, devices, behavior patterns |
| Typical use | CRM merges, logged-in users, subscriptions | Cross-device stitching, cold-file matching |
| Failure mode | Misses matches that really exist | Merges two different people by mistake |
My default advice: start deterministic, then add probabilistic rules only where you can measure their error rate. A missed match costs you a duplicate. By contrast, a wrong merge costs you a customer’s trust, and sometimes a compliance incident.
What Is an Identity Graph?
An identity graph is the database that stores every identifier as a node and every proven connection between identifiers as an edge. When people say a vendor “has an identity graph,” they mean a pre-built network of these links covering millions of people or companies.
Picture one customer as a small cluster. Her work email connects to her CRM record. That record connects to a phone number, which connects to a support ticket, which connects to a device ID from your app. The persistent ID sits at the center and names the whole cluster.
Graphs beat flat tables for this job for one reason: identities change shape. People switch emails, replace phones, and move companies. In a graph you retire one edge without touching the rest of the cluster. A flat merged record, by contrast, turns every bad link into archaeology.
💡 Pro Tip: Store the evidence for every edge: which rule created it, at what confidence, on what date. The first time a bad merge reaches production, that provenance turns a three-week unmerge project into a one-hour fix. I learned this the expensive way.
How Is B2B Identity Resolution Different From B2C?
B2C identity resolution unifies one person across devices and channels, while B2B adds a second job: tying each person to a company and a role. That extra layer changes almost everything about how you match.
In consumer marketing, the atomic unit is the individual, sometimes the household. B2B identity is a triangle: the person, the account, and the role connecting them. Maria the marketing director at one company and Maria the consultant at her next employer are the same human but a completely different sales context.
Company matching brings its own mess. “IBM,” “International Business Machines,” and “IBM Deutschland GmbH” must resolve to the right node in a corporate hierarchy, usually with help from firmographic data like domain, industry, and headcount. Senzing’s entity resolution overview shows how deep that name-matching rabbit hole goes.
| Aspect | B2C Identity Resolution | B2B Identity Resolution |
|---|---|---|
| Unit of identity | Person or household | Person plus account plus role |
| Key identifiers | Personal email, phone, device IDs, loyalty ID | Work email, company domain, firmographics |
| Hardest problem | Cross-device and cross-channel stitching | Person-to-account mapping and job changes |
| What breaks identities | Cookie resets, new devices | Job changes, rebrands, mergers |
| Typical payoff | Personalization, ad frequency control | Account rollups, routing, ABM targeting |
The job-change problem deserves special respect in B2B. A work email dies the day someone resigns, taking your cleanest deterministic key with it. Any B2B identity program that ignores employment changes is building on sand.
What Does Identity Resolution Power?
Identity resolution powers five practical things: a single customer view, personalization, attribution, suppression, and account rollups. None of them work well on fragmented records, which is why this quiet plumbing layer matters so much.
- Single customer view. One profile showing everything a person did across web, email, sales, and support. This is the foundation the other four stand on.
- Personalization. Recognizing a returning visitor as an existing customer, so you stop showing new-customer offers to people who already pay you.
- Attribution. Connecting the ad click on a phone to the purchase on a laptop. Without resolved identities, every device looks like a separate person and your channel math lies.
- Suppression and compliance. Honoring an opt-out everywhere it applies, and answering a data access request with the person’s full footprint instead of one system’s slice.
- Account rollups. The B2B special: aggregating every contact, deal, and activity under the right company, so account owners see the whole buying group.
Notice that suppression is on the list. Teams usually buy identity resolution for personalization and attribution, then discover the compliance value later. If you cannot find every record belonging to one person, you cannot delete them on request either.
Reporting sanity is the quiet sixth benefit. Board metrics like customer count, churn, and pipeline coverage all assume each customer is counted once. Resolve identities properly and those numbers firm up. Skip it, and every dashboard argument in the building is secretly an identity argument.
What Happens to Identity Resolution Without Third-Party Cookies?
Identity resolution is shifting from rented third-party identifiers to owned first-party ones, even though the cookie’s death keeps getting postponed. The honest version of this story has three parts.
First, the facts. Safari has blocked all third-party cookies by default since March 2020, and Firefox blocks known trackers. Chrome spent years promising deprecation, then reversed course: in April 2025 Google announced it would keep offering third-party cookies in Chrome and drop the planned standalone prompt.
Second, the practical read. Cookies survived, but as an unreliable identifier: blocked in two major browsers, restricted in the biggest one’s private mode, and legally constrained by consent rules. Meanwhile first-party identifiers, meaning logins, email signups, and purchase accounts, keep working everywhere. That is why every serious identity strategy now starts with owned data.
Third, the clean room honesty. Data clean rooms let two companies match their customer lists inside a neutral environment without exchanging raw personal data. They are genuinely useful for large advertisers collaborating with retailers or publishers. For a typical mid-market B2B team, though, they are overkill; fixing your own CRM matching delivers far more value per hour invested.
🔍 Field Note: In 2024 a client asked me to scope a clean room project because "cookies are dying." Their own database still had thousands of duplicate accounts and no survivorship rules. We spent the budget on internal matching instead, and their campaign audiences grew 22 percent without touching a single new tool.
Identity Resolution vs CDP vs MDM: What Is the Difference?
The short version: identity resolution is the matching layer, a CDP is the activation layer, and master data management is the governance layer. Vendors blur these lines constantly, so here is the clean separation.
| System | Core Job | Main Output |
|---|---|---|
| Identity resolution | Decide which records belong to the same person or company | Persistent IDs and an identity graph |
| CDP (customer data platform) | Collect behavioral data and activate segments across channels | Audiences pushed to email, ads, and web tools |
| MDM (master data management) | Govern one certified golden record for core business entities | Master records with stewardship and audit trails |
The overlap causes the confusion. Every CDP embeds some identity resolution, because it cannot build profiles without matching. MDM hubs include match-and-merge too, wrapped in data governance process: stewards, approval workflows, and audit requirements.
The difference is intent. MDM asks “what is the one certified truth about this customer?” and moves carefully. A CDP asks “which audience does this profile join right now?” and moves fast. Identity resolution answers the question both of them depend on: “are these records the same entity at all?”
My rule for choosing: if your pain is marketing activation, look at CDPs. When conflicting records feed finance and operations, look at MDM. And if duplicates sit everywhere, fix the matching layer first, because both of the others inherit its mistakes.
What Do Vendor Match Rates Actually Mean?
A vendor match rate tells you how many records got linked, not how many got linked correctly. Once you internalize that sentence, vendor evaluations get much easier.
The classic trick is the denominator. “We matched 95 percent” often means 95 percent of records that already had a clean email, which might be half your file. Measured against your full database, the real coverage could be 50 percent. Always ask: matched against what?
The second trick is match level. A record matched to a household, a company, or a “modeled” audience segment counts toward the headline number. Person-level, deterministic matches are a much smaller slice. Ask for the breakdown by confidence tier, and ask how the vendor verified accuracy, not just coverage.
Precision and recall pull against each other here. A vendor can inflate match rate by loosening thresholds, which quietly raises false merges. In 2024 I tested a provider claiming 95 percent match rates on a file of 18,000 B2B contacts. Person-level verified matches came out at 61 percent. The rest were company-level guesses, some of them wrong in embarrassing ways.
🧠 Worth Remembering: Three questions expose most match-rate theater. What denominator was used? Which share is person-level versus household or company-level? And how was accuracy audited, by whom? A vendor with good answers will have them ready.
How Do You Implement Identity Resolution? First Steps
Start with deterministic matching on your own first-party data, and add probabilistic rules only where you can measure precision. You do not need a graph database on day one. A disciplined sequence looks like this:
- Inventory your identifiers. List every system that stores customer data and which keys it holds: emails, phones, domains, account IDs.
- Pick match keys and standardize them. Normalize emails, phones, and company names before any comparison runs.
- Run a deterministic pass. Exact email and domain joins first. Review a random sample of 100 matches by hand before trusting the output.
- Define survivorship rules. When two records merge, decide which field wins: most recent, most complete, or most trusted source.
- Assign persistent IDs. Stamp every resolved cluster with an internal ID that never gets recycled.
- Monitor continuously. Track duplicate rate, merge volume, and unmerge requests monthly. Rising unmerges mean your thresholds drifted too loose.
One preparation step raises every number downstream: fill the gaps first. A record missing its email or company domain cannot match on it. Teams often run B2B data enrichment with a provider such as CUFinder to complete emails, domains, and firmographic fields before matching runs. That reliably lifts match coverage, but keep expectations honest: no enrichment vendor can rescue match logic nobody has reviewed.
📌 Checkpoint: After your first deterministic pass, measure the duplicate rate on a sample before and after. If duplicates dropped by less than a third, your standardization step is leaking. Fix formats before touching probabilistic rules, not after.
What Are the Most Common Identity Resolution Mistakes?
The most common mistakes are over-merging on loose thresholds, skipping survivorship rules, and ignoring how fast identities go stale. I have cleaned up after all three, and they follow a predictable script.
Over-merging is the scariest one. In 2023 a team I supported loosened a fuzzy-name threshold to boost their match rate. The system merged two different buyers with the same surname at the same enterprise, and a renewal quote went to the wrong person. Untangling 4,000 suspect merges took three weeks, mostly because nobody had stored why each link was created.
Missing survivorship rules cause quieter damage. Two records merge, and the system keeps the older title and the deader phone number. The merge technically succeeded while making the data worse. Decide field-by-field which source wins before you merge anything at scale.
Ignoring data decay is the slow killer. Identities are perishable: people change jobs, emails die, companies rebrand and merge. An identity graph with no expiry logic treats a link proven in 2021 as equally true today. Build edge aging into the design, and re-verify the identifiers your revenue depends on.
A fourth mistake deserves a mention: treating identity resolution as a one-time project. The matching backlog you clear this quarter rebuilds itself from new signups, imports, and integrations. Budget for it like a process, not an event.
How Do You Measure Identity Resolution Success?
Measure identity resolution with four numbers: duplicate rate, match coverage, precision on a labeled sample, and unmerge rate. Together they tell you whether the matching layer is helping weeks before revenue metrics can.
Duplicate rate is the bluntest one. Sample 200 random contacts quarterly and count how many have a hidden twin. Healthy databases sit under 5 percent; I have audited files above 20 percent that everyone swore were clean.
Match coverage asks what share of your full database carries a resolved, persistent ID. Precision asks how many of those links are correct, and only a hand-labeled sample answers that honestly. Finally, unmerge rate counts how often someone has to split a bad merge. A rising unmerge trend is the earliest warning that thresholds drifted too loose.
Notice what is missing from that list: the vendor’s headline match rate. Track your own numbers on your own file. Anything else is somebody’s marketing.
How Is AI Changing Identity Resolution?
AI is improving the fuzzy middle of identity resolution: the matches too messy for exact rules but too valuable to ignore. The core deterministic layer, meanwhile, has not changed much, and that is fine.
Three upgrades are real. Machine learning models now score name and company similarity better than hand-tuned rules, especially across languages and transliterations. Embedding techniques catch that “Bob at Acme Corp” and “Robert, Acme Corporation” likely match. And modern systems learn from steward decisions, so every manual merge or split trains the next round of scoring.
One warning from the field, though. AI matching raises coverage and confidence scores together, which makes wrong merges look more certain than ever. Keep a human review queue for borderline scores, and keep measuring precision on labeled samples. Clever models amplify whatever match logic and hygiene you already have, in both directions.
Frequently Asked Questions
What is another name for identity resolution?
Common synonyms are ID resolution, identity matching, and entity resolution. The underlying technique is called record linkage or data matching in academic and government work. Marketers also say identity stitching, and the stored result is usually called an identity graph.
What is an identity resolution rule?
An identity resolution rule defines when two records are allowed to link, for example “exact match on email” or “same name plus same company domain at 90 percent confidence.” Platforms like Salesforce Data Cloud bundle these into rulesets you configure per data source. The rules control the trade-off between coverage and false merges.
What is identity resolution in AEP?
In Adobe Experience Platform, identity resolution is handled by Identity Service, which links identifiers from different datasets into a private identity graph per customer. Profiles are then assembled from every fragment connected in that graph. It is the same matching-layer concept, implemented inside one vendor’s ecosystem.
What is identity resolution in MDM?
Inside master data management, identity resolution is the match-and-merge step that decides which source records feed one golden record. MDM then adds governance on top: stewardship, survivorship policies, and audit trails. In short, MDM is the program; identity resolution is its matching engine.
Is identity resolution the same as identity verification?
No. Identity verification confirms a person is who they claim to be, usually for security or KYC compliance, with documents or biometrics. By contrast, identity resolution connects data records that describe the same person or company. Verification asks “are you really you?” while resolution asks “are these records the same entity?”
Should I use deterministic or probabilistic matching?
Use deterministic matching first, because its links are near-certain and easy to audit. Add probabilistic rules only for the records deterministic keys cannot reach, and validate them on a labeled sample before trusting the output. Most teams land on a hybrid with strict thresholds and human review for borderline scores.
Is identity resolution legal under GDPR and CCPA?
Yes, when you process the data under a lawful basis, honor consent choices, and document the purpose. Privacy laws actually assume some identity capability: you cannot fulfill a deletion or access request without finding every record belonging to that person. The risk sits in linking data collected for one purpose to uses the person never agreed to.
So that is identity resolution: fifty-year-old matching math, applied to the modern mess of devices, channels, and duplicate records. Get the deterministic layer right, store your evidence, respect decay, and the fragmented data problem becomes boring in the best possible way.
Bad
Okay
Good
Amazing
