Sie sitzen vermutlich genau in der typischen Lage, in der das Thema Customer Data Platform plötzlich dringend wird. Das CRM kennt Leads und Accounts. Das Shopsystem kennt Bestellungen. Google Ads, Meta, Newsletter-Tool und Webtracking laufen separat. Gleichzeitig fragt das Datenschutzteam zu Recht, wo Einwilligungen gespeichert sind, wer worauf zugreift und wie Löschanfragen sauber durch alle Systeme gehen sollen.
In mittelständischen Projekten ist das selten ein reines Marketingproblem. Es ist ein Architekturproblem mit direkten Folgen für Kampagnen, Datenqualität, Betriebskosten und DSGVO-Compliance. Genau deshalb wird die Frage nach einer Customer Data Platform oft falsch gestellt. Nicht: „Welche CDP ist die beste?“ Sondern: Brauchen wir überhaupt eine CDP, und wenn ja, in welcher Form?
Wer diese Entscheidung sauber trifft, spart sich teure Umwege. Wer sie aus einem Tool-Pitch heraus trifft, baut oft nur ein weiteres Silo mit schöner Oberfläche.
Inhaltsverzeichnis
- Was eine Customer Data Platform wirklich leistet
- Kernfunktionen und die Wahl der richtigen Architektur
- Der Business Case – Messbarer Nutzen für Marketing und IT
- DSGVO-Konformität und Datenhoheit mit einer CDP sicherstellen
- Ihre Roadmap zur erfolgreichen CDP-Implementierung
Was eine Customer Data Platform wirklich leistet
Eine gute Customer Data Platform ist im Marketingstack das, was ein zentrales Nervensystem im Körper ist. Sie ersetzt nicht jedes Organ. Aber sie verbindet Signale, ordnet sie richtig zu und sorgt dafür, dass an der richtigen Stelle überhaupt eine sinnvolle Reaktion möglich wird.
Das Grundproblem ist nicht zu wenig Daten, sondern zu viele Inseln
Die meisten Unternehmen haben heute kein Datendefizit. Sie haben ein Verbindungsdefizit. Webtracking läuft im einen Tool, Bestellhistorie im ERP oder Shop, Leads im CRM, Newsletter-Reaktionen im E-Mail-System, Servicefälle im Ticketsystem. Jeder Bereich sieht einen Ausschnitt. Niemand sieht den Kunden als Ganzes.
Genau hier setzt die CDP an. Die Kategorie wurde 2016 von David Raab formal definiert als „packaged software that creates a persistent, unified customer database that is accessible to other systems“. Diese Definition zitiert SAS in der Einordnung zur Customer Data Platform. Entscheidend ist daran nicht der Begriff „Database“, sondern die Kombination aus persistent, unified und accessible to other systems.
Viele Tools speichern Kundendaten. Eine CDP wird erst dann relevant, wenn sie daraus ein belastbares, dauerhaft nutzbares Kundenprofil macht, das andere Systeme aktiv verwenden können.
Eine CDP lohnt sich nicht, weil sie Daten sammelt. Sie lohnt sich, wenn dieselben Daten endlich für Segmentierung, Aussteuerung und Governance konsistent nutzbar werden.
Die vier Aufgaben, die eine CDP von anderen Systemen unterscheiden
Im Alltag lässt sich eine Customer Data Platform auf vier Kernaufgaben herunterbrechen:
- Daten aufnehmen. Ereignisse, Profile und Transaktionen aus Website, App, CRM, Shop, Service oder Offline-Quellen laufen an einer Stelle zusammen.
- Identitäten zusammenführen. Aus verschiedenen IDs entsteht ein einheitliches Kundenprofil statt mehrerer konkurrierender Datensätze.
- Zielgruppen bilden. Marketing und CRM-Teams können Segmente nach Verhalten, Status, Kaufhistorie oder Einwilligung definieren.
- Daten aktivieren. Diese Segmente oder Profile gehen an E-Mail-Tools, Werbeplattformen, Personalisierungssysteme oder interne Anwendungen zurück.
Das klingt simpel. In der Praxis scheitern Projekte meist daran, dass eines dieser vier Elemente fehlt. Wenn Daten zwar gesammelt, aber nicht sauber vereinheitlicht werden, entstehen Dubletten. Wenn Segmentierung möglich ist, aber keine stabile Aktivierung in die Zielsysteme existiert, bleibt die CDP ein hübsches Dashboard ohne operative Wirkung.
Ein pragmatisches Beispiel aus dem Mittelstand: Ein B2C-Händler will Kundinnen, die bereits gekauft haben, aus einer laufenden Prospecting-Kampagne ausschliessen und stattdessen in eine Bestandskundenstrecke überführen. Ohne CDP liegt der Kauf im Shop, die Kampagne in Meta, das Profil im CRM und die Einwilligung in einem separaten Consent-Setup. Mit CDP kann diese Kette zusammenlaufen. Ohne sie arbeitet jedes System mit einer eigenen Wahrheit.
CDP, CRM, DWH – Das richtige System für Ihren Zweck
Die teuersten CDP-Projekte beginnen mit dem Satz: „Wir brauchen noch ein zentrales Tool.“ Das ist meistens zu unpräzise. Oft braucht ein Unternehmen gar keine CDP, sondern ein sauber aufgesetztes Data Warehouse, ein besser integriertes CRM oder erst einmal ein tragfähiges Tracking-Konzept.
Wofür jedes System gebaut wurde
Ein CRM organisiert in erster Linie Beziehungen, Aktivitäten und Vertriebslogik. Sales sieht Kontakte, Pipelines, Ansprechpartner, Aufgaben und Historie. Für B2B ist das unverzichtbar. Aber ein CRM ist nicht dafür gebaut, grosse Mengen an Eventdaten aus Web und App fortlaufend zu verarbeiten und daraus in Echtzeit Marketingsegmente zu bilden.
Ein Data Warehouse ist die richtige Schicht für konsolidierte Analyse, Reporting, Modellierung und historisierte Datenhaltung. Dort gehören Daten hin, die langfristig ausgewertet, mit Geschäftslogik angereichert oder für BI verwendet werden. Ein Warehouse ist meist die beste Antwort auf Fragen wie: Welche Produktgruppen entwickeln sich in welchen Regionen? Wie verändert sich Wiederkaufsverhalten über Zeit?
Eine Customer Data Platform sitzt näher an der operativen Aktivierung. Sie ist dann sinnvoll, wenn aus vereinheitlichten Kundendaten konkrete Massnahmen entstehen sollen. Also Zielgruppen für Kampagnen, personalisierte Inhalte, Trigger, Ausschlüsse oder kanalübergreifende Journey-Steuerung.
Der blinde Fleck in vielen Diskussionen ist deshalb nicht die Funktionsliste der CDP, sondern die Architekturfrage: Welche Daten müssen wirklich in eine Aktivierungsplattform, welche bleiben im Warehouse, und welche Prozesse gehören weiterhin ins CRM? Genau diese Abgrenzung hebt Verndale in der Einordnung zu CDP, Warehouse und Privacy-Governance als kritischen Punkt hervor.
Ein Praxisfall mit Warenkorbabbruch
Nehmen wir einen simplen, aber realen Fall. Eine Nutzerin besucht den Shop, sieht sich ein Produkt an, legt es in den Warenkorb und bricht ab.
Im CRM passiert zunächst oft gar nichts. Es sei denn, die Person ist bekannt, eingeloggt und der Prozess wurde bewusst modelliert.
Im Data Warehouse landet das Ereignis im besten Fall später für Analysezwecke. Das hilft dem BI-Team, Abbruchmuster zu erkennen. Es löst aber noch keine unmittelbare Reaktion aus.
In der CDP wird derselbe Ablauf dann spannend, wenn die Person identifiziert oder probabilistisch an ein bestehendes Profil gebunden werden kann, die Einwilligung für den Kanal vorliegt und eine Aktivierungsstrecke existiert. Dann kann das System den Warenkorbabbruch als Trigger für E-Mail, Onsite-Personalisierung oder Zielgruppenausschluss verwenden.
Praktische Regel: Wenn Sie primär analysieren wollen, starten Sie beim Warehouse. Wenn Sie Beziehungen und Vertriebsarbeit organisieren wollen, starten Sie beim CRM. Wenn Sie Verhalten über Kanäle hinweg in Aktionen übersetzen wollen, prüfen Sie die CDP.
Vergleich der Systeme im Alltag
| System | Primärer Zweck | Typische Stärke | Schwäche ohne Ergänzung |
|---|---|---|---|
| CRM | Kontakt- und Beziehungsmanagement | Vertriebsprozesse, Account-Sicht, manuelle Pflege | Schwach bei Eventdaten und kanalübergreifender Echtzeit-Aktivierung |
| DWH | Zentrale Analyse- und Modellierungsschicht | Historie, BI, Governance, flexible Auswertung | Nicht automatisch für Marketingaktivierung gebaut |
| CDP | Vereinheitlichung und Aktivierung von Kundendaten | Segmente, Trigger, kanalübergreifende Nutzung | Ohne sauberes Datenmodell und Governance schnell chaotisch |
Ein DMP spielt in vielen mittelständischen Setups heute eine deutlich kleinere Rolle als früher. Wenn das operative Problem auf First-Party-Daten, Identitätsauflösung und Aktivierung basiert, ist die eigentliche Entscheidung fast immer CRM plus DWH, DWH plus CDP oder ein gestuftes Modell daraus.
Kernfunktionen und die Wahl der richtigen Architektur
Montagmorgen, 9:15 Uhr. Marketing will eine Warenkorbabbruch-Strecke live schalten, der Vertrieb möchte Bestandskunden aus einer Kampagne ausschließen, und die IT fragt zuerst nach Einwilligung, Datenherkunft und Zielsystemen. Genau in diesem Moment zeigt sich, ob eine CDP nur gut präsentiert wurde oder im Betrieb trägt.
Zur Einordnung der Funktionsschichten hilft diese Übersicht:
Was technisch in einer CDP passieren muss
Eine CDP funktioniert nur dann zuverlässig, wenn vier Schichten fachlich und technisch sauber aufeinander abgestimmt sind. In Mittelstandsprojekten scheitert das selten an fehlenden Features. Meist scheitert es an unklaren Events, widersprüchlichen IDs und einem Aktivierungssetup, das mehr verspricht als die Datenbasis hergibt.
-
Ingestion
Daten kommen aus Webtracking, Apps, CRM, ERP, Shop, Service und oft auch aus CSV-Importen oder Batch-Prozessen. Entscheidend ist dabei nicht nur die Anbindung, sondern ein einheitliches Ereignismodell. Wenn „Purchase“, „Order Completed“ und „Checkout Success“ denselben Geschäftsvorfall beschreiben, aber unterschiedlich übertragen werden, entstehen Inkonsistenzen sehr früh. -
Unification
In dieser Schicht werden Attribute und Referenzen harmonisiert. Kundennummer, E-Mail, Hash, Device-ID, Login-ID, Bestell-ID und Statuswerte müssen in ein gemeinsames Modell übersetzt werden. Sonst entsteht kein belastbares Kundenprofil, sondern lediglich besser sortierte Fragmentierung. -
Segmentation
Zielgruppen werden erst dann verlässlich, wenn Profile, Zustände und Zeitbezüge stimmen. Dann lassen sich Wiederkäufer, inaktive Bestandskunden, B2B-Kontakte mit konkretem Produktinteresse oder servicekritische Kundengruppen sauber definieren, ohne in jedem Tool andere Regeln zu pflegen. -
Activation
Segmente oder Einzelprofile werden an operative Systeme zurückgegeben. Typisch sind HubSpot, Salesforce, Klaviyo, Meta Ads, Google Ads, Braze, Bloomreach oder interne Personalisierungslogiken im Shop. Hier zeigt sich schnell, ob die CDP nur Daten sammelt oder tatsächlich in Prozesse eingreift.
Wer mag, kann sich dazu auch diese technische Einordnung ansehen:
Warum Identity Resolution über Erfolg oder Frust entscheidet
Identity Resolution ist die zentrale Funktion einer CDP. RudderStack beschreibt die technische Rolle von Identity Resolution in CDPs anhand der Zusammenführung von Web-, App-, CRM- und Transaktionsdaten über persistente Identifikatoren zu einem Single Customer View. Für den Betrieb bedeutet das vor allem eines: dieselbe Person wird nicht parallel als Newsletter-Profil, CRM-Kontakt, Käuferkonto und anonymer Besucher behandelt.
In realen Projekten ist das oft der Kipppunkt zwischen brauchbarer Aktivierung und dauerhaftem Datenstreit. Sobald Identitätsauflösung und Datenharmonisierung getrennt voneinander laufen, sinkt die Qualität beim Audience-Matching, bei Triggern und bei Ausschlüssen. Marketing sieht dann hohe Reichweite. Der Vertrieb erkennt Dubletten. Datenschutz bekommt Rückfragen zur Herkunft einzelner Merkmale.
Ein typisches Beispiel aus dem E-Commerce: Ein Nutzer klickt mobil auf eine Kampagne, sieht sich mehrere Produktseiten an, meldet sich später am Desktop zum Newsletter an und kauft danach mit Gutschein. Wenn diese Signale nicht in einer zusammenhängenden Pipeline verarbeitet werden, entsteht keine verlässliche Journey. Es entstehen mehrere Teilprofile mit widersprüchlichem Status.
Für Teams, die tiefer in Eventmodelle einsteigen, ist sauberes Engagement Tracking im Marketing und Produktkontext oft die Vorarbeit, ohne die auch eine gute CDP stumpf bleibt.
Schlechte CDP-Projekte scheitern selten an fehlenden Features. Sie scheitern an schlechten Identitäten, unscharfen Events und Zielsystemen, die niemand sauber gemappt hat.
Traditionell oder Composable
Für den deutschen Mittelstand ist die Architekturentscheidung meist wichtiger als die Demo des Tools.
Bei einer traditionellen CDP liegen Ingestion, Speicherung, Identity Resolution und Aktivierung häufig in einer proprietären Plattform. Das reduziert Einführungsaufwand und beschleunigt erste Use Cases. Der Preis dafür ist oft geringere Flexibilität bei Datenmodell, Governance und Integrationen. Sobald ERP-Logik, B2B-Vertriebsprozesse oder mehrere Länderorganisationen dazukommen, werden diese Grenzen spürbar.
Bei einer Composable CDP bleiben Datenhaltung und Teile der Verarbeitung stärker in bestehenden Warehouse- oder Cloud-Strukturen verankert. Die Aktivierungsschicht wird modular darauf gesetzt. Das passt gut zu Unternehmen, die bereits ein stabiles ETL-Setup, klare Ownership und belastbare Datenmodelle haben. Es passt schlecht zu Teams, die operative Kampagnen schnell starten wollen, aber weder Tracking noch Consent-Logik sauber im Griff haben.
Drei Fragen entscheiden in der Praxis schneller als jede Herstellerfolie:
-
Ist das Datenmodell bereits geführt oder nur historisch gewachsen?
Wenn Begriffe, Events und Statuswerte zwischen Shop, CRM und ERP nicht konsistent sind, wird Composable unnötig schwer. -
Wo muss Datenhoheit tatsächlich liegen?
Unter DSGVO-Vorgaben ist oft relevant, welche Daten in welcher Schicht gespeichert, angereichert und exportiert werden. Wer das nicht beantworten kann, sollte keine verteilte Architektur aufbauen. -
Wer betreibt die Logik dauerhaft?
Eine modulare Architektur senkt den Vendor-Lock-in nur dann, wenn intern auch jemand Mapping, Monitoring und Änderungen verantwortet.
Ich rate Mittelständlern selten pauschal zu einer Seite. Ein traditioneller Ansatz ist oft sinnvoll, wenn Marketing schnell arbeitsfähig werden muss und die IT wenig Kapazität für Eigenbau oder Orchestrierung hat. Composable ist meist die bessere Wahl, wenn Datenhoheit, Integrationsfähigkeit und technische Steuerbarkeit wichtiger sind als eine zentrale All-in-one-Oberfläche.
In der Praxis sind viele Mittelständler noch nicht bereit für Composable, obwohl die Argumente dafür auf dem Papier gut klingen. Wenn Ereignisdefinitionen fehlen, Ownership unklar ist und niemand das Datenmodell verantwortet, schafft Modularität keine Freiheit, sondern zusätzliche Reibung. Genau deshalb ist die eigentliche Vorfrage nicht: Welche CDP ist die beste? Sie lautet: Brauchen Sie überhaupt eine CDP, oder zuerst Ordnung in Tracking, Identitäten und Governance?
Der Business Case – Messbarer Nutzen für Marketing und IT
Der Business Case einer Customer Data Platform zeigt sich meist an einem unspektakulären Montagmorgen. Das Marketing fragt, warum Käufer weiterhin Retargeting sehen. Der Vertrieb arbeitet mit einem anderen Kundenstatus als das CRM. Die IT bekommt ein Ticket, weil Consent-Informationen im E-Mail-Tool anders aussehen als im Shop. Wenn solche Reibungen zum Normalzustand gehören, kann eine CDP wirtschaftlich sinnvoll sein. Wenn sie im Unternehmen kaum auftreten, wird aus der CDP schnell ein teures Infrastrukturprojekt ohne klaren Ertrag.
Genau an diesem Punkt trennt sich für den Mittelstand sinnvolle Investition von Tool-Euphorie. Der Nutzen entsteht nicht durch ein neues System allein, sondern durch weniger manuelle Datenarbeit, weniger Fehlsteuerung im Marketing und klarere Verantwortlichkeiten zwischen Fachbereichen und IT.
Was das Marketing tatsächlich davon hat
Marketing profitiert dort zuerst, wo Budget durch unklare Zielgruppen und verspätete Daten verloren geht. Typische Fälle sehe ich in fast jedem zweiten Projekt. Bestandskunden landen weiter in Prospecting-Kampagnen. Inaktive Kontakte bleiben in Standard-Strecken. Reklamationsfälle erhalten parallel Upsell-Mails, weil Servicestatus und Kampagnenlogik nie sauber zusammengeführt wurden.
Eine CDP reduziert diese Widersprüche, wenn Identitäten, Statuswerte und Aussteuerung konsistent modelliert sind. Das verbessert nicht automatisch jede Kampagne. Es verhindert aber viele der Fehler, die im Tagesgeschäft teuer und peinlich zugleich sind.
Drei Effekte sind in der Praxis besonders greifbar:
- Weniger Media Waste, weil Käufer, Retourenfälle oder gesperrte Kontakte sauber ausgeschlossen werden.
- Schnellere Segmentierung, weil Zielgruppen nicht bei jeder Kampagne neu aus Shop, CRM und E-Mail-Tool zusammengesucht werden müssen.
- Bessere Trigger-Logik, weil Verhalten, Transaktionen und Kontaktstatus in derselben Entscheidungslogik zusammenkommen.
Der eigentliche Hebel ist oft nicht Personalisierung, sondern Fehlervermeidung. Das ist weniger glamourös, aber meist der belastbarere Business Case.
Warum IT-Teams oft stärker profitieren als erwartet
In vielen Unternehmen bringt das Marketing das Thema CDP auf die Agenda. Den grössten strukturellen Nutzen hat später oft die IT. Der Grund ist einfach. Ohne CDP oder saubere Alternativarchitektur bauen Teams dieselben Exporte, Mappings und Felddefinitionen mehrfach nach. Das kostet Zeit, erhöht die Fehlerquote und macht Änderungen langsam.
Eine gut aufgesetzte CDP zwingt zu Entscheidungen, die ohnehin fällig sind. Wer liefert Rohdaten? Welches System führt welchen Status? Wer verantwortet Consent-Signale? Welche Felder sind verbindlich und welche nur abgeleitet? Diese Fragen schaffen mehr Wert als manche Personalisierungsfunktion im Demo-Call.
Auch die Architekturentscheidung hat direkten Einfluss auf den Business Case. Traditionelle CDPs bringen Marketing meist schneller in die operative Nutzung. Das ist ein Vorteil, wenn Ressourcen in der IT knapp sind und Kampagnen kurzfristig besser laufen sollen. Composable-Ansätze rechnen sich eher dort, wo bereits ein belastbares Datenfundament existiert, interne Teams Integrationen beherrschen und Datenhoheit nicht an eine geschlossene Plattform abgegeben werden soll.
Ich sehe in mittelständischen Projekten regelmässig denselben Zielkonflikt. Die Fachseite will schnell aktivieren. Die IT will kein weiteres System, das Daten kopiert, Logik versteckt und später teuer angepasst werden muss. Genau deshalb ist der Business Case nie nur eine Marketingrechnung. Er ist immer auch eine Betriebsentscheidung.
Wer Marketing und Vertrieb auf derselben Datengrundlage ausrichten will, muss ausserdem Prozesse jenseits der CDP sauber definieren. Für diese operative Abstimmung ist der Beitrag zu Sales- und Marketing-Alignment in der GTM-Strategie relevant, weil viele vermeintliche Datenprobleme in Wahrheit aus unklaren Übergaben zwischen Teams entstehen.
Ein realistisches Projektszenario aus dem Mittelstand
Ein mittelständischer Onlinehändler arbeitet mit Shopify, CRM, E-Mail-Tool und mehreren Ad-Plattformen. Bestellungen aus dem Shop sind sauber erfasst, aber Zielgruppen werden noch per Exportlisten gebaut und nur einmal täglich aktualisiert. Im Retargeting erscheinen Käufer weiter als Nicht-Käufer. Im CRM fehlen Verhaltensdaten aus dem Shop. Bei Auskunfts- oder Löschanfragen beginnt eine manuelle Suche über mehrere Systeme.
In so einer Lage ist der erste sinnvolle CDP-Use-Case selten Hyperpersonalisierung. Meist geht es zuerst um Käuferstatus, Consent-Status und eine einheitliche Sicht, die Ads, E-Mail und CRM gleich verwenden können.
Wenn der erste Use Case einen täglichen operativen Schmerz beseitigt, bekommt das Projekt Rückhalt. Wenn der erste Use Case nur in der Präsentation gut aussieht, scheitert die Priorisierung oft schon nach den ersten Integrationsaufwänden.
Der messbare Nutzen zeigt sich dann sehr konkret. Weniger manuelle Exporte. Weniger widersprüchliche Zielgruppen. Weniger Rückfragen, welches System gerade recht hat. Für Datenschutzverantwortliche werden ausserdem saubere Prozesse wichtiger als Einzelfallrecherchen. Wer dazu eine externe Orientierung braucht, findet ergänzende Informationen zum Datenschutz.
Wann sich die Investition trägt und wann nicht
Eine CDP trägt sich im Mittelstand meist dann, wenn mindestens drei Bedingungen erfüllt sind: Es gibt mehrere aktive Kanäle mit spürbaren Datenbrüchen, das Volumen an Kampagnen oder Zielgruppen rechtfertigt Automatisierung, und das Unternehmen ist bereit, Datenmodell und Verantwortlichkeiten verbindlich festzulegen.
Fehlt einer dieser Punkte, sollte man nüchtern bleiben. Wer nur einen Newsletter, ein CRM und wenige manuelle Segmente betreibt, braucht oft keine CDP. Wer Tracking, Consent und Identitäten noch nicht im Griff hat, sollte zuerst diese Grundlagen bereinigen. Und wer Composable wählt, ohne internes Ownership für Modellierung und Betrieb zu klären, verschiebt das Problem nur in eine technisch anspruchsvollere Form.
Der beste Business Case lautet deshalb nicht: Wir brauchen eine CDP, weil alle darüber sprechen. Er lautet: Wir verlieren heute Geld, Zeit und Steuerbarkeit an klar benennbaren Stellen, und eine passende CDP-Architektur behebt genau diese Probleme mit vertretbarem Betriebsaufwand.
DSGVO-Konformität und Datenhoheit mit einer CDP sicherstellen
Im deutschen Mittelstand kippt die Stimmung beim Thema Customer Data Platform oft an genau einem Punkt. Sobald klar wird, dass noch mehr Kundendaten zentralisiert werden, lautet der Reflex: Das macht Datenschutz doch nur komplizierter. In gut aufgesetzten Architekturen ist oft das Gegenteil der Fall.
Eine CDP ist kein Datenschutzrisiko per se
Die DSGVO gilt seit dem 25. Mai 2018. Sie hat den Bedarf an sauberer Einwilligungs-, Profil- und Datenzugriffslogik deutlich erhöht. Genau deshalb sind CDPs attraktiv geworden. Gleichzeitig verweist eine Branchenübersicht auf ein globales CDP-Marktvolumen von 7,8 Milliarden US-Dollar für 2024 und eine Projektion auf 63,71 Milliarden US-Dollar bis 2031, was die strategische Relevanz unterstreicht, gerade auch für mittelständische Unternehmen. Diese Einordnung findet sich bei VWO in den CDP-Statistiken und Marktprognosen.
Wichtig ist aber die operative Perspektive. Eine CDP verbessert Datenschutz nicht automatisch. Sie verbessert ihn dann, wenn sie Datenquellen zentral bündelt, Zugriff steuerbar macht und Consent nicht nur speichert, sondern durch Prozesse hindurch wirksam werden lässt.
Eine schlecht konfigurierte CDP ist ein Compliance-Risiko. Eine sauber modellierte CDP ist ein Governance-Werkzeug.
Consent, Auskunft und Löschung müssen technisch mitgedacht werden
In der Praxis gibt es drei DSGVO-Fallstricke, die fast jedes Projekt betreffen:
- Consent ist nur als Feld vorhanden
Viele Teams speichern den Einwilligungsstatus irgendwo, aber die Aktivierungssysteme berücksichtigen ihn nicht konsequent. Dann ist Consent dokumentiert, aber nicht durchgesetzt. - Löschung endet an Systemgrenzen
Wenn Website, CRM, E-Mail, Data Warehouse und Ads-Konnektoren nicht an derselben Identität hängen, wird das Recht auf Löschung zur händischen Detektivarbeit. - Auskunft ist theoretisch möglich, praktisch aber zäh
Daten liegen zwar vor, aber nicht in einer Form, die schnell zusammengeführt und erklärt werden kann.
Eine gute CDP kann hier helfen, weil sie Identitäten und Datenflüsse an einem Punkt sichtbar macht. Löschanforderungen, Berichtigungen und Datenzugriffe lassen sich wesentlich strukturierter umsetzen, wenn nicht jedes System eine eigene Personendefinition führt.
Für Teams, die Vertriebs- und Marketingtools unter DSGVO-Gesichtspunkten bewerten, ist dieser Überblick zu DSGVO-Anforderungen bei Sales-Tools eine sinnvolle Ergänzung, weil viele CDP-Diskussionen an denselben Rechts- und Prozessfragen hängen.
Datenschutz scheitert selten am Prinzip. Er scheitert an ungeklärten Datenflüssen, fehlenden Zuständigkeiten und Systemen, die Consent nicht bis zur Aktivierung durchreichen.
EU-Only-Infrastruktur ist oft keine Kür, sondern Vorgabe
Gerade in Deutschland ist Datenhoheit nicht nur ein juristisches Thema, sondern ein Beschaffungs- und Governance-Thema. Viele Unternehmen, öffentliche Träger und regulierte Branchen wollen oder müssen wissen, wo Daten liegen, wer darauf zugreift und welche Subprozessoren im Spiel sind.
Darum ist die Frage nach EU-only Hosting, regionaler Verarbeitung und technischer Kontrolle bei CDP-Architekturen mehr als ein Detail. Bei traditionellen Plattformen hängt die Antwort stark vom Anbieter ab. Bei Composable-Ansätzen lässt sich das oft granularer gestalten, weil Speicher- und Verarbeitungsorte stärker in der eigenen Infrastruktur oder in bewusst gewählten EU-Umgebungen liegen.
Wer intern Aufklärungsarbeit leisten muss, braucht oft gut verständliche Materialien statt reiner Juristensprache. Als ergänzende Lektüre sind diese Informationen zum Datenschutz hilfreich, weil sie typische Datenschutzfragen in verständlicher Form einordnen.
Ihre Roadmap zur erfolgreichen CDP-Implementierung
Die meisten CDP-Projekte werden nicht zu gross geplant, sondern zu früh zu technisch. Teams starten mit Konnektoren, Eventlisten und Anbieter-Shortlists, bevor sauber definiert ist, welches Problem zuerst gelöst werden soll. Das führt fast immer zu langen Setups mit wenig sichtbarer Wirkung.
Phase 1 bis 2 von Zielbild bis Datenmodell
Phase 1 beginnt fachlich, nicht technisch. Definieren Sie zwei bis drei konkrete Use Cases, die ohne CDP heute nur schlecht oder gar nicht funktionieren. Gute Startpunkte sind Ausschlusslogik für Käufer, Reaktivierung inaktiver Kontakte, kanalübergreifende Trigger oder einheitliche Consent-gesteuerte Zielgruppen.
Danach folgt die Auswahl. Nicht mit Feature-Listen anfangen, sondern mit Fragen wie diesen:
- Welche Systeme sind führend für Kundenstammdaten, Transaktionen, Consent und Kampagnen?
- Welche Daten müssen operativ verfügbar sein, und welche reichen im Warehouse für Analysezwecke?
- Wer betreibt das Modell fachlich und technisch nach dem Go-live?
- Welche Anforderungen an Hosting und Datenhoheit sind nicht verhandelbar?
Phase 2 ist Architekturarbeit. Jetzt wird das Datenmodell entworfen. Ereignisse, Profileigenschaften, Identifier, Namenskonventionen, Consent-Felder und Zielsysteme müssen festgelegt werden. Genau hier trennt sich sauberes Setup von späterem Reparaturbetrieb.
Ein pragmatischer Ablauf in dieser Phase:
- Systeminventur erstellen
Alle relevanten Quellen und Senken erfassen. Shop, CRM, CMS, App, Service, Newsletter, Ads, BI. - Identifier priorisieren
Festlegen, welche IDs für Matching und Profilbildung massgeblich sind. - Kanonisches Eventmodell definieren
Damit „Kauf“, „Lead“, „Login“ oder „Abbruch“ in allen Quellen dasselbe bedeuten. - Governance festziehen
Ownership für Datenfelder, Freigaben und Aktivierungsregeln benennen.
Phase 3 bis 4 von Pilot bis Skalierung
Phase 3 ist der Pilot. Hier gilt: klein, sichtbar, belastbar. Ein einziger sauberer Use Case ist wertvoller als zehn halbfertige Journeys. Wählen Sie etwas, das fachlich relevant, technisch erreichbar und datenschutzseitig klar beherrschbar ist.
Geeignete Pilotmuster sind oft:
- Käufer aus Prospecting ausschliessen
- Newsletter-Strecken an Kauf- oder Inaktivitätsstatus koppeln
- CRM-Kontakte mit Webverhalten anreichern
- Servicefälle als Ausschlusskriterium für Kampagnen nutzen
Phase 4 ist die eigentliche Skalierung. Erst jetzt kommen zusätzliche Kanäle, neue Segmente, weitere Datenquellen und anspruchsvollere Personalisierungslogiken dazu. Viele Teams überspringen diese Reihenfolge und wundern sich dann, warum das Operating instabil wird.
Starten Sie mit einem Use Case, den Vertrieb, Marketing, IT und Datenschutz gemeinsam als sinnvoll anerkennen. Diese Einigkeit ist im Mittelstand oft wichtiger als die perfekte Toolentscheidung.
Checkliste für Auswahl und Betrieb
Zum Abschluss eine Checkliste, die sich in echten Auswahlprozessen bewährt:
- Use Cases zuerst
Wenn der Anbieter beeindruckt, aber kein priorisierter Business-Fall dahintersteht, fehlt dem Projekt die Zugkraft. - Identity Resolution prüfen
Nicht nur fragen, ob es sie gibt. Fragen, welche Identifier unterstützt werden, wie Regeln gepflegt werden und wie Konflikte sichtbar werden. - Consent operativ testen
Kann das System Einwilligungen nicht nur speichern, sondern bis in Segmentierung und Aktivierung durchsetzen? - Warehouse-Bezug klären
Muss alles in die CDP kopiert werden, oder lässt sich vorhandene Infrastruktur sinnvoll nutzen? - Zielsysteme realistisch bewerten
Konnektoren auf dem Papier reichen nicht. Entscheidend ist, ob die Felder, Events und Trigger sauber gemappt werden können. - Betriebsmodell festlegen
Wer pflegt Segmente, Events, Schemas, Berechtigungen und Dokumentation nach dem Launch? - Erfolg pro Use Case messen
Nicht auf eine diffuse Gesamtwirkung hoffen. Für jeden Anwendungsfall muss klar sein, woran Nutzen erkennbar wird.
Eine Customer Data Platform ist für den Mittelstand dann die richtige Lösung, wenn sie ein echtes Verbindungsproblem löst. Nicht, wenn sie nur als weiterer zentraler Speicher gedacht ist. Wer sauber zwischen CRM, Warehouse und Aktivierungsplattform trennt, DSGVO nicht als Nachtrag behandelt und die Architektur an die eigene Reife anpasst, bekommt ein System, das Marketing und IT tatsächlich entlastet.
Wenn Sie prüfen möchten, ob für Ihr Unternehmen eher eine traditionelle oder eine Composable Customer Data Platform sinnvoll ist, kann ein neutraler Architektur-Workshop viel Geld sparen. Die Küstermann Media GmbH unterstützt mittelständische Unternehmen dabei, Datenarchitekturen, EU-only-Infrastrukturen und operative Marketing-Setups so zu planen, dass sie technisch tragfähig und DSGVO-konform bleiben.
