CDPs in 2026

A CDP in 2026 is the same thing as it was when first birthed over a decade ago: A CDP is whatever the vendor says it is.
That may sound cynical—but after waves of trends, acquisitions, the (reluctant) entrance of MarTech suite vendors into the market, and the rise of cloud data warehouses as core customer data repositories—it remains the most practical definition.
Of course, that’s not a particularly helpful definition either. So as MarTech and Digital leaders like you navigate this rather gassy landscape, let’s nudge the question of CDPs in 2026 into a different frame—one that supports actual business value and offers you directional advice for an uncertain future.
As usual, you need to start with value and purpose, and then define architecture and capabilities, and only then explore whatever we’ll call the CDP marketplace.
What Enterprise MarTech Leaders Really Need
After 10 years at Real Story Group advising enterprise stack leaders on this topic, a consistent if oft-forgotten premise is that the whole point of a CDP is to add value to Marketing and Digital operations.
As a practical matter, marketers and other digital engagement leaders have always wanted some specific capabilities:
- A marketer-friendly, actionable view into a subset of processed customer attributes labeled with marketer-relevant terms
- Simple interfaces to create ad-hoc and always-on segments
- A proper activation environment, with a connector framework, and reusable activation templates
- A real-time API supporting inbound queries for attributes on a specific record with subsecond response times
- An event subsystem with marketer-friendly trigger management
- Relatedly, a "speed lane" where a select subset of raw events can prompt a reaction in near-real time
These are the objectives, and I repeat them here since they can get lost in “bottom-up” efforts starting from your lakehouse to grow customer data maturity from the storage layer going upwards.
Of course bottom-up thinking does remain important, because providing basic customer data management and processing capabilities in any enterprise requires a very heavy lift by enterprise DataOps and ITOps teams. All those bulleted items above assume you have your customer data house in good order, and most enterprises have had major back-end work to complete here. So let’s continue the discussion with architecture.
An Architectural Reference Model
Customer data is complicated enough that for larger enterprises, we need to speak of a “data ecosystem.” For example, no single platform can manage multiple terabytes of raw signals, while driving real-time insights, and trigger sub-second personalization routines. So Real Story Group counsels that a mature ecosystem relies on at least three distinct, underlying "hubs."
An enterprise stack needs to rely on three broad data hubs, each with a specific business purpose, and each requiring specialized skills and tools. Source: RSG
We isolate these as three distinct hubs because they require different expertise, usually different supporting tools, different (if related) data models, and march to different rhythms of work. Let’s briefly look at each.
On the left, Core Data Hub is a store of raw data and processed attributes—a superset of everything you know about the customer. Internal structures range from exceptionally well-curated “master data” to highly evanescent behavioral events streaming in as raw data. It doesn't deal with speed of delivery; it worries about completeness, accuracy, business-driven processing, governance, and history.
Critically, this hub serves more than Marketing, and in fact supplies the truth to all the different enterprise entities that need it, including Finance, Product, Customer Service, Compliance and more. This is why most enterprises don’t want to manage this hub exclusively in their Marketing operation, as part of their MarTech stack.
The Data Orchestration Hub is your activation layer. It holds a lighter weight, mostly processed subset of customer data inherited from the Core Data Hub, supplemented with select real-time feeds or events, which may invoke business-managed triggers. This hub gets run by Marketing and CX and/or DX Team.
The Data Insights Hub is where raw and processed data alike get converted into insights, increasingly with the help of AI. Unlike the Core and Orchestration Hubs, which could be considered roughly the past and present—the “Insights Hub” focuses on the potential and what’s next—uncovering patterns, predicting behaviors, recommending actions, and refining the logic that governs the entire ecosystem..
This hub is managed by your Marketing Data Science Team, or some hybrid combination of marketing analytics, business intelligence, and enterprise data science resources.
Where CDP Vendors Come in
Recall that all three hubs are logical concepts. Physically each one might entail a single overall vendor platform, or two, three or more platforms, from different vendors. There are many levels to composability.
Here’s where CDPs come in. Some vendors sell a CDP that tries to serve a single environment for all three hubs; mostly these are mid-market solutions akin to Customer Experience Platforms.
At the enterprise tier, we see two CDP vendor patterns:
- Combination Core Data + Orchestration Hub. This feels architecturally inelegant but we have seen some RSG corporate members succeed with this model. Ping me for details.
- Data Orchestration Hub only. CDP is decoupled from your core customer data hub, focused on activation only for digital and marketing ops teams.
Now recall from above that when we’re talking about this from a MarTech perspective, activation is where you ultimately add value. This is why a Core Data Hub is necessary, but not sufficient. Reverse ETL and other vendors promise a more “composable” approach for bridging that Core-to-Activation gap. This seems architecturally elegant, but underneath the covers, they’re typically not zero-copy, and more importantly, not often marketer friendly.
This brings us to Databricks’ recent CDP announcement, where they are moving up the stack, essentially now providing two logical hubs from the same vendor (as several traditional CDP vendors have done for some time). There are some big caveat emptors here. But my bigger caution is that Databricks has no priors building marketing software, and that if your marketing ops specialists puke all over their interfaces, you’re the one that loses.
AI Confirms Some Trends
The rapid evolution of AI in the context of MarTech is confirming this architecture. Specifically, it’s largely ruling out your CDP as an Insights Hub, and pushing Orchestration Hub to assume more advanced Decisioning.
Hopefully by now we’ve all realized that Insights AI is perhaps the most impactful type of AI (among Generative, Decisioning, and Insights) for your marketing team. It’s also a precondition for effective Decisioning AI. Moreover, your Insights (AI-enabled or not) are only going to be as strong as your underlying base of data. This is why your CDP – which typically does not have access to raw data – is not a great platform for Insights going forward. In the Year 2026, don’t let your CDP’s “AI-enabled” algorithms spit back insights based on limited data. Decisioning AI is different; it’s also the hardest to test and execute. We know overall that decisioning services need to be close to good data, and this is why many CDPs are focusing more on decisioning in general, and journey orchestration in particular.
Here, though, AI will change the game a bit. Especially as agents mature, journeys and next best actions they drive are likely to become their own technology domain, driving a diverse set of customer interfaces and experiences. This recorded briefing shares some broader thoughts about AI and the future of journey orchestration.
A CDP in 2026
I began this article with a somewhat cynical definition, so in the interest of closing on a more positive note, here’s a revised, vendor-free definition for 2026: a CDP is whatever you make of it. You have many choices here, but architecture remains foundational, and centering marketer capabilities becomes a top priority. This may extend into journey and related decisioning services for now, but understand that in the long run, that’s likely to become a separate, AI-driven layer in your stack.
If you’d value an outside perspective on your enterprise needs from an experienced team, contact RSG here.