Master data management: one golden record that sticks

Support has three tickets open for the same human. CRM shows Sam Lee with email A. Billing shows Samuel Lee with email B. The warehouse has both as separate customers, so lifetime value is split and the “VIP” flag never fires. Marketing wonders why churn models look weird. Nobody wonders enough to fix the root: there is no trusted master record for “who is this customer?”

Master data management (MDM) is the discipline of creating and maintaining authoritative records for shared business entities (customers, products, suppliers, locations, chart-of-accounts members) and syncing those truths to the systems that need them.

This guide is for analysts and data people who feel the pain in joins and dashboards, and for leaders who keep funding “another customer 360 project” that dies in integration. You will get plain definitions, architecture patterns, a match-and-merge sketch, governance hooks, and a realistic rollout path. Pair with data governance and quality habits from the rest of Analytics Made Simple.

What you’ll learn

What master data is (and what it is not)
Why MDM shows up as analytics pain
Hub, registry, and coexistence patterns in plain language
Match, merge, and survivorship without vendor fog
A 90-day starter plan that does not require boiling the ocean

Master data vs the rest of your data

Kind	What it is	Example
Master data	Shared nouns the business reuses	Customer, product, store
Transaction data	Events and facts	Orders, payments, clicks
Reference data	Codes and lists	Country codes, status enums
Unstructured	Docs, tickets text, images	Support transcripts

MDM focuses on the nouns. If the nouns are wrong, every fact you hang on them is wrong in multiple places at once.

Why MDM matters for analytics

Analytics is mostly joining things. Joins need keys. Keys need agreement. Without master data you get:

Double-counted customers and broken retention curves
Product hierarchies that do not match the website nav
Supplier names that never align between procurement and finance
Hours lost to “which id is the real id?” in every onboarding

MDM is less romance, more traffic control for identity.

Core jobs MDM must do

Ingest candidate records from source systems
Match records that likely refer to the same real-world entity
Merge / link them under a surviving golden id (or a link set)
Survivorship pick which field values win when sources disagree
Publish the golden record or crosswalk back to consumers
Govern changes, stewardship queues, and quality metrics

Match rules (toy example)

Suppose two customer rows:

A: email=sam@example.com, phone=null,   name=Sam Lee,   zip=94107
B: email=null,             phone=4155550199, name=Samuel Lee, zip=94107

A simple rule set might say: exact email match = auto-merge; else if normalized name equality and same zip and close phone = steward review; else keep separate. Real systems add fuzzy name scores, address standardization, and historical ids. The idea stays the same: write rules you can explain to Support.

Survivorship

When CRM has a mobile phone and billing has a landline, which wins? Survivorship rules answer that. Example policy: “verified billing address wins over marketing address; most recently verified phone wins; never overwrite a verified email with a blank.” Write it down. Otherwise the last batch job wins, which is not a strategy.

Architecture patterns (without the brochure)

Pattern	Plain idea	Tradeoff
Registry	MDM stores links between source ids, sources keep details	Lighter, but consumers must resolve links
Hub / consolidation	MDM stores the golden record and serves it	Powerful, more integration work
Coexistence	Sources stay active; MDM syncs both ways with care	Flexible, easy to get into sync loops if careless
Warehouse-led	Build golden tables in the warehouse first	Great for analytics; apps may still be inconsistent

Many teams start warehouse-led for analytics (a golden dim_customer) while politics catch up for operational MDM. That is valid if you label it honestly: “analytics golden” is not yet “every app writes back.”

Choosing scope

Do not MDM the universe. Rank entities by pain × reuse:

Customer / account (usually first for B2C and B2B)
Product / SKU / offer
Location / store / region
Supplier / vendor

Pick one. Define success metrics before buying software: duplicate rate, match precision on a labeled sample, time-to-resolve steward queue, % of dashboards using the golden id.

Governance and stewardship

MDM without stewardship is an automated way to merge the wrong people. You need:

A steward queue for uncertain matches
SLAs so the queue does not become a junk drawer
Access rules for who can edit golden attributes
A change log when a merge or split happens (splits will happen; people marry, companies rebrand, data entry fails)

This is where MDM meets data governance. The definition of customer lives with a domain owner; the MDM system enforces it operationally.

Common challenges

Challenge	Symptom	Mitigation
Source quality	Garbage in, golden garbage out	Fix entry validation at source; do not only clean downstream
Political ownership	Every app wants to be system of record	Write RACI; escalate once; document losers too
Over-matching	Two real people become one	Precision targets; steward review for medium scores
Under-matching	Duplicates remain	Tune rules; add trusted keys; measure residual dupes
Sync loops	Field flips every night	Clear direction of authority per attribute
Analytics only	Apps still create dupes	Be honest about scope; plan operational publish later

90-day starter plan

Days 1-15: Choose entity. Pull a sample of duplicates that hurt a real KPI. Label 200 pairs as match / not match for testing.
Days 16-40: Build a warehouse golden table with explicit rules and a crosswalk of source ids. Publish one dashboard on golden ids only.
Days 41-60: Stand up a steward process (even a spreadsheet queue at first). Track open cases and error types.
Days 61-90: Automate the top match rules. Present before/after duplicate rates. Decide whether you need a commercial MDM platform or can continue warehouse-led.

Buying enterprise MDM software on day one without labeled examples is how you get a multi-year implementation with no baseline.

How to talk about this with leadership

Skip “single source of truth” poetry. Show one broken journey: duplicate customer → wrong LTV → bad win-back spend. Show the cost of analyst hours. Show the residual risk if finance and product never share an id. Then ask for a pilot, not a program rename.

Quick recap

Master data is the shared nouns; MDM keeps their identities coherent
Match, merge, survivorship, publish, and steward are the core jobs
Start warehouse-led if needed, but label the scope honestly
Measure duplicate rate and steward queue health
Pilot one entity for 90 days before platform theater

A useful mental model is passports. People collect stamps (source systems). The passport number (golden id) should stay stable even when the photo or address updates. When two passports actually belong to one traveler, merge carefully and keep a history. When one passport was wrongly issued to two travelers, split and apologize to the reports that assumed otherwise.

Data engineers often ask whether MDM belongs in the warehouse or in an app platform. The honest answer is “both, eventually, for different consumers.” Analytics can move first because it reads. Operational MDM must write back without creating loops. Sequence the work so each stage has a user who cares.

If you are evaluating vendors, bring your labeled match pairs and ask them to run a bake-off on your messy data, not on a polished demo tenant. Ask how stewards work day to day. Ask how splits are handled. Pretty graphs of “customer 360” do not survive a bad merge policy.

Write the messy edge cases in the open. Hidden footnotes become tribal knowledge and then become outages.

If two teams need different definitions, name both clearly instead of forcing a fake compromise that satisfies nobody.

Ship the smallest useful artifact this week: a definition card, a quality check, or a retired vanity chart. Momentum beats manifesto.

Teach newcomers where the source of truth lives. Onboarding is a governance surface whether you designed it or not.

When something fails, prefer a short postmortem over a new committee. Fix the rule or the test that should have caught it.