Customer Data Platform (CDP)

Dieser Leitfaden fasst zusammen, was ich aus zehn Jahren Data-Praxis bei Douglas, FALKE und Funke, aus 317 Podcast-Folgen mit CDOs und Data-Leadern und aus meinem Springer-Buch Customer-Data-Plattformen über Customer Data Platforms gelernt habe. Er ist nicht neutral, er ist nicht vollständig, und er ist nicht für Einsteiger — für die schreibt Wikipedia besser. Er ist für dich, wenn du im Mittelstand vor der Frage stehst: Brauchen wir eine CDP, und wenn ja: wie setzen wir sie auf, ohne in die typischen Fallen zu laufen. Ich gehe dabei so vor, wie ich das Thema auch intern durchdiskutiere — mit klarer Definition, Abgrenzung zu CRM und Data Warehouse, einer ehrlichen Bewertung der Anbieterlandschaft und einem Phasen-Modell, das in vier von fünf Fällen funktioniert.

Was ist eine Customer Data Platform?

Die Kurzdefinition: Eine Customer Data Platform ist ein System, das Kundendaten aus allen deinen Quellen — CRM, Shop, App, Website, Service, Outbound — in ein einziges, persistentes, identitäts-aufgelöstes Profil pro Person zusammenführt und es deinen Marketing-, Service- und Analytics-Tools kanalübergreifend in Echtzeit zur Verfügung stellt. Die CDP-Definition klingt technisch, aber der entscheidende Teil ist das Wort persistent. Eine CDP speichert Profile dauerhaft und greift bei jeder neuen Interaktion darauf zurück — im Gegensatz zu einer DMP, die in Cookie-Sessions denkt, und zu einem Data Warehouse, das Reports baut, aber nicht aktiviert.

Was eine CDP nicht ist, lässt sich schneller sagen. Sie ist kein Data Warehouse — ein DWH ist die Wahrheit für die Finanzabteilung, eine CDP ist die Wahrheit für den Kunden. Sie ist keine Marketing Cloud — eine Marketing Cloud aktiviert, aber resolved keine Identität über 40 Quellen. Sie ist kein Tag Manager — ein Tag Manager feuert Events, speichert aber keine Profile. Und sie ist ausdrücklich kein CRM — der Unterschied zwischen CDP und CRM ist fundamental, und wer ihn verwischt, wird nach sechs Monaten merken, dass er ein zu teures CRM gekauft hat.

Daraus folgt die Arbeits-Definition, die ich in Kapitel 1 meines Buchs verwende: Eine CDP ist dann eine CDP, wenn sie (1) Identitäten deterministisch ODER probabilistisch zusammenführt, (2) Profile persistent hält, (3) Daten in Echtzeit an aktivierende Systeme weitergibt und (4) DSGVO-konform Consent-Bezug herstellt. Fehlt eines der vier Merkmale, hast du wahrscheinlich ein anderes System mit CDP-Label im Marketingprospekt.

Warum CDP jetzt — die drei Treiber

Der erste Treiber ist das Ende der Third-Party-Cookies. Chrome hat das Thema zwar mehrfach verschoben, aber die Richtung ist klar: Firefox und Safari haben Third-Party-Cookies schon abgeschafft, Consent-Banner drücken auf Marketing-Attributionen, und was übrig bleibt, sind First-Party-Daten. Wer die nicht strukturiert verwaltet, verliert in den nächsten zwei Jahren schlicht Reichweite — weil das Retargeting ohne Identitäts-Resolution nicht mehr funktioniert und das Attributions-Modell intransparent wird. Eine CDP ist die technische Antwort auf eine regulatorische Realität, nicht ein "Nice to Have".

Der zweite Treiber ist die neue Identitäts- und Consent-Lage. DSGVO gibt es seit 2018, TDDDG seit 2024, der EU AI Act schließt 2025/26 nach. In Summe verlangt der Regulator, dass du pro Kontaktpunkt weißt, welches Consent für welchen Zweck vorliegt — und zwar technisch nachweisbar. Eine CDP ist nicht primär ein Marketing-Werkzeug, sondern ein Consent-Management-Layer mit Aktivierungsfunktion. Wer das vergisst, kauft sich eine Lösung für das falsche Problem.

Der dritte Treiber ist der Kostendruck auf MarTech-Stacks. In typischen mittelständischen Marketing-Abteilungen existieren heute 30 bis 60 Tools nebeneinander, oft mit überlappendem Funktionsumfang. Eine CDP ist ein Konsolidierungs-Hebel: Sie macht Attributions-Tools, mehrere E-Mail-Tools und diverse Personalisierungs-Engines überflüssig, weil sie die Profil-Schicht zentralisiert. Das spart nicht nur Lizenz-Kosten — es reduziert die Zahl der Schnittstellen, die gepflegt werden müssen, was in der Regel der größere Kostenblock ist.

Die vier Kernfunktionen einer echten CDP

Identity Resolution. Die erste und wichtigste Funktion. Eine CDP verknüpft anonyme Cookie-Profile mit eingeloggten CRM-Identitäten über deterministische Regeln (gleiche E-Mail, gleiche Kundennummer, gleiche Hashes) und — wenn erlaubt — probabilistische Verfahren (Device-Fingerprinting, Verhaltensmuster). Was hinten rauskommt, ist ein Unified Profile: eine Person, mehrere Identifier, eine konsolidierte Sicht. Das ist der eine Punkt, an dem du eine echte CDP von einer umetikettierten Marketing Cloud unterscheidest.

Profil-Persistenz. Der zentrale Unterschied zur DMP. Eine CDP speichert das Profil dauerhaft, unabhängig von Sessions, Geräten und Cookie-Ablauf. Das heißt: Wenn ein Kunde nach 14 Monaten wieder über eine Google-Ad auf deine Website kommt, erkennt die CDP ihn (wenn Consent vorliegt), lädt sein Profil und reichert es mit dem aktuellen Verhalten an. Eine DMP kann das nicht — sie denkt in Segment-Aufbau für die aktuelle Kampagne, danach ist das Profil weg.

Echtzeit-Aktivierung. Eine CDP schiebt Profil-Attribute und Segmente in Sub-Sekunden an aktivierende Systeme: Personalisierungs-Engine, E-Mail-Versender, Push-Service, Paid-Media-Audience-Manager. Der Use-Case, der das am deutlichsten macht: Warenkorb-Abbruch-Mail mit individueller Empfehlung, basierend auf dem Kauf-Profil der letzten 18 Monate — nicht nur auf den letzten drei Clicks. Ohne Echtzeit-Aktivierung hast du ein teures Reporting-Tool.

Öffnung für Analytics und AI. Eine moderne CDP ist kein geschlossener Silo, sondern legt ihre Daten in einem Format ab, das Data-Science-Teams und AI-Modelle konsumieren können — ideal direkt in deinem Data Warehouse (z. B. Snowflake, BigQuery) oder über reverse ETL. Der gleiche Profil-Layer speist dann Churn-Prognosen, CLV-Modelle und personalisierte Recommendations. Das ist der vierte Test: Kann die CDP out of the box mit deinem DWH reden? Wenn nicht, kaufst du dir das Silo der nächsten Dekade.

Wann du eine CDP brauchst — und wann nicht

Drei Fragen entscheiden, ob CDP für dich relevant ist — und in welcher Reifegrad-Stufe.

Frage 1: Hast du mehr als zwei Kanäle, in denen der gleiche Kunde auftaucht? Wenn du nur im Shop arbeitest und keine App, keinen Newsletter, keinen Service-Channel, keine Offline-Kasse hast — dann reicht ein gutes CRM. CDP-Investment rechnet sich ab drei oder mehr Kontaktpunkten, weil erst dann der Identity-Resolution-Hebel anschlägt.

Frage 2: Hast du konkrete Use Cases, die unter zwei Sekunden Latenz brauchen? Wenn deine Kampagnen-Kadenz Wochen ist und deine Personalisierung "nächste Kampagne" heißt, reicht ein Data Warehouse plus Reverse ETL. CDP-Investment ist gerechtfertigt, wenn du eine Rolle in der Customer Journey hast, die Millisekunden-Reaktion braucht: Produkt-Empfehlung on-site, Warenkorb-Abbruch-Mail, Churn-Prävention mit Inbound-Anruf.

Frage 3: Kannst du die Organisations- und Prozess-Seite stemmen? Eine CDP ist zu 30 Prozent Software, zu 70 Prozent Operating Model und Data Governance. Wer die CDP aus dem Marketing-Budget kauft, ohne IT, Data und Legal an Bord zu haben, hat in zwölf Monaten ein teures Shelfware-Projekt. Das ist der häufigste Failure-Mode, den ich beobachtet habe — deutlich häufiger als technische Fehlentscheidungen.

Wenn die Antwort auf alle drei Fragen ein "ja, aber nicht ganz" ist, lohnt sich der Make-or-Buy-Check: vielleicht reichen erweiterte DWH-Fähigkeiten plus Reverse-ETL-Tool, vielleicht brauchst du wirklich die dedizierte CDP. Diese Entscheidung soll nicht ins Blaue fallen.

CDP-Reifegrad-Check (0–4): Reifegrad 0 heißt, die Customer-Daten liegen in drei oder mehr unverbundenen Silos, niemand hat den Überblick. Reifegrad 1 heißt, es gibt ein CRM, das 60 Prozent der Kundendaten sieht, aber Shop- und App-Daten fehlen. Reifegrad 2 heißt, Daten sind technisch integriert, aber nur Marketing hat Zugriff, Service und Produkt arbeiten weiter auf Silos. Reifegrad 3 heißt, der Profil-Layer ist zentral, mindestens drei Kanäle aktivieren daraus. Reifegrad 4 heißt, du hast auch AI-Modelle an den Profil-Layer gedockt und Use Cases wie CLV-Prognose oder dynamische Personalisierung laufen produktiv. CDP-Investment rechnet sich, wenn du von 1 auf 3 willst — davor bist du auf CRM-Ausbau besser bedient, danach brauchst du CDP plus Feature Store.

CDP einführen — die sieben Phasen

Der Einführungs-Leitfaden ist ein eigener Cluster-Artikel; hier die verkürzte Version mit den harten Meilensteinen pro Phase.

Phase 1 — Zieldefinition. Pro Monat maximal vier Use Cases, die die CDP bedienen muss. Weniger ist mehr — wer mit 20 Use Cases startet, priorisiert am Ende keinen. Der Use Case muss messbar sein (z. B. "Warenkorb-Abbruch-Mail-Öffnungsrate auf 38 Prozent") und an Geschäftszahlen anschließen (Umsatz-Plus in Prozent). Ohne diese zwei Eigenschaften kommst du nicht ins Budget.

Phase 2 — Daten- und Use-Case-Inventar. Welche Datenquellen muss die CDP integrieren, in welcher Frequenz, mit welcher Latenz? Ohne diese Liste ist jeder Anbietervergleich eine Bauchentscheidung. Erwarte, dass das Inventar sechs bis acht Wochen dauert — es ist die arbeitsintensivste Phase, aber die, die den Rest rettet.

Phase 3 — Anbieterauswahl. RfP-Prozess mit klaren Bewertungskriterien in vier Dimensionen: Identity-Stärke, Aktivierungs-Fähigkeit, Governance-Tools, Fit-to-Stack. Nutze den CDP-Anbieter-Vergleich 2026 als Startpunkt — 19 Vendoren mit Pricing, Features und Audio-Quotes aus dem Podcast. Wichtig: Die Demo ist nutzlos ohne deine Daten. Lass Anbieter mit einem abgespeckten Daten-Sample eine Identity-Resolution live bauen.

Phase 4 — Identity-Resolution-Konzept. Deterministisch vorrangig, probabilistisch nur dort, wo DSGVO erlaubt und Use Case rechtfertigt. Das Konzept sollte pro Identifier-Typ definieren: Welcher Match-Score reicht für welchen Use Case? Privacy-Team muss hier mit am Tisch sitzen.

Phase 5 — Pilot. Ein Use Case, eine Region/Marke, 90 Tage. Ziele: Technik funktioniert, Profil-Qualität stimmt, Aktivierung liefert. Meilenstein ist nicht "die CDP läuft", sondern "der Use Case generiert die erwartete Business-Zahl". Wenn nicht: Stopp und Diagnose, nicht Ausbau.

Phase 6 — Rollout. Use Case für Use Case, nicht Big Bang. Jede Welle bekommt ein Quality-Gate (Profil-Qualität, Latenz-Messung, CTA-Wirkung). Du schützt dich damit gegen den "alles drin, aber nichts nutzbar"-Zustand, den ich bei Douglas selbst erlebt habe — der Aufräum-Zyklus danach kostet ein Jahr.

Phase 7 — Betrieb und Weiterentwicklung. Die CDP ist nie fertig. Pro Quartal ein neuer Use Case, pro Halbjahr ein Governance-Audit, pro Jahr ein Anbieter-Check ("ist unser CDP-Vendor noch konkurrenzfähig?"). Wer eine CDP nach Rollout stehen lässt, hat sich eine Legacy gekauft, keine Plattform.

Anbieter-Landschaft 2026

Im DACH-Raum sind heute sieben Anbieter ernst zu nehmen: Tealium, Bloomreach, mParticle, Segment (Twilio), Salesforce Data Cloud, Adobe Real-Time CDP und Zeotap. Jede hat ein Stärkefeld, keine ist in allen vier Entscheidungsdimensionen führend. Der detaillierte CDP-Anbieter-Vergleich 2026 geht mit 19 Vendoren tiefer; hier die Strukturprüfung.

Entscheidungsdimension 1 — Identity-Stärke. Wie gut ist das Stitching über Devices, Kanäle und Zeit? Tealium und Zeotap sind hier historisch stark, mParticle in Mobile-lastigen Stacks. Vorsicht bei Salesforce Data Cloud: die Identity-Engine ist jünger und zeigt in großen Datensätzen noch Schwächen.

Entscheidungsdimension 2 — Aktivierungs-Fähigkeit. Wie viele native Destinations (ohne Custom-Build), wie schnell die Latenz? Segment und mParticle führen in Breite, Bloomreach punktet in E-Commerce-Native-Aktivierung. Adobe und Salesforce setzen stark auf Aktivierung in die eigene Cloud-Welt — gut, wenn du dort bist, verdächtig, wenn du offen bleiben willst.

Entscheidungsdimension 3 — Governance und Consent. Welche Consent-Capture- und Propagation-Fähigkeiten hat die Plattform, wie gut sind Audit-Logs, wie tiefgreifend die Data-Residency-Kontrolle? Tealium ist hier stark, weil es aus dem Tag-Management-Ursprung kommt. Salesforce und Adobe haben Enterprise-Grade Governance, aber teure Lizenzmodelle.

Entscheidungsdimension 4 — Fit-to-Stack. Welche deiner Systeme musst du mit Custom-Glue an die CDP anschließen? Das ist selten ein Produkt-Feature-Thema, sondern eine Frage der Connector-Bibliothek. Segment ist breit, Bloomreach tiefer in E-Commerce, Zeotap stark in Telco/Finance/Publisher.

Die Folge #300 mit Julian L. P. von Tealium ist das beste Grundsatzgespräch, das ich zu diesem Thema geführt habe — über die Frage, ob CDP und Data Warehouse sich ersetzen oder ergänzen.

