Can AI Break the Hype Cycle?

Generative AI and its agentic offspring may be foundational technologies, but they are still following the normal technology hype cycle: excitement at the potential, followed by news of failed deployments, followed by a more mature understanding of what’s required for success. The third stage generally comes down to a realization that the main obstacles are organizational, not technical: projects fail due to poor internal alignment, change management, reward systems, and so on. Similarly, when it comes to customer data (and all other business data), there’s a dawning recognition that whether the data resides in a CDP, cloud warehouse, or marketing platform, the real challenge is still transforming raw data into usable information through quality management, unification, and mapping. 

We’re just beginning to see the third-stage insights from the industry’s more advanced thinkers. It's true that they’re important: the only way people will be convinced to address these issues is by seeing real data and hearing about actual experience. But they are also utterly predictable. 

What’s less predictable is that AI has the potential to remove those barriers. If AI radically changes how work gets done, then the organizational structures designed for existing business processes (and blocking progress) will change as well. For data, AI could – at least in theory – handle preparation tasks that have always been the main roadblocks to deployment. 

These are not subtle ideas and I don’t consider them particularly brilliant insights. But I also don’t see them being discussed (at least explicitly). Instead, most of the AI conversation is still about using AI to replace individual tasks within existing workflows or about creating AI-based workflows within existing organizational structures. What I’m suggesting is a clearer focus on using AI to remove the traditional roadblocks to technology deployment: in addition to redesigning organizations around AI capabilities (with a particular focus on accommodating future change), this might also mean developing AI coaches to help existing organizations with change management. For data management, it means developing AI tools to automate end-to-end data preparation. 

I will somewhat airily leave the details to people who make their living helping organizations with technology management; they will no doubt have many more and better ideas than I can offer here. My goal is simply to convince them to adopt roadblock removal as a conscious objective in their work. This is what will empower AI to deliver the fundamental changes that we all see as its potential.

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.

Uniphore Buys ActionIQ: What We Can Learn

Acquisitions of, or by, major CDP vendors have been vanishingly rare in recent years.  So news that ActionIQ  had been purchased by Uniphore generated an especially large amount of interest.  Let’s look at it from three perspectives.

1.    Significance for ActionIQ.  Although ActionIQ has been a significant CDP since its founding in 2014, the company was always a bit different from most other CDPs.  Rather than starting as a tag manager or messaging platform, ActionIQ’s roots were in big data technology: co-founders Tasso Argyros and Nitay Joffe were, respectively, the founder of big data engine Aster Data (purchased by Teradata in 2011) and a leading data engineer at Facebook.  Not surprisingly, the company’s approach to CDP was also driven by data technology: in particular, it used in-memory storage to support high volume, real time use cases.  In recent years, the company evolved its technology to offer component-based and warehouse-native options in addition to a conventional integrated CDP.

The company’s business results were less stellar than its technology.  It primarily targeted large enterprises that could most benefit from its sophisticated approach, and had reasonable success in that market.  But, despite raising a hefty $144 million (per Crunchbase), growth stalled in recent years.  Headcount, which stood at 208 in mid-2021 (per LinkedIn) has declined steadily since then and last week was 161.  We don’t know whether sales also fell; it’s likely that the headcount reductions reflected preemptive belt-tightening as new funding became less available, rather than tracking an actual revenue decline.  

Either way, it doesn’t seem that ActionIQ was on a path for substantial growth as an independent company.  So a sale to a friendly buyer like Uniphore makes good sense.  I’m told that the ActionIQ product itself will continue to be sold, supported, and developed, so it’s a good outcome for ActionIQ customers as well.

2.    Significance for Uniphore.  I’ll admit I wasn’t familiar with Uniphore before this deal, even though they are in fact a well-established, fairly large company (founded in 2008, 800+ employees, $621 million in funding).  Their specialty has been speech-related customer experience tech, such as self-service, phone agent and sales assistance and conversational analytics.  Like others in that industry, they are currently focusing on enhancing their products with AI to improve worker productivity and business results.  

What’s more interesting is where they differ with the competitors, which is a greater focus on the data infrastructure needed to support AI.  This is where the ActionIQ acquisition makes sense, since it will help to support what Uniphore calls the “Zero Data AI Cloud”.  As the name suggests, Uniphore’s vision is to provide AI systems with data without first exporting that data into a separate database.  This is the “zero copy” or “warehouse-native” approach that’s increasingly popular in CDP circles.  It’s also something that ActionIQ has evolved to support, so the acquisition is strategically sound.  As you’re probably aware, Uniphore also announced its acquisition of Infoworks at the same time as the ActionIQ acquisition.  Infoworks is an even more technical vendor, dedicated to managing cloud data migrations.  At 75 employees and $71 million in funding since it was founded in 2014, it's smaller than ActionIQ but still a substantial business.  Like ActionIQ, its head count has also fallen in recent years, from a recent peak of 112 in early 2023.

Uniphore’s pivot to AI data infrastructure seems like a good move, at least compared with the hugely overcrowded AI-based CX marketplace.  I think “pivot” is a fair term here, since Uniphore’s earlier acquisitions – Hexagone and RedBox in 2023, Colabor in 2023, and Emotion Research Labs in 2021 – all firms applied AI to more conventional CX use cases, such as emotion detection and conversation analysis.  Of course, the data infrastructure space itself is the playground of major cloud companies like Google and Amazon, as well as cloud data firms like Snowflake and Databricks.  Whether Uniphore can carve out a unique niche for itself as a tooling provider to connect those systems is uncertain but it seems worth a try.

As an aside -- I don't think a true "zero copy" approach to AI data is really possible.  We had this debate in the early years of the CDP industry, when companies including Salesforce and Adobe argued they could assemble customer profiles on the fly without a persistent database.  They ultimately learned that didn't work.  This doesn't invalidate Uniphore's strategy, even though the actual implementation will almost surely involve extracting, cleaning, and reorganizing data and storing the results somewhere that AI systems can use it.  That "somewhere" could in fact be a data warehouse -- the approach favored by composable CDP vendors.  This might more accurately be called "one copy" than "zero copy," although it wouldn't sound as appealing.

3.    Significance for the CDP Industry.  ActionIQ’s decision to sell to Uniphore obviously says something about the prospects for independent CDP vendors, but the implications are limited because ActionIQ’s technology was atypical.  In fact, since ActionIQ already supported the “composable” and “warehouse-native” approaches that are often touted as successors to traditional CDP systems, you could argue the deal indicates that prospects for firms taking those directions are more limited than their advocates believe.  

Given ActionIQ’s unique situation, I don’t think this deal presages a sudden burst of exits by mid-tier CDP vendors.  Even though growth has largely stalled for those firms, I think most can keep afloat long enough to find their footing in a new world.  This footing may well differ for different firms: for example, we’ve seen Lytics attempt to simplify CDP deployment enough to make it accessible to smaller businesses, while mParticle is moving more in the direction of combining customer data with analytics.  All need to dodge the giant cloud, cloud database, marketing cloud, and messaging vendors who are trampling the heart of traditional CDP territory.  Some will indeed take shelter within larger organizations like Uniphore.  Others may stay independent but retreat to niches such as data management tools or serving specific industries.  So even though the market for traditional, integrated CDP products is likely to shrink, I believe most of the vendors will survive in some form or another.  This is because the fundamental need driving CDPs – the need for unified, accessible customer data – will only grow stronger.  Companies that find a profitable way to meet that need will be able to thrive over time.

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. 

Filling the Gaps for a Composable CDP

Back in February, I mentioned that CDP Institute had published a Composable CDP Self-Assessment Tool that asks people what gaps they must fill to convert their current systems into the functional equivalent of a CDP. I recently checked how many responses we’ve received, and was disappointed that there were just fourteen. Obviously this isn’t enough to draw statistically meaningful conclusions, especially when you bear in mind that the audience of CDP Institute members can’t be considered representative of the industry as a whole. But I summarized the answers anyway to see what rough patterns might emerge. They were much more intriguing than I expected.

To set the context: the survey asks the status of 102 customer data management functions in the respondent’s current systems. These are grouped into eleven categories: data capture, data sources, ingestion, data preparation, data storage, identity linking, customer profiles, data sharing, process integration, segment creation, and segment (i.e., audience) output. Answer options are: not needed; needed and available; needed and not available; and don’t know. The most important of these is “needed and not available,” since that’s a gap to be filled. All questions were required.

When I took my first overview of the data, the first, and critically important, observation was that there did seem to be significant clusters in the answers. That was important because it suggested that people were giving accurate answers – at least, to the best of their knowledge – rather than randomly filling in a response. Had the answers been random, I would have expected to see roughly the same distribution of responses to each question, and that was definitely not the case. I’ll guess that requiring answers to all 102 questions filtered out the people who didn’t take the survey seriously.

The next observation was that gaps were more common in some areas than others. The gap percentages (i.e., percentage of "needed and not available" replies) ranged from 46% to 29%. The pattern is clear: the areas with fewest gaps (data sources, data store, data capture, and data sharing) are needed for pretty much any data warehouse, while the most gaps were tied to customer data management (data preparation, identity linking, ingestion, segment output, customer profiles).  This adds to the credibility of the data, even allowing for some confirmation bias.  More important, it's a reminder that you can’t assume a data warehouse built for other purposes will have all the features needed to support CDP applications.

