System Selection Isn't About Features Anymore

I recently explored rebuilding the CDP Institute’s venerable RFP Generator with a vibe coding platform. The project was a success – Replit* took about one hour** to build and deploy an attractive, bug-free system that is significantly more capable than the original.***

But looking closely at the RFP Generator – which has been running with virtually no maintenance for six years – also raised the obvious question of how it should be updated. The current focus of the system is features: users specify their target use cases and the system returns a list of the features those cases require; it then suggests vendors based on how many of those features the vendors provide. That made sense when most systems were largely self-contained bundles of capabilities. Features were the main differentiators and collecting information on each system’s features was the main task of a vendor selection project. Even hands-on evaluation tools like pilot projects and bake-offs, which have to some extent replaced or at least supplemented the traditional Request for Proposal, are still largely aimed at understanding system features more clearly.

But systems today are anything but self-contained. They are components of a larger architecture, more-or-less-fluidly exchanging data and participating in workflows that span different systems, departments and even companies. Any new software has to fit into this larger ecosystem.  

This shifts the focus of the purchase process to integration and compatibility. Understanding those is important because different systems are built to play different roles: some are designed to be a company’s primary platform (such as a data warehouse or marketing suite), some are designed to supplement a specific other platform (such as applications on a vendor’s app exchange or an optional module in a platform system), and still others are designed to work with any system that supports the same integration methods.

This means that delivering the right features is no longer enough. Systems must deliver the right features in a way that fits with the company’s larger system architecture. Compatibility with that architecture is the first screen that must be applied to any potential vendor list. In fact, since new tools often make it practical for users to add their own features to a purchased system, finding exactly the right set of features is considerably less important than it used to be.

The CDP Institute’s existing tools already accommodate this change to some extent. We capture whether a particular CDP works with its own database or connects to an external warehouse, which is one of the key architectural differentiators. We also ask whether a system can be installed on-premises, which is an important consideration for some buyers. The vendor selection portion of the new RFP Generator allows users to filter systems on those options. But we could surely do more to understand the different architectural options and the markers that indicate which systems are compatible with which options, and to collect and expose that information.

It's also important to recognize that new architectural options will continue to emerge. The AI-powered transformation of marketing technology is still in that early stage where the industry is trying many alternatives before settling on a standard approach. (Or several standards.) Once the industry coalesces around a few standards, it will be much easier for buyers to identify systems that match their company standard.  But it will be at least several years before the winners are clear.  This means buyers will struggle for some time to figure out which systems are compatible with their company's chosen approach.

Of course, technology isn’t the only factor that matters when selecting a system. Pricing, industry experience, professional services, typical client size, and local presence are all important considerations. The CDP Institute already captures those in its vendor data and the old RFP Generator already asks the user about them. But it would be helpful to find a way to identify some of the less concrete variables, such as cultural fit, ease of use, and skill requirements.

Ideally, a vendor selection tool would also include a user readiness assessment, to help buyers understand what types of systems are best for them, what kinds of problems they are likely to face, and maybe even what they should do avoid those problems. This is important because -- as I’ve pointed out many times in the past -- by far the most common causes of failure with new systems lie within the purchasing organization, not in the systems themselves.****

In short, finding the right system today is less about finding features and more about architectural and organizational fit. The buying process needs to adjust.  Vendor selection tools should – and I’m confident will – adjust along with it.

_______________________________________________________________________ 

* Lovable also worked very well. Botpress, not so much.

** This was after I spent a day and half prepping the data and writing detailed design instructions. It would have taken much longer if I wasn’t working with materials already assembled for the old system. Still, it would have a taken a conventional developer weeks if not months to deliver a system after they were handed those inputs. Replit cost me $20 in processing credits; conventional developer costs would surely have been in the thousands.

*** You’ll have to trust me that the system is ready to go. There’s no point to releasing it until we make additional changes in the data collected. The same goes for our Vendor Comparison report, which uses the same vendor information as the RFP Generator. Replit built an interactive version of that in just a few minutes. Woot!

****The CDP Institute does have an existing Readiness Assessment tool, although it's limited and not connected with the RFP Generator. 

What Comes After the Composable CDP?

For a bunch of smart people, the technology community can be awfully slow learners. One mistake they keep repeating is believing that the latest technology is a “silver bullet” that solves all problems. This despite years of experience finding that (a) no technology solves all problems and (b) every new technology is eventually replaced by something else.

The Customer Data Platform industry is as prone to these errors as everyone else. The current silver bullet is composability, which is touted as the ultimate solution to problems of CDP cost and complexity. Just hearing the claim should lead anyone to realize it’s not true: composability solves some problems in some situations (i.e., unnecessary data movement at firms with sophisticated technical resources) but it won’t help companies that lack the necessary data infrastructure or staff resources. I suspect that even the most ardent composable enthusiasts would agree with this more nuanced view if you pinned them to a wall.

It's a step in the right direction to move past “composability is great” to discussing “when composability is the best solution.” But it’s also important to address the second flaw in the “silver bullet” fantasy, which is to assume that the best current technology is the best future technology. In other words, it’s worth asking, what comes next?

Remember, composability isn’t a solution: it’s an architecture. The fundamental argument for composable CDPs is that it’s better to have an architecture that uses the enterprise data warehouse as the primary store for customer data, rather than an architecture where customer data is assembled, stored and accessed in a separate CDP database. So the question about what’s next is really a question of what other architectures are possible.

I can think of two candidates.

• Read customer data directly from the source systems, without assembling it in any persistent database (i.e., neither a data warehouse nor a CDP). This vision of real-time, on-demand customer profile assembly is what many people thought a CDP should be back in the early days of the industry. At that time, ten to fifteen years ago, the existing technology simply couldn’t make it work. Many source systems didn’t allow real-time access, internal networks couldn’t handle the volume, and the processing costs to assemble profiles in real-time were too high. The problem pre-dates CDPs, of course: the need to make data accessible by pulling it from source systems into a separate database is why data warehouses were first created in the 1980s. There has certainly been progress in recent years, although I can’t say that the necessary technology is fully available. Still, the scope of what can be done in real time continues to expand, which diminishes the share of data that must be assembled in a warehouse. This, in turn, diminishes the relevance of the warehouse-centric composable architecture.

• Create customer digital twins. I’m highly skeptical that AI can accurately mimic customer behavior: this seems most likely to reinforce mediocrity by failing to predict unexpected behaviors (the most interesting kind) or reactions to novel situations (which includes the most important  innovations). But I can still imagine creating a digital twin for each customer, updated in real time with data captured across all company systems. The twins would be self-contained objects (or maybe agents) that can be queried any time a company system wants to find the best action for a particular customer in a given situation. While their role might resemble the customer profiles assembled in today’s data warehouses, I’m sure the technology will be quite different. I can't predict the specifics of that technology but am sure that clever people somewhere are already working on it. My only point here is that, again, the architecture won’t look like the warehouse-based composable CDP.

There are surely other possibilities that haven’t occurred to me. In fact, I’d offer better than 50/50 odds that the next CDP silver bullet will be something I haven’t listed. Placing the right bet matters a lot to investors and developers but not so much to users, who can wait to see what becomes available. 

What does matter to users is identifying their requirements.  This is something that debates about architecture only distract them from doing. So my fundamental recommendation is that CDP users think less about chasing the silver bullet and more about building the golden record – that is, how to create the accurate, unified, accessible customer data that a CDP using any architecture is intended to provide.

Let's Debate CDP Functions, Not Definitions

What’s the definition of a CDP? It's a bad question because it diverts attention from what really matters: What capabilities do CDP users need? Still, buyers keep asking and sellers keep answering, typically in ways that promote their own interests. Looking for an unbiased perspective on the topic, I recently asked ChatGPT what answers it was finding. It came back with a reasonable cluster of responses and particularly interesting details on who was using each one (see below for the full response)*:

• Unified customer database: 70–90% of analyst pages, trade articles and vendor docs 
• Marketing activation / audience building platform: 60–85% of vendor docs, blogs and many press releases  
• Real-time/streaming profile & interaction engine: 30–60% depending on whether the source is vendor marketing (more likely) or neutral analyst articles (less likely to require “real-time”). 
• Privacy, governance & identity management layer: 15–35%, increasingly present in analyst pieces and vendor positioning  
• Part of a larger ‘data cloud’ or enterprise data stack: 10–30%, especially in vendor/marketing copy from big cloud vendors

These are categories that ChatGPT identified without me defining them in advance.  So it's particularly interesting that there’s no mention of composability, warehouse-centricity, no-copy, hybrid, embedded, integrated, stand-alone, or other architectural details that have dominated recent industry discussions. In a way, this represents a failure by the CDP Institute to propagate our view that a CDP must build a separate database of its own. But a less parochial response is to be pleased that the main distinctions reflect system functions, which is where the focus belongs.

