MDM matching and survivorship are the two mechanisms that turn duplicate-riddled source data into trustworthy master data: matching decides which records describe the same real-world entity, and survivorship decides — attribute by attribute — which source’s value wins in the resulting golden record.
These two engines are where I spent most of my MDM years at Nestlé Purina, running product master data on Profisee across one of the world’s largest SAP estates. Everything else in an MDM program — the hub, the workflows, the integrations — exists to feed and distribute what matching and survivorship produce. Get them right and the platform disappears into the plumbing; get them wrong and you manufacture corruption at enterprise scale, one confident false merge at a time. This is the playbook I wish I’d had: how the rules actually work, how to set thresholds you can defend, how to tune with real data, and what to do when a merge goes wrong.
Before Matching: Standardize or Suffer
Matching quality is decided before the matcher runs. Raw source data compares badly: “Intl. Business Machines” vs “IBM Corp” vs “I.B.M.” will defeat naive comparison no matter how clever the algorithm. The standardization pass — casing, punctuation, abbreviation expansion, address normalization, phone/email formatting — converts records into comparable form first.
This is also why profiling comes first: you can’t standardize formats you haven’t discovered. When we profiled product data across Purina’s regions, the same product carried different identifier schemes and classification structures per region — no match rule survives contact with that until the crosswalks and standardization exist. Budget real time here; it’s the highest-leverage unglamorous work in the whole pipeline.
Matching: Deterministic, Fuzzy, and the Candidate Problem
Deterministic matching links records on exact (post-standardization) key equality: same GTIN, same tax ID, same normalized email. Fast, explainable, and precise — when a reliable shared key exists. Its limit is coverage: most cross-system duplicates exist precisely because no shared key does.
Fuzzy (probabilistic) matching scores similarity across multiple attributes — edit distance on names, token overlap on addresses, phonetic encoding for spelling variants — and combines the attribute scores into a match score. This is where real duplicate discovery happens, and where all the judgment lives: which attributes contribute, how they’re weighted, and what score means “same entity.”
Every serious program runs both, layered: deterministic rules sweep the easy equalities first, fuzzy rules hunt in what remains. Two practical notes practitioners learn the hard way:
- Candidate selection (blocking) is the scalability trick. Comparing every record to every record is quadratic death at volume. Blocking restricts comparisons to plausible candidates (same postal region, same first-token of name) — and a bad blocking key silently hides true matches by never comparing them. When recall seems mysteriously low, audit the blocking before the scoring.
- Weight attributes by discriminating power, not importance. A shared rare surname is strong evidence; a shared country is nearly none. The business may care most about “name,” but the matcher should care about whichever fields best separate same-entity from different-entity in your data.
Threshold Bands: Auto-Merge, Review, No-Match
A match score means nothing until you decide what to do with it, and the defensible design is three bands, not one line:
- Above the auto-merge threshold: confidence is high enough to merge without human eyes. Set this conservatively — the cost asymmetry demands it (more below).
- The review band: plausible matches routed to a steward queue for human decision. This band is not a failure of automation; it’s where the genuinely ambiguous cases belong.
- Below the no-match floor: treated as distinct entities.
The width of the review band is a staffing decision disguised as a technical setting: widen it and quality rises while the steward queue grows; narrow it and you’re delegating judgment calls to arithmetic. Size the band to the stewardship capacity you actually have — an unworked queue is worse than a narrower band, because it becomes a backlog everyone learns to ignore.
And the asymmetry that should anchor every threshold conversation: a missed duplicate is embarrassing; a false merge is destructive. Undermatching leaves two records where one belongs — visible, annoying, fixable. Overmatching fuses two real entities, and every downstream transaction that touches the merged record makes the eventual unwind worse. When in doubt, thresholds err toward the review queue.
Survivorship: Building the Golden Record Per Attribute
Once a match group exists, survivorship constructs the golden record from it. The rule patterns:
- Source priority (most trusted): a per-attribute ranking of systems — ERP wins for legal name and tax data, CRM for contact preferences, PIM for marketing attributes. The workhorse rule; building the ranking forces the right argument about which system is genuinely authoritative for which facts.
- Most recent: newest value wins. Use sparingly — recency is not accuracy, and one badly governed source with frequent sloppy updates will dominate every attribute you give this rule to.
- Most complete / best quality: prefer values that pass validation or come from records with fewer quality flags.
- Steward decision: route the conflict to a human for attributes where no automated rule is defensible.
The design principle that separates mature configurations from naive ones: survivorship is per-attribute, not per-record. A supplier’s golden record can take its legal name from the ERP, its address from a verified external service, and its category from a steward’s ruling. Platforms that crown one whole “winning record” leave accuracy on the table on every merge.
Two operational rules: document every survivorship decision with its rationale and version history (when the auditor or the angry product manager asks why the golden record says what it says, “the ERP outranks the CRM for that attribute, approved on this date” is an answer; “that’s what the tool did” is not), and route rule changes through the same decision-rights structure as everything else — an untracked survivorship tweak changes every future golden record, and six months later nobody remembers why.
Tuning: The Labeled-Pairs Discipline
You cannot tune what you cannot score. The practice that turns matching from folklore into engineering is a labeled test set: a few hundred record pairs your domain experts have judged by hand — true match, true non-match, genuinely ambiguous — drawn disproportionately from your data’s hard cases (the franchises, the family members at one address, the regional product variants).
Every rule change then gets measured against the labels before it ships: did precision (false-merge avoidance) hold while recall (duplicate discovery) improved? At Purina, the hard cases were regional variants of the same product — records that looked nearly identical but were legitimately distinct entities — and the labeled set was what kept match tuning from quietly fusing them. Rebuild the labels as your data evolves; last year’s test set validates last year’s data.
When Merges Go Wrong: Unmerge and Monitoring
Plan for wrong merges before the first one happens, because it will happen:
Unmerge capability is an evaluation criterion, not a nice-to-have. Unwinding a merge after downstream systems have consumed the golden record means re-splitting attributes, re-pointing transactions, and notifying consumers — ask any platform you’re evaluating to demonstrate it live, with history preserved.
Monitor the engine like the production system it is. Match-rate trends (a sudden spike usually means a source format changed, not a duplicate epidemic), review-queue depth and aging, auto-merge rates per rule, and steward overturn rates — a rule whose auto-merges stewards keep reversing is a threshold set wrong. These metrics belong on the same dashboard as your other data quality monitoring.
The Bottom Line on Matching and Survivorship
Standardize before you match; layer deterministic and fuzzy rules with blocking that doesn’t hide true pairs; run three threshold bands sized to real steward capacity, with the asymmetry — false merges hurt more than missed ones — pushing doubt into the review queue; apply survivorship per attribute under documented, version-controlled rules; tune against labeled pairs, not vibes; and treat unmerge and engine monitoring as first-class. That’s the whole discipline. It’s not glamorous, but it’s the difference between a golden record the enterprise trusts and an expensive way to corrupt data consistently.
Frequently Asked Questions About MDM Matching and Survivorship
What is matching in master data management?
Matching identifies which records — within and across source systems — describe the same real-world entity. Deterministic rules link records on exact shared keys; fuzzy rules score similarity across names, addresses, and other attributes when no shared key exists. The output is match groups that survivorship then resolves into golden records.
What are survivorship rules in MDM?
Survivorship rules decide which source’s value enters the golden record when matched records disagree, attribute by attribute. Common patterns: per-attribute source priority (the workhorse), most recent, most complete, and manual steward decision for high-stakes conflicts. Mature programs document and version every rule.
What is the difference between deterministic and fuzzy matching?
Deterministic matching requires exact equality on a key after standardization — precise, fast, explainable, but limited to records that share reliable keys. Fuzzy matching scores similarity probabilistically across multiple attributes, discovering duplicates that share no key at the cost of tuning effort and genuine ambiguity that needs human review.
How should match thresholds be set?
As three bands: auto-merge above a conservative high bar, a steward-review band for plausible matches, and no-match below the floor. Size the review band to your actual stewardship capacity, and bias toward review rather than auto-merge — a false merge corrupts downstream data in ways a missed duplicate never does.
What is a false merge and how do I prevent it?
A false merge combines two genuinely different entities into one golden record, corrupting every transaction and report that touches it. Prevention: conservative auto-merge thresholds, steward review for borderline scores, a labeled test set heavy on your data’s hard cases, and unmerge capability rehearsed before you need it.
What is blocking in record matching?
Blocking (candidate selection) restricts comparisons to plausible candidate pairs — same region, same name token — so matching scales beyond the quadratic cost of comparing everything to everything. It’s essential at volume, and a poorly chosen blocking key silently hides true matches by never comparing them.
Can survivorship take values from different sources for one record?
Yes — that’s the point of per-attribute survivorship. One golden record can carry its legal name from the ERP, address from a verified external source, and classification from a steward decision. Platforms that select one whole winning record instead of winning values sacrifice accuracy on every merge.
How often should match rules be tuned?
Whenever sources change and on a scheduled review — new systems, format changes, and data drift all degrade rules tuned for last year’s data. Maintain a labeled test set of hand-judged pairs, measure every rule change against it before deployment, and watch steward overturn rates as the live signal that a threshold has drifted wrong.