Identity Resolution Deep Dive
The problem underneath every unified profile
Every system that promises a "360-degree customer view" — a CDP, a CRM, an email platform's audience builder — is quietly depending on identity resolution to work correctly first. The raw reality is that the same human shows up as a different ID in nearly every system that touches them: a cookie ID on the marketing site, a device ID in the mobile app, an email address in the CRM, a loyalty-card number at point of sale, a hashed phone number in SMS. Identity resolution is the ongoing process of deciding which of these IDs belong to the same person and merging them into one addressable profile. Get it wrong and every downstream system inherits the error silently — the wrong product gets recommended, the wrong LTV gets reported, the wrong person gets a win-back email for a purchase they never made.
Deterministic matching: certain, but narrow
Deterministic matching links two records only when they share an exact, high-confidence key — the same verified email, the same hashed phone number, the same login/account ID, the same loyalty number. Because the match is based on an exact key both records actually contain, confidence is very high and false-positive risk is low. The limitation is coverage: deterministic matching only works when the key is actually present in both records, and a large share of real traffic — a first-time anonymous visitor, a logged-out mobile session — simply doesn't carry one yet. Deterministic resolution is the right default for merging profiles, but it can't connect anonymous activity to a known identity until that anonymous visitor does something that hands over a key (signs up, logs in, opens a tracked email link).
Probabilistic matching: broader, but uncertain
Probabilistic matching infers a likely match from a combination of weaker, circumstantial signals when no shared deterministic key exists — same IP address plus same device type plus overlapping active hours plus similar browsing pattern, for instance. Each individual signal is weak evidence on its own; combined, a model can produce a confidence score that two anonymous sessions (or an anonymous session and a known profile) likely belong to the same person. This is what lets a CDP stitch a user's anonymous mobile-web browsing to their later app-login session even though no deterministic key ever connected them directly. It's genuinely useful for cross-device reach, but it is inherently a probability, not a fact — and it has gotten structurally weaker over the past several years as device fingerprinting signals (IP persistence, cross-app identifiers) have been deliberately restricted by browser and OS vendors for privacy reasons.
Deterministic vs. probabilistic identity matching
| Dimension | Deterministic matching | Probabilistic matching |
|---|---|---|
| Basis for match | Exact shared key (email, phone hash, login ID) | Weighted combination of circumstantial signals |
| Confidence | High — effectively certain when the key matches | A probability score, never certainty |
| Coverage | Only where a shared key exists in both records | Can bridge anonymous-to-anonymous or anonymous-to-known |
| False-positive risk | Low | Non-zero, and grows with signal degradation |
| Trend over time | Stable — unaffected by privacy restrictions | Weakening as fingerprinting signals are restricted |
Identity graphs: the structure that holds it together
An identity graph is the data structure that stores every resolved identity and the links between them — nodes are the individual IDs (a cookie, a device ID, an email, a CRM contact ID) and edges are the matches connecting them, each typically tagged with how it was established (deterministic key X, probabilistic score Y) and when. A mature identity graph isn't static; it's a living structure that merges nodes as new deterministic signals arrive (an anonymous visitor finally logs in) and, just as importantly, can split a bad merge if later evidence contradicts an earlier probabilistic link. The graph is what lets a CDP answer "what is this person's complete history across every channel" as a single query instead of a manual cross-reference.
BEFORE login:
cookie_x7 ---(probabilistic, same device+IP)--- cookie_q2
AFTER user logs in on cookie_x7 with jane@co.com:
cookie_x7 ---(deterministic: email)--- user_jane
cookie_q2 ---(still probabilistic)---- user_jane [weak edge retained]
LATER evidence contradicts the probabilistic edge
(cookie_q2 logs in as a DIFFERENT person):
cookie_q2 ---(deterministic: email)--- user_marcus
cookie_q2 --X-- user_jane [edge removed, graph self-corrects]Merge errors compound; always monitor merge/split rates
How CDPs apply this to anonymous + known stitching
In practice, a CDP's identity resolution engine runs continuously against incoming events: each new event carries whatever identifiers are available (an anonymous ID always, plus an email or user ID once the visitor identifies themselves), and the engine checks those identifiers against the existing graph. The pattern almost every CDP implements is anonymous-id-first tracking followed by an identify/alias call: track anonymous behavior under a device-generated ID from the first pageview, then fire an explicit "identify" event the moment the user logs in or converts, which deterministically merges all prior anonymous activity under that ID into the now-known profile. This is why instrumentation quality upstream (making sure the anonymous ID is set consistently before any identify call fires) matters as much as the resolution logic itself — a CDP can only stitch identities it was actually handed.
What's next
Identity resolution is the engine underneath a CDP's unified profile — understanding how CDPs package this capability, and where they differ from a CRM or DMP, builds directly on this foundation.
Next: Customer Data Platforms (CDP) →
I build these systems professionally.
Whether it's a RAG pipeline, analytics migration, or AI workflow — let's talk.