Of course, the variety of definitions is still problematic. While it’s usually safe to assume that a system labeled as a CDP will provide a unified customer database, it’s less certain that it will also offer marketing activation and downright dicey as to whether it will offer real-time streaming profiles and interactions. This means the label provides little useful guidance: imagine a can of soup labelled “contains tomatoes and maybe chicken and could also have mushrooms, rice or shrimp”. The only way to know what's inside would be to open it -- which defeats the purpose of a label.  

(And, yes, the problem is worse for CDP than other categories. When I ran the same prompt for the term "customer relationship management software," a single answer dominated: 71% defined CRM as “a software/system/platform to manage customer interactions and data.”  The next highest share was just 29% for “integrated suite (sales, marketing, service automation)”. It’s true that the dominant answer is exceptionally broad, but at least most people understand this and won’t expect anything more specific.)

So, although industry understanding has not been entirely destroyed by architectural debates, there is still enough disagreement on the scope of a CDP to limit the term’s utility. (If the CRM example is typical, it may be a natural progression for popular categories to expand their meaning over time. That would be an interesting hypothesis to explore if anyone out there is looking for a thesis topic.)

The industry could fight to restore a more specific CDP definition, but that’s probably a losing battle. It’s more likely productive to shift the discussion away from defining the term "CDP" to defining the functions required to manage customer data. 

Yes, I’m proposing that the solution to our problem is a checklist. Don’t roll your eyes: whole books  have been written on the topic. (Ok, maybe just one book.)  But in an industry that has long been driven more by theory than practical requirements, anything that gets buyers to focus on what they actually need is a win.  

Getting the industry to agree on a shared requirements checklist wouldn’t be easy, since every participant would want to add or remove items depending on whether their products supports them. Indeed, the very notion of a comprehensive requirements list favors broad, integrated products over narrow point solutions. But I’d still invest a few embers of hope in a project to forge a complete customer data framework. The potential benefits, for users and vendors alike, are well worth the effort.

State of Martech Report: Customer Data Platforms Are Evolving, Not Dying

Scott Brinker’s State of Martech report has grown from a one-page logo jigsaw to a small industry, co-authored with MartechTribe’s Frans Riemersma and apparently produced by a small army of elves reviewing thousands of products each year. The latest edition, released yesterday, provides the now-expected deep analysis of industry trends covering category growth, the impact(s) of AI, stack architectures, and more. It’s all interesting and too complicated (or maybe complex?) to recap here, so I can only suggest that you read it on your own. 

In addition to data based on the 15,384 vendors now listed (up 9% from 2024), the report analyzes results from a survey of martech and marketing operations leaders. Again, there’s lots of fascinating information, but I was of course drawn to the sections related to Customer Data Platforms.

On its face, the report offers some pretty bad news for the CDP industry: the fraction of companies citing a CDP as the “center” of their martech stack fell from 15.5% in their similar 2024 survey to 12.5% in 2025. However, the 2025 survey is based on just 96 responses, meaning that’s a swing of three answers, so it’s not cause for too much alarm.* Still, it’s an interesting result, and even more intriguing when you separate B2B respondents (52% of the sample) from others (14% B2C and 34% mixed B2B/B2C). CDPs have never been widely adopted in the B2B world, and indeed, their share is unchanged from 2024 (7.9%) to 2025 (8.0%). The flip side to that is in the B2C and mixed group, the shift is larger: from 26.9% in 2024 to 17.4% in 2025. But, again, bear in mind the sample size: that 17.4% represents seven responses. A shift of three answers is well within the range of statistical noise.

Let’s put sampling issues aside and assume there’s some drop-off in reliance on CDP. The question is, what has taken its place?

Did you just answer “cloud data warehouse, of course”? That’s not entirely wrong – the data warehouse share grew from 20.9% to 23.9%. But the big winner was MAP/CEP (marketing automation/customer experience platform), which grew from 19.4% to 26.1%. CRM grew from 17.9% to 19.5%, or nearly as much as data warehouses. Multi-product suites fell from 1.4% to zero, which hints quite strongly that the respondents heavily skewed away from large enterprises.**

If we combine the MAP/CEP, CRM, and DXP or ecommerce categories into “customer-facing systems”, the combined share of that group grew from 43.3% to 52.1%. So if I were to read any trend from this data, it would be that companies are centering their martech stacks on customer-facing systems, not on data warehouses.

