🥁 This episode is brought to you by Human37, a leading customer data strategy agency in Europe. 🥁
We recently managed to bring together some leading minds in the CDP arena — not to fight or argue, but to find some common ground and put an end to the debate-turned-battle between the Composable and the Packaged CDP camps.
🥁🥁
Here’s the guest list for the episode:
- Boris Jabes from Census represents the Composable CDP camp
- Michael Katz from mParticle represents the Packaged CDP camp
- David Raab from the CDP Institute represents the neutral party that cares deeply about the category (he coined the term, Customer Data Platform, after all)
- Jacques Corby-Tuech, a RevOps practitioner, represents the end user or the beneficiary of a CDP
- Matthew Niederberger, a CDP consultant, represents folks who implement CDPs of all types
And some context on how we landed here:
At Human37, Glenn implements CDPs of all types for companies in Europe. And in my quest to grow this community (thank you for being a part), I talk to a lot of people — all types of stakeholders essentially.
And Glenn and I found one thing in common:
Everybody in the CDP space was confused.
People building CDPs, people selling CDPs, people buying CDPs. Even people using CDPs and those implementing CDPs — everyone was confused and many were frustrated.
And we just wanted to change that.
We also think that this battle between Composable and Packaged CDPs is fruitless — it’s not helping anybody or adding much value. And we wanted to get people together who want to discuss more pressing problems in the data space.
Needless to say, we’re far from achieving that goal but this is a good start and we’re optimistic.
🥁🥁
So, without further ado, welcome to Round 1 of the CDP Rapid Fire! 🥁🥁
In this round, I’ll deliver one statement at a time and each guest will respond with “I agree” or “I disagree”, along with some quick thoughts to support their stance.
What’s really valuable here is that together, these five individuals represent all the stakeholders involved in buying, deploying, and deriving value from a CDP.
Let’s get into it.
Watch the full episode above or on YouTube, and if you prefer to read, well, keep going...
🥁🥁
"A Composable CDP is better suited for engineering-driven organizations."
[Boris] I agree.
[Michael] Depends.
[David] I'll go with "depends" as well, if that's an option.
[Jacques] "Depends" as well.
[Matthew] "Depends," but leading towards "I agree."
"If an organization is starting from scratch, it's faster to implement a Packaged CDP."
[Boris] I might lean for the sake of conciliatory behavior, to agree, but I think it really depends on what "from scratch" means.
[Michael] Yeah, it all depends.
[David] I actually would lean towards Packaged here fairly clearly, but you got a bunch of consultants in the room, they're all gonna say "everything depends." 😆
[Jacques] I lean towards Packaged — it’s a better solution in that term.
[Matthew] Sorry David, I'll have to prove you right — it indeed depends. There are just too many options out there.
"The pricing structure of Packaged CDPs must be simplified."
[Boris] I don't think I know the ins and outs of every single Packaged CDP's pricing complexity, but I would definitely say that people are unhappy with the pricing of CDPs.
[Michael] I don't know if “simple” is the single most important defining characteristic of pricing. We're gonna be making a pretty cool announcement over the course of the next month or so — I think we've solved a lot of the problems that people have with respect to the historic approach that CDPs have taken to pricing. 🤔
[David] I don't think I've ever heard anyone complain about the complexity of the pricing structure. So I'll go with, no, I don't think that's a major issue in the industry.
[Jacques] I've bought a few CDPs in my time and I've never had any issues with the pricing complexity. It's all been pretty explicitly clear.
[Matthew] I wholeheartedly agree. I think this area needs a lot more transparency.
"Data governance and privacy compliance are a lot easier to manage using a Packaged CDP since those components are fully integrated.”
[Boris] Disagree. Privacy and compliance only work if you have the really complete picture. And, I'll concede that having a ready-to-go thing is good, but you need to have the full picture.
[Michael] Completely agree. These capabilities need to be integrated from the point of data collection. So the system that provides an access point to the ecosystem of tools can also provide an appropriate choke point as well. There's really no other approach that solves it as elegantly as the CDPs like mParticle that focus on the end-to-end movement.
[David] I disagree, because very few companies have all the privacy-relevant data in their CDP. So it just ain't that simple.
[Jacques] For me, it's more of a people problem than a technology problem. Whether you do Packaged or Composable, you're gonna have to have people set up the right systems and processes. 💯
[Matthew] I'm definitely in the middle again, so depends. Jacques made a point there with being a people problem. It's a people, money, and tech problem — it's all combined. Somebody needs to have an overview of all your data and that goes beyond any piece of technology. 💯
"Organizations can assemble a Composable CDP using components offered by Packaged CDPs."
[Boris] I suppose theoretically, but I think I'd have to disagree because how do you swap out one of the pieces? It seems complicated or not easily doable.
[Michael] Everything that I am talking about is really through the lens of mParticle, not CDPs very broadly. So if the solution offers configurability in the various components, then, yeah, of course, you can mix and match. It probably makes a lot more sense than choosing multiple different CDPs and layering them on top of each other — we're all kind of competitive and don't really like integrating. 😆
[David] Well, maybe in theory. People do have multiple CDPs, as Michael just said, and they do string them together, but if you really wanted a componentized solution, that's just weird.
[Jacques] I think in theory, yes, but, in practice, there are elements of both that do slightly different things in slightly different ways that they're not replaceable. So it's a Venn diagram and there is a space that's shared, but they're still two separate circles mostly.
[Matthew] Yeah, so I'm slowly seeing a trend where some lacking modules or parts of a Packaged CDP are replaceable by new and better, possibly even cheaper, solutions coming onto the market. So yeah, I agree with that, absolutely.
"Packaged CDPs are more suitable for organizations where Identity Resolution is a must-have."
[Boris] I think if identity resolution is a must-have, then you are almost certainly not a simple organization, and therefore, you must invest in your own entity matching of some sort, and de-anonymizing users off your website is kind of level 1. So if it's really crucial to your organization, then disagree.
[Michael] I would agree. The reason you need identity resolution is to solve for things like privacy as well as personalization. And not all identity resolution is the same. The way we tend to think about it is providing an open flexible framework where everything is completely configurable and the customer is in total control over the waterfall and the rules that they create in terms of how things get matched because that has a huge implication in terms of how the data ends up getting activated. So if the goal is personalization, then, you absolutely need integrated identity resolution capabilities.
[David] Well, ID resolution is a must-have for everyone, but there are plenty of ID resolution systems that exist outside of Packaged CDPs and, of course, the Packaged CDPs vary greatly in their ID resolution capabilities, so overall I'm gonna disagree, just because I think it's framing the issue probably in a way that's not terribly relevant. 👍
[Jacques] As David said, ID resolution is usually fairly critical for most businesses, but how you do it is less important as long as you've got that data resolved and you do the really mission-critical stuff like data privacy — it doesn't really matter where and how you do it. 💯
[Matthew] Disagree as well. It's a nice feature and would make life a lot easier to have everything in a Packaged CDP, but it's not required.
"Composable CDPs are better suited for organizations where data models are complex with many-to-many relationships between business entities."
[Boris] I think the more you want flexibility, the more you're gonna want to be Composable, so I would say, yes.
[Michael] I would disagree because I think that there are varying levels of functionality that I've seen across the reverse ETL landscape. I'm not familiar with the way that Census does it but I know others are definitely more limited in that regard.
[David] Well, it depends on the CDP and it depends on the Composable tools there. Some CDPs are built for B2B and they're gonna do just fine, thank you very much.
Some CDPs do have severe constraints on the data models and others don't. And the same on the other side. Let's assume Composable in practical terms means you're using a data warehouse as your primary data store — that's an inherently flexible technology. So if you're really asking which has the most flexible data model and you're not gonna pay too much attention to the differences between the CDPs, you will get the maximum flexibility using a data warehouse.
[Jacques] I mean for me this isn't a CDP or reverse ETL problem — this is a downstream destination issue where you're trying to actually unlock the use of that data. I've experienced both working fine, depending on the downstream destination. It really depends on where you're trying to send the data and how flexible that downstream system is. 💯
[Matthew] We just don't have enough data points to properly answer that question, but in general, as David said, if the data warehouse is your source, you can be as flexible as you can be. But you know, Packaged CDPs can also be quite flexible — you can get creative within them.
“Behavioral data, a key element of a CDP, is much easier to collect using components offered by a Packaged CDP.”
[Boris] I think it’s much easier to aggregate and collect from everywhere. If it’s just coming from your website (or app), it’s 100% easier to collect using a Packaged CDP. But the more it’s spread out across other systems that also generate first-party data (billing, engagement, etc), I think I’d disagree.
[Michael] From a collection standpoint, absolutely agree — at least through the lens of mParticle where we’ve built 25 native SDKs for data collection. The alternative is using ETL tools and when you look at their connectors, some ETL vendors don’t even accept identity in a vast majority of their connectors, which is a key component of behavioral data.
[David] I like Michael’s answer mainly because CDP vendors have put a lot of energy into the data collection side of things. So comparing that with a generic data collection tool or a “collection of data collection tools”, you’re probably getting an easier solution with a Packaged CDP.
[Jacques] I agree. The other thing to look at is that you can implement real-time workflows with a Packaged CDP which is quite an important factor for a lot of businesses.
[Matthew] Well there are a couple of composable data collection solutions available right now whereas most of the leading CDPs started as data collection tools 8-10 years ago. So, I would have to disagree as other Composable solutions do exist.
🥁🥁
The above transcript has been slightly edited for clarity and brevity. You can watch the whole of Round 1 above or an abridged version on LinkedIn.
And here’s Round 2 of the CDP Rapid Fire! 🧯
🥁🥁
.svg)
.svg)
.svg)