Skip to main content

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·Last updated 2026-06-01·Drafted by Lira · Edited by German Medina

Identity resolution in Data 360 (formerly Data Cloud) runs two kinds of rule in sequence: match rules decide which source records are the same person, and reconciliation rules decide, once matched, which attribute value wins in the resulting profile. This page is the first half — how the engine looks at two ssot__Individual__dlm records and decides they collapse into one UnifiedIndividual__dlm. Reconciliation is its own page (see reconciliation rules).

This is the decision the rest of the system inherits. Get it right and a person who exists in three source systems becomes one unified individual everything downstream can reason about. Get it wrong and you either merge two people who aren't the same, or fail to merge one person who is — both silently. Identity resolution is a business decision, not a checkbox (principle 4).

The match ruleset

A match ruleset is the set of individual match rules the engine evaluates for one DMO — typically the Individual. Each rule names one or more match criteria; a single ruleset usually holds several rules, and a source record needs to satisfy only one of them to match. That "only one" is the whole shape of how match rules combine, and it's worth stating precisely before anything else, because it's where over-merge and over-split are decided.

How criteria combine: an OR of AND-groups

Read a match ruleset as an OR of AND-groups:

  • A single match rule is an AND of its criteria — every criterion in that rule must hold for the rule to fire.
  • The ruleset is the OR of its rules — any one rule firing is enough to declare a match.

So a ruleset like "match on exact email, OR on (fuzzy name AND exact phone)" matches a pair when their emails are exactly equal, or when their names are a fuzzy match and their phones are exactly equal. Two records that share only a fuzzy name — and nothing else — do not match, because no single rule's full AND-group is satisfied.

Ruleset = Rule A  OR  Rule B  OR  Rule C
Rule A  = email-exact
Rule B  = fuzzy-name  AND  phone-exact
Rule C  = party-id-exact

Adding a rule loosens the ruleset (one more way to match). Adding a criterion inside a rule tightens that rule (one more thing that must hold). Holding those two moves apart in your head is the difference between deliberately widening a net and accidentally tearing it.

Exact match vs fuzzy match

Match criteria come in two kinds, and the distinction governs how much you can trust the rule.

  • Exact match — the two values must be equal after normalization. This is the criterion for a strong identifier: a verified email (ssot__ContactPointEmail__dlm), a phone (ssot__ContactPointPhone__dlm), or a party identification value (ssot__PartyIdentification__dlm) such as a loyalty number or a CRM ID. Exact match on a clean key is the most defensible thing a match rule can do.
  • Fuzzy match — the values are compared for similarity rather than equality, to absorb the normal variation in human-entered data. Data 360 offers fuzzy matching primarily on name (so "Bob" and "Robert", or a transposed-letter typo, can still match). Fuzzy match is as useful as it is dangerous: it is the criterion most likely to merge two different people, which is why you rarely let a fuzzy criterion stand alone — you pair it with an exact one in the same AND-group, as in fuzzy-name AND phone-exact above.

Normalization runs first

Every criterion compares normalized values, not raw ones. Before any rule is evaluated, Data 360 standardizes the keys — lowercasing email, stripping whitespace and punctuation, reformatting phone numbers toward a canonical form — so that Jane@Example.com and jane@example.com are treated as the same value rather than two. Without it, an exact-email rule misses obvious matches and you get over-split for no reason other than casing.

Normalization is what makes both exact and fuzzy criteria behave, so the keys you match on and how they're normalized is a topic in its own right (see match keys and normalization). For this page, the rule is simply: the engine matches on the normalized value, so the quality of your match rules is capped by the quality of your normalization.

Running matching is reprocessing

Match rules don't take effect quietly. Saving a new or changed ruleset triggers identity resolution reprocessing across the org: the engine re-evaluates the affected source records, recomputes the IndividualIdentityLink__dlm mappings, and rebuilds the unified profiles. That has three consequences worth budgeting for:

  • It costs. Reprocessing is work, and Data 360 bills on work processed (principle 11) — a ruleset change is not free to iterate on.
  • It takes time. Reprocessing isn't instantaneous; the unified profiles you query right after a change may still be settling.
  • Counts shift. A looser rule lowers the unified count (more records collapse together); a stricter rule raises it (fewer collapse). If a downstream report keys on UnifiedIndividual__dlm, its numbers move the moment matching reprocesses — by design, but it surprises whoever reads the report if nobody told them.

Because source-to-unified is mediated by the link object, you confirm what a rule change did by inspecting IndividualIdentityLink__dlm — how many source individuals now resolve to one unified individual — never by joining ssot__Individual__dlm to UnifiedIndividual__dlm directly, which isn't a path the model exposes.

The asymmetric stakes

The reason match-rule tuning deserves real care is that its two failure modes are not equally bad, and neither raises an error:

  • Too loose → over-merge. Distinct people fuse into one UnifiedIndividual__dlm. They can see each other's data, suppression leaks across them, and personalization addresses the wrong person. In a consent-bearing channel this is a privacy incident, not a metrics nuisance.
  • Too strict → over-split. One person fragments into several unified individuals. Metrics double-count, a suppression set misses some of their records, and the "single view" the platform promised quietly isn't.

Both are invisible until someone notices a number that can't be right — or a customer sees an order that isn't theirs. Which risk your rules should lean against is a deliberate decision, framed by the asymmetry above; that framing lives in the Style Guide. What this page asserts is narrower and non-negotiable: test the ruleset against real data and have the business sign off before it runs on the whole org (principle 4).

Related

Reference: