What is a CDP — and do you actually need one?

What is a CDP?

A customer data platform collects customer data from across your systems, resolves the records belonging to the same person into one profile, and pushes those profiles out to the tools that act on them.

The middle job is the one that distinguishes the category. Plenty of systems store customer data — a warehouse, a CRM, an email platform. Identity resolution across those sources is one of the defining jobs buyers expect a CDP to perform, and to keep performing as new data arrives.

Do you actually need one?

For some buyers, the first decision is no longer which CDP to buy. It is whether they need a separate CDP at all.

Several buyers in these interviews compare a packaged CDP with expanding their warehouse, building internally, or stretching a platform already in the stack. That comparison is worth stating plainly because the category's own material rarely does: the choice on the table is not only which vendor, but buying a CDP against not buying one.

One buyer puts it directly: they are reviewing our options and considering not replacing it with an off-the-shelf CDP, and may grow Braze and Snowflake's capabilities instead. Another has evaluated several CDPs but have not yet committed to one, and is deciding whether to use a purpose-built CDP or rely on our existing Snowflake infrastructure — noting that consultants suggested expanding Snowflake's capabilities. A third is still deciding whether to build a CDP internally or choose from industry leaders.

What are the alternatives to buying a CDP?

Three alternatives come up, and each has a different failure mode.

Each of these is covered in depth elsewhere: the warehouse and in-house routes on the CDP exit-ramps page, and the email-platform route on does your ESP replace a CDP. If the system you already own is a CRM, that comparison is its own page.

What the three have in common is the question underneath them: the buyer is testing whether the CDP job can be absorbed elsewhere rather than assuming it requires another packaged platform. That is the shape of the decision, and it is not the shape of most vendor material about it.

What has to be true before a CDP works?

Trustworthy source data, and enough governance over it to make identity resolution meaningful.

The distinction is worth holding: a CDP answers are these records the same customer? It does not answer is this customer record accurate in the first place? That second question belongs upstream, to data governance or master data management.

One buyer defers their evaluation for exactly this reason. They are prioritising establishing a customer Master Data Management solution first, on the basis that foundational customer record data must be in place before evaluating Customer Data Platforms. The CDP is not cancelled — it is sequenced behind the data work, with a revisit planned for late the following year.

That caution is earned. A buyer already running a major platform reports issues with data hygiene, such as duplicate records and inconsistent reporting, and describes the platform as not as usable as they would like. A CDP resolves identity across sources; it does not repair source data that is wrong.

Worth reading alongside this: buyers describe implementations running well past what the sales cycle implies, which has its own page, and the data underneath is often the root cause when a CDP gets replaced rather than the platform itself — covered in why companies replace their CDP.

What makes the case for buying one?

A specific, nameable gap — not a general wish for better data.

The clearest example in these interviews comes from a retailer evaluating platforms to capture more data on guests who don't use our loyalty numbers, in order to understand the large majority of sales coming from customers they cannot currently identify. That is a concrete population, a concrete blind spot, and a concrete thing a platform would change.

Another describes considering a CDP as part of a commerce replatform, with the aim of centralising data and unifying it across analytics and advertising platforms — again, a named problem with a named trigger.

Set those against the buyer who says simply that they haven't prioritized CDPs at this time while acknowledging their potential value. The pattern suggests the strongest case starts with a specific thing the buyer cannot currently see, rather than with conviction about the category itself.

How do buyers rate the platforms?

Average buyer rating (1–10) for the customer data platforms buyers most often name.

Platform	Avg rating	How buyers position it
Hightouch	7.9	The warehouse-native option, and the highest-rated here — it activates data where it already sits rather than copying it somewhere new.
Amperity	7.2	Named for identity resolution at retail scale — one of the clearest jobs buyers associate with dedicated CDP capability.
Segment	7.0	The most-rated platform here, usually described as the source of truth feeding everything downstream.
Salesforce Data Cloud	6.8	The route for teams already committed to Salesforce. One buyer here reports duplicate records and inconsistent reporting.
Tealium	6.9	The tag-management lineage is visible: buyers name it for collecting data across sources and routing it onward.
mParticle	6.4	Mobile-first heritage, and the second-lowest of this set.
BlueConic	6.2	The lowest-rated here. It is also the platform in the deferral above — a buyer holding a re-evaluation until the master-data work underneath is done.

The ratings do not produce an obvious winner: six of the seven sit below 7.3, with Hightouch alone at 7.9. The ranking will not make the decision for you. What buyers wish they had known and what they actually pay are more useful inputs than the ranking.

How do you know if you need a CDP?

Three questions get you further than a vendor comparison, and these are our recommendation rather than a framework buyers describe.

What specifically can you not see? The buyers with the easiest internal case can name a population — customers who never identify themselves, sales they cannot attribute to a person. If the answer is our data is messy, that is a different project.

Is the problem identity resolution, storage, or source quality? These point three different ways. If the data has nowhere central to land, that is a warehouse problem. If the records themselves are wrong or duplicated at source, that is a governance problem and the interviews suggest fixing it first. If the data is landing fine and the gap is joining it to one person and pushing that profile into several systems — that is the CDP-shaped one.

What is the honest alternative? The buyers here name one — the warehouse, a build, or a platform already in the stack. Price the CDP against that, not against doing nothing.

If the answer turns out to be yes, the questions worth asking vendors and how to write the RFP are published separately.

Common questions