Skip to main content

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

Match rules decide when two records are the same person. This page is the layer underneath that decision: what the rules compare. In Data 360 (formerly Data Cloud), identity resolution never matches on "a record" in the abstract — it matches on specific fields, on specific DMOs, after those values have been normalized. Pick the wrong keys, or skip the normalization, and the rules you wrote in match rules run against values that were never going to line up.

This is the reference for the keys themselves. The mechanics of how criteria combine live in match rules; the data model those keys sit on lives in Data Model Objects. Here we cover which fields are worth matching on, what normalization does to them first, and how to tell a key that holds from one that quietly doesn't.

What you match on: the key-bearing DMOs

Identity resolution compares attributes that live on the standard profile DMOs. The ones that carry the keys worth matching on:

  • ssot__PartyIdentification__dlm — the strongest keys you have. This DMO holds identifiers a system already issued and stands behind: a loyalty number, a CRM record ID, an external system's customer ID. Each one is, by construction, meant to point at exactly one party. A match on a verified party identification is the closest thing to certainty identity resolution offers.
  • ssot__ContactPointEmail__dlm — email as a match key. Strong when it's a real, verified address, because most people don't share one; weaker the moment it's a shared household or role address (info@, family@).
  • ssot__ContactPointPhone__dlm — phone as a match key. Same logic as email: a personal mobile is a good key, a shared landline or a switchboard number is not.
  • ssot__Individual__dlm — the person record itself, carrying the attributes you fall back to when there's no hard identifier: name (ssot__FirstName__c, ssot__LastName__c) and date of birth. These are the probabilistic keys — useful in combination, dangerous alone.

The pattern across all four: a key is strong in proportion to how uniquely and stably it points at one human. Party identification is strong by design. A free-text first name is not a key at all on its own — it's a hint.

Normalization: what runs before the comparison

Two records can describe the same person and still fail to match, because the strings differ even though the values don't. JANE@EXAMPLE.COM and jane@example.com are the same mailbox. +1 (415) 555-0100, 415-555-0100, and 4155550100 are the same phone. Identity resolution normalizes key values to a canonical form before it compares them, so that cosmetic differences don't read as different people:

  • Case-folding — names and emails compared without regard to upper/lower case.
  • Whitespace trimming — leading, trailing, and collapsed interior spaces removed, so " Jane " and "Jane" are one value.
  • Phone to a canonical format — numbers reduced to a consistent (E.164-style) shape so formatting, spaces, and punctuation don't fragment a match.
  • Email lowercasing — the address folded to lowercase so the only thing that distinguishes two emails is the actual address.

The point is not the specific transforms — it's the order. Normalization is the step that turns a key's value into something comparable. Skip it and the match rule is comparing presentation, not identity.

Strong keys versus fragile keys

The strength of a match key is the strength of the resolution it produces. A useful way to rank them:

  • Strong and stable — a verified party identification (ssot__PartyIdentification__dlm), a confirmed personal email or mobile. These point at one party, change rarely, and survive normalization cleanly. Lean on these; they're what lets you match deterministically (see match rules).
  • Usable in combination — name plus date of birth, name plus phone. No single one is decisive, but together they constrain the match enough to be defensible. This is what fuzzy matching exists for.
  • Fragile on its own — a free-text name alone, a shared household email, a role address. Matching on a name by itself is how two different people named the same thing collapse into one unified individual — the over-merge, the privacy-leaking failure. Never resolve identity on a free-text name as a standalone key, especially not for anything that drives a consent-bearing channel.

A key isn't strong because the field is populated. It's strong because the value uniquely and durably identifies a person and survives normalization to a stable form. A perfectly populated ssot__LastName__c is still a fragile key.

Garbage in, garbage resolved — with no error

The keys are the input to identity resolution, and identity resolution inherits their quality exactly. This is the failure mode that surprises people most: bad keys don't throw. A phone field full of inconsistent formats, an email column with casing and whitespace noise, a "customer ID" that's actually re-used across accounts — none of these produce a validation error. They produce bad resolution: over-splits where keys should have matched and didn't, over-merges where a non-unique key matched people who aren't the same.

This is principle 1 in its most literal form: model the keys deliberately. Decide, while the model is still empty, which fields are your match keys, confirm they're populated and normalized, and treat a non-unique or unnormalized key as a defect to fix before identity resolution runs — not a number to explain afterward. And it's principle 4: because the failure is silent, the keys are part of what the business signs off on against real data, not a setting you trust by default.

Related

Reference: