Identity Resolution
Two rule types, two jobs
Identity resolution is configured in a ruleset. Match rules decide which records are the same person or entity; reconciliation rules decide which value survives when matched records disagree. Confusing these is the most common trap on this domain.
Match rules use criteria such as exact match, normalized match (case, spacing, and punctuation normalization for emails and phones), and fuzzy match (typos, transpositions) on fields like Email, Phone, and Party Identification. Criteria inside one rule are ANDed together; separate match rules within a ruleset are ORed. Reconciliation options include Most Recent, Most Frequent, Source Priority, and Last Modified - choose based on whether recency, volume, or system of record should win.
Output
A completed ruleset run produces Unified Individual records plus Unified Link objects that tie source records to the unified profile. Only after that do unified-profile segments and unified attributes exist. Rulesets run on a schedule and can also be run on demand; you cannot edit a ruleset while a run is in progress.
Traps
- Assuming identity resolution runs automatically at ingestion.
- Applying fuzzy matching to a field that should be exact, such as a stable customer number.
- Forgetting that match rules only find candidates - reconciliation assigns the winning values.
- Expecting existing unified profiles to update without a subsequent ruleset run.
Rule of thumb
Match answers "are these the same?" Reconciliation answers "which value do we trust?" If a question asks why a customer's name or email looks outdated, inspect reconciliation settings, not the match rules.