Advanced Identity Resolution: One Traveler, Three Identities, Messy Data

The scenario

Altavia Airways has three pictures of every traveler: a 25-million-member loyalty program, booking records arriving from global distribution systems, and a mobile app with its own account store. The fundamentals build covered wiring sources like these into Data 360 and running a first ruleset. Altavia did exactly that — and the results were quietly wrong in both directions.

Under-merged: Robert Keller in loyalty, Bob Keller in bookings and R. Keller in the app stayed three profiles, so the agent greeting a Gold member had no idea about his complaint from last week's flight. Over-merged: a travel agency books hundreds of passengers with the agency's own email on every record — exact email matching fused hundreds of strangers into one monster profile. And a family sharing one household email got merged into a single "traveler" with two frequent-flyer numbers.

Airline data is the identity-resolution stress test: name variants across systems, third-party contact points, shared households. This post is about tuning past the defaults — assuming you already know what rulesets, match rules and reconciliation rules are from Part 1.

First: stop feeding the matcher poisoned keys

Altavia's worst problem — the agency-email mega-profile — is not a match-rule problem. No rule tuning survives a key that genuinely is shared by hundreds of people. The fix belongs upstream, before identity resolution ever sees the data:

• Classify contact points at ingestion. Bookings carry a channel code that distinguishes direct bookings from agency bookings. Altavia added a formula field on the stream marking agency-channel emails, and mapped only direct-booking emails to Contact Point Email. Agency emails still exist on the booking DMO for operations — they just no longer participate in matching.
• Normalize before you match. Trim, lowercase, strip formatting at the mapping stage where the source is sloppy. The match engine has normalized methods (below), but garbage keys with real-looking shapes — noemail@test.com, na@na.com — need an explicit exclusion list at ingestion.

Fuzzy matching: what the precision levels actually do

With poisoned keys excluded, Altavia turned to under-merging. Match rule criteria support match methods beyond exact: normalized variants (email, phone) and fuzzy methods backed by an AI language model trained on names at global scale — it catches misspellings, diacritics ("José"/"Jose") and nickname synonyms ("Bob"/"Robert"), which is precisely the Keller problem.

Fuzzy methods come in three precision levels, and the level is a risk dial, not a quality dial:

The design principle: every rule needs an anchor. Fuzzy criteria widen a match; an exact criterion (normalized phone, loyalty number, passport-derived key) justifies it. Fuzzy-on-fuzzy rules are how strangers get merged.

Altavia's ruleset, rule by rule

Match rules OR together — a profile pair unifies if any rule's criteria all pass. Altavia ships four:

Rule 1 — Loyalty anchor (exact)
  Loyalty_Number__c        : Exact

Rule 2 — Contact-point anchor
  Email (Contact Point)    : Exact Normalized
  First Name               : Fuzzy — High precision
  Last Name                : Exact

Rule 3 — Phone anchor
  Phone (Contact Point)    : Exact Normalized
  First Name               : Fuzzy — Medium precision
  Last Name                : Exact

Rule 4 — Booking identity
  Frequent_Flyer_Ref__c    : Exact
  Birth_Date__c            : Exact

Note what Rule 2 does to the household problem: a shared family email alone no longer merges — the fuzzy-high first name plus exact last name means Priya and Arjun Mehta at the same address stay two travelers, while Preya and Priya Mehta collapse into one. That single precision choice was the difference between the program working and support calls about "my husband's boarding pass is on my app."

When teams genuinely disagree on risk tolerance — service wants conservative merging, marketing wants coverage — Data 360 supports multiple rulesets, each producing its own unified profile set. Altavia decided against it: two universes of unified IDs means every downstream consumer (graphs, segments, agents) must pick one, and the operational overhead outweighed the flexibility. Reach for a second ruleset only when two consumers truly cannot share one definition of "same person."

Reconciliation: who wins each field

Matching decides which profiles unify; reconciliation rules decide what the unified profile says when sources disagree. The available policies — source priority, last updated, most frequent — are chosen per field, and treating that as one global decision is the second most common tuning mistake. Altavia's grid:

Write the "why" column down somewhere real. Six months later, when marketing asks why the unified email isn't the one from last week's booking, the answer should be a design decision you can point to — not archaeology.

Measure, then loosen — never the reverse

Tuning without measurement is guessing. Two instruments matter:

• The ruleset's processing results report the consolidation rate — how much source profiles shrank into unified ones. Track it per run: a sudden jump after a rule change means a rule started over-matching; barely above zero means your keys never overlap and the rules aren't the bottleneck — the data is.
• A spot-check query against the unified link DMO, reviewing the biggest unified profiles first — that's where over-merges hide:

SELECT
    l.UnifiedRecordId__c AS unified_id__c,
    COUNT(l.SourceRecordId__c) AS source_profiles__c
FROM UnifiedLinkssotIndividual__dlm l
GROUP BY l.UnifiedRecordId__c
ORDER BY source_profiles__c DESC
LIMIT 50

A traveler with five source profiles is plausible. A "traveler" with three hundred is an agency inbox you missed. (Check the exact link-object name in your org — it carries your ruleset's suffix, e.g. UnifiedLinkssotIndividualIr1__dlm.) Altavia reviews this list after every ruleset change, before anything downstream consumes the new profiles.

What you learned

• Shared keys (agency emails, household addresses) are an ingestion problem — exclude them from matching before tuning anything.
• Fuzzy precision is a risk dial; anchor every fuzzy criterion to an exact key, and default to high/medium precision.
• Match rules OR together — design each rule to be independently trustworthy.
• Reconciliation is per-field policy design: source priority, last updated and most frequent each have a right home.
• Track consolidation rate and audit the largest unified profiles after every change; loosen incrementally, never all at once.

Next in the advanced series: streaming and the real-time layer — because a perfect profile that arrives late is still the wrong answer. The full track lives on the Data 360 page.

Sources: Salesforce Help — Identity Resolution Match Methods · Match Rules for Individuals · Identity Resolution Reconciliation Rules