Customer Data Platform Vendors: What They Sell vs. What You Need
Customer data platform vendors sell the promise of a single, unified view of your customer. What they actually deliver depends almost entirely on how well your data infrastructure, team capability, and business processes are set up before you sign anything. The CDP market has matured considerably, but the gap between vendor pitch and operational reality remains wide enough to swallow significant budget.
A CDP consolidates customer data from multiple sources, resolves identities across touchpoints, and makes that data available to other tools in your stack. That is the category definition. Whether a specific vendor does that well, at your scale, for your use cases, is a completely different question, and one most procurement processes fail to answer properly.
Key Takeaways
- Most CDP failures are not vendor failures. They are failures of data readiness, internal alignment, and use case clarity that exist before the vendor is selected.
- The CDP market splits into two distinct categories: composable CDPs that sit on your existing data warehouse, and packaged CDPs that manage their own data layer. Choosing the wrong architecture for your stack is an expensive mistake to reverse.
- Vendor consolidation is accelerating. Several major CDPs have been acquired by larger marketing clouds, which changes the roadmap, pricing leverage, and integration assumptions you may have built your business case on.
- A CDP without a clear activation strategy is a very expensive data storage project. Unification alone does not drive growth.
- Before evaluating vendors, define three to five specific use cases with measurable outcomes. If you cannot do that, you are not ready to buy a CDP.
In This Article
- Why the CDP Category Is Harder to Evaluate Than It Looks
- The Composable vs. Packaged Architecture Decision
- The Major Vendors and What They Are Actually Good At
- What Vendor Consolidation Means for Your Buying Decision
- The Use Case Problem That Kills Most CDP Implementations
- Identity Resolution: The Capability That Separates Vendors More Than Anything Else
- How to Structure a CDP Evaluation That Does Not Waste Six Months
- The Honest Conversation About CDP ROI
Why the CDP Category Is Harder to Evaluate Than It Looks
I have sat in a lot of vendor presentations over the years. The CDP category produces some of the most confidently delivered pitches in enterprise software, and also some of the most misleading. Part of the problem is definitional. The term “customer data platform” was coined to distinguish a category from CRMs, DMPs, and marketing automation tools, but vendors have stretched it in every direction since. Some CDPs are primarily data ingestion and identity resolution tools. Others are full marketing activation platforms with built-in campaign orchestration. A few are essentially analytics layers with a CDP label applied for positioning purposes.
When I was running an agency and we were helping clients evaluate marketing technology, the first thing we did was strip the vendor labels off and ask: what does this tool actually do, and what does it require from us to do it? That question alone eliminated half the shortlist in most cases. It also surfaced the real conversation, which was usually about internal data maturity rather than vendor capability.
The CDP Institute, which is one of the more useful independent resources in this space, has published category definitions that help clarify the landscape, but even their taxonomy has struggled to keep pace with how quickly vendors are repositioning. The honest framing is this: a CDP is a system that ingests customer data from multiple sources, builds persistent customer profiles, and makes those profiles available to downstream systems. Everything beyond that is vendor-specific and needs to be evaluated on its own terms.
If you are thinking about where CDP investment fits within a broader go-to-market strategy, the Go-To-Market and Growth Strategy hub covers the commercial context that should be shaping these decisions before you get anywhere near a vendor shortlist.
The Composable vs. Packaged Architecture Decision
The most consequential decision in CDP selection is not which vendor you choose. It is which architecture you commit to. This has become clearer as the composable CDP model has gained serious traction, driven by the growth of cloud data warehouses like Snowflake, BigQuery, and Databricks.
A packaged CDP manages its own data layer. You send data to it, it builds profiles within its own infrastructure, and it pushes activation signals out to your other tools. Vendors like Segment, Salesforce Data Cloud, and Adobe Real-Time CDP operate broadly within this model, though each has its own architecture nuances. The advantage is that the CDP does more of the heavy lifting. The disadvantage is that you are creating a parallel data environment that needs to stay in sync with your warehouse, your analytics stack, and everything else.
A composable CDP, by contrast, sits on top of your existing data warehouse. Tools like Hightouch, Census, and Rudderstack’s warehouse-native offering work in this model. Your data stays where it is. The CDP layer handles identity resolution, audience building, and activation without duplicating your data into a separate system. For organisations that have already invested in a modern data warehouse, this is often a more pragmatic path.
The composable model is not universally better. It requires a more mature data engineering function and a warehouse that is already well-structured. If your data is a mess upstream, a composable CDP inherits that mess directly. A packaged CDP at least gives you some ability to clean and structure data within its own layer, which can be useful in the short term even if it creates technical debt later.
The architecture decision also affects cost modelling significantly. Packaged CDPs tend to price on data volume, profile counts, or event throughput. Composable CDPs often price on destination syncs or active profiles. Neither model is inherently cheaper, but the cost scaling dynamics are different, and they need to be modelled against your actual data volumes before you commit.
The Major Vendors and What They Are Actually Good At
Rather than a ranked list, which would be outdated within months given how quickly this market is moving, it is more useful to characterise the major vendors by their genuine strengths and the contexts where they make sense.
Segment built its reputation on developer-friendly data collection and clean API integrations. It is still one of the strongest options for companies with a significant product-led growth motion, where tracking in-product behaviour and connecting it to marketing activation is the primary use case. Twilio acquired Segment in 2020, and the integration with Twilio’s messaging infrastructure has become a genuine differentiator for companies doing sophisticated multi-channel engagement. The limitation is that Segment’s profile unification capabilities are less advanced than some competitors, and the platform can become expensive at scale.
Salesforce Data Cloud (formerly Salesforce CDP, formerly Customer 360 Audiences) is the right choice if your organisation is already deeply invested in the Salesforce ecosystem. The integration with Sales Cloud, Marketing Cloud, and Service Cloud is genuinely strong, and the Einstein AI layer adds real capability for predictive scoring and segmentation. Outside the Salesforce ecosystem, the value proposition weakens considerably. The implementation complexity and cost are also non-trivial, and Salesforce’s enterprise sales process is not known for its flexibility on pricing.
Adobe Real-Time CDP is the counterpart for organisations running Adobe Experience Cloud. The real-time profile activation capability is genuinely impressive in demo conditions, and Adobe has invested heavily in identity resolution. The same caveat applies: if you are not already in the Adobe stack, the onboarding cost and complexity is hard to justify. Adobe also tends to require significant professional services investment to get to production-ready deployment, which is worth factoring into total cost of ownership.
mParticle is strong in mobile-first environments and has deep roots in the gaming and media industries. Its data quality and governance capabilities are among the best in the category. For companies where mobile event data is the primary data source and data accuracy is non-negotiable, mParticle is worth serious consideration.
Hightouch and Census represent the composable end of the market. Both are well-built products that do what they say. Hightouch has expanded into AI-driven audience segmentation and campaign orchestration, which makes it a more complete platform than it was two years ago. Census has strong data transformation capabilities and works well for teams that are already using dbt in their data pipeline. Neither is a full CDP replacement for organisations that need strong identity resolution, but for teams with a mature warehouse, both offer a significantly lower-friction path to activation.
Bloomreach sits at the intersection of CDP and marketing automation, with particular strength in e-commerce. If personalisation at the product and content level is the primary use case, Bloomreach’s combined CDP and engagement platform is worth evaluating. It is not the right fit for B2B or complex enterprise environments, but for retail and e-commerce, it is one of the more commercially grounded options in the market.
What Vendor Consolidation Means for Your Buying Decision
The CDP market has seen significant consolidation over the past few years, and that trend is continuing. Twilio acquired Segment. SAP acquired Emarsys. Acoustic spun out from IBM. Oracle has been quietly repositioning its data management capabilities. Salesforce has absorbed and rebranded its CDP offering multiple times. Adobe acquired Marketo and has been integrating its data capabilities across the Experience Cloud.
Consolidation changes the buying calculus in ways that are not always obvious at the point of selection. When a CDP is acquired by a larger marketing cloud, the product roadmap tends to shift toward serving the acquirer’s broader platform strategy rather than the standalone use cases that made the original product valuable. Integration priorities change. Pricing models change. The sales team changes. The support quality changes.
I have seen this play out with other categories of marketing technology. A client selects a best-in-class point solution, it gets acquired 18 months later, and within two years the product they bought is being sunset or folded into a suite they do not need. The lesson is not to avoid acquired products, but to factor acquisition risk into your evaluation. Ask vendors directly about their ownership structure, investor backing, and whether they are actively in conversations with potential acquirers. You will not always get a straight answer, but the response itself is informative.
Understanding how vendor decisions fit into a broader commercial transformation is something BCG’s work on go-to-market transformation addresses well. The principle that technology choices need to be anchored in commercial strategy rather than driven by technology preference applies directly to CDP selection.
The Use Case Problem That Kills Most CDP Implementations
The most common reason CDP implementations fail is not technical. It is that the organisation did not define specific, measurable use cases before selecting the vendor. They bought a platform, then tried to figure out what to do with it. I have seen this pattern more times than I can count, including in organisations that were otherwise commercially sophisticated.
A CDP is not a strategy. It is infrastructure. The value comes from what you do with unified customer profiles, not from the unification itself. Before you evaluate a single vendor, you need to be able to answer these questions with specificity: Which customer segments are we currently unable to identify or reach? What personalisation or suppression use cases are we leaving money on the table with? What does a 10% improvement in retention look like in revenue terms? Which downstream activation tools do we need the CDP to connect to, and what data do they need?
If you cannot answer those questions, you are not ready to buy a CDP. You are ready to do the internal work that should precede the buying decision. That work typically involves a data audit, a use case prioritisation exercise, and an honest assessment of your team’s capability to implement and operate whatever you buy.
The difficulty of go-to-market execution is well-documented, and CDPs are often positioned as solutions to GTM complexity. They can genuinely help, but only when the underlying GTM strategy is clear. Technology does not fix strategic ambiguity. It amplifies it.
Identity Resolution: The Capability That Separates Vendors More Than Anything Else
If there is one technical capability that separates CDP vendors more than any other, it is identity resolution. The ability to recognise that a user who browsed your site on a mobile device last Tuesday is the same person who opened your email on Thursday and converted through a desktop session on Friday is genuinely difficult to do well. Most vendors claim to do it. The quality varies enormously.
Identity resolution operates through two broad approaches: deterministic matching and probabilistic matching. Deterministic matching uses known identifiers, typically email addresses, phone numbers, or login IDs, to link records with certainty. Probabilistic matching uses signals like device fingerprinting, IP addresses, and behavioural patterns to infer identity connections with a confidence score. Most enterprise CDPs use a combination of both.
The practical question when evaluating vendors is: what is your match rate on our data, and how do you validate it? Ask for a proof of concept using a sample of your actual customer data. Vendors who are confident in their identity resolution capabilities will agree to this. Those who resist or deflect are telling you something important.
The deprecation of third-party cookies has made first-party identity resolution more valuable and also more complicated. Vendors who have invested in privacy-preserving identity approaches, including clean room integrations and consent-based identity graphs, are better positioned for the current environment than those still relying heavily on third-party data signals. This is worth probing specifically in any vendor evaluation.
Forrester’s research on agile scaling and technology adoption is relevant here: the organisations that scale technology successfully are those that build capability incrementally rather than trying to implement everything at once. Identity resolution is a capability that improves with time and data volume. Starting with deterministic matching and expanding from there is usually the right sequencing.
How to Structure a CDP Evaluation That Does Not Waste Six Months
Most enterprise technology evaluations are too long, involve too many stakeholders, and produce RFP documents that vendors answer with templated responses that tell you almost nothing useful. Here is a more efficient approach, drawn from running procurement processes on both the agency and client side.
Start with architecture, not features. Decide whether you are going packaged or composable before you talk to any vendors. This decision is driven by your existing stack, your data team’s capability, and your budget model. Once you have made that call, your shortlist is already half the length it would otherwise be.
Define three to five prioritised use cases with clear success metrics before any vendor conversation. Share these use cases with vendors and ask them to walk you through exactly how their platform would support each one, including what data inputs are required, what the implementation timeline looks like, and what the ongoing operational requirements are. Vague answers to specific use cases are a red flag.
Run a paid proof of concept with your top two vendors. A meaningful POC uses your actual data, tests your actual use cases, and involves your actual team. Vendors who will not do a paid POC or who want to run a demo environment using synthetic data are not giving you useful signal. The POC does not need to be long, four to six weeks is usually sufficient, but it needs to be real.
Talk to references who are similar to you in scale, industry, and technical maturity. Vendor-provided references are selected to be positive, but they are still useful if you ask the right questions: What did implementation actually cost versus what was quoted? What took longer than expected? What would you do differently? What support quality have you experienced post-implementation?
Model total cost of ownership over three years, not just the licence fee. Include implementation costs, internal engineering time, ongoing support, and the cost of any adjacent tools you will need to make the CDP work. The licence fee is rarely the biggest number in the total cost calculation, and vendors know this, which is why they lead with it.
Growth strategy frameworks from Forrester’s intelligent growth model are useful for contextualising where CDP investment fits in a broader commercial plan. Technology investment should be sequenced against growth priorities, not driven by vendor sales cycles.
The Honest Conversation About CDP ROI
CDP vendors will show you ROI case studies. Some of them are real. Many of them are the best-case outcomes from implementations where the client had strong data foundations, clear use cases, and capable teams. They are not representative of the average implementation.
The honest picture of CDP ROI is that it is highly variable and heavily dependent on factors that are within your control rather than the vendor’s. Organisations with clean first-party data, well-defined activation use cases, and the internal capability to act on customer insights tend to see meaningful returns. Organisations that buy a CDP hoping it will solve a data strategy problem they have not addressed tend to see expensive underperformance.
I spent years judging effectiveness work at the Effie Awards, and the pattern that consistently separated effective marketing from ineffective marketing was not the sophistication of the technology. It was the clarity of the insight and the precision of the execution. A CDP can sharpen both of those things, but only if the underlying commercial thinking is already sound.
If you are building a growth strategy that includes customer data infrastructure, the broader context for those decisions is worth working through carefully. The Go-To-Market and Growth Strategy hub covers the commercial frameworks that should be shaping technology investment decisions, including how to sequence capability building against growth priorities.
The BCG long-tail pricing research is a useful reminder that commercial strategy decisions, including technology investment decisions, need to be grounded in how your specific market actually works rather than in category-level generalisations. The CDP that is right for a high-volume B2C retailer is rarely the right CDP for a mid-market B2B SaaS company, even if both are described as needing “a unified customer view.”
Buy a CDP when you have specific, measurable use cases that require unified customer data to execute. Buy it when your data foundations are clean enough to make unification meaningful. Buy it when you have the internal capability to implement, operate, and iterate on it. If those conditions are not met, the money is better spent on the work that creates those conditions.
About the Author
Keith Lacy is a marketing strategist and former agency CEO with 20+ years of experience across agency leadership, performance marketing, and commercial strategy. He writes The Marketing Juice to cut through the noise and share what works.
