7 myths about Composable CDPs, busted

A few years ago, the term Composable CDP didn’t even exist. The idea that you could access all of the core components of a traditional CDP directly from your existing data infrastructure was unheard of.

Fast forward to today, and things look very different. The Composable CDP is firmly established in the industry–and it works. In response, major CDP vendors are either critiquing Composable CDPs or marketing themselves with the word “Composable” without actually changing their infrastructure. In this blog, we’ll clearly state what a Composable CDP is and bust the seven biggest myths about it.

Defining the “Composable CDP”

A Customer Data Platform (CDP) deals with customer data. It collects, stores, models, and finally activates this data to tools that marketers use. Traditional CDPs are packaged monoliths that perform all of these services together, notably storing customer data within their own systems. The Composable CDP accomplishes these same goals–collecting, storing, modeling, and activating customer data–with four key differences:

1. Composable CDPs run on your own data infrastructure. A Composable CDP does not store your data but instead lets you store it in your own data warehouse.
2. Composable architecture is modular and interoperable. You must be able to swap out components of your CDP, like event collection, at your discretion, without vendor lock-in.
3. The Composable CDP is schema-agnostic. No matter what entities your business cares about, you can organize your CDP data that way in your warehouse and activate it. This contrasts with traditional CDPs, which have rigid user and event models.
4. Composable CDPs offer unbundled pricing. You only pay for the features you need rather than buying redundant functionality from an all-in-one platform.

If you’d like to learn more about what makes a Composable CDP different from (and better than) a traditional one, check out our past blog. In the meantime, let’s move on to bust the biggest myths about Composable CDPs.

Myth 1: Composable = Reverse ETL

When companies hear the term “Composable,” they tend to associate it with Reverse ETL, which syncs data from the warehouse to downstream tools. This association oversimplifies the Composable CDP. We’re willing to eat crow: Hightouch has inadvertently supported this simplification because we’re the #1 Reverse ETL provider, and we also pioneered the Composable CDP category.

The Composable CDP, however, does more than just activate data. A composable CDP does everything a traditional CDP does: collect, store, model, and then activate data. The Composable CDP does this entirely centered around your data infrastructure (likely a data warehouse). For companies with sufficient data collection, storage, and modeling infrastructure, Reverse ETL is the last piece they need to add to create the Composable CDP–which was the case with many of the first Composable CDPs that Hightouch enabled.

Some traditional CDPs added lightweight Reverse ETL features and said, “Look, we’re Composable!” Not quite. Those traditional CDPs still don’t operate primarily with your data infrastructure. They are still bundled, un-modular software with separate event collection, data storage, and rigid schema requirements. Reverse ETL alone does NOT meet the four requirements for a Composable CDP outlined above.

Key Takeaway: To be “Composable,” all of a CDP’s components must center on your data infrastructure. A CDP is not composable just because it offers Reverse ETL.

Myth 2: The Composable CDP Requires Many Vendors

A Composable CDP allows companies to choose best-in-class vendors for each part of the CDP stack, like event collection, identity resolution, and Reverse ETL. Because of this, some companies hesitate to explore the Composable CDP because they’d rather deal with just one vendor–such as an all-in-one traditional CDP provider.

Hightouch offers a complete but Composable solution, which means you can assemble all the components of a Composable CDP with just Hightouch and your data warehouse. You don’t need a separate vendor for event collection, identity resolution, audience management, analytics, and activation. You could easily use your warehouse and one vendor, Hightouch, for your Composable CDP.

Now, if you have preferred vendors for any part of the CDP stack–that’s fine! Composability means bringing the data infrastructure and providers you like or have already implemented. For example, you could implement Hightouch for just Reverse ETL and keep an existing event collection provider like Snowplow in place. The key is that you as the customer have total flexibility and ownership here to put together the CDP that works for your specific business at this moment in time. With a traditional CDP, this is impossible because you must migrate off your existing data infrastructure or, worse and more likely, maintain redundant vendors.

Key Takeaway: The composable architecture allows for, but does not require, multiple vendors.

Myth 3: Composable CDPs are More Expensive

This goes hand-in-hand with the prior myth: people assume that the Composable CDP requires multiple vendors and that all of those vendor contracts will add up to a high total cost.

In reality, Composable CDPs are typically much more affordable than traditional CDPs. Composable CDPs allow you to purchase just the features you need and use your existing infrastructure for the rest. In contrast, traditional CDPs make you pay for every feature in an outrageously expensive bundled package. Furthermore, traditional CDPs store yet another copy of all of your customer data that likely already exists in your data warehouse. Storage isn’t free–and those costs come back into your bill, one way or another.

Key Takeaway: Composable CDPs are more affordable than traditional CDPs. They allow organizations to pay for what they need without introducing redundant features and duplicative storage costs.

Myth 4: Composable CDPs Offer Less Functionality

Because Composable CDPs allow companies to use just parts of their solutions to flesh out their CDP data infrastructure, it’s easy not to realize that the Composable CDP offers everything a traditional CDP does: event collection, identity resolution, data activation, and more. Furthermore, the data warehouse is powerful enough to support use cases that traditional CDPs don’t. For example, Hightouch’s Match Booster enriches customer data in-flight to ad platforms to improve match rates, and our Personalization API allows companies to personalize onsite and in-app experiences directly from the data warehouse. The Composable CDP can do everything traditional CDPs can and then some.

