Is the Composable CDP bullsh*t?

If you keep up with data or marketing trends, there’s a phrase you’re undoubtedly seeing more often: the "Composable Customer Data Platform." You might have heard about it on this blog, in whitepapers from Snowflake and Databricks, or even on the pricing pages of some long-standing CDP companies.

The term is suddenly everywhere and is used to describe almost any type of company that even tangentially touches customer data, which left me wondering: Am I participating in some self-serving vendor bullshit designed to sell software? Or is composability actually a thing people should care about?

In this blog post, I will clearly state what a Composable CDP really is and explain why this approach is gaining traction. At the end, I’d love for you to share your opinion on whether I’m right or if this is a bunch of 💩.

What a Composable CDP really is

A traditional CDP is a monolith that collects, stores, and syncs customer data for an organization. Traditional CDPs live independently from a company’s broader data warehouse, and their components are tightly coupled.

A Composable CDP has a similar purpose but a very different architecture. At a bare minimum, Composable CDPs must fully embrace these organizing principles:

1. The Composable CDP runs on your data infrastructure. The Composable CDP does not store a separate copy of your data. Your organization already has data storage (such as a data warehouse), which should be the underlying storage layer that powers your CDP use cases.
2. The Composable CDP is schema-agnostic. Unlike CRMs that revolve around contact lists or CDPs that revolve around web events, the data warehouse and, thus, Composable CDPs have no limitations or opinions on how data should look. You can orient and activate around anything—households, pets, bank accounts. Just use whatever makes sense to your business.
3. The Composable CDP is modular and interoperable. Every enterprise has some data infrastructure (like event collection, ETL, dashboards, etc.) before deciding to buy a CDP. The Composable CDP works with what you already have and then fills in any gaps in capability that you need. You shouldn’t have to tear down and rebuild your entire house just because you want to renovate the kitchen. As you evolve, this same flexibility lets you swap out components over time, reducing the risk of vendor lock-in.
4. The Composable CDP has unbundled pricing. You only need to pay for the capabilities you’ll use—not the shelfware that comes with the platform.

Traditional CDP Architecture

Composable CDP Architecture

Lastly, the Composable CDP architecture unlocks new features not found in traditional CDPs. An example at Hightouch is Match Booster or, more broadly, support for data clean rooms.

I’ve found that many companies tack on some lightweight warehouse-related capability and suddenly declare they are “Composable.” This is not correct. Composability is a new way of thinking about customer data, MarTech, and software. It has pretty clear attributes and is not something you can transform into overnight.

In a recent conversation, one of our prospects captured the core of this trend:

"The term "Packaged CDP" has become almost like an infection in the market due to the direct association of that term with data silos. Everyone seems to want to get away from that, and by default, the alternative is "Composable." If you ask every provider out there to self-identify, you won't hear many volunteers for Packaged. You'll hear Composable a ton, Hybrid, Connected, and Warehouse-Native, but not a lot of proud Packaged CDPs out there right now.

Composability has become synonymous with any link to the warehouse, and that's definitely not how it works."

I put a fair amount of weight on this interpretation. It’s a lot easier to change your pricing page or sales presentation than to change your software, so vendors are fleeing to the safety of a new term to hide their flaws.

The problem with this is that a Composable CDP is actually a real thing, and its moment has come.

Why is now the moment for Composable CDPs?

The architects behind traditional CDPs weren't stupid. They were simply building for a different time. Specifically, traditional CDPs were invented when companies were just figuring out how to collect data from websites and mobile apps. In these early days, traditional CDPs had to tackle a bunch of problems all at once, and, in the process, they evolved into big, inflexible, and lengthy-to-implement solutions.

As much as they try to deny it, the truth is that traditional CDPs—by design—operate as data silos. From their point of view, this is a feature, not a bug. I know this because my co-founder and I were early engineers at a successful traditional CDP and helped build those features!

But it's 2023, and times have changed. The cloud data warehouse is now the center of gravity for most companies. Data teams already use warehouses to help solve problems like identity resolution and predictive modeling. Sales and marketing teams often don’t think of it this way, but they also rely on warehouses every day to track conversions, pull customer segments, and build dashboards in tools like Looker and Tableau.

Warehouses aren’t perfect, but they’re often the most complete source of data in growing companies. The Composable CDP embraces this investment and opens it up to marketing teams. Your data team has already done so much in the data warehouse — it's kind of crazy to throw that away and start over!

Why companies are choosing the Composable CDP