This is actually consistent with the trends we’ve seen in the CDP industry itself, where the most recent major acquisitions (ActionIQ by Uniphore , Lytics by ContentStack, mParticle by Rokt) all involved merging a CDP into a customer-facing product, and where customer-facing vendors like MessageGears, Klayvio, Insider, Listrak, and Braze have added CDP (or CDP-ish) capabilities***. The CDP Institute classifies all of these systems as CDPs, in addition to whatever else they do. So, the way I see it, companies that list those products as the “center” of their martech stack are still building their stack on a CDP, even if they don’t call it one. That’s good news for the industry, not bad.

The survey also takes another look at the role of data warehouses in the martech stack, asking “Do you have a customer data warehouse/lakehouse integrated with your martech stack?” More than half the respondents (56.2%) said they did, a number that climbs to 92% for B2C vendors and 80% for enterprise companies. What’s interesting here is the relation of those answers to the previous question: many more firms have integrated a warehouse than are using their warehouse as the center of their martech stack. This is far from shocking but, again, suggests that the mere presence of a warehouse doesn’t mean that warehouse is the primary customer data store.

If you’re a “warehouse-centric” composable CDP vendor, you could read the relatively small share of warehouse-as-central system either as cause for alarm – the market isn’t as big as you thought – or reason to rejoice – the potential for growth is huge. Both could be true at the same time. But if the primary industry trend is for CDP functions to migrate to customer-facing systems (run by marketing or other business units), then a shift of CDP functions toward the (IT-controlled) data warehouse seems to be the wrong way to bet.  (In this context, the recent sale of leading composable CDP Census to data movement platform Fivetran may signal incipient consolidation in the young-but-already-overcrowded composable CDP sector. That Census was bought by a data movement tool rather than a customer-facing system reinforces the notion that composable CDP products serve IT teams while customer-facing CDPs serve marketers and other end-users.)

Presumably all those non-central warehouses are acting as data sources to CDPs or customer-facing systems with a CDP inside.  Indeed, the Brinker/Riemersma report positions CDPs (stand-alone or embedded) as intermediaries between data systems and activation systems (which they call "systems of knowledge" and "systems of context," respectively), responsible for "organizing or framing the data in a way that best serves more situational needs."  I quite agree, and couldn't have said it better.  I would expand on this by noting that CDPs within customer-facing systems will have direct access to the data those systems generate, so the role of the data warehouse is limited to supplying data that the warehouse collects elsewhere. A CDP with direct access to customer-facing systems overcomes one of the main drawbacks of the warehouse-centric approach, which is that warehouses often can't provide the real-time access to behavior data that's needed for many customer-facing applications of CDP data.

I should stress that CDPs are a bit player in the Brinker/ Riemersma epic. Definitely download the report (it’s free and ungated) and focus on whichever portions you find most relevant. It’s all good.

------------------------------------------------------------------------------------------------------------------------------------

*The 2024 survey had 168 responses, of which 60% were B2B, 9% were B2C and 31% were mixed. Doing that math, that’s 67 responses in the B2C and mixed group, of which 18 cited CDP as the center of their stack.

**The 2025 report says 30 of the 96 responded were from ‘enterprise’ organizations, but doesn’t indicate how these split between B2B, B2C and mixed.

***In addition, at least one unacquired CDP (BlueConic) has repositioned as a customer-facing system.

Composable CDP is Dead

Composable CDP is Dead. Sure, it’s a clickbait headline. But how else to gain attention on a topic that’s over-saturated with hype?

Of course, I would never say something untrue just to gain attention. So let me clarify exactly what’s deceased. It isn’t composability or CDP, or the vendors who have adopted the “composable CDP” label. What’s dead is “composable CDP” as a distinct category of software.

You might stop here to argue that “composable CDP” was never a meaningful category, and I wouldn't necessarily disagree. But the term did have a broad meaning along the lines of “software components that provide functions needed in a CDP.” What made it useful was the contrast with packaged (a.k.a. standard, conventional, traditional, integrated, or just plain “real”) CDPs, which, according to the CDP Institute definition, provide a complete set of CDP functions – specifically, the functions to collect, organize, and share customer profiles. Companies that wanted to build their own CDP, possibly using their existing data warehouse as a base, could use the “composable CDP” label to identify products that might help with their project.

