Das Pitch-Deck eurer Customer Data Platform sieht überzeugend aus. Alle Daten an einem Ort. Unified Customer Profiles. Real-time Audiences, die sich automatisch aktualisieren. Dann kauft ihr Segment, mParticle oder Rudderstack, implementiert sechs Monate lang, und stellt fest: Die gleichen Segmentierungsfehler, die vorher in Klaviyo lagen, liegen jetzt in der CDP. Nur dass sie jetzt teurer sind und ein zusätzliches Team brauchen.
Das CDP-Versprechen: Alle Daten, ein Ort, alle Probleme gelöst
Die Grundidee von Customer Data Platforms klingt bestechend. Kundendaten liegen verstreut: im Shop-System, im CRM-Tool, im Analytics-Stack, im Helpdesk. Eine CDP sammelt alles ein, baut ein einheitliches Kundenprofil und verteilt die Daten in Echtzeit an die Systeme, die sie brauchen. Kein manuelles CSV-Matching mehr, keine veralteten Segmente, keine widersprüchlichen Datenstände zwischen Klaviyo und Braze.
So weit die Theorie. In der Praxis sehen wir etwas anderes.
Die meisten CRM-Probleme, die uns begegnen, sind keine Datenprobleme. Es sind Logik-Probleme. Ein Segment, das „alle aktiven Nutzer” heißt, aber seit acht Monaten nicht angepasst wurde, wird nicht besser, weil die Daten jetzt aus einer CDP kommen statt direkt aus dem Shop. Ein Welcome-Flow, der auf das falsche Event triggert, triggert auch mit einer CDP auf das falsche Event. Und ein Frequency-Cap-Problem bleibt ein Frequency-Cap-Problem, egal wie einheitlich das Kundenprofil ist.
CDPs lösen ein reales Infrastruktur-Thema. Aber sie werden zu oft als Antwort auf Fragen verkauft, die organisatorischer Natur sind.
Die Schicht, die niemand wartet
Jede CDP fügt eine Abstraktionsschicht zwischen Datenquelle und CRM-Tool ein. Events fließen vom Shop zur CDP, werden dort transformiert, angereichert, und dann an Braze, Klaviyo oder Brevo weitergeleitet. Jede dieser Transformationen braucht Regeln: Welches Event heißt wie? Welche Properties werden gemappt? Welche Audiences werden automatisch aktualisiert?
In den ersten drei Monaten nach der Implementierung kennt das Team diese Regeln. Nach sechs Monaten erinnert sich noch die Person, die das Setup gebaut hat. Nach zwölf Monaten ist diese Person in einem anderen Projekt, und niemand traut sich, die Transformationslogik anzufassen.
Wir sehen dieses Muster regelmäßig. Die CDP wird zum Legacy-System, bevor sie ihren ROI erreicht hat. Nicht weil die Technologie schlecht wäre, sondern weil die organisatorische Kapazität fehlt, eine zusätzliche Schicht dauerhaft zu warten. Und im Gegensatz zum CRM-Tool selbst, wo das Team täglich arbeitet und Fehler früh bemerkt, läuft die CDP im Hintergrund. Fehler in den Transformationsregeln zeigen sich erst Monate später, wenn Segmente nicht mehr stimmen oder Events verschwinden.
Datenqualität ist Organisationsarbeit, kein Tool-Kauf
Wenn eure Kontakte falsche Tags haben, doppelte Profile existieren oder Custom Events nie bereinigt werden, löst eine CDP das nicht. Sie repliziert den Fehler schneller an mehr Stellen.
Saubere Daten brauchen drei Dinge, die kein Tool liefern kann. Erstens: klare Ownership. Wer ist verantwortlich für die Event-Taxonomie? Wer entscheidet, ob ein neues Custom Event angelegt wird oder ein bestehendes erweitert? Zweitens: dokumentierte Naming-Conventions. Wenn ein Team das Event „purchase_completed” nennt und ein anderes „order_placed”, hilft keine CDP der Welt. Drittens: regelmäßige Hygiene. Ein monatlicher Check auf Duplikate, verwaiste Segmente und ungenutzte Properties.
Das klingt unspektakulär. Ist es auch. Aber es ist der Unterschied zwischen einem CRM, das funktioniert, und einem CRM, das beschäftigt aussieht.
Wann eine CDP Sinn ergibt und wann nicht
Wir sagen nicht, dass CDPs überflüssig sind. Sie haben ihren Platz, und für bestimmte Setups sind sie die richtige Lösung.
Eine CDP ergibt Sinn, wenn ihr zehn oder mehr Datenquellen habt, die in Echtzeit synchronisiert werden müssen. Wenn ihr mehrere CRM-Tools parallel betreibt, etwa Braze für die App und Klaviyo für E-Mail, und ein einheitliches Kundenprofil braucht. Wenn ihr ein dediziertes Data-Engineering-Team habt, das die Transformationsschicht dauerhaft betreuen kann.
Eine CDP ergibt wenig Sinn, wenn ihr ein CRM-Tool und ein Shop-System habt. Wenn eure Probleme in der Segmentierungslogik liegen, nicht in der Dateninfrastruktur. Wenn euer Team schon jetzt Schwierigkeiten hat, das bestehende Setup zu warten, und eine zusätzliche Schicht die Komplexität erhöht statt sie zu reduzieren.
Die direkte Integration, Shopify zu Klaviyo, App zu Braze, Brevo mit nativem Plugin, ist in den meisten Fällen schneller aufgesetzt, einfacher zu warten und deutlich billiger. Was diese Integrationen nicht können, ist selten der Grund, warum die CRM-Performance leidet.
Was ihr stattdessen tun könnt
Drei Schritte, die weniger kosten als eine CDP-Implementierung und oft mehr bringen.
Naming-Conventions dokumentieren. Setzt euch einmal hin und definiert: Wie heißen eure Events? Welche Properties gehören dazu? In welchem Format? Schreibt es auf, macht es zum Standard, und prüft neue Events dagegen. Das klingt trivial, aber in den meisten Instanzen, die wir prüfen, gibt es keine dokumentierte Taxonomie.
Wöchentlichen Daten-Hygiene-Check einführen. Fünfzehn Minuten pro Woche. Duplikate prüfen, verwaiste Segmente löschen, ungenutzte Custom Events identifizieren. Wie wir in unserem Artikel über Trustpilot-Bewertungen gezeigt haben, verraten oft externe Signale mehr über Datenprobleme als interne Dashboards.
Bestehende Integrationen aufräumen. Statt eine CDP draufzusetzen: Prüft, welche Daten tatsächlich zwischen euren Systemen fließen. Welche Felder werden nie genutzt? Welche Events kommen doppelt an? Welche Transformationen passieren schon im CRM-Tool und brauchen keine externe Schicht?
Der blinde Fleck bei CDPs ist nicht die Technologie. Der blinde Fleck ist die Annahme, dass ein neues Tool ein organisatorisches Problem löst. Wer erst die Basics in Ordnung bringt, Ownership, Naming, Hygiene, braucht in vielen Fällen gar keine CDP. Und wer eine braucht, weiß dann wenigstens, warum.
