Stage one: exact-key matching is precise — and quietly incomplete

Deterministic strong-key matching links two records only when they share an exact identifier — a verified email, a member number, a hashed phone. It’s fast, precise, and the correct place to start; for a business with clean, strongly-keyed, single-channel data it may be all you ever need. The problem is not that it’s wrong. The problem is what it silently excludes.

Everyone who doesn’t present a shared strong key is invisible — absent from the profile, the segment, and the report. In practice that’s:

• the shopper who checked out as a guest with a different email each time;
• the household that shares an address but not an inbox;
• the book of business you acquired, still keyed on the old platform’s IDs.

These aren’t long-tail edge cases. They cluster in your highest-value, longest-tenured, most-acquired-through segments, so the revenue you can’t see is concentrated exactly where it hurts most.

This is why the match rate can’t warn you: it’s a ratio computed over the records you attempted to resolve, and an unresolved customer shows up as several complete-looking records the arithmetic never knows are one person. The percentage goes up and to the right while the reality fragments underneath it. So the first move is not to ingest more data — it’s to re-baseline: measure the resolved rate per source, and bucket the unresolved records by why they missed. That bucketing tells you whether you have a matching problem or a governance one, and the two don’t share a fix.

Stage two: multi-signal coverage is where identity is won or lost

This is the stage that recovers the customers exact keys can’t — and the one most teams either skip or botch. Coverage doesn’t come from ingesting everything; most fields recover almost no one and a few recover almost everyone, so the discipline is a shortlist, not a firehose:

• Rank candidate fields by expected coverage gain against precision risk — secondary email, phone, name-plus-address, device.
• Check real fill-rate per source before building a rule; a field that recovers everyone in theory and is populated 4% of the time in practice is a rounding error, not a rule.
• Build tiered rules — strict combinations for near-certain matches, broader ones for lower-confidence recovery.
• Sandbox every rule against a frozen snapshot and score it against a held-out truth key, so you read its coverage lift and its precision before it ships. Go/no-go is per rule, measured — not per vendor promise.

Then the part the “identity resolution is a feature” story ignores entirely: a probabilistic match must never inherit consent. A deterministic match is a statement of fact; a probabilistic one is a statement of likelihood — and treating the second like the first is how you end up marketing to a daughter on her mother’s opt-in because they share an address. Confidence has to gate permission:

• high-confidence, strong-key matches can drive activation;
• lower-confidence probabilistic links can inform a unified view for analytics, but stay suppressed from activation and never inherit another record’s marketing consent until a stronger signal confirms it.

That confidence-to-consent mapping is a signed-off policy artifact, not a line buried in a match rule, and it’s what lets you chase coverage hard without taking on merge risk. The honest concession: packaged platforms genuinely help here — native fuzzy matching and confidence scores are real and useful. What they won’t do is set your precision threshold, choose your fields, or own your merge policy. That’s the actual job, and it’s yours.

Stage three: real time is a latency problem, not a re-resolution one

The last stage makes a resolved, consented profile act in the moment — and the costly misconception is that “real time” means resolving identity faster. It doesn’t. The identity is already resolved; what’s missing is speed of action. A correct profile that lands a day late still costs you the basket abandoned and emailed about tomorrow, the churn signal seen after they’ve gone, the product retargeted an hour after it was bought.

Mechanically, real time is ingestion and activation bolted onto the identity you already have:

• Stream live behaviour in — page views, sessions, event-level activity — through a web/mobile SDK or server-to-server, as identity-aware events onto a streaming graph, not the nightly batch.
• Bridge anonymous-to-known, so pre-login activity attaches to the right person the instant they sign in.
• Wire the resolved profile into whatever drives the next message or on-site experience, closing the loop from event to person to action while the moment is still open.

The discipline is what you don’t do: append with strong keys only, and never re-open probabilistic resolution in the stream. Re-resolving under latency pressure reintroduces merge errors at speed, with none of stage two’s sandboxed precision testing to catch them. And the concession is cost — real time is metered per event in a way batch never was, so promote only the moments whose time-to-act value justifies it and leave the rest in batch. Real-time capability isn’t a maturity badge you earn by streaming everything; it’s a scalpel for the handful of moments where being an hour late loses you the customer.

Which stage are you actually in?

“Buy a CDP with identity resolution” disappoints because it answers a purchasing question when the real one is architectural. Identity resolution doesn’t ship resolved; it’s built in order — matching you can trust, coverage you can defend on precision and consent, real time you apply only where latency costs you. Skip coverage and your real-time actions are fast and wrong; skip governance and your coverage is a compliance breach waiting for an audit. The tool you run it on — packaged, warehouse-native, or a mix — changes the implementation, not the sequence.

So Monday’s move is a diagnosis, not a purchase. Recompute your resolved rate per source, then bucket the unresolved records by why they missed:

• mostly no shared key → you’re stalled before coverage; the next work is fields and rules;
• mostly weak-signal near-misses → you have a precision-and-consent policy to write;
• mostly right, but slow → you’ve earned the real-time conversation.

You can’t fix the stage you’re in until you know which one it is — and the number on your dashboard was never going to tell you.

Where to go next

Once you know which stage you’re stuck in, the next question is what to run it on — and that’s an architecture decision, not a feature checklist. Our guide to choosing between a composable and a packaged CDP works that choice the same measure-first way this post does, so you pick the stack that fits the stage you’re actually at — not the one the demo showed.