In fact, traditional CDPs are actually worse at their core functions than Composable CDPs. This is because they rely on rigid black-box systems that don’t conform to your use cases or use all of your data. This creates four broad problems:

1. Traditional CDPs have limited data. Most CDPs only collect behavioral data across web and mobile applications. They lack other valuable data in your warehouse, such as data from data science models, POS systems, and offline data sources.
2. Your data has to conform to the schema structure of a CDP. Most CDPs only support users, accounts, and events. For complex businesses with data science models and custom objects like workspaces, playlists, and products, this rigidity just doesn’t work to meet their needs.
3. You have little control over your identity resolution algorithm. Because identity resolution is defined and owned by the CDP vendor, your business logic is limited to the whims and wishes of that provider. This means you have little control (and even worse, visibility) over how customer identifiers are merged and resolved.
4. You don’t own your identity graph. Because identity resolution occurs within the CDP, the identity graph lives in the CDP, which means you don’t actually own it and can’t use it for any valuable analytics use cases across your business.

Key Takeaway: The Composable CDP can do everything that traditional CPDs do (and then some) and does it better.

Myth 5: Composable CDPs are Hard to Implement

Many organizations are wary about starting with a Composable CDP because they think their data isn’t ready. They believe it will take a lot of time and effort to prepare data and the vendor(s) required for a Composable CDP. Conversely, these organizations often believe buying an all-in-one, out-of-the-box traditional CDP would be more straightforward.

In reality, the Composable CDP leverages your existing infrastructure and data investments, while a traditional CDP requires you to start from scratch. Implementing a traditional CDP can take anywhere from 6-12 months–and doing something as simple as trying to adjust your data schema means starting again. In contrast, the average Hightouch customer starts activating data from their existing storage to downstream tools in as little as 23 minutes. This is impossible with a traditional CDP because you have to stand up the entire platform before using it.

Now, we’re not saying that every Composable CDP implementation can be done in minutes. Your Composable CDP implementation time will vary depending on your existing data infrastructure and your needs. For example, if you need to implement event collection and identity resolution, it will take longer than simply implementing Reverse ETL for activation. The beauty of this approach is that you can get started activating what you have first - without waiting for the rest.

Key Takeaway: A Composable CDP will always be faster to implement than a traditional one because you can use your existing infrastructure and data investments and just add what you need.

Myth 6: Composable CDPs Aren’t Marketer-Friendly

Because Composable CDPs run on top of the data warehouse, historically the domain of data teams, many organizations think they are inaccessible to marketers. Even though the warehouse may not have been accessible for marketers to use in the past, they absolutely need access to the customer data stored there. We realized this very early with our customers at Hightouch, which is why we built our Customer Studio toolkit so marketing teams could easily use warehouse data.

Key Takeaway: Composable CDP solutions offer no-code tooling so non-technical users can achieve all the benefits of a CDP directly from the warehouse.

Myth 7: Composable CDPs Don’t Support Real-Time Use Cases

“Real-time” use cases can be tricky to consider because there’s no set definition for what real-time means. How fast does data need to move to be considered real-time? The uncertainty here has allowed certain bad actors to call themselves “real-time” when they are far from it. Furthermore, while some CDP use cases benefit from real-time event forwarding, most marketing and advertising use cases work perfectly well with a slight delay of a few minutes.

Sure, real-time event forwarding might allow you to serve a personalized ad, email, or push notification to a specific user within 30 seconds, but most of the time, it doesn’t actually make sense to remarket to a user just seconds after they abandon their shopping cart. Think about a company like Netflix (they have one of the most advanced recommendation systems in the world), but even Netflix doesn’t make movie suggestions in real-time. It’s all based on past behavioral data powered by data science models–all of which live in a data warehouse, not a CDP.

Most marketing use cases aren’t real-time, and actual real-time use cases are not solved by CDPs alone. For example, the most commonly known real-time use case is a password reset. The speed at which you receive the reset link in your email inbox is directly linked to the application server and not a CDP.

Typically, Composable CDPs take a few minutes to ingest, process, and then activate customer data because of how the warehouse processes it. However, those delays allow for essential data enrichment and identity resolution, which makes customer data far more valuable and actionable. Ultimately, your organization needs to consider how quickly it needs data for different use cases and evaluate solutions based on that. Even if you genuinely need real-time data for specific use cases, you can still solve this in a Composable CDP with real-time event forwarding that bypasses the warehouse.

Key Takeaway: The Composable CDP can solve real-time use cases like traditional CDPs can– by using event-streaming to avoid processes like identity resolution. Most CDP use cases are better served with slight latency and the improved data it provides.

Wrapping Up

The fact that every enterprise CDP vendor is talking about Composability shows us one thing clearly: the Composable CDP is gaining traction–fast. This approach is simply the _right way _to manage customer data. Legacy players are jumping onto the marketing bandwagon, so hopefully, this blog helps you cut through the noise to critically evaluate if the CDP you’re considering is really Composable– and why that matters to you.

If you’re considering a Composable CDP for your organization, we’d love to talk to you and brainstorm how you can best accomplish your goals. You can book a demo with us anytime!