Why Are There So Many Types of Customer Data Platforms? It's Complicated.

I spend much of my time these days trying to explain Customer Data Platforms to people who suspect a CDP could help them but lack clear understanding of exactly what a CDP can do. At the end of our encounter they’re often frustrated: a simple definition of CDP still eludes them. The fundamental reason is that CDPs are not simple: the industry has rapidly evolved numerous subspecies of CDPs that are as different from each other as the different kinds of dinosaurs. Just as the popular understanding of dinosaurs – big, cold-blooded and extinct – has little to do with the scientific definition, a meaningful understanding of CDPs often has little to do with what people initially expect.

Let’s start with the big picture. I’ve for years divided customer management systems into three broad categories, which are best seen as layers in a unified architecture. Frequent readers of this blog can feel free to recite them along with me (throwing rice at the screen is optional): data, decisions, and delivery.

Refining this notion just a bit:, the data layer includes systems that create customer data and systems that store it in a unified customer database. Decision systems include several categories such as marketing planning and content management, but the most relevant here are analytics, including segmentation and predictive models, and personalization*, which selects the best message for each individual. The delivery layer holds both systems that send outbound messages such as email and advertising and interactive systems such as Web sites and call centers. An important point is it’s hard to do a good job of delivering messages, so delivery systems are large, complex products.  Picking the right message is just one of many features and often developers’ main concern.

A complete architecture has entries in each of these five categories. But many companies have multiple source and delivery systems that are disconnected: these are the infamous silos. The core technology challenge facing today’s marketers can be viewed as connecting these silos by adding the customer database, analytics, and personalization components that sit in between.

By definition, the CDP fills the Customer Database gap. Some CDPs do only that – I will uncreatively label them as “Data CDPs”.

I’ll also take a slight detour to remind you that the customer database must be persistent – that is, it has to copy data from other systems and store it. This is necessary to track customers over time, since the source systems often don’t retain old identifiers (such as a previous mailing or email address) or, if they do keep them, don’t retain linkages between old identifiers and new ones. There’s also lots of other data that source systems discard once they have no immediate need for it, such as location, loyalty status or life-to-date purchases at the time of a transaction. Marketing and analytical systems may need these and it’s often not possible or practical to reconstruct them from what the source systems retained.  This is especially true in situations where the data must be accessed instantly to support real time processes.

But I digress. Back to our Data CDP, which obviously leaves the additional gaps of analytics and personalization. Why wouldn’t a CDP fill those as well? One answer is that some CDPs do fill them: we’ll label CDPs with a customer database plus customer analytics as “Analytics CDPs” and those with a customer Database, analytics, and personalization as “Personalization CDPs”, again winning no prizes for creativity.  A second answer is that some companies already have chosen tools they want for analytics or personalization.  Like message delivery, those are complicated tasks that can easily be the sole focus of a “best of breed” product or products.

This variety of CDPs also addresses another question that some find perplexing: why one company might purchase more than one CDP.  As you’d expect, different CDPs are better at some things than others. In particular, some systems are especially good at database building while others are good at analytics or personalization.  It often depends on the origins of the product.  The result is that a company might buy one CDP for its database features and have it send a unified feed into a second CDP for analytics and/or personalization. There are some extra cost and effort involved but in some situations they're worth it.

Are you still with me?  I’ve presented three different types of CDPs but hope the differences in what they do and which you’d want are fairly clear.**  Now comes the advanced course: other systems that either call themselves CDPs or offer CDP alternatives.

These fall into many categories but can all be mapped to the same set of five capabilities. Let’s start with Marketing Suites, by which I mean delivery systems that have expanded backwards to include a customer database, analytics and personalization. Many email vendors have done this and it’s increasingly common among Web personalization and mobile app marketing products.   In most cases, these vendors now deliver across multiple channels. Adobe Experience Cloud also fits in here. 

To qualify as a CDP, these systems would need to ingest data from all sources, maintain full input detail, and share the results with other systems. Many don’t, some do. We could easily add another CDP category to cover them – “Marketing Suite CDP” would work just fine. But this probably stretches the definition of CDP past the breaking point. For CDP to have any meaning, it must describe a system whose primary purpose is to build a persistent, sharable customer database. The primary purpose of delivery systems is delivery, something that’s hard to do well and will remain the primary focus of vendors who do it. So rather than over-extend the definition of CDP, let’s think of these as systems that include a customer database as one of their features.


We also have some easier cases to consider, which are systems that provide customer analytics and personalization but don’t build a unified customer database. Some of these also provide delivery functions – examples include marketing automation, CRM, and ecommerce platforms. Others don’t do delivery; we can label them as Orchestration. In both cases, the lack of a unified, sharable customer database makes it clear that they’re not CDPs.  Complementing them with a CDP is an obvious option. So not much confusion there, at least.

Finally, we come to the Customer Experience Clouds: collections of systems that promise a complete set of customer-facing systems. Oracle and Salesforce are high on this list. Both of those vendors have recently introduced solutions (CX Unity and Customer 360) that are positioned as providing a unified customer view. It’s clear that Salesforce does this by accessing source data in real time, rather than creating a unified, persistent database. Oracle has been vague on the details but it looks like they take a similar approach. In other words, the reality for those systems shows a gap where the persistent customer database should be. Again, this makes CDPs an excellent complement, although the vendors might disagree.

So, there you have it. I won’t claim the answers are simple but do hope they’re a little more clear. All CDPs build a unified, persistent, sharable customer database. Some add analytics and personalization.  If they extend to delivery, they're not a CDP.  Systems that aren’t CDPs may also build a customer database but you have to look closely to ensure it’s unified, persistent and shareable. Often a CDP will complement other systems; in some cases, it might replace them.

Still disappointed?  I am genuinely sorry.  But if it helps bear this in mind: while simple answers are nice, correct answers—which in this case means getting a solution that fits your needs – are what matter most.




_______________________________________________
*I usually call this ‘engagement’ but think ‘personalization’ will be easier to understand in today’s context. For the record, I’m specifically referring here to selecting the best message on an individual-by-individual basis, which isn’t necessarily implied by ‘personalization’.

**If you want to know which CDP vendors fit into each category, the CDP Institute’s free Vendor Comparison report covers these and other differentiators. Products without automated predictive modeling can be considered Data CDPs; those having automated predictive but lacking multi-step campaigns could be considered Analytics CDPs; those with multi-step campaigns could be considered Personalization CDPs. There are many other nuances that could be relevant to your particular situation: the report lists 27 differentiators in all.