Ask a room of marketers what a CDP does and you'll hear some version of “it brings all our customer data together.” That's the pitch. Identity resolution is the part of the platform actually responsible for deciding whether the person who browsed on mobile last week is the same person who called support yesterday — and it is, without much competition, the single highest-leverage decision in the entire build.
It's also the part most organizations spend the least deliberate time on. Platform selection gets a vendor bake-off. Identity resolution gets whatever the platform ships with by default, tuned lightly if at all. That gap is where most of the CDP disappointments we get called in to fix actually originate — not in the tool, but in a matching decision made in week one that nobody revisited until it was expensive to unwind.
These are the mistakes we see most often, roughly in the order they tend to get made.
Mistake 1: Buying the platform before agreeing the matching logic
Every CDP vendor demo shows identity resolution working beautifully, because the demo data was chosen to make it work beautifully. The actual question — which signals count as proof two records are the same person, and in what order of trust — rarely gets answered before the contract is signed. It gets answered afterward, under implementation deadline pressure, usually by accepting whatever the platform defaults to.
That ordering is backwards. The matching logic is a business and legal decision dressed up as a technical one — how confident you need to be before merging two records has real consequences, and those consequences are yours to own regardless of which platform enforces them. Decide the model first. Let the platform selection be informed by how well each option can express the model you actually need, not the other way around.
Mistake 2: Reaching for probabilistic matching before deterministic is exhausted
Probabilistic matching — inferring that two records likely belong to the same person from a cluster of weaker signals like device, IP range, or behavioral similarity — gets pitched as the sophisticated option. It's really the fallback option, appropriate for the identity gaps that remain after every deterministic key available to you has been exhausted, not a first resort.
| Deterministic matching | Probabilistic matching | |
|---|---|---|
| Basis | Exact match on a trusted identifier — email, login, loyalty ID, hashed phone | Statistical inference from a cluster of weaker, non-exact signals |
| Confidence | Effectively certain when the identifier itself is trustworthy | A probability score, not a certainty, even when tuned well |
| Right for | Any decision with real consequences — account data, regulated fields, suppression, deletion | Filling gaps in anonymous-to-anonymous stitching, at low stakes, with a clear reversal path |
| Wrong for | Nothing — it's the default you should exhaust first | Any merge you can't cleanly explain or reverse if it's wrong |
The organizations that get burned here aren't the ones using probabilistic matching. It's the ones using it for merges deterministic matching should have handled, because it was switched on platform-wide as a convenience rather than scoped to the specific gap it exists to fill.
Mistake 3: No policy for what happens when a merge is wrong
Every identity resolution system will, eventually, merge two records that shouldn't have been merged, or fail to merge two that should have been. That isn't a sign of a broken system — it's a certainty in any system operating on incomplete signals at scale. The mistake is not planning for it.
- No audit trail of which signals triggered a merge, so a wrong merge can't be diagnosed, only noticed.
- No unmerge path, so correcting a mistake means manual data surgery instead of a defined operation.
- No monitoring for merge rate anomalies, so a rule that starts over-matching after an upstream schema change goes unnoticed until someone complains.
- No distinction between a merge that's wrong and a merge that's merely surprising — treating every escalation as an emergency burns the credibility you need for the ones that actually are.
A merge is a claim about a real person. Treat it like one — with evidence, a way to reverse it, and a record of why it happened.
Mistake 4: Collapsing household and individual identity into one thing
Shared devices, shared accounts, and shared IP addresses are common enough that most identity graphs eventually have to decide what to do about them. Organizations that haven't thought about this explicitly tend to let the platform quietly merge everyone on a shared connection into one profile — which works fine until a personalization engine starts recommending products to the wrong household member, or a regulated industry realizes two account holders have been treated as one customer.
Household and individual identity are two different graphs, related but distinct, and the decision about which one drives a given activation needs to be made deliberately per use case — not inherited by accident from however the matching rules happened to be configured.
Mistake 5: Designing identity resolution and consent as separate projects
Identity resolution and consent management usually get built by different teams, on different timelines, and the interaction between them gets worked out later, if at all. That ordering creates a specific failure: a profile gets fully resolved across sources before anyone checks whether the person consented to being tracked across all of them.
Consent state has to be a first-class input to the resolution logic, not a filter applied to its output. A record that shouldn't be linked under the applicable consent basis shouldn't be linked at all — not linked and then suppressed downstream, where a configuration mistake three steps later quietly exposes it anyway.
Mistake 6: Designing for launch day, not for drift
Identity resolution gets tuned carefully during implementation, validated against real data, and signed off. Then a new source system launches, a mobile SDK update changes what device signal looks like, or a third-party ID gets deprecated — and the matching logic that was correct on launch day quietly degrades, because nobody owns watching it after go-live.
- Match rate and merge rate trends, tracked over time, not just validated once at launch.
- An owner for identity resolution specifically, distinct from whoever owns the CDP generally — it's a big enough decision to deserve a name attached to it.
- A defined process for evaluating a new identifier or source before it's plugged into the graph, rather than adding it and observing what happens.
Getting it right
- 01Agree the matching model — what counts as proof, and in what order of trust — before evaluating platforms, not after selecting one.
- 02Default to deterministic matching. Scope probabilistic matching narrowly, to the specific gap it exists to fill, with a lower confidence bar reflected in how its output is used.
- 03Build the audit trail and the unmerge path at the same time as the matching rules, not after the first bad merge forces the question.
- 04Decide, explicitly, how household and individual identity relate for each use case that touches personalization or account data.
- 05Gate resolution on consent state as an input, not a downstream filter.
- 06Assign ownership of match-rate monitoring to a person, not a dashboard nobody is on the hook for checking.
None of this requires a more expensive platform. It requires treating identity resolution as the decision it actually is — one with real consequences for real people — rather than a configuration screen you get through on the way to building audiences.