Eine CDP einführen ist selten das technische Problem, als das es in Anbieter-Pitches erscheint. Die sieben Phasen, die ich hier durchgehe, sind eine Destillation aus sechs Einführungs-Projekten und ungefähr 20 Beratungs-Engagements — einschließlich der Einführungen bei Douglas und Funke, bei denen ich als Chief Data Officer selbst beteiligt war. Die Phasen sind bewusst in dieser Reihenfolge: wer Phase 2 vor Phase 1 macht, bezahlt das in Monat 14 mit einem Re-Plan.
Warum dieser Leitfaden
Die drei Fehler, die mir in CDP-Projekten am häufigsten begegnen, sind keine technischen.
- Use Cases werden im Nachgang definiert. Das Unternehmen kauft eine CDP, "weil wir sowieso eine brauchen", und überlegt dann, was damit zu tun sei. Das ist fast immer der teurere Weg.
- Die Phase "Daten-Inventar" wird ausgelassen oder verkürzt. Zwei Wochen Sprint statt sechs Wochen gründlich — mit der Folge, dass im Rollout unerwartete Datenquellen auftauchen.
- Kein designierter Product Owner. Ein Steering Committee ist kein Product Owner. Ohne eine Person mit Tagesverantwortung rutscht das Projekt in Stakeholder-Abstimmung ab.
Dieser Leitfaden ist so geschnitten, dass er genau diese drei Fehler abfängt.
Phase 1 — Zieldefinition
Dauer: 3 bis 4 Wochen. Teilnehmer: CMO, CDO/Head of Data, CIO/CTO, Product-Verantwortliche für Kanäle. Output: Eine Liste von maximal vier priorisierten Use Cases, jeder mit Business-Zahl und Messbarkeit.
Der Use Case muss zwei Eigenschaften haben. Erstens: Er schließt an eine Geschäftszahl an, die das Management jeden Monat sieht (Umsatz, Retention, Conversion, Akquise-Kosten). Zweitens: Er hat eine messbare Zielgröße ("Warenkorb-Abbruch-Mail-CTR von 16 auf 24 Prozent in 90 Tagen").
Beispiele für starke Use Cases: Warenkorb-Abbruch mit On-Site und E-Mail-Retargeting; Churn-Prävention mit Real-Time-Trigger und Service-Anruf; cross-channel Reaktivierung inaktiver Segmente. Beispiele für schwache Use Cases: "Wir wollen personalisieren" (zu vage); "Wir wollen alle Daten an einem Ort haben" (kein Geschäftsfall).
Maximal vier Use Cases, weil du mehr nicht parallel pilotieren kannst. Eine häufige Falle: Die Liste startet mit 15 Use Cases, wird dann "nicht priorisiert, weil alle wichtig sind". Du brauchst hier Reibung, nicht Konsens.
Phase 2 — Daten- und Use-Case-Inventar
Dauer: 6 bis 8 Wochen. Teilnehmer: Data Engineering, Marketing-Ops, IT-Architektur, Privacy Officer. Output: Eine Datenquellen-Matrix (Quelle × Use Case × Frequenz × Latenz) plus Identifier-Map.
Das ist die arbeitsintensivste Phase, und die, die am häufigsten abgekürzt wird. Sie muss vier Fragen beantworten:
- Welche Datenquellen speisen welchen Use Case? Pro Use Case eine Tabelle: Quelle, Typ (Event, Master-Daten, Transaktion), Frequenz (Realtime, Stündlich, Täglich), Volumen.
- Welche Identifier stehen pro Quelle zur Verfügung? E-Mail, Kundennummer, Device-ID, Cookie-ID, externe IDs wie Google Click ID. Das bestimmt später, welche Identity-Resolution-Logik möglich ist.
- Welche Consent-Lage gilt pro Datenquelle? Nicht alle Daten dürfen in jeden Use Case fließen. Der Privacy Officer muss pro Kombination freigeben oder blockieren.
- Welche Lücken sind zu füllen? Kritische Datenquellen, die technisch noch nicht ingest-bereit sind. Das können offline POS-Daten sein, alte App-Versionen, oder CRM-Felder, die kein Marketing-Zugriff haben.
Die Ausgabe der Phase 2 ist deine Verhandlungsgrundlage im RfP. Ohne dieses Inventar kaufst du Features, die du nicht nutzt, und übersiehst Anforderungen, die du hättest stellen müssen.
Phase 3 — Anbieterauswahl
Dauer: 8 bis 10 Wochen (inkl. Proof-of-Concept). Teilnehmer: Kern-Einkaufs-Team (CDO, CMO, CIO), plus Rechtsabteilung für DSGVO-Prüfung. Output: Unterzeichneter Vertrag mit einem Anbieter.
Der RfP-Prozess hat vier Schritte.
Schritt 1: Shortlist. Basierend auf den Use Cases und dem Daten-Inventar filterst du auf drei bis vier Anbieter. Der CDP-Anbieter-Vergleich 2026 ist dein Startpunkt. Wichtig: Nicht mehr als vier. Jede ernsthafte Evaluation kostet pro Anbieter 80 Personenstunden — bei fünf oder mehr verlierst du den Fokus.
Schritt 2: RfP-Dokument. Ein Template mit 40 bis 60 Fragen, strukturiert nach den vier Entscheidungsdimensionen (Identity, Aktivierung, Governance, Fit-to-Stack). Jede Frage hat ein Gewicht und eine Bewertungsskala.
Schritt 3: Proof-of-Concept mit echten Daten. Jeder Shortlist-Anbieter bekommt ein abgespecktes Daten-Sample (zehn Prozent deiner Produktion, mit realistischen Identifier-Problemen) und baut eine Identity-Resolution plus einen Use-Case-Prototypen. Dauer: drei bis vier Wochen pro Anbieter, idealerweise parallel.
Schritt 4: Bewertung und Verhandlung. Scoring gegen die RfP-Kriterien, Gesamt-Gewichtung, Vertragsverhandlung mit Fokus auf Volumen-Flexibilität, SLA-Garantien und Exit-Klauseln.
Die Folge #309 mit Daniel H. von Zeotap dreht sich explizit um die Politik dieses Prozesses. Der Kern-Satz: In 60 Prozent der CDP-Auswahl-Projekte scheitert das beste technische Produkt am schwächsten internen Stakeholder-Alignment.
Phase 4 — Identity-Resolution-Konzept
Dauer: 3 bis 4 Wochen, parallel zur Pilot-Vorbereitung. Teilnehmer: Data Engineering, Privacy, Marketing-Ops. Output: Ein dokumentiertes Regelwerk für jede Identifier-Verknüpfung.
Jeder Identifier-Typ (E-Mail-Hash, CRM-ID, Device-ID, Cookie-ID, Kundennummer) braucht eine Regel: Unter welchen Bedingungen wird er mit einem anderen Identifier verbunden, mit welchem Match-Score, für welche Use Cases ist die Verknüpfung gültig?
Beispiel: "Wenn die gehashte E-Mail eines anonymen Cookie-Profils einem CRM-Kontakt entspricht, verknüpfe die beiden Identifier mit Match-Score 1.0 und propagiere das eingeloggte Profil auch auf die anonyme Session — aber nur, wenn der CRM-Kontakt Consent für Marketing-Profilbildung hat."
Das Regelwerk ist der DSGVO-Anker des gesamten Projekts. Wenn Jahre später eine Beschwerde oder ein Audit kommt, ist das das Dokument, das du auf den Tisch legst.
Phase 5 — Pilot
Dauer: 12 Wochen. Scope: Ein Use Case, eine Region oder Marke, klare Abnahmekriterien. Output: Ergebnis-Bericht: hat der Use Case die Business-Zahl getroffen?
Der Pilot ist nicht "die CDP technisch zum Laufen bringen". Der Pilot ist: Beweisen, dass der Use Case die in Phase 1 definierte Zielgröße trifft. Alle anderen Metriken (System-Uptime, Latenz, Datenqualität) sind sekundär.
Drei Abnahmekriterien müssen erfüllt sein:
- Technische Stabilität: Alle eingebauten Datenquellen liefern wie erwartet, Latenz innerhalb SLA, Datenqualität geprüft.
- Profil-Qualität: Identity Resolution produziert realistisch dedupliziert Profile (unter fünf Prozent Dublette).
- Business-Wirkung: Die Zielgröße ist erreicht (oder signifikant, nahe dran mit nachvollziehbarer Lern-Kurve).
Wenn eins davon nicht passt: Stopp, nicht Ausbau. Ein Pilot, der seine Zielgröße nicht trifft, wird im Rollout eher schlechter — nicht besser, weil mit Scale die Komplexität steigt.
Phase 6 — Rollout
Dauer: 6 bis 12 Monate. Scope: Welle für Welle, nicht Big Bang. Output: Reihenweise produktive Use Cases mit eigenem Quality-Gate.
Ich habe mehr CDP-Implementierungen scheitern sehen, weil sie zu schnell aufgespannt wurden, als wegen technischer Schwächen. Der Rollout braucht eine Kadenz:
- Welle 1: Use Case 1 (aus dem Pilot) in Volllast.
- Welle 2: Use Case 2 plus mindestens zwei neue Datenquellen. Quality-Gate: laufen Use Case 1 und 2 parallel ohne Interferenz?
- Welle 3: Use Case 3, neue Region/Marke. Quality-Gate: skaliert die Identity Resolution auf größere Datenmengen?
- Welle 4 und später: ergänzende Use Cases und Daten-Ausbau.
Zwischen den Wellen liegt ein Puffer von mindestens vier Wochen. In dieser Zeit: Betriebs-Stabilisierung, Team-Lernen, Retrospektive.
Phase 7 — Betrieb und Weiterentwicklung
Dauer: laufend. Scope: Product-Owner-Rolle, Quarterly Planning, jährlicher Anbieter-Check. Output: CDP als kontinuierlich weiterentwickelte Plattform.
Eine CDP ist ein Produkt, kein Projekt. Der Betrieb hat vier wiederkehrende Rhythmen:
- Wöchentlich: Monitoring der Data-Quality-Scores und Latenz-Metriken, Incident-Behebung.
- Monatlich: Review der Use-Case-Performance gegen Business-Zahlen, Backlog-Priorisierung.
- Quartalsweise: Neuer Use Case oder substantielle Erweiterung (neue Datenquelle, neue Destination).
- Jährlich: Governance-Audit, Anbieter-Check ("ist unser Vendor noch wettbewerbsfähig?"), Roadmap-Reset.
Wer diese Rhythmen nicht implementiert, hat nach zwei Jahren Legacy — technisch läuft es, aber der Business-Wert stagniert, und der Rest der Organisation wächst an der CDP vorbei.
Häufige Stolpersteine
"Wir fangen mit zwei oder drei Use Cases parallel an, dann sehen wir schneller Wirkung." Nein. Parallelisierung verdoppelt nicht den Output, sondern die Koordinations-Komplexität. Pilot ein Use Case.
"Die IT macht das Daten-Inventar im Alleingang, Marketing beliefert sie nur mit Anforderungen." Führt dazu, dass Anforderungen missverstanden werden. Daten-Inventar braucht Marketing-Ops am Tisch.
"Wir nehmen erst den billigsten Anbieter und wechseln später, wenn es nicht passt." Anbieter-Wechsel nach Produktivsetzung kostet typisch zwölf bis 24 Monate und das Äquivalent der halben Erstimplementierung. Entscheide lieber einmal gut als zweimal mittel.
"Der Pilot ist ein Erfolg, wir rollen aus — das Detail-Monitoring machen wir später." Wer nach Welle 1 kein Monitoring aufgesetzt hat, merkt Daten-Qualitäts-Probleme in Welle 3 erst, wenn bereits vier Use Cases darunter leiden. Monitoring ist nicht Phase 7 — es muss im Pilot mitlaufen.
Und dann?
Wenn du an diesem Punkt den Leitfaden als Grundlage für dein eigenes Projekt brauchst: Die Phasen oben sind die Kurzfassung des Kapitel-6-Frameworks in meinem Springer-Buch — dort findest du die detaillierten Vorlagen (RfP-Fragenkatalog, Daten-Inventar-Template, Identity-Resolution-Regelwerk).
Wenn du den Anbieter-Auswahl-Schritt schon jetzt vertiefen willst, ist der CDP-Anbieter-Vergleich 2026 die nächste Leseempfehlung. Wenn du stattdessen nochmal über die grundlegende CDP-Definition oder die Abgrenzung zum CRM nachdenken willst — auch das sind eigene Cluster-Artikel im selben Pillar.