What’s changed is that many of the packaged CDP vendors quickly caught on to the demand for CDP components and split their products into modules.  This let companies buy only the functions they needed and apply those functions to data in a cloud data warehouse. The repackaging is easier for some vendors than others, depending on how their products were originally built. But enough of the original CDP vendors now offer some flavor of CDP components that companies looking for components to build an in-house CDP should consider them as well. Thus ends the utility of “composable CDP” as a category. RIP.

The composable CDP vendors saw this day coming. Many have switched their positioning to "warehouse-native," which is more accurate and reduces the focus on point solutions.  But their main strategy has been to move beyond offering a single component for a single function – that is, their original product – to offer multiple components and a complete set of CDP functions.¹ The change to offering a complete solution weakens some of the composable vendors’ original sales arguments, including the superiority of “best of breed” solutions and the ease of swapping components from different vendors “like Lego blocks”. But it also allows new arguments, including the virtues of buying multiple preintegrated components from the same vendor and the value to end users of working with fewer tools. If any of the vendors feels embarrassed at switching from one side of the debate to the other, I haven’t noticed.

Then again, there’s no reason they should be ashamed. Products naturally expand their footprints: it’s a marketing truism that it’s easier to sell new products to existing customers than to sell existing products to new customers. And CDP buyers clearly prefer integrated solutions: according to the CDP Institute Industry Update, nearly three-quarters of CDP products extend beyond profile creation to include marketing execution. In practice, only very large companies can afford to build custom solutions by cobbling together “best of breed” products. I summarized this years before CDPs existed as “Raab’s Law”, which states that “Given a choice, most buyers prefer suites over best-of-breed solutions.” The pithier version is “Suites win.”

This doesn't mean that most companies actually use integrated marketing suites.  The majority clearly do not.  In fact, a recent Acxiom survey found just 17% of marketers plan to move to a suite in the next twelve months; the rest are using multiple products and 29% expect to add more.  Reasons companies don't adopt suites include cost, agility, and the lack of required functions.  Still, when you look at marketing software categories including campaign management, journey orchestration, analytics, and email execution, leading independent vendors have been acquired by suite owners and the remaining independents are largely relegated to niche segments or have expanded to become suites themselves.  This is what the composable CDP vendors are doing.

Wait, did I just say that an integrated CDP is a software suite? To some degree, yes: in the finest Alice-in-Software-Land tradition, words mean whatever I want them to mean.²  But the less flippant answer is that it depends on your perspective: in discussing CDP functionality, a single product that provides all necessary functions does look like a suite, while components for individual functions look like point solutions. But if you raise the perspective to marketing architecture, the CDP itself might be a single component alongside content management, marketing automation, email, and media buying components, while a marketing suite like Adobe would encompass them all. Go up to the enterprise level, and the marketing suite could be one component alongside finance, human resources, and operations, compared with an enterprise-wide suite like SAP. 

It’s possible that Raab’s Law begins to weaken above the departmental level, where conflicting managers are powerful enough to insist on their own systems rather than accepting the loss of control implied by a shared system. Feel free to explore this on your own. What matters here is that talk of components reintroduces the topic of composability. 

Although composable CDP only entered the martech discussion about two years ago, the broader label of composable architecture began to build momentum around 2020.³ Today it’s applied to nearly every type of software, and we see composable-oriented organizations like MACH Alliance expanding their scope accordingly.⁴  

There’s actually a good chance that composability has hit its peak on the hype cycle, as greater experience gives practitioners a better understanding of its limits. As with composable CDP, these primarily involve integration costs and support complexity.  They also include scaling challenges to move large volumes of data between large numbers of components, and problems when one weak component drags down performance across the entire structure. Call it the Revenge of Raab’s Law.

For composable CDP in particular, experience has also revealed high processing costs when everything is done within a cloud data warehouse.  (This is why cloud data companies like Snowflake and AWS are so enthusiastic about the warehouse-native CDP approach.)  Users have also discovered that the cloud data warehouses struggle with certain kinds of real-time processing, a core requirement for many CDP applications.

This more realistic understanding of composable limitations doesn’t mean that composability is dead. Marketers were never really all that interested to begin with: just 3% in the Acxiom survey said they plan to move to a composable strategy in the next 12 months, compared with 17% moving towards a suite.⁵  The people who really care about composability are the technicians: when Messagegears surveyed people interested in “data cleaning and quality control,” 56% said they prefer a composable architecture and 33% had no preference, leaving at most 11% in favor of packaged systems. 

