Part Four: Composable Gets Conflated
This post is part of the CDP 2.0: Why Zero-Waste Is Now series. For the best experience, we recommend starting with the Introduction and reading each chapter in sequence.
To understand today’s CDP market, we need to disentangle the concept of "composability," which has been conflated to mean different things, depending on the marketing contexts. From a purely technical standpoint, composability describes platforms which can be used in a modular fashion, with associated unbundled pricing. In other words, customers can choose which features they want to use and only pay for those they use.
As mentioned earlier, the vast majority of CDPs have become more flexible and unbundled in their pricing strategies. Strictly speaking, all CDPs should be composable and most CDPs are composable. However, as the warehouse-native CDPs rebranded from "reverse-ETL" to
"composable CDPs," the term was widely expanded to include CDPs, which were overlays to CDWs.
These warehouse-native CDPs further expanded the definition of composability to also include schema-agnostic features, zero-copy support and rapid time-to-value. While the “composable” positioning was quite clever, the conflation of these concepts have created confusion for both buyers and sellers of CDPs, as it has created a false dichotomy between packaged and composable CDPs on a functional level.
As discussed earlier, zero-copy support is really a term of art to describe the general support of data quality and governance efforts. While warehouse-native CDPs inherit virtues, which we discussed earlier, these are not the exclusive realm of warehouse-native CDPs and are properly discussed on a case-by-case basis.
The time-to-value positioning has been advanced as the major virtue of warehouse-native CDPs, as their deployment into customer CDW environments appears to be more straightforward than packaged CDPs. However, this is a major mischaracterization of established CDP capabilities. All the major established CDP can be installed and running use cases within hours. Likewise, warehouse-native CDP deployments ofter require extensive professional services before they can be fully deployed as a CDP, especially if complex identity resolution is required. Mostly, this is clever positioning by warehouse-native CDPs, turning the mature deployment methodologies of established CDPs into a supposedly liability. In most use cases, deployment speed is really dependent on the customer context more than any inherent CDP limits.
The schema-agnostic requirement of zero-copy is an interesting area to consider. Established CDPs are more prescriptive than composable CDPs in their workflows, requiring a data mapping exercise. Warehouse-native CDPs may provide more flexibility, though they do require customers to have already created a coherent data model before deployment. Marketers generally prefer established CDPs as they are specifically designed to support their workflows using well-defined user preferences defined over the past decade. Warehouse-native CDP deployments require the customer data engineering teams to create a schema for their users—and continually update this as use cases change. Properly considered, this really a choice of marketer enablement vs. data engineering customization.
Another claimed benefit of schema-agnostic capability is the ability to work more easily within the context of a customer's data infrastructure. In practice, this is not a universal difference between established and warehouse-native CDPs. The ability to work with different data sources varies across all CDPs, largely dependent on the quality of integrations for specific sources. For example, a specific established CDP integrates better with some CDW platforms than all the “composable” CDPs.
For the buyer of CDPs, this conflation of composable "requirements" is not helpful in choosing the appropriate CDP. Since most CDPs offer unbundled pricing, this makes most CDPs "composable" by the technical definition. Expanding the definition of composable to mean "zero-copy’ deployment, we have to be precise as to what this actually means. As discussed earlier, this does not mean "no data copy," as all CDPs do this for performance. In practice, this means, "how does the CDW-based quality efforts?" The answer to this is largely context dependent—warehouse-native approaches will support current CDW-based quality efforts better, with packaged CDPs closing the gap over the next year. Outside of the CDW quality efforts, vertical CDPs will handle quality issues better than general purpose CDPs.
The rest of the "composable" requirements are largely product marketing considerations, which ignore customer context. While we admire the product marketing skills of the warehouse-native CDP vendors, the conflation of these concepts has made CDP selection, which is already complicated, even more difficult.
