DATA 360 / IDENTITY RESOLUTION
Identity Resolution
Match and reconciliation rules, the unified individual, and the difference between a profile that resolves cleanly and one that silently merges two customers into one.
Foundation · 2
Production note
Identity resolution gotchas: the silent failures
The identity resolution failures that don't throw an error. Over-merge leaks one customer's data to another; over-split fragments one person into many; a direct source-to-unified join returns a wrong mapping; the wrong reconciliation winner sends mail to a stale address; a rule change silently reprocesses the whole org and shifts every count. Seven gotchas, each as the instinct, what actually happens in production, and the fix.
Decision framework
Data 360 Identity Resolution: Style Guide
The opinionated rules Cleon applies to every identity resolution decision in Data 360 — one question at the center, how strict should the match be, framed by the asymmetric cost of a false merge versus a false split, the strength of the key you resolve on, and whether the business signed off against real data with reprocessing budgeted. Patterns to prefer, patterns to refuse, the agent-readiness check, and a pre-ship checklist before any ruleset change ships. The discipline document that ties the Identity Resolution subcategory together.
Reference · 5
Reference
The unified individual: how Data 360 resolves many profiles into one
What identity resolution produces: the unified individual. UnifiedIndividual__dlm vs the source ssot__Individual__dlm, the IndividualIdentityLink__dlm bridge that maps source to unified, why source-to-unified traversal always goes through that link and never a direct join, and why counting the wrong object silently breaks every metric downstream.
Reference
Match rules: when Data 360 calls two records the same person
How Data 360 decides two source records are the same person: match rulesets, individual match rules, exact match (email / phone / party ID) vs fuzzy match (name), and how criteria combine as an OR of AND-groups. What running matching reprocesses, and why loose rules and strict rules both fail silently.
Reference
Reconciliation rules: which value wins in the unified profile
Once match rules have grouped source records into one person, reconciliation rules decide which attribute value wins in UnifiedIndividual__dlm — per attribute. Most Recent, Most Frequent, Source Priority, Last Updated: what each does, when to prefer a ranked source list over recency, and why this is the email and address activation actually sends to.
Reference
Match keys and normalization: what you resolve identity on
What identity resolution actually compares: the DMOs and fields that serve as match keys — party identification, contact-point email and phone, individual name and date of birth — and the normalization that runs first. What makes a key strong and stable versus fragile, and why an unnormalized key fails silently.
Reference
Unified identity downstream: what every other surface inherits
How resolved identity feeds everything else — and why everything else silently depends on it. Counting UnifiedIndividual__dlm vs the source ssot__Individual__dlm in Query, identity as the grain under Calculated Insights and Segmentation membership, activation keyed on the unified individual, and why a coherent unified profile is the prerequisite for an agent to answer about a customer (principle 10).