As the founder of a company that sells a Composable CDP, I talk to people about their customer data needs every day. I admit this introduces a bit of bias, but I’ve tried to sum up the main reasons I've heard from our customers, ranging from startups to massive enterprises, for choosing a Composable CDP.

Composable CDPs are better at activating customer data

When modern businesses think about their "customer data," what they have in mind is a lot more than just user-level properties like names and emails. Depending on your industry, you might also care about other entities like pets, deliveries, movie tickets, vacations, and so on. Composable CDPs natively understand the relationships between these different entities. In stark contrast, after all these years, traditional CDPs still only understand rigid, pre-defined concepts like users and events.

Suppose, for example, that you're a car insurance company, and you want to build an audience of customers who own vehicles purchased after 2015 with policies coming up for renewal in the next three months. Here's the problem: traditional CDPs don't understand vehicles or insurance policies, so instead, you need to hack together user-level properties like last_vehicle_purchase_at and next_renewal_at. This might work at first, but you'll quickly run into other issues like customers that own multiple cars, families that share the same policies, etc. It’s an incredibly frustrating waste of time.

As customers start using a Composable CDP, they tend to find that many of their “craziest” ideas that previously seemed impossible become easy. They run more experiments; they have more fine-grained segments and audiences; as a result, they can run more personalized campaigns and get better outcomes. These benefits are not only because our software is good (though it is); it’s because the Composable CDP sits on top of your warehouse and brings CDP features to the data you already have in the way you naturally structure it.

Only Composable CDPs can activate a company's FULL data

Composable CDPs deliver results faster

Because the Composable CDP is, by definition, modular and works with your existing data and infrastructure, you can get started right away. My sample is probably slightly biased because of the kinds of companies that choose Hightouch, but 90% of our customers launch a live use case on Hightouch the same day they sign their contract. That is a literal impossibility with the months-long implementation that comes with a traditional CDP. Traditional CDPs require companies to effectively build a second data warehouse. This massive implementation project comes with a high risk of failure and isn’t a one-time cost. Composable CDPs, on the other hand, are lightweight and tend to succeed because they mesh with existing infrastructure.

Composable CDPs are more affordable.

Traditional CDPs are outrageously expensive. This is for two reasons.

First, traditional CDPs—by design—have their own data infrastructure, but they cannot replace your internal data warehouse, which you will continue to use for analytics anyways. This means that as a customer, you’ll end up paying to process and store the same data point at least twice, and often many more times.

Second, traditional CDPs—by design—are bundled solutions, so customers find themselves buying an extensive suite of offerings, even if they only need a third of the functionality.

Your own experience with composability may vary, but we’ve heard from many customers who moved to a composable approach and reduced their CDP bill by 40% to 50% or more.

Composable CDPs have less vendor lock-in

The Composable CDP operates off of your existing data warehouse. This means you own your data—without relying on yet another vendor—and are future-proofed even as you change individual components of your CDP. A traditional CDP is a beast to implement and a beast to leave because it’s an all-in-one solution. Only the composable approach allows you to easily swap out vendors for different parts of your data stack at your discretion.

Composable CDPs are stronger at security, privacy, and compliance

Whenever you add a new tool that replicates data, you create a new avenue for a security breach. Of course, any piece of software introduces new risks for security and compliance, but the less surface area, the better. The Composable CDP architecture does not store your customer data, period. While most traditional CDPs struggle to become HIPAA-compliant or data-residency compliant even after years of trying, for Composable CDPs, compliance is a breeze because the data is secured and tightly governed in your warehouse. This is the prime reason for our success in healthcare and financial technology & services.

Wrapping up

I’ve spent years trying to help data and marketing teams activate customer data, and I worry that the vendor community is on a fast track to ruin the concept of a Composable CDP. This is frustrating because the idea actually matters.

This is more than just a vocabulary exercise. Real people with real responsibilities on marketing and data teams everywhere are struggling with customer data. They are putting their jobs and reputations on the line to run campaigns and buy software because they think it will help their companies grow. If the vendor community turns this into one more meaningless concept, I fear people will be slower to adopt and less likely to realize the benefits of this approach.

I am certain the future is composable– not just in enterprise CDPs but across the stack. Companies will use their data warehouse to store and activate customer data, buying just the components they need and achieving the flexibility and scale required to deliver personalized experiences customers deserve. We’ll all be better for it.

But what do you think?

I started this post trying to cut through the noise of our category, and I hope I have helped. But did I? I welcome your thoughts and debate - please, tell me I’m wrong! You can email me at tejas@hightouch.com or join the discussion on my LinkedIn. I hope to hear from you.