Customer Data Platforms vs Master Data Management: How They Differ

My wanderings through the Customer Data Platform landscape have increasingly led towards the adjacent realm of Master Data Management (MDM). Many people are starting to ask whether they’re really the same thing or could at least be used for some of the same purposes.

Master Data Management can be loosely defined as maintaining and distributing consistent information about core business entities such as people, products, and locations. (Start here
if you’d like to explore more formal definitions.) Since customers are one of the most important core entities, it clearly overlaps with CDP.

Specifically, MDM and CDP both require identity resolution (linking all identifiers that apply to a particular individual), which enables CDPs to bring together customer data into a comprehensive unified profile. In fact some CDPs rely on MDM products to perform this function.

MDM and (some) CDP systems also create a “golden record” containing the business’s best guess at customer attributes such as name and address. That’s the “master” part of MDM.  It often requires choosing between conflicting information captured by different systems or by the same system at different times. CDP and MDM both share that golden record with other systems to ensure consistency.

So how do CDP and MDM differ? The obvious answer is that CDP manages a lot more than just master data: it captures all the details of transactions and behaviors that are not themselves customer attributes. But many MDM products are components of larger data integration suites from IBM, SAP, Oracle, SAS, Informatica, Talend and others. These also manage more than the identifying attributes of core data objects. You could argue that this is a bit of a bait-and-switch: the CDP-like features in these suites are not part of their MDM products. But it does mean that the vendors may be able to meet CDP data requirements, even if you need more than their MDM module to do it.

Another likely differentiator is that MDM systems run on SQL databases and work with structured data. This is the best way to manage standardized entity attributes.  By contrast, CDPs work with structured, semi-structured and unstructured data which requires a NoSQL file system like Hadoop. But, again, the larger integration suites often support semi-structured and unstructured data and NoSQL databases.  So the boundary remains blurry.

On the practical level, MDMs are primarily tools that IT departments buy to improve data quality and consistency.  Business user interfaces are typically limited to specialized data governance and workflow functions. CDPs are designed to be managed by business users although deploying them does take some technical work. Marketing departments are the main CDP buyers and users while MDM is clearly owned by IT.

One CDP vendor recently told me the main distinction they saw was that MDM takes a very rigid approach to identity data, creating a master ID that all connected systems are required to use as the primary customer ID. He contrasted this with the CDP approach that lets each application work with its own IDs and only unifies the data within the CDP itself.  He also argued that some CDPs (including his, of course) let users apply different matching rules for different purposes, applying more stringent matches in some cases and looser matches in others. I’m not sure that all MDM systems are really this rigid.  But it’s something to explore if you’re assessing how an MDM might work in your environment.

Going back to practical differences, most CDPs have standard connectors for common marketing data sources, analysis tools, and execution systems. Those connectors are tuned to ingest complete data streams, not the handful of entity attributes needed for master data management.  There are certainly exceptions to this among CDPs: indeed, CDPs that focus on analytics and personalization are frequently used in combination with other CDPs that specialize in data collection. MDM vendors are less marketing-centric than CDPs so you’ll find fewer marketing-specific connectors and data models. Similarly, most MDMs are not designed to store, expose, reformat, or deliver complete data sets. But, again, MDMs are often part of larger integration suites that do offer these capabilities.

So, where does this leave a weary explorer of the CDP jungle? On one hand, MDM in itself is very different from CDP: it provides identity resolution and shares standard (“golden”) customer attributes, but doesn’t ingest, store or expose full details for all data types.  On the other hand, many MDM products are part of larger suites that do have these capabilities.

The real differentiator is focus: CDPs are built exclusively for customer data, are packaged software built for business users (mostly marketers), and have standard connectors for customer-related systems. MDM is a general-purpose tool designed as a component in systems built and run by IT departments.

Those differences won’t necessarily show up on paper, where both types of systems will check the boxes on most capabilities lists. But they’ll be clear enough as you work through the details of use cases and deployment plans.

As any good explorer will tell you, there’s no substitute for seeing the ground on foot.

Wondering How Customer Data Platforms Relate to Other Marketing Systems? Here's a Picture

I was asked the other day about the distinction between Customer Data Platforms and Journey Orchestration Engines. My immediate answer was “Some CDPs are JOEs and some JOEs are CDPs. A CDP is a JOE if has journey orchestration. A JOE is a CDP if its data is accessible to other systems. Think Venn diagram with two intersecting circles.”  It's not clear the answer helped, but it did get me thinking about clarifying with a Venn diagram.  The diagram I originally had in mind was this one, showing that CDPs unify customer data and make it available, while JOEs unify customer data and select messages. Systems that do all three are both a CDP and a JOE.

On reflection, that’s not the right way to draw a Venn diagram. Each circle should represent one set of traits. So the picture should really look like this:

That's fine, but it seems odd that “unify customer data” has no system associated with it. Is there a type of system that just unifies customer data without making it accessible or selecting messages? Come to think of it, there is.  Systems that just do customer matching used to be called Customer Data Integration but I don’t hear that much any more.  Sometimes people talk about Identity Resolution but mostly it seems that Customer Data Integration has been absorbed by the larger category of Master Data Management (MDM) systems, which integrate all kinds of data. So let’s add MDM as the label for that.    

But why stop there?  Let's see how other systems would fit into the diagram. First to come to mind was marketing automation platforms (MAPs), which also select messages (like a JOE) but don’t build a unified customer database or offer open data access. The diagram with MAPs included looks like this:

The next is a Data Lake. It provides open data access like a CDP, but doesn’t build a unified view of the data.  Adding that to the diagram gives us:

Hmm, what about CRM? In many ways its out there with MAP: another system that selects messages but doesn’t build a unified database. So we need to introduce a new split, of marketer-controlled vs. sales controlled. I'll give control a different color for clarity.  Apologies to CRM people that your circle is so tiny; I'm not suggesting anything about the importance of your systems.

Still thinking about control, Data Management Platforms (DMPs) look a lot like Marketing Automation Platforms: they’re marketer-controlled systems that select messages (sort of) but don’t unify data from all sources or provide open access. So unless we want to further subdivide the marketer controlled space, they share the same location as MAPs.

Since control has its own color, Data Lake and MDM jump out as not having an owner. In fact, they’re both typically owned by corporate IT, so we can easily add that circle.

This raises one more question: is there an IT-controlled equivalent of a CDP?  That would be a system that unifies customer data and provides open access but is owned by IT not marketing.  You betcha.  It might be an Enterprise Data Warehouse (EDW) if that has all the access features of a CDP (high speed, flexibility, etc.). But most EDWs don’t meet that standard. So let’s just call it an Enterprise-controlled CDP, or ECDP, if you’re wild and crazy enough to accept a four letter acronym. You’ll remember there’s some debate about whether marketing or IT should really own the CDP.  This doesn't provide an answer but it does give a clearer picture of the question.

I've summarized this information in a table below.  Still confused?  We just posted a answers to Frequently Asked CDP Questions on the CDP Institute blog.  Maybe that will help.