What a CDP is — and isn't
A Customer Data Platform unifies customer data from all your sources — CRM, shop, app, website, service, outbound — into a single, persistent, identity-resolved profile per person, and makes that profile available to your marketing, service, and analytics tools across all channels in real time. The technical part is straightforward; the decisive word is persistent. A CDP stores profiles permanently and reuses them at every interaction — unlike a DMP, which thinks in cookie sessions, or a Data Warehouse, which builds reports but does not activate.
What a CDP is not is easier to say. It is not a Data Warehouse — a DWH is the truth for finance, a CDP is the truth for the customer. It is not a Marketing Cloud — a Marketing Cloud activates but does not resolve identity across 40 sources. It is not a Tag Manager — a Tag Manager fires events but does not store profiles. And it is explicitly not a CRM. The distinction between CDP, CRM, and DMP is fundamental, and confusing them costs millions in misinvestment within six months.
The four core functions of a real CDP
Identity Resolution. The first and most important function. A CDP links anonymous cookie profiles with logged-in CRM identities through deterministic rules (same email, same customer ID, same hash) and — where permitted — probabilistic methods (device fingerprinting, behavior patterns). The output is a Unified Profile: one person, multiple identifiers, a consolidated view. This is the single test that distinguishes a real CDP from a re-labeled Marketing Cloud.
Profile persistence. The central difference from a DMP. A CDP stores the profile permanently, independent of sessions, devices, and cookie expiration. When a customer returns 14 months later via a Google ad, the CDP recognizes them (with consent), loads their profile, and enriches it with current behavior. A DMP cannot do this — it builds segments for the current campaign, then the profile is gone.
Real-time activation. A CDP pushes profile attributes and segments to activation systems in sub-seconds: personalization engine, email sender, push service, paid-media audience manager. The clearest use case: cart-abandonment email with individual recommendations, based on the purchase profile of the last 18 months — not just the last three clicks.
Openness for analytics and AI. A modern CDP is not a closed silo but stores its data in a format that data science teams and AI models can consume — ideally directly in your Data Warehouse (Snowflake, BigQuery) or via reverse ETL. The same profile layer feeds churn predictions, CLV models, and personalized recommendations. This is the fourth test: can the CDP talk to your DWH out of the box? If not, you're buying the next decade's silo.
When you need a CDP — and when you don't
Three questions determine whether CDP is relevant for you — and at which maturity stage.
Question 1: Do you have more than two channels where the same customer appears? If you only operate a shop and have no app, no newsletter, no service channel, no offline POS, a good CRM is sufficient. CDP investment pays off from three or more touchpoints, when the identity-resolution lever kicks in.
Question 2: Do you have concrete use cases that need sub-two-second latency? If your campaign cadence is weeks and your personalization means "next campaign", a Data Warehouse plus reverse ETL is enough. CDP investment is justified when you have a customer-journey role that requires millisecond response: on-site product recommendation, cart-abandonment email, churn prevention with inbound call.
Question 3: Can you handle the organizational and process side? A CDP is 30% software, 70% operating model and data governance. Buying a CDP from the marketing budget without IT, data, and legal on board produces an expensive shelfware project in twelve months. This is the most common failure mode I have observed — far more frequent than technical errors.
The 7-phase implementation model
- Goal definition — maximum four use cases per month that the CDP must support. Less is more.
- Data and use-case inventory — six to eight weeks of work, but it saves the rest.
- Vendor selection — RfP with clear criteria across four dimensions: identity strength, activation capability, governance tools, fit-to-stack.
- Identity resolution concept — deterministic primary, probabilistic where GDPR permits and use case justifies. Privacy team at the table from the start.
- Pilot — one use case, one region/brand, 90 days. Milestone is "the use case generates the expected business number", not "the CDP runs".
- Rollout — use case by use case, no big bang. Each wave gets a quality gate.
- Operations and continuous development — a CDP is never finished. One new use case per quarter, one governance audit per half-year, one vendor check per year.
Vendor landscape 2026
In the DACH market, seven vendors are seriously considered in 2026: Tealium, Bloomreach, mParticle, Segment (Twilio), Salesforce Data Cloud, Adobe Real-Time CDP, and Zeotap. Each has a strength area; none leads in all four decision dimensions. The detailed 19-vendor comparison goes deeper, with audio quotes from the podcast.
Where to go from here
The German-language version of this pillar at /wissen/cdp/ contains the full depth (FAQ, vendor matrix, audit checklist). For consulting on CDP selection or implementation: consulting page. For the comparison article CDP vs. CRM vs. DMP: /wissen/cdp/vs-crm-vs-dmp/ (German, English version planned).