Your unified profile count looks healthy. That’s exactly the problem.
TL;DR — Data 360’s match rate hides your miss rate: the large, non-random share of customers that strong-key matching silently drops — often your best ones. Probabilistic identity resolution recovers them, and Data 360 already has it — but switch it on without a precision-gated method and it merges the wrong people. This post makes the case for closing the gap, not the how-to. Start by measuring your miss rate per source.
Salesforce Data 360 — the platform Salesforce renamed from Data Cloud in 2025 — will tell you, to the individual, how many unified customer profiles you have. It shows you a match rate, a tidy count of resolved customers, a number that climbs over time. What it will not tell you — what no dashboard volunteers — is how many of your actual customers never made it into that count at all.
That silence is the most expensive thing in your customer data platform.
Strong-key matching is the right place to start
A CDP builds a single view of a customer by matching records that belong to the same person and stitching them into one profile. The question is: how does it decide two records are the same person?
The safe, obvious way — and the right place to start — is to match only on a strong identifier. Same email address. Same loyalty or member number. Same account reference. If two records share that exact value, they’re the same person; if they don’t, they’re left alone. No guessing, no probability, no false links. It’s correct and boring, and it should be — this is the trustworthy backbone everything else is built on.
(If you work with this stuff, this is the stage practitioners call “L1” identity resolution. The label doesn’t matter. What it does — and doesn’t do — is the whole point.)
But a strong key has a ceiling, and it never warns you
Here’s the ceiling: a strong-key match can only link records that carry that key, with the same value. Everything else is invisible — not flagged, not queued, just absent from every profile and report. And the customers who fall through are disproportionately the ones you’d most want to see.

One customer, counted as three strangers. Strong-key matching isn’t wrong here — it’s just silent: nothing tells you these belong together.
The customers who fall through are your best ones
Jane isn’t an edge case, and the fallout isn’t random — it’s skewed toward exactly the customers you can least afford to lose sight of. The more valuable the customer, the more fragmented they tend to be: the person who buys across two of your lines, arrived through an acquisition, and has shopped for years simply touches more systems than a one-time guest — and every extra touchpoint is another chance to land without a shared key.
So strong-key matching doesn’t just miss customers; it misses your best ones first. In most mid-sized businesses that’s a large, structural share of the base — and each of them resolves to nothing, or to several fragments that each look like a separate, lower-value stranger.
Why this is a problem, not just untidy data
The instinct is to file this under data hygiene — untidy, but harmless. It isn’t harmless, because every decision downstream inherits the gap.
You under-count your best customers. Someone loyal across two parts of your business, but split across two unlinked records, shows up as two half-value customers. Their real worth is invisible, so you rank them below single-purchase shoppers who happen to have one clean record — and you spend accordingly, backwards.
You pay to re-acquire people you already have. Real, consented, contactable customers sit outside every audience simply because no profile claims them. So they get marketed to as prospects. You buy back customers you never lost.
Your measurement is quietly wrong. Cross-sell value, retention, attribution — all computed over the matched base. If a large slice of behaviour never joins a profile, that base is a skewed sample, and the reports are confidently precise about the wrong number.
And it’s a compliance blind spot. Holding a complete view of everything a person has with you — for suppression, for vulnerability, for regulatory duty of care — is impossible when half their records are unlinked. You can’t act on a whole customer you can’t assemble.
The through-line: strong-key matching doesn’t just give you a smaller view. It gives you a skewed one, and it never warns you it’s skewed. The match rate looks fine because it only measures the records that matched — a bit like judging a fishing net by counting the fish already inside it.

Probabilistic identity resolution is where the missing customers live
There’s a next stage, and it exists for exactly one reason: to recover the records a single strong key can’t reach. This is probabilistic identity resolution — instead of relying on one exact identifier, it matches on several softer signals at once — name, postal address, phone, device, payment token — combined carefully enough to re-link a guest order to a known customer, or merge two different-email records into one person. (This is the stage the same practitioners call “L2.” Again — the label isn’t the point; the recovered customers are.)
Go back to Jane. No two of her records share a key, so strong-key matching left them apart — but they share softer signals. Weigh those together and the three fragments collapse into one person:

