Identity Resolution Explained: Deterministic vs Probabilistic Matching in a Customer Data Platform (CDP)

Identity resolution is how a customer data platform (CDP) decides that several records, devices and accounts belong to the same person and links them into one profile. It compares match keys such as email, customer ID or phone number, either exactly (deterministic) or by scored similarity (probabilistic), and merges records above a confidence threshold. Done well, it also carries consent and suppression through every merge.

Who this is for: architects, DPOs and marketing-operations owners choosing or auditing identity resolution software. You get the mechanics, regulatory pitfalls, a banking and a healthcare example, a vendor comparison and a buyer's checklist. Part of the Learn hub.

Identity resolution meaning: what problem it solves

One person leaves many records: a CRM contact, an app install ID, two browser cookies, a call-centre phone number, a loyalty card. Without resolution you count one person five times, email them three times and cannot honour an opt-out everywhere. It is not identity verification (proving who someone is, as in know-your-customer checks) and it overlaps with, but differs from, master data management; see CDP vs CRM vs DMP vs MDM vs data warehouse.

The output is an identity graph: nodes are identifiers or records, edges are evidence that two nodes are the same person, and each connected cluster becomes a profile. The CDP Institute describes the underlying job as linking information that relates to the same customer 1. Where the graph sits in the wider platform is covered in customer data platform architecture.

Match keys: what you match on

Key hygiene matters more than algorithms. Segment recommends blocking values such as zeros and dashes, -1, null and "anonymous" for every identifier 2. Amperity's preprocessing upper-cases emails, turns junk patterns such as test@ into NULL and keeps only the last ten digits of phone numbers 3. Adobe warns that shared devices (family computers, airport kiosks, call-centre workstations) and fake values can collapse several people into one graph 4. Salesforce advises adding criteria such as name because a phone number or email alone can merge household members 5.

Deterministic vs probabilistic identity resolution

Probabilistic methods usually descend from the Fellegi-Sunter model of record linkage. Splink, an open-source implementation from the UK Ministry of Justice, outputs match probabilities for candidate pairs and can be trained without labelled data 6. Amperity's Stitch scores pairs into categories (exact, excellent, high, moderate, weak, non-match), keeps exact, excellent and high pairs by default, and lets you change the cutoff 3; its summary report shows what share of profiles came from deterministic, probabilistic and transitive links 7. Hightouch treats deterministic matching as the default and says its probabilistic option processes some data outside the warehouse 8. Law has its own yardstick: the CCPA defines a probabilistic identifier as identification "to a degree of certainty of more probable than not" 9.

Confidence thresholds

Use three bands: auto-merge above a high score, a review queue in the middle, no link below. Calibrate against a labelled sample and track precision (share of merges that are right) and recall. Set thresholds by cost of error: wrongly merging two people in a newsletter audience is a nuisance; wrongly merging two patients or two borrowers is a harm. Use different thresholds per purpose, and record the threshold and version on every merge. Salesforce states the trade-off plainly: stricter match methods lower the consolidation rate, looser ones raise it but can produce wrong matches 5.

Identity graph: household vs individual

A profile is the surface; the graph keeps the evidence. Keep household as its own entity linked to individuals rather than merging people. The CCPA defines a household as a group of consumers who cohabit at the same address and share devices or services 9. Households help with one mailing per address, joint accounts and guarantor or caregiver relationships, but consent, preferences and access rights belong to individuals. Adobe's "unique namespace" setting expresses the same idea: two people sharing a device are split into separate graphs instead of merged 4.

Merge, unmerge and keeping consent through merges

Regulatory pitfalls

• GDPR accuracy and minimisation. Personal data must be accurate and limited to what is necessary 12. A false merge creates inaccurate data about a person, and collecting extra identifiers only to raise match rates conflicts with minimisation.
• Automated decisions. People have a right not to be subject to solely automated decisions with legal or similarly significant effects 13. If matching feeds such decisions, keep a human review path. The EU AI Act lists creditworthiness evaluation among high-risk uses 14.
• HIPAA minimum necessary. Covered entities must make reasonable efforts to limit PHI used or disclosed to the minimum necessary, with exceptions such as treatment and authorised disclosures 15. Linking identifiers across systems for marketing needs a defined, scoped purpose; see HIPAA marketing rules.
• Probabilistic matches in regulated decisions. A rule of thumb: never let a probabilistic link alone drive credit, eligibility or clinical outcomes; require a deterministic key or human confirmation.

Example: a bank with retail, wealth and corporate lines

A hypothetical customer holds a mortgage and current account (retail), a managed portfolio (wealth) and is sole director of a company with business accounts (corporate), plus a sole-trader account.

Three rules follow. A same-person link is not permission to use data across lines: purpose limitation still applies, with consent and notices per line. Companies are organisations, but sole traders are individuals; the ICO says PECR consent rules for email and text do not apply to corporate subscribers but do to sole traders and some partnerships, and advises treating unclear cases as individuals 16. And operational or regulatory uses need deterministic keys; probabilistic suggestions stay in marketing analytics. Do not confuse this with the deposit-insurance file called a single customer view; see single customer view and the customer 360 data model for retail banking.

Example: a health system with portal, website and call centre

A defensible policy: deterministic keys only (patient ID, verified login) for anything touching PHI; probabilistic matching confined to a governed clinical master patient index, not marketing; a separate pseudonymous marketing identity space; minimum-necessary scoping per use. See patient 360 vs EHR.

Identity resolution software: how vendors differ

| Amperity (Stitch) | Blocking, pairwise scoring, deterministic, probabilistic and transitive links; configurable cutoff 37 | SaaS | Stable ID can still "jitter" | | Twilio Segment (Unify) | Exact identifier matching; identifier priority, per-profile limits (defaults: 1 user ID, 5 others), blocked values; flat matching 2 | SaaS | Tightening rules later; no documented unmerge | | Hightouch | Deterministic by default, optional probabilistic; graph tables written to your warehouse, golden record; Business tier plans 8 | Your warehouse (probabilistic partly outside) | Needs clean, consistently formatted identifiers | | Adobe Experience Platform | Identity graph with unique namespaces and namespace priority; 50 identities per graph 4 | Adobe-hosted SaaS | Graph collapse from shared devices |

Evaluation checklist for buyers

• Which methods are supported (exact, normalized, fuzzy, ML), and can probabilistic be switched off per use case?
• Are scores and thresholds exposed, configurable per purpose and logged per merge, with a review queue for mid-confidence pairs?
• Can I block placeholder values and cap identifiers per profile?
• Is unmerge supported, and what happens to segments, journeys and downstream tools?
• Do consent and suppression survive merge, unmerge and erasure at identifier level (seeded test)?
• Are source values preserved with survivorship rules rather than overwritten?
• Are households and organisations modelled separately from individuals?
• Where does matching run, and what data leaves my environment?
• Can I export the graph and merge lineage?
• How is cost computed (profiles, rows processed, credits), and what does a full re-run cost?
• Which metrics exist: consolidation rate, sampled precision, ID churn, collapse alerts?
• Can it run on-premise or in my own cloud account if required?

Turn these into procurement language with the CDP RFP template.

Back to the Learn hub. If identity resolution has to run inside your own environment, with your keys and your audit trail, see how the PrivyCDP platform is deployed on-premise, in your own cloud account or air-gapped, and how it fits your GDPR or HIPAA obligations.

This article is general information, not legal advice.