Master Data Management for Marketing
MDM is a governance discipline, not a tool
Master Data Management defines, for each core business entity (customer, product, campaign, account), a single authoritative 'golden record' and the explicit rules for which source system owns which attribute of it, how conflicts are resolved, and how changes propagate to every consuming system. Vendors sell MDM platforms (Informatica MDM, Reltio, Profisee), but the actual hard work — agreeing on ownership and resolution rules across marketing, sales, and finance — is organizational, not something software alone solves.
System of record vs system of reference
A system of record is the authoritative source for a given attribute — e.g. your billing system is the system of record for 'is this customer currently paying,' and your CRM is the system of record for 'who is the assigned account owner.' Every other system that displays or uses that attribute is merely a system of reference, consuming a copy. MDM's core job is making this ownership explicit per field, so that when the CRM and the ecommerce platform disagree about a customer's email, there's a documented answer for which one is right, instead of an ad hoc argument every time it comes up.
Typical field ownership map for a B2C marketing org
| Attribute | System of record | Why |
|---|---|---|
| Billing email | Billing/payments platform | Legally tied to the transaction and receipt |
| Marketing email preference | Email/marketing automation platform | Owns consent and subscription state directly |
| Lifecycle stage | CRM or warehouse-computed mart | Derived from cross-system behavior, not any single source |
| Shipping address | Ecommerce/order platform | Tied to actual fulfillment, most current by definition |
| Support tier/plan | Billing/subscription platform | Source of contractual truth |
MDM failure shows up as 'which number is right' meetings
Survivorship rules for merging records
When MDM processes detect that two 'different' records (two CRM contacts, two ecommerce accounts) actually represent the same real entity, merging them requires 'survivorship' rules deciding which value wins per field when the records disagree — most-recently-updated, highest-priority-source, or most-complete-value are common strategies, and the choice should match the field ownership map rather than being uniform across all fields. The merge also needs to preserve a crosswalk back to both original record IDs, since downstream systems and historical reports may still reference either one.
Operationalizing MDM in a modern warehouse-centric stack
Rather than a standalone MDM product, many marketing orgs now implement MDM principles directly in dbt: a dim_customers_golden model that explicitly encodes the field-ownership and survivorship rules in SQL (reading from each source's staging model, applying COALESCE in a deliberate priority order per field), tested with dbt tests asserting uniqueness and referential integrity. This keeps MDM logic version-controlled, code-reviewed, and auditable, rather than buried inside a separate platform's proprietary configuration.
What's Next?
Clean master data only matters if it can actually move reliably between systems — and that depends on the integration patterns and engineering discipline covering how APIs, webhooks, and sync jobs are built and operated.
I build these systems professionally.
Whether it's a RAG pipeline, analytics migration, or AI workflow — let's talk.