But don’t get too excited, composable fans: preference isn’t the same as intent, let alone action.  You can bet many of those technicians won’t be able to make the changes they’d prefer.⁶  Still, the technicians’ views matter a great deal because growing use of customer data beyond marketing gives IT and data teams a larger role in selecting customer data systems.

Will technicians get over their infatuation with composability? Only time will tell.  But it’s likely their ardor will cool as they learn more about it and get distracted by whatever Big Thing comes Next. 

This doesn’t mean the the pendulum will swing back to favor traditional, integrated CDPs. Rather, as Hegel would have predicted, we can expect a synthesis where most customer data is assembled and remains in the warehouse, but some functions are executed outside of the warehouse in a CDP that reads the warehouse data directly. In this world, traditional CDP functions such as data ingestion and identity management become components that operate within the warehouse, while functions such as real-time response, analytics, and journey orchestration become part of a separate, internally-integrated component that can reasonably be labeled a CDP.

The composable CDP is dead. Long live the CDP components. 

_________________________________________________________________________________

1. The definition of “complete” varies from vendor to vendor, and inevitably matches whatever components the vendor has available at any particular moment. But that approach is common throughout the software industry, so it doesn’t’ represent uniquely deceptive behavior by the composable CDP camp.)

2. See the previous discussion of “complete.”

3. The idea of building systems from components has been around much longer than the label, using terms such as micro-services architecture and headless CMS. CDP itself is also much older than four years. All these terms are much more widely used than composable architecture and composable CDP. 

 

4. I’ve never spoken with anyone at MACH Alliance, but surely they face the same struggles maintain consistent definitions and standards as the CDP Institute. Fun fact: while several of the traditional CDP vendors have met the rigorous standards required to join the MACH Alliance, none of the composable CDP vendors are members. 

5. The remainder intend to muddle through with their current crazy wall of loosely connected applications, while complaining about integration cost and feature overlap.)

6. How big is gap between preference and planning? Well, in the Acxiom survey where 3% of respondents said they plan moving to a composable approach, 36% said they thought a “modern sophisticated marketing stack” should have a composable architecture. Let’s call them composable-curious. Of the rest, 38% cited an integrated marketing suite, compared with 17% planning to move in that direction, and 34% chose a best of breed approach, compared with about 80% living that particular dream. 

CDP Round Table: Forget Composable, Are Cloud Databases a Threat to CDPs?

On July 16 and July 18 2024, the CDP Institute hosted a pair of online roundtable discussions for industry vendors. Here are summaries of the conversations.

 

July 16 Roundtable - U.S. and Europe participants.

We started with a quick list of trends that the Institute is watching. These include Composable CDP, CDP integration with advertising channels, third-party cookie deprecation, vertical (industry-specific) CDPs, and AI applications in CDP systems.

The discussion quickly focused on Composable CDP. Key points included:

•  Replacing the term “composable” with “warehouse native”. This is more accurate and resonates in particular with data and IT teams, who want to get the most use from their warehouse investments. “Composable” is still more commonly understood among marketing users.
• Composable CDP comes up most often at large enterprises, which have the most mature IT and data resources.
•  Composable also has appeal in healthcare and financial services, where regulatory concerns make companies reluctant to copy data into a separate CDP database. (Note: I have also heard the opposite, because IT and data teams don’t want to give business users direct access to their entire warehouse and would rather provide them with a limited extract.)
• Digital native companies are also good prospects for Composable because they tend to have well managed data already in place.
•  Composable promises a faster start than building a separate CDP, which is appealing to all potential users. Whether this really happens depends on the state of existing data sources and warehouses.
• Composable CPDs have an advantage because the company’s existing warehouse will include both customer and non-customer data elements tailored to company and its industry. Standard CDPs often must build a custom data model for each new industry, and may struggle to include non-customer information such as product data. Vertical CDPs are appealing because they have industry-specific data models already in place.

Other observations:

• The fast growth of cloud databases, and Snowflake in particular, is a threat to packaged CDPs because they make it easier for IT to build their own products. So far, the cloud databases haven’t built in key tools such as data quality and ID resolution, but there are indications that will change. Such tools are already available as pre-integrated applications in the cloud database vendors’ marketplaces. This is worth calling out as a separate trend from Composable CDP.
• The data engineers who buy cloud databases are not aware that CDP systems exist. They see the value when it’s explained to them, but are still likely to want to expand use of their warehouse systems to justify the investment. This is true even if the warehouse doesn’t already have rich customer data features and customer data has been a low priority. “Data-in-place” and “zero-copy” are strong selling points against putting data into a separate CDP.
•  Regulatory changes, such as anti-redlining rules for banks and Sunshine laws for healthcare marketing, have driven investments in customer data in the past. Privacy regulations may play a similar role in the nature future. This is also worth calling out as a trend.
• There is limited convergence between CDPs and privacy systems. Few CDP vendors have invested in privacy features beyond ingesting consent data, possibly because privacy is complicated so it would take a major investment. In addition, privacy systems have different buyers from CDPs, and privacy managers feel it’s safer to buy from OneTrust than lesser known vendors. But basic privacy and security always requirements in CDP RFPs.
• Journey orchestration is available in many CDPs, which means they overlap with existing journey orchestration systems. But very few clients will replace a mature journey orchestration system with a CDP, due to the effort involved in training staff and migrating programs. Most CDPs with extensive journey orchestration and messaging capabilities are vendors that started as journey orchestration and messaging products and added a CDP capability. Journey orchestration and messaging systems that connect directly with a warehouse may pose another threat to CDPs.
• Advertising integration is often the first CDP application in Italy and elsewhere in Europe.

July 18 Roundtable - APAC participants

Industry trends

• Overview: composable, cloud database, advertising integration, cookie deprecation, privacy & compliance, vertical industry CDPs, AI
• Seeing lots of requests for clean room and consent management, and how CDPs can merge those to streamline work for customers. Some parts of consent can be managed in CDP, others should be in separate platform. Privacy is often first use case.
• Among companies with CDP already deployed, often see extension beyond marketing to other departments. CDP often leads to teams within marketing working together that before kept separate.
• When a new CDP is deployed, people become aware of it organically and through analytic reporting that uses CDP data.
• Cloud databases and composable CDPs introduce new buyer personas from IT and CTOs, who have different use cases and technical concerns from marketers. 

Other items

• Understanding of CDP is relatively low in SouthEast Asia (SEA), compared with Australia, India and Japan.
• Composable is mostly raised by IT teams, who are looking for easiest path to moving data from one platform to another, without understanding the strategy behind the CDP project. Applies to both small and large organizations. Companies like Salesforce with a lot of installed products can co-exist with composable.
• Companies can easily identify many use cases for a CDP. Vendors spend time helping them to prioritize. The sales process is sometimes slowed because buying teams are overwhelmed by the number of use cases.
• Greatest interest among marketers is performance marketing use cases, where results can be directly measured, such as data activation, segmentation, and pipeline-to-paid. This is limiting because there are so many other use cases that don’t have immediate results, such as brand building.
• Advertising is often an early use case, since simple things like suppression and lookalike audiences from CDP can generate immediate, measurable result.
• It’s usually easy to build a use case for CDP looking at almost any part of the lifecycle, from acquisition through churn reduction.
• Confusion about CDP definition can slow down sales, because there are so many different vendors that are hard for buyers to differentiate. The products have changed over time, starting from data capture and now moving to integration with cloud data warehouses and activation in multiple engagement channels, including those outside of marketing.
• It’s not clear whether growth in composable and cloud databases has caused a drop-off in selling stand-alone CDPs. CDP Institute industry update report shows that growth has definitely slowed in the past 18 months, but we don’t know the reason. The slowdown might just mirror the general tech employment slowdown post-covid, and it’s possible that the companies buying composable and cloud databases would have built their own solution anyway, so they were never the companies fueling growth of stand-alone CDP.
• Composable in APAC is having more of an impact in the small to medium sector than with big enterprises.
• AI requires higher data quality.
• Companies feel competitive pressure to invest in AI but are moving slowly, in part due to privacy and security concerns. CDP vendors have added both predictive and generative AI to their systems. Predictive AI deployments are much further along and we’re now seeing initial deployments of generative AI.
• Generative AI is being used to automate existing tasks but not yet to transform tasks. Expect to see more impact next year in terms of benefiting system users, developers, and ultimately at touchpoints where it will change the customer experience itself.
• Generative AI will eliminate some jobs and create others, probably for a net positive impact. People can view AI as a centaur that helps them do their work or a cyborg that takes over their job completely. There are many issues to work out from an enterprise perspective before generative AI becomes widely adopted.