No single signal is proof; combined, they clear a confidence threshold and Jane resolves to one profile instead of three. And this usually isn’t a technology gap at all. Data 360 already has the machinery: tiered match rules, plus native AI-based matching that returns a confidence score rather than a blunt yes/no. The capability is already inside the platform you’ve paid for — the same one you may still be calling Data Cloud.
The hard part isn’t the technology — it’s the discipline
The machinery is already in Data 360. The hard part is using it without merging two different people — a rule that fuses two strangers into one profile is worse than the gap it closed: you end up activating on, and reporting against, a customer who doesn’t exist, sometimes on consent that was never theirs.
Done safely, it’s a sequence, not a switch:
- Baseline the gap — resolved rate per source, misses bucketed by why.
- Shortlist candidate fields that could recover missed records.
- Check feasibility — real fill-rate and quality per source; cut weak fields before building.
- Design tiered match rules from the fields that survive.
- Test in a sandbox — score each rule on coverage lift and precision against a held-out truth key.
- Govern confidence → consent — which merges may drive activation, which are view/suppression only.
- Promote and monitor — deploy only what passes, then watch for over-matching and drift.

That’s a subject in its own right — this post isn’t the method, it’s the case for why you need one.
This week: measure your miss rate, not your match rate
You don’t need the full method to start — you need one number. For each source feeding Data 360, what share of its person-records actually resolve into a unified profile? Per source, not the average: the average hides the source sitting at 40%, which is where your invisible customers are.
Then group the misses by why — guest checkout, two emails, an acquired system that never carried your key are three different problems with three different fixes. That’s your baseline, and everything else measures against it.
Data 360 can see them — it just wasn’t asked to look
You might find the gap is small. More often, teams discover the number they’d been celebrating covered a fraction of their customers — and the rest, the ones they most wanted to understand, were never in the room.
Seeing the gap and closing it aren’t the same move: the recovery is real, but it takes the method above, not a switch you flip. Data 360 can see these customers. It just wasn’t asked to look — and asking it properly is the work.
Ready to size your own gap?
The Identity Coverage Sprint is a fixed-scope engagement that runs exactly that method on the Data 360 you already own: it baselines your resolved rate per source, precision-gates every new match rule so no two strangers are ever merged, and promotes only the rules that prove a coverage lift you can defend. Not new platform spend — just the coverage your CDP investment was already meant to deliver. Book a scoping call and we’ll baseline your coverage gap.
Frequently asked questions
Probabilistic Identity Resolution — FAQ
What's the difference between deterministic and probabilistic identity resolution?
Deterministic — or "strong-key" — matching links two records only when they share an exact identifier: the same email, member ID, or account reference. Probabilistic identity resolution links records by weighing several softer signals together — name, address, phone, device — and scoring how likely they are to be the same person. Deterministic is the precise backbone; probabilistic recovers the records that carry no shared key.
Is Data 360 the same thing as Salesforce Data Cloud?
Yes. Data 360 is the current name for the product Salesforce previously called Data Cloud; it was renamed in 2025 as part of the Agentforce 360 platform. The identity-resolution mechanics did not change with the rename — the strong-key and native AI-based matching are the same features you had under the Data Cloud name.
Does probabilistic matching risk merging two different people?
It can, if it's switched on without precision testing — and that's the central risk. A rule that boosts coverage but occasionally fuses two strangers into one profile creates activation and compliance problems worse than the gap it closed. Safe practice is to measure each rule's precision against a held-out truth set and gate what it's allowed to do by its confidence score.
What is a "miss rate" and how do I measure it in Data 360?
Your miss rate is the share of a source's person-records that never resolve into a unified profile — the inverse of the match rate that gets reported. Measure it per source rather than as an average, then bucket the misses by cause: guest checkout, multiple emails, acquired system. The worst-resolving source is usually not the one you were watching.
First in a series on customer unification in Salesforce Data 360 — from basic exact-key matching to smarter multi-signal resolution. Next: how to size the gap and prove a coverage lift you can defend.