A look individual functions shows something hidden by the category averages: even categories closely related to data warehouses will still have functional gaps for supporting a CDP. For example, while data warehouses are generally good at storing data, they often lack third party data and privacy management. Similarly, although capturing and sharing data are core capabilities for a data warehouse, they often lack real-time connectivity. This reinforces the need to look at requirements in detail when assessing the suitability of your existing warehouse as the base for a CDP.

 

It's also worth looking at the functions without the category filters. This shows more clearly that common data warehouse functions (such as loading structured data) are rarely gaps while CDP-specific functions (such as connections to advertising media, anonymous-to-known profile conversations, and end-user data access) are often gaps.  There are too few responses to make these rankings anything approaching precise. But, even if they were, what any individual company needs would still depend on its own situation.

Given the small sample size of this data set, it’s best to view these results more as anecdotes than an industry survey. But I still believe they offer some useful guidance to CDP vendors and users:

• For vendors: it’s worth noting which categories show the most gaps. The “composable CDP” discussion was initially driven by companies offering reverse ETL features, which correspond roughly to the data sharing, segment creation, and segment output categories. Ironically, these fall in the middle of category gap rankings. The biggest gaps, and probably the greatest opportunity for CDP components, relate to specialized data preparation, identity linking, ingestion and segment output. I'd guess that the reason the "composable" discussion started elsewhere is tools for specialized data prep, identity linking, etc. are already widely available, so there was less room for new entrants.  By contrast, reverse ETL is a relatively new category where it's easier for a new firm to establish itself.  CDP is actually just one application of reverse ETL; in "crossing the chasm" terms, it's a beach head where new vendors can establish themselves and then grow beyond. 
  

From a different perspective, it's also not surprising that more composable CDP vendors are offering products to fill gaps in other CDP categories: it's always easier to sell a new product to an existing customer than to sell an existing product to a new customers.  Offering a more complete set of components begins to make the composable products look more like an integrated suite, losing some of the flexibility of swapping components but also reducing the integration burden that composable vendors otherwise ignore.  It still maintains the core difference between a standard CDP that builds a separate database and a "composable" one that draws from the warehouse.

• For users: the list of common gaps is a helpful reference for ensuring that problematic functions are all considered in a requirements analysis. This is especially important at companies with strong existing data warehouse teams, whose members may not be familiar with CDP requirements.  To the extent that users' own systems match the category gap averages, it may make the most sense to consider custom enhancements to existing capabilities for categories with relatively few gaps, while buying new packaged components for categories with many gaps. Of course, if a company has many gaps across all categories, it probably makes more sense to buy a traditional CDP than to buy, integrate, and maintain a large number of separate components. 

 

 

CDP Overview: How We Got Here, Where We're Going, and What Could Get in the Way

Has anyone asked you recently about the past, present, and future of Customer Data Platforms?  No?  That's odd; people ask me those questions

all the time.  Here are my current answers. 

It’s eleven years since the term “customer data platform” appeared in 2013.  What stages has it gone through over that time?
 

The first stage was just to recognize that CDP was a separate category of software.  What was new about CDP was that it was packaged software that was building a customer database.  Before then, customer databases were custom projects, like a data warehouse, and the only packaged marketing software was applications like campaign management systems or predictive modeling tools.  The earliest CDPs actually bundled the database building capability with an application.  But, fairly soon, vendors realized that there was more value in the database building features, which were rare, than in the applications themselves, which were fairly common.

Once we had identified the CDP category, the next stage was convincing people that it was important.  The concept itself was easy to grasp (“all customer data in one place”).  But there was initial skepticism about whether it was a legitimately separate category or just another name for existing technologies such as CRM, data warehouses or DMPs.  So we spent most of our time explaining the difference between CDP and other systems that also built customer databases.  In fact, the formal CDP Institute definition – "packaged software that builds a persistent, unified customer database accessible to other systems" – is carefully crafted so that each term identifies a differentiator between CDP and some other type of system.  “Packaged software”, for example, distinguishes CDP from data warehouses and data lakes, which are custom built.  I won’t go through the other elements point-by-point.

Once the concept was reasonably well defined, we faced skepticism about need for separate CDP database, compared to just reading existing source data in real time to build profiles.  That’s what ”persistent” refers to in the CDP definition.  It took the big martech vendors including Salesforce and Adobe several years to accept that.  The reason is  that building profiles on demand by assembling data in real time just takes too long.

Even after category was established, there was great confusion about what really qualified as a CDP.  That’s why the CDP Institute launched its RealCDP certification program, which expanded on our definition by defining five key requirements: assemble all data types, keep all details, retain the data indefinitely (subject to regulatory constraints), build unified profiles, and share the data with other systems.  We later added a sixth point relating to two real time capabilities: access to individual customer profiles, for things like call centers and website personalization, and real time event triggers, for things like responding to dropped shopping carts.  Of course, we are just one voice among many, and are easily drowned out by vendor promotions. So, unfortunately, some of that confusion persists to this day.

