There’s been some interesting debate lately about CDPs vs. CDWs — customer data platforms vs. cloud data warehouses. If CDWs such as Snowflake, Databricks, AWS Redshift, etc., are becoming a universal data layer in companies, is there still a role for domain-specific data platforms, such as marketing-controlled CDPs?
The short answer, in my opinion, is “Yes, but it depends…”
There is still a significant distinction between live business operations systems that run in real-time serving customers and employees — CRMs and ERPs are quintessential examples — and analytical and large-scale storage platforms such as data lakes and data warehouses. They have different functionality, different trade-offs in costs, speed, and scale, and different users and use cases that they’re optimized for.
Of course, the two are increasingly symbiotically entwined, as shown in the “DataOps ecosystem” that I’ve crudely illustrated here:
Front-line apps and ops feed into data lakes and warehouses. And increasingly, that shared data layer and various models, transformations, and machine learning algorithms run on top of it are feeding back into front-line apps and ops — the “reverse ETL” capability, as it’s often called.
A few of my CDP vendor friends objected that CDPs weren’t explicitly represented on that ecosystem map. However, I actually did envision CDPs as a part of that ecosystem — but with the caveat that it depends on which category they’re in:
- Are they front-line apps & ops?
- Are they connectors (iPaaS)?
- Are they event streams and external data managers?
- Are they data warehouses?
- Are they data transformation engines?
- Are they business intelligence tools?
- Are they a kind of ETL + reverse ETL solution?
The answer is: it depends on the CDP.
Some fit very clearly into one or two of those categories. Some of them span many, but with a domain-specific bent towards marketing and customer experience. Some provide very specific services, such as identity resolution (which I would put in the apps & ops layer, as it’s often integral to real-time delivery of customer-facing services).
The more a particular CDP sits towards the bottom of that ecosystem diagram, the more growing capabilities in CDWs and their related technologies are overlapping them — and I suspect will steadily overtake them.
The more a CDP sits towards the top of that ecosystem diagram, however, the less of a threat CDWs will be — at least for the next few years.
Of course, the more a CDP sits towards the top, the more likely the competitive debate is around CDPs vs. CRMs. Depending on who you ask — especially if you ask a CDP vendor or a CRM vendor — you’ll probably get different answers. (And since I work at one of the leading CRM platform companies, you should assume my answer there would be biased.)
But truthfully, I find this debate blurred by labels rather than actual capabilities.
Which led me to recall a model that David Raab — the world’s leading CDP expert who literally invented the category — proposed years ago to frame the capabilities of different customer management systems: Data, Decisions, and Delivery.
If you evaluate individual platforms and your overall martech stack (or, really, your overall business tech stack) by the ability to fulfill these functions, you can rise above the Battle of the Labels.
Most business leaders don’t care — or shouldn’t care — about CDWs vs. CDPs vs. CRMs. Remember: they’re not necessarily mutually exclsuive, and as Meatloaf said, “Two out of three ain’t bad.” But getting the right capabilities in place is crucial.
What’s even more important is how you leverage those capabilities in the design of your business architecture, your back-stage operations and employee experience (EX), and your front-stage customer experience (CX). Ultimately it is your Design — more so than any technology for Data, Decisions, or Delivery — that differentiates your company from your competitors.
Thinking about all that, and then also mixing in thoughts about build vs. buy trade-offs and the evergreen questions about how vendors can differentiate themselves in a massive martech landscape, led me to draw the diagram at the top of this post.
It incorporates Raab’s technology layers for Data, Decisions (which I’ve renamed Decisioning to more clearly emphasize that it’s a technology, not a human act), and Delivery, but it also adds a fourth “D” for Design.
I distinguish between three kinds of Design:
- Design of your business technology and operations architecture
- Design of your operational processes and employee experience (EX)
- Design of your front-facing customer experience (CX)
I call these inner design, middle design, and outer design, respectively.
On the y-axis, we go from things you should probably buy to things you should probably build. In general, you should buy as much technology as you can, and instead invest your “build calories” towards the design layer, where your business can have greater comparative advantage.
On the x-axis, we go from things that are more commoditized to things that are more differentiated.
Overall, technology trends towards commoditization more so than design. But design has patterns and best practices that can be inspired by or outright borrowed from others. Technology architecture in particular — inner design — rarely has to be invented from scratch for each company out there.
But customer experience, well, that’s the single biggest lever of differentiation most companies have.
Within technology, I’d suggest that delivery is the most commoditized — we all use the same protocols for sending email and rendering web pages. Decisioning, on the other hand, is the most differentiated. There are arguably an infinite number of things to decide and infinite ways to algorithmically decide them.
Data sits in between the two. The core capabilities of CDWs are largely commoditized. But the services that get layered on top of them can be quite differentiated. And specialized data management systems — such as identity-focused CDPs — can be differentiated too, by the use cases they’re optimized for and the services they embed.
And this bring us full circle back to the CDP vs. CDW debate. CDPs (and, for that matter, CRMs) often blend data and decisioning for their customer-centric use cases. But in an expanding data ops ecosystem around CDWs, there’s blending of data and decisioning too — modeling, transformation, machine learning, etc., are making decisions with data.
While this doesn’t provide an easy answer, I do hope this framework helps in thinking about how the pieces fit together in your marketing technology strategy.
As one last parting variation on this model, one of the reasons that there are so many different martech solutions on the planet is because most marketing platforms and apps combine elements of data, decisioning, and delivery together — and have an opinionated way of enabling middle design (process, EX) and outer design (CX).
These combinations have effectively an infinite canvas for martech vendor diffeneriation. Which particular differentiating features have the greates impact for their customers — well, that’s where the real competition in martech is happening.
