Marketing Customer Information Management
The same customer looks different to every system that touches them
Billing sees an account number. Support sees a ticket history. The ecommerce platform sees an order history tied to a session. The MAP sees an email address with engagement events. Each of these is a legitimate, accurate view of the same human being — and none of them, alone, is the complete picture. Customer information management is the discipline of deciding which attributes belong where, and how they get unified into something marketing can actually act on.
Single customer view and the golden record
A single customer view (SCV) is a unified profile that consolidates every known attribute and interaction for one person across every system and channel into one place. The golden record is the specific, agreed-upon, authoritative version of each field within that profile when multiple source systems disagree — for example, if billing has a customer's address as "123 Main St" and the CRM has it as "123 Main Street, Apt 4," a golden record rule decides which one wins (commonly: most recently updated, or most authoritative source system, per field).
Building a golden record requires three sequential steps: identity resolution (recognizing that records from different systems refer to the same person — see the data requirements lesson), matching/merging (combining their attributes into one profile), and survivorship rules (deciding, field by field, which source wins when values conflict).
Field Source: CRM Source: Billing Golden Record Rule Winner
---------------------------------------------------------------------------------------------------
Email j.doe@gmail.com j.doe@work.com Most recently updated CRM (updated 3 days ago)
Mailing address 123 Main St 123 Main St, Apt 4 Most complete value Billing
Phone (missing) 555-0142 Most complete value Billing
Marketing consent Opted in 2024-11-02 (not tracked) System of record for consent CRM (only source that tracks it)
Lifetime spend (not tracked) $4,280 System of record for $ BillingSurvivorship rules should be written down, not decided ad hoc in a sync job
Marketing use vs. operational/transactional use — different needs, same record
The same customer record serves very different purposes depending on who's using it, and conflating these needs causes real problems. Operational/transactional use (billing, fulfillment, support) needs precision and legal accuracy: the exact current address, the exact current payment method, an audit trail of every change. Marketing use needs behavioral and preference signals layered on top: engagement history, channel preference, inferred interests, lifecycle stage, propensity scores — information that's probabilistic and changes constantly, not strictly "correct" in the way a billing address is correct.
A common mistake is building marketing segmentation logic directly against the operational database, which is optimized for transactional integrity (strict schemas, normalized tables, slow-changing data) rather than for the flexible, frequently-recomputed attributes marketing segmentation actually needs.
Operational vs. marketing view of customer information
| Dimension | Operational / transactional view | Marketing view |
|---|---|---|
| Primary purpose | Accurate billing, fulfillment, support, compliance | Segmentation, personalization, targeting, lifecycle messaging |
| Update frequency | Changes rarely, requires strict validation | Changes constantly — new engagement events daily |
| Tolerance for uncertainty | Low — must be legally/financially accurate | High — propensity scores and inferred interests are probabilistic by design |
| Typical system | ERP, billing platform, core database | CDP, MAP, CRM marketing module |
| Example field | Current legal mailing address | Inferred product category affinity |
Don't let marketing attributes leak into the operational record uncontrolled
Governance: who owns which field
As the number of source systems grows, data governance — explicitly assigning one system as the system of record for each field, and documenting who can edit it and how changes propagate — becomes necessary to prevent the golden record from silently drifting out of sync. This doesn't need to be heavyweight; even a simple shared table mapping field → system of record → update owner prevents most of the conflicts that otherwise surface as "why does the customer's name show differently in two reports."
What's next
A unified customer record is only as good as the data flowing into it in the first place — the next lesson covers the different ways businesses acquire that data and the tradeoffs between them.
Next: Marketing Data Acquisition Strategies →
I build these systems professionally.
Whether it's a RAG pipeline, analytics migration, or AI workflow — let's talk.