Die Folge mit Daniel H. von Zeotap (#309) bringt den Punkt auf den Nagel, den die meisten unterschätzen: Der Anbieter-Auswahl-Prozess ist zu 60 Prozent technisch, zu 40 Prozent Stakeholder-Alignment. Wer das nicht einkalkuliert, kauft das falsche System aus den falschen Gründen.

Zero-Party-Data — der neue Rohstoff

Zero-Party-Data ist ein Begriff, den Forrester 2018 geprägt hat, und der seitdem missbraucht wird. Die Zero-Party-Data-Strategie ist einfach definiert: Es sind Daten, die ein Kunde dir absichtlich und in Kenntnis des Zwecks gibt — Präferenzen, Intentionen, Produkt-Wünsche. Third-Party-Data sind fremd gekauft, Second-Party-Data kommen aus Partnerschaften, First-Party-Data fallen im Kontakt mit dir an, Zero-Party-Data sind bewusste Abgaben.

Warum das wichtig ist: Third-Party-Data verschwinden, First-Party-Data brauchen Consent und sind oft indirekt (welche Produkte hat er angesehen?). Zero-Party-Data sind direkter und ethisch sauberer — weil der Kunde sie bewusst gegeben hat. Die CDP ist der Ort, an dem Zero-Party-Data gesammelt, mit First-Party-Verhalten verknüpft und in Aktivierung überführt werden. Ohne CDP bleibt Zero-Party-Data ein Preference-Center-Eintrag ohne Wirkung.

Drei Methoden funktionieren in der Praxis. Erstens: Preference-Center auf der Website, das statt 30 Kanäle abzufragen drei Präferenzkanäle auf Produkt-Ebene aufmacht ("Wasch-Tipps", "Neue Kollektionen", "Sale"). Zweitens: Quiz-Funnel, die echte Daten sammeln ("Für welche Haut-Konstellation suchst du eine Pflege?"). Drittens: Progressive Profiling, bei dem du in jeder Session eine Mikro-Frage stellst, statt beim Onboarding 25 auf einmal. Bei FALKE haben wir über Progressive Profiling in 18 Monaten die Relevanz-Score unserer Newsletter-Segmente signifikant gesteigert — Newsletter-Öffnungsraten sind eine schwache Proxy, aber sie zogen mit.

CDP im B2B vs. B2C

Die drei strukturellen Unterschiede, die oft übersehen werden.

Unterschied 1 — Account-Graph statt Person-Graph. Im B2C ist die Identität eine Person. Im B2B ist die Identität ein Konto (Unternehmen), innerhalb dessen mehrere Personen interagieren, deren individuelle Datenpunkte zu einem Konto-Level-Profil aggregiert werden müssen. Viele B2C-CDPs können das nicht sauber — und viele B2B-Verantwortliche merken das erst im Implementierungs-Sprint.

Unterschied 2 — Kaufprozess-Länge. B2B-Sales-Cycles sind drei bis 18 Monate lang. Die CDP muss Profile über lange Zeiträume stabil halten, mehrere Sales-Touchpoints attribuieren (SDR, AE, CS) und nicht von Marketing-Cookies allein abhängen. CRM-Integration ist hier kein Add-on, sondern Kern.

Unterschied 3 — Consent-Hebel. Im B2B greifen teilweise andere Rechtsgrundlagen (berechtigtes Interesse), gleichzeitig ist die Consent-Bereitschaft von Decision-Makern niedriger. Das verschiebt das Mix-Verhältnis zwischen First-Party-Tracking und Marketing-Ops-Daten.

Ein B2B-Unternehmen braucht eine CDP ab etwa zehn Account-Executives und dem Moment, in dem mehr als zwei Kanäle konsistent auf die gleichen Konten wirken — davor ist HubSpot oder ein gut konfiguriertes Salesforce noch die sinnvollere Investition.

Operating Model — wer pflegt die CDP?

Die CDP ist ein Produkt, kein Projekt. Wer sie wie ein Projekt behandelt, hat nach Go-Live die klassische Lücke: Der Integrator ist weg, die CDP läuft, niemand weiß, wer welchen Use Case betreibt. Ein funktionierendes Operating Model hat drei Rollen.

CDP Product Owner. Verantwortlich für Roadmap, Use-Case-Priorisierung, Anbieter-Beziehung. Sitzt idealerweise im Marketing oder in einer Daten-Produkt-Einheit, nicht in der IT.

Audience Architect. Baut und pflegt Segment-Logik, kümmert sich um Identity-Regeln, arbeitet eng mit Daten-Engineering. Das ist die operative Arbeitspferd-Rolle.

Data Engineer für CDP. Baut und betreibt Integrationen, Ingest-Pipelines, Monitoring, Reverse-ETL-Flows. Oft geteilt mit dem Data-Platform-Team.

Zentral vs. dezentral — die häufigere Frage: In Konzernen mit Markenportfolio (wie Funke) empfiehlt sich ein zentrales CDP-Team mit Service-Modell gegenüber den Marken. In homogenen Mittelständlern genügt eine Personalunion aus Product Owner und Audience Architect plus anteiliger Daten-Engineering-Kapazität.

Häufig gestellte Fragen

Ist eine CDP nicht nur ein teures CRM? Nein. Ein CRM kennt Kunden, die in einem Sales-Prozess stehen — oft in einer einzigen Datenquelle. Eine CDP kennt alle Personen, die dir in irgendeiner Form begegnet sind, über alle Kanäle und Systeme hinweg, in einem persistenten Profil. Der Unterschied zwischen CDP und CRM liegt in Breite (CDP mehr Kanäle), Granularität (CDP sub-sekundig, CRM tagesaktuell) und Zweck (CDP aktiviert, CRM verwaltet). Die beiden ersetzen sich nicht, sie ergänzen sich.

Wie lange dauert eine CDP-Einführung realistisch? Für einen mittelständischen B2C-Player mit drei Kanälen und ordentlicher Datenbasis: acht bis zwölf Monate bis zum ersten produktiven Use Case, weitere 12 Monate bis zum Reifegrad 3. Wer dir sechs Monate verspricht, hat nicht eingerechnet, dass Phase 2 (Daten-Inventar) allein sechs Wochen dauert.

Brauche ich eine CDP auch ohne E-Commerce? Möglicherweise ja, wenn du Service-, App- und Marketing-Daten in Echtzeit zusammenbringen willst. Beispielsweise bei Versicherern wie CSS (Podcast-Folge #209) oder Medien-Unternehmen. Das einzige K.o.-Kriterium ist die Kanal-Anzahl, nicht die Branche.

CDP vs. Data Warehouse vs. CRM — was, wenn ich alles habe? Glückwunsch, du hast die häufigste mittelständische Situation. Die CDP sitzt zwischen CRM (Sales/Service-Verwaltung) und DWH (analytisches Reporting) — sie zieht Profil-Daten aus beiden, aktiviert sie und gibt aggregierte Segment-Signale zurück. Das ergibt einen Drei-Schichten-Stack, nicht drei konkurrierende Systeme.

Kann ich eine CDP auch selbst bauen? Technisch ja, auf Basis von Snowflake oder BigQuery plus Reverse ETL (z. B. Hightouch, Census). Das ist der "Composable CDP"-Ansatz. Die Rechnung lohnt sich ab einer bestimmten Team-Größe (eigene Daten-Engineering-Kompetenz) und Use-Case-Komplexität. Für die meisten Mittelständler ist der Build-Ansatz nicht günstiger, sondern nur verteilter auf interne Kosten. Mehr zum Make-or-Buy-Check.

Was kostet eine CDP im Mittelstand? Lizenz-seitig zwischen 60.000 und 250.000 Euro pro Jahr, je nach Profilvolumen und Anbieter. Implementierung einmalig 150.000 bis 600.000 Euro. Laufender Betrieb 1,5 bis 3 FTE (Product Owner, Audience Architect, anteilig Data Engineer). Wer dir ein Festpreis-Paket unter 100.000 Euro pro Jahr all-in verspricht, verkauft dir entweder eine sehr kleine CDP oder ein Produkt, das später nicht skaliert.

Wenn du an diesem Punkt bist und überlegst, wie die CDP-Frage für dein Unternehmen konkret aussieht: lies die CDP-Definition, dann den CRM-Vergleich, und wenn du dann noch Blut leckst, den CDP-Anbieter-Vergleich 2026 und den Einführungs-Leitfaden. Das ist bewusst eine lange Leseleiter — CDP-Entscheidungen, die in unter zehn Lesestunden fallen, sind meistens die teuren.