Identity Resolution: Deterministic, Probabilistic, and Where Each Breaks
A customer buys on the website with one email, logs into the app with another, and calls support with a phone number. Your platform has three profiles. Your dashboard says three customers. Your welcome series has sent three welcomes.
Nobody made a mistake. The rules that decide when two records are the same person were never written down, so the platform’s defaults decided. This is identity resolution, and it is where most CDP programs lose accuracy without noticing. Segments count wrong. Frequency caps don’t hold. Personalization talks to a stranger. The dashboards look fine.
There are two ways to match, deterministic and probabilistic. Each is right for some cases and wrong for others, and each breaks in specific, predictable places. Knowing where is what lets you choose.
What identity resolution is deciding
Every event that reaches a customer data platform arrives with some identifier: a cookie, an email, a customer number, a device ID, a phone. Identity resolution is the set of rules that decide which identifiers belong to the same person, and therefore which events land on the same profile.
The output is one unified profile per person, or as close to it as your rules allow. It isn’t a data type. It is a practice, with decisions that have to be made, written, and tested. It’s the practice that turns the seven types of customer data from seven piles into one record.
Fig 1 · Two ways to decide it’s one person · Deterministic and probabilistic matching side by side, and where each breaks
Deterministic matching
Two records are the same person when they share an identifier you trust exactly: the same email, the same customer number, the same verified phone. No guessing. If the key matches, merge; if it doesn’t, don’t.
Most CDPs run on this by default, with a hierarchy of strong keys (a registered customer ID, an email) and weak keys (a cookie, a device ID). In Bloomreach Marketing (Engagement) the vocabulary is hard IDs and soft IDs. A hard ID, like a registered email, identifies a person on any device. A soft ID, like a browser cookie, identifies one device until it’s linked to a hard ID.
Where deterministic breaks
The customer has more than one of the same key. A work email and a personal one. Two phone numbers. Deterministic matching sees two people unless you have a rule that says a customer can hold several emails and a way to learn that they do. Most platforms handle it through a customer ID that sits above the email.
The key is shared. A family iPad. A shop-floor terminal where staff log customers in. A call-center agent’s browser. One cookie, many people. Deterministic matching merges everyone who touched the device into one profile, and that profile now has six people’s browsing history. This is the case that produces personalization about someone else’s purchase.
The key is wrong at the source. Typos in the email at checkout. A customer number reused after a migration. Deterministic matching trusts the key, so a wrong key merges the wrong people with full confidence.
The key is missing. The anonymous visitor who never logs in. Deterministic has nothing to match on, so every session is a new person until they identify. For a shop where most traffic never logs in, most of the behavior data sits on profiles that will never be joined to a customer.
Consent doesn’t travel with the merge. Profile A consented to email. Profile B, same person, didn’t. After the merge, which consent wins? If the platform’s default is “the newest record,” a merge can silently grant or revoke consent. This one belongs in the consent data design, not only in identity.
Probabilistic matching
Two records count as the same person when enough weaker signals line up: the same device fingerprint, the same IP range, the same postal address written two ways, or the same name plus similar behavior. A score is computed; above a threshold, merge.
Used mostly by ad-tech and by enterprise CDPs with large anonymous audiences. Sometimes used in a lighter form inside marketing CDPs for fuzzy matching on names and addresses.
Where probabilistic breaks
It is a bet, and bets lose. A 90% confidence score means one merge in ten is wrong. At scale that is thousands of profiles carrying someone else’s data. In a welcome series that is annoying. In a bank, a pharmacy, or a children’s retailer it is a complaint.
Wrong merges are hard to undo. Deterministic errors trace back to a key. Probabilistic errors trace back to a score computed on signals that have since changed. Splitting a wrongly merged profile months later, with campaigns already sent, is a manual job.
The signals are weakening. Safari and Firefox ship fingerprinting protection by default, and EU regulators read fingerprinting as tracking that needs consent under ePrivacy. IP addresses are shared and rotate. Every year probabilistic matching has less to work with, and the post-cookie direction is against it.
Regulators read it as tracking without consent. Inferring that two records are one person is itself processing of personal data. In the EU it needs a legal basis. “We thought they were probably the same person” is a hard sentence to say to a supervisory authority.
It hides the data-quality problem. Probabilistic matching then joins records that should have shared a customer ID. The real problem, the missing key, stays unfixed, and the workaround gets more expensive.
Choosing, and writing it down
For a mid-market brand running a marketing CDP, the choice is usually deterministic by default with explicit exceptions, not one or the other. The decisions that need to be written before the first campaign:
The key hierarchy. Which identifiers are strong enough to merge on, in what order. A registered customer ID above email above phone above cookie is common. Yours may differ; write yours.
Multi-key customers. Can a person hold several emails? Several phones? If yes, how does the platform learn the second one, and which one do campaigns use?
Shared devices. What happens when a second hard ID appears on a device that already has one. Options range from “re-link the device to the new person” to “never merge on cookie alone.” Retail with in-store terminals needs this decided on day one.
Anonymous behavior. How long anonymous profiles are kept, and what happens to their history when the visitor finally identifies. Merging a year of anonymous browsing into a new customer profile is a feature; merging a shared terminal’s year is a problem.
Consent on merge. Which record’s consent survives, per purpose, and who is told when a merge changes it.
Fuzzy matching, if any. Where probabilistic rules are allowed, for example deduplicating postal addresses for a catalog mailing. Also the threshold, and who reviews a merge before it takes effect.
Each decision is a paragraph. Six paragraphs, in the tracking plan, reviewed when a new channel or source arrives. That is the whole practice. Most programs skip it, then spend the next two years discovering the defaults one incident at a time.
How to tell whether you have a problem today
Three checks that take an afternoon:
Count profiles with the same email, the same phone, or the same customer number. Any non-zero result is a hierarchy that isn’t enforced.
Pick ten heavy-traffic anonymous profiles and read their history. If the browsing looks like several people, you have shared-device merges.
Take twenty customers from the CRM and find them in the CDP. If more than one or two are split across profiles, the join is failing at the source, and no matching rule will fix a key that never arrives.
The result decides what to do next. Duplicates on a strong key are a configuration fix. Shared-device merges are a rule change. Customers who can’t be found are a data-engineering problem upstream of the platform.
The takeaway
Identity resolution isn’t a feature you switch on. It is six decisions, written down, that the platform enforces for you once they exist. Deterministic matching breaks where the key is shared, duplicated, wrong, or missing. Probabilistic matching breaks because it guesses, and the signals it guesses from are disappearing. Choose deterministic, name the exceptions, test the shared-device case before the first send, and read the duplicate count every month. The dashboards will finally mean what they say.
Read next
Seven types of customer data inside a CDP. What the six decisions are joining.
The first conversation with engineers before a CDP migration. Where the key hierarchy gets decided, with the people who assign the IDs.
Multi-step journey orchestration across channels. What duplicate profiles do to a journey.
WRITTEN BY
Jan Sacha
Co-Founder · Bloomreach Consultant
Bloomreach Marketing consultant, in his third year at Asteroad running daily CDP and marketing automation work for European clients. Former Exponea enterprise consultant and CEO of Digiline.
Put these ideas to work.
If an article names a problem you are dealing with, tell us. We will listen first, then tell you honestly what we would do. No pitch, no commitment.