Part of the reason for the continuing confusion is a debate over whether CDP just builds profiles or also should include data activation capabilities such as analytics and personalization.  Our view is they’re not essential, but over time, we’ve seen the industry split between CDPs that only build profiles and CDPs that include activation functions.  The majority of CDP vendors provide activation, so that’s clearly what most buyers want.

More recently, we’ve seen interest in using customer data beyond marketing, which makes IT and data teams more interested in CDP projects.  That’s a big change because when CDP was just a marketing tool, IT teams were very happy to let marketers buy the CDP becaise it kept the marketers happy without consuming IT resources.  Now, CDP is too important to be left to marketers.  This also makes the CDPs that just build profiles more appealing in some situations – and we have in fact seen slightly faster growth in that group most recently.

IT involvement in turn brings more interest in companies building their own CDP, and leveraging their existing data lakes and warehouses as the foundation.  This has been called ‘composable CDP’ although it’s not really the right use of the term ‘composable’.  Most people now agree that 'warehouse-based' is a better label.  Semantics aside, the problem is that IT teams often underestimate the requirements for a proper CDP and, thus, the work involved in creating one.  So it’s important to ensure they do a thorough job of scoping the project in advance, so they make the best choice.

The other thing we’ve seen, more or less continuously, is expansion of CDP into new industries.  Originally they were used primarily in retail and media.  Then, they grew more common in financial services, hospitality, and telecom, which are all industries that traditionally had pretty good customer data systems.  Most recently, we’re seeing CDPs in education, healthcare, and government applications.
 

We’re also seeing CDP used more for advertising applications, as companies lean more heavily on first-party data to replace the loss of third-party cookies and replace other targeting methods that become harder as privacy rules become more stringent.  
 

In fact, CDP also supports other privacy-related applications, such as closer control over ensuring that contacts are authorized by consumer consent, and providing data clean rooms for privacy-safe data sharing.  Funneling all customer list creation through a CDP is one way to avoid breaking privacy rules.

Where do you see the industry headed next?  

The biggest issue right now is the movement towards ‘composability’.  We can’t control whether IT and data departments try to build their own CDP-equivalent.  But we can educate them about the actual requirements and we can give them tools that make it easier to meet those requirements.  Many CDP vendors are now breaking apart their systems to provide modules that companies can use as components in building an internal system.  Of course, that helps those vendors to survive a transition to a composable CDP world, but it also helps to maintain the reputation of the industry as a whole.  What we don’t want to see is composable CDP projects fail because that makes people question the value of the CDP concept itself.

Closely related to the composable trend is a trend for ‘no copy’ access to external data by a CDP.  This means the CDP can read data from other systems without copying it into the CDP data store.  That used to be more or less impossible at scale, because finding, reading, and integrating masses of external data took too long.  With today’s technologies, that process can be much faster, so it becomes a more practical alternative.  Some common use cases are reading things that change quickly and are only relevant at the moment you need them, like inventory levels or local weather conditions.  Of course, this ability also blurs the distinction between a traditional CDP, which imported all its data, and a warehouse-based CDP, which works with data stored externally.  That’s okay but it does add still more confusion to the discussion.  

I’ll also make a side note that the original CDP skeptics argued for reading source system data on demand, so it may seem this proves they were right.  But so far I don’t think you can have a CDP that only works by reading external data on demand, because some processes like identity resolution and data aggregation still take too long to do purely on the fly.  So I see the future CDP as having a core of data that it does copy and store in its own database, for things like the identity graph that tells how to combine data from different sources into each customer’s profile.  Whether that database is a CDP or data warehouse doesn't matter: either way, the data will have been copied from the original source system and preprocessed for use by the CDP.  The core data could well be supplemented with data read on-demand from external systems, which could be the original source or a data warehouse or data lake.  At least in theory, this would give you the best of both worlds: minimal data copying but maximum performance.

Putting aside composability, CDPs will need to adjust to new privacy rules by adding features like encryption, advanced privacy policy management, and data clean rooms.  They’ll adjust to new media and new data types, like audio and video, which need to be not just stored but analyzed in ways that are currently close to impossible.  And, of course, they’ll adjust to growing AI capabilities, which will make it easier to perform some functions like adding new data sources, matching identifiers that belong to the same person, building predictive models, and analyzing business results.  AI will also add to the volume and complexity of data that CDPs have to handle, which itself may require new technology to support.  For example, if AI starts to create a huge variety of content personalized for each individual, that makes result analysis vastly more complicated.  Somehow the CDP will need to deal with that.

On a more prosaic level, I expect to see more CDPs that are tailored to the needs of particular industries.  That’s a typical development for a mature software category.  Specialist systems can be more cost-effective to build and deploy, because they use special data structures and features tailored to a particular industry’s needs.  This will bring down the cost of CDPs, which has been an obstacle to expanding the base of CDP purchasers.  

And, as I’ve already mentioned, I expect to see CDPs used more widely beyond marketing.  One thing we’ve learned in recent years is that customers expect a personalized experience every time they interact with a company, whether it’s before they buy a product or after they start using it.  That requires making customer data available at every interaction point.  Beyond direct customer interactions, teams like product development and operations planning also can benefit from using customer data.

Are there any particular obstacles or threats to the CDP’s continued success?

Certainly CDPs will have to adapt to the changes we’ve already discussed in data types and volumes, in the users for customer data, and in whatever technical developments change the best way for CDPs to be built.  Individual vendors may struggle to keep up.  But I think the need for complete, sharable customer profiles is here to stay.  So to the extent that that’s the core definition of a CDP, the future of the industry is secure.

That said, I do see two major threats to the CDP industry as we know it today.  

The first is technical: the cloud databases from specialists like Snowflake and Databricks and general cloud platforms like Google Cloud, AWS, and Microsoft Azure.  All those vendors are increasingly eyeing the giant pile of customer data held in a CDP and wanting it for themselves.  To get it, they’re adding applications to build profiles, such as data quality and identity resolution, and to do analytics and marketing.  Sometimes they make the applications to be features to their own database systems; sometimes they build direct integrations with specialist applications through a marketplace of some sort.  Either way, this cuts out the CDP, which has traditionally been an intermediary between enterprise data stores and business applications.  Again, this comes back to the notion of the warehouse as the primary customer data store, which makes the CDP database unnecessary.  I think threat is limited today because most IT departments don’t have the resources to build those systems for themselves. But as new tools make it easier to build those systems, the threat becomes more important.  There are really just two ways for CDPs to respond to this threat:

• one is to become platforms themselves, which is to say, to replace the data warehouse itself.  That’s not as crazy as it sounds, since the CDP is really a set of tools that builds the customer database, so it can work on top of a Snowflake or Google BigQuery or whatever database the client wants.  In this world, the CDP evolves from a tool to build customer profiles to a tool to build data warehouses in general.  Difficult but not impossible, at least for the largest CDP vendors who have the resources to compete.

• The other option is to become applications on top of the warehouse, offering specialized capabilities like cross-channel journey orchestration.  The would build on CDPs’ existing capabilities to share their profiles with activation systems, and to themselves do activation functions that apply across all channels, such as predictive models and best offer selection.  It’s actually an easier path for most CDP vendors, since it continues their role as intermediaries between data sources and business applications.  But it’s also a fairly narrow role and there will be lots of competition.  Specialization by industry, company size, and other variables will be the key to avoiding that competition by becoming the best choice in a particular niche.

The second threat isn’t technical, but the ability of organizations to actually make use of a CDP once it’s built.  We run into this all the time, when companies tell us their staff doesn’t know what to do with a CDP or doesn’t have the skills to do what they’d like.  It’s a problem that will only get worse as customer data grows more complicated and there are more possibilities for using customer data.  Maybe AI will solve the problem, and that’s something CDP vendors need to invest in to make happen.  But there’s no guarantee that AI will be the answer, and my guess is that even AI will need skilled users to take advantage of the possibilities it creates.  

Of course, if the CDP turns out not to be useful, the staff members will blame the CDP, not their own lack of skill.  But it doesn’t really matter who takes the blame: if CDPs don’t create value, companies won’t be willing to invest in them.  So it’s really important for the CDP industry to help train CDP users, not just in the technical details of how to use a CDP, but in the business programs that a CDP can support. 

Does CDP Need a New Definition?

The earliest Customer Data Platform systems were introduced before 2010; the term CDP was coined to describe this emerging class in 2013. My definition had changed very little when we launched the CDP Institute in 2016, and has been the same ever since: “packaged software that builds a unified, persistent customer database accessible to other systems”. The Institute added the RealCDP checklist* in 2019 to attach more specifics to the definition in the hopes of helping buyers ensure a system that called itself a CDP could actually support the use cases they expected a CDP to support. By then, industry analysts were beginning to offer their own definitions which, while worded differently, were broadly consistent with the Institute definition. Even the major marketing suite vendors, who initially argued a separate (“persistent”) database wasn’t necessary, eventually discarded that position and introduced products that matched our criteria.

A successful concept like CDP quickly takes on a life of its own. It soon became apparent that many people were using CDP in a much looser sense to mean any system that built and shared customer profiles. This extended past packaged software to include custom-built systems and included systems whose scope was more limited than a true CDP. This expansion skewed some survey resuls but otherwise seemed relatively harmless; in any case, resistance seemed both pedantic and futile. What really mattered was these systems still gave CDP users access to the unified profiles.

Unfortunately, the evolution of the term didn’t stop there. As CDP became popular, many vendors adopted the label whether or not they actually met even the looser definition. At the same time, legitimate CDP vendors offered additional capabilities to analyze and deploy the data in the profiles. The resulting confusion ultimately led some vendors to avoid the CDP label entirely because it no longer provided a useful way to differentiate their products. Today, vendors seeking the latest label are more likely to call themselves digital experience managers than a CDP, even if their products meet the CDP requirements.

But the greatest challenge to the utility of the CDP label arose in the past few years when a number of vendors chose to claim that the core feature of the CDP – a dedicated database built by importing data from other systems, a.k.a. “persistence” – could be abandoned while still calling the result a CDP.  Their argument was the customer profiles could reside in a general purpose data warehouse, which most companies already had in place. 

The claim gained some plausibility from the fact that modern cloud data warehouse technologies, such as Snowflake, Google Big Query, and AWS Redshift, are in fact used by some conventional CDP vendors. The problem was they implicitly assumed that every company’s data warehouse had organized the data into useable customer profiles. In fact, very few data warehouses perform the specific tasks, most notably identity resolution, customer-level aggregation, and real-time response, needed to support CDP use cases. While it’s technically possible to add those features to an existing data warehouse, it’s usually a major project that often costs more, takes longer, and delivers less useful results than installing a separate, conventional CDP. (As always, the details depend on the situation.)

One positive result of the interest in warehouse-based profiles has been the decision of some CDP vendors to break their systems into modules that let users buy the data preparation functions separately from the rest of the CDP. This lets companies that want a warehouse-based system to still benefit from the mature capabilities those CDP vendors have developed over many years. These vendors have also often added the ability to combine data from a warehouse or other external system with data stored in a conventional, persistent CDP database, without actually loading that external data into the CDP. This gains some advantages of the warehouse-based approach, such as reduced data movement and storage costs, while retaining the benefits of the persistent CDP, such as greater control and flexibility.

You’ll note that all these changes affect the input side of the CDP data flow. It was once a very simple process: data from other systems was copied into the CDP, where it was formatted into profiles and shared with other systems. Now, the input process may be some mix of copying data into the CDP, reading fully-formed profiles from a warehouse, or combining internal and external data. By contrast, the delivery side of the process has remained the same: the CDP shares its profiles with other systems. 

In some cases, this has led to a subtle shift in perception of the CDP’s purpose: from a system that builds customer profiles, to a system that delivers those profiles to other systems. In this view, the core function of the CDP is to convert general purpose profiles into the specific formats needed by analytical, orchestration, and delivery systems (which we can call “activation systems” if you’ll trade some jargon for simplicity). This may still involve some data processing, such as advance calculation of model scores and aggregates to make them available in real time, and new data structures to hold the results of that processing. So there’s more happening here than a simple data transfer or API call.

Some people carry this shift even further and argue the CDP should really be defined as an activation system that reads profiles from somewhere else. Since three-quarters of the CDPs we track actually do have at least some activation capabilities, this isn’t quite as crazy as it may sound.

All that said, I’m not yet ready to redefine CDP. “Packaged software” and “persistent customer database” are meaningful terms that distinguish one configuration from other approaches (“custom software” and “external profiles”) that can also make profiles available to other systems. More important, the packaged/persistent configuration has significant cost and execution advantages over the custom/external alternative. So it’s important to avoid blurring the distinction between the two approaches. 

 At most, I’d offer retronyms that distinguish the “packaged CDP” (packaged/persistent) from the “warehouse CDP” (custom/external). By definition, the “warehouse CDP” doesn’t build its own profiles, so the term seems to ignore the fundamental function of the CDP.  You might call that oxymoronic, if not just plain moronic. But if we slightly redefine the core function of the CDP to be delivery of profiles rather than creating them, we can overcome that objection and, perhaps, give the market terms it intuitively understands.

You’ll also note the shift from profile creation to delivery puts the emphasis on the delivery side of the CDP flow, which we’ve noted has been the most stable and applies to both the packaged and warehouse approaches. This lets us join the trend to redefining CDP as a profile sharing system.

In short, the key distinction is whether the primary customer profiles are built and stored in the company data warehouse or in a separate CDP database. It’s worth maintaining that distinction because one approach relies on the company’s technical staff to assemble the functions needed to build and store the profiles, while the other relies on a packaged CDP to provide those functions. There are variations within each theme, including whether the warehouse uses modules from a CDP vendor to assemble its profiles or to help deliver them, whether real-time data is posted to the warehouse or held separately, and whether the CDP enriches its profiles with external data without importing that data. These are important from a practical standpoint, but do not affect the fundamental architecture of the system. Focusing first on where the profiles reside should help buyers understand the most important choice they have to make. This choice will in turn determine the other decisions they have to consider. 

 

_________________________________________________________

* ingest data from all sources, retain all details, keep the data as long as desired, build unified profiles, share the profiles with any other system, and enable real-time event-triggers and profile access.

Do Self-Service Systems Really Lead to Better Results? Our Member Survey Offers Surprising Answers to Industry Questions

The CDP Institute just published its annual Member Survey, which is always a treasure chest of interesting data. I’ve already published my primary analysis on the Institute site (you can download it here) but wanted to call out a number of findings that either contradict or confirm martech industry conventional wisdom. After all, nothing’s more fun than tweaking the nose of authority.

Data unification is growing: false. Most of us have a deep-rooted confidence in progress, at least when it comes to technology (human nature is another matter). The need for unified customer data has now been so widely understood for so long that we just naturally assume that more companies will have developed it. That has been true since the survey began in 2017 through last year’s survey: both CDP deployment and presence of a unified customer database have increased steadily. But both measures fell in the current survey. It’s hard to imagine companies have actually abandoned their unified databases, but even if growth has only slowed, that would be a big surprise.

Budget pressures are slowing industry growth: true. Some industry vendors report business is booming, but most will admit buyers are taking longer to make decisions. Sure enough, the fraction of vendors who reported growth in CDP investment is down from last year’s survey, both for the past year and the current year. 

Budgets may not be the only reason for slower growth, but the budget pressures rose more quickly than any other obstacle (from 20% to 29%). Cooperation, which can also be a symptom of budget pressures, grew the second-fastest (36% to 43%). 

 

Budget-pressed buyers are making smarter decisions: false. I can’t point to anyone who has made this exact claim, but think it’s implicit in reports that companies have more martech than they need and hope to simplify their stacks in the future. 

The survey does show that budget pressures are changing martech selection methods: more are selecting on cost (up from 43% to 54% for operating cost and 42% to 51% for initial cost), while selection on feature sophistication and breadth have fallen the most (26% to 15% and 41% to 24%).

Unfortunately, our surveys have consistently found that selection on cost correlates with low satisfaction with martech investments, while selection on features correlates with high satisfaction. So it seems that a short-term focus on cost is likely to cause long-term problems with martech results.

 

Martech departments are growing: true. The fraction of survey respondents who said they work in a martech department has more than doubled since the last survey, which was the first that listed martech as an option. It’s unlikely that the number of people working in martech has actually doubled in the past year, but it does seem reasonable to believe that some meaningful fraction of employees have been moved from marketing or IT into a dedicated martech department.

IT staff is playing a larger role in martech decisions: true. Despite the growth in respondents who work in martech departments, the current survey showed a small increase in the fraction of respondents who reported that that corporate IT manages their marketing technology (28% to 30%) and sharp declines in the fraction reporting that a martech team was in charge (43% to 32%) or each department runs its own martech (27% to 18%). This may be another cost-saving measure or it may reflect the growing importance attached to customer data (and martech in general) throughout the enterprise.

The bad news is that IT responsibility also correlates with lower martech satisfaction. Bear in mind that survey respondents are themselves mostly martech and marketing people, who are generally happiest when their own team is in charge. IT people probably give a different answer but are a small fraction of the survey respondents.

CDP projects are easy: false. Past surveys have found that about 60% of deployed CDPs are reported as delivering value, while the remaining 40% are struggling. I have always suspected most of the 40% are new projects that will deliver value eventually. The success rate is much higher in the current survey (80%), possibly because the slowdown in deployment has meant there are fewer new projects. But I'd want to see similar results in one or two other surveys before accepting that as a trend.

A separate question, asking vendors about success rates, finds the fraction reporting that say almost all or the majority of projects are successful has grown from 48% to 54%. While this might suggest some improvement in success rates, the more important message is that a bare majority of vendors say most CDP projects succeed.  Even when answers from CDP vendors are tabulated separately, just 68% say nearly all or a majority of projects are successful. Figures are lower for service providers (45%) and other respondents (15%). 

It's important to realize this is no worse than success rates for other large system deployments.  In fact, it's apparently better than average, since most studies put failure rates at 60% to 70%.  (See this page for a compendium.)  But these findings should dispel any notion that CDP deployments are easy. 

CDP projects fail because of technical complexity: false. It's also important to recognize that CDP failure rates are not due to any inherent problem with CDP technology.   As in previous surveys, by far the top reason for CDP project failure is organization. This has grown even more prominent in the current survey, while problems with poor requirements and CDP performance have fallen.

Comparing CDP status with satisfaction offers additional insight.  The satisfaction measure reflects success with martech in general, not with CDP in particular.  In other words, companies with a high score are "good at martech".  So, while it's not surprising that satisfaction rates are high among companies with a successfully deployed CDP and low among those who have not, this does support the position that CDP success is based more on the skills of the organization than CDP technology in particular. 

 

Privacy is growing more important: true. Last year’s survey showed a distressing decline in the priority given to data privacy regulations, with the share of firms making little effort to comply growing from 12% to 20%. That trend has now reversed, with the share of companies using privacy as a selling point increasing from 21% to 27%. 

Privacy was also listed in the CDP benefits question for the first time.  It was cited by 22% of respondents, ranking seventh of eleven items, and shows a below-average satisfaction score. This may indicate that most CDP users are looking elsewhere for their primary privacy management solution.

 

Self-service leads to success: false. The martech management section of this year’s survey added a new question about whether companies seek systems that empower business users to execute tasks without technical assistance. The concept of “no-code” is directly relevant here, although we didn't use the term.  This capability was by far the most common management technique, which wasn’t surprising: “empowering end-users” is a popular goal that saves money and makes users more effective.   But it also correlated with a low satisfaction score, which was surprising indeed. Is it possible that self-service doesn’t save money or make users more effective after all?

 

Answers to another survey question shed a bit more light. Among the options listed for CDP capabilities were self-service data extracts and self-service predictive models. Self service extracts were a common requirement (41%) correlated with a roughly average satisfaction rating, while self-service models were an uncommon requirement (8%) correlated with a very low satisfaction rating. My interpretation is that self-service extracts are a simple task that’s well understood by business users, so companies with well-run martech operations provide that capability.  By contrast, self-service predictive models are a complicated task that few users are equipped to handle on their own, so they are prioritized largely by companies with a poor understanding of what makes for martech success.  The larger message is that self-service should be deployed only when users are ready for it – and pushing beyond those limits can cause problems despite the apparent savings in cost and time.

 

Real-time processing is a high priority for most users: mixed. Real-time processing is commonly cited as an important CDP capability. In fact, the CDP Institute’s RealCDP requirements include real-time access to profiles and real-time event triggers. Again looking at the capabilities question, we see that real-time profiles are indeed a common requirement (42%), while real-time recommendations are much less common (15%) but correlate with very high satisfaction. The lesson here is that there are different types of real-time processing, and users consider some more important than others. Discussions about real-time should include similar nuance.

CDP must load data from all sources and retain full details: mixed. Both of these items are on the RealCDP requirements list. But loading data from all sources is the highest ranked capability (78%) and correlates with roughly average satisfaction, while loading full detail is cited by just 14% of respondents and correlates with much lower satisfaction. As with real-time and self-service, I take these answers to show that users have a mature understanding of what they do and don’t need from the CDP.  Loading all data sources is a core CDP promise and goes back to the problem CDP was originally designed to solve: getting access to all customer data. Storing full detail is not needed in most situations.  In practice, users choose which data elements are worth the cost. That said, I still believe that users want the option to store any particular details they need.

CDP users want to access their data warehouse directly: false. This year’s survey added a capabilities question about reading data from an external source without loading it into the CDP. This is a hot topic in the industry, both as a way of supplementing a traditional CDP (which maintains its own data store) and as a way of building a CDP-equivalent system that relies only on data in the enterprise data warehouse. Only a small fraction of respondents (14%) were interested in this and that group reported exceptionally low satisfaction levels. I interpret this to mean that, despite all the marketplace noise, there is actually very little interest among knowledgeable users in building a CDP that relies primarily on external data.

Summary

This report contains more bad news about industry growth and budget pressures than I like to see, but the tech sector’s troubles are well known and it’s not surprising that CDP projects should suffer with everyone else. I’m especially reluctant to highlight the data about success rates, because I know it will be taken out of context by vendors eager to promote alternatives to CDPs. I should stress again that the main obstacles to CDP success are organizational, not technical, and that success rates reported here are consistent with tech project success rates in general.  Bottom line: CDPs are major projects that don’t always go smoothly but are not more failure-prone than any other major IT effort.

What worries me more than bad news is the hints that companies are making poor decisions. Prioritizing cost over requirements will surely lead to more companies purchasing unsuitable products. Putting IT in charge of martech will almost surely lead to unhappy martech users. While budget issues are unavoidable, poor management decisions are unforced errors. Your company should work hard to avoid them.

All that said, the most interesting results are the ones that challenge conventional wisdom. Do self-service systems really lead to bad results? Is the importance of real-time overstated? Is there really so little interest in reading data directly from a warehouse? These are headline topics in martech today, and are often accepted as truth with little discussion. The questions are worth asking because the reality is almost always more complicated than the simple answers. When is self-service useful and when is it over-used? What kinds of real-time processes are really important? How is external data best integrated with a conventional CDP? Answering those questions will help companies make better decisions and ultimately lead to greater martech success.