CDP vs. Lakehouse: Welche Architektur wann sinnvoll ist
Wann eine eigenständige CDP sinnvoll ist, wann ein Lakehouse mit Reverse ETL besser passt und welche Rolle Governance, Kosten und Hybrid-Architektur spielen.
Die Kernaussagen auf einen Blick.
- Eine CDP ist häufig schneller bei der Aktivierung von Kundendaten. Ein Lakehouse bietet dagegen mehr Kontrolle über Datenmodell, Governance und Machine-Learning-Prozesse.
- Marketing bevorzugt oft eine fertige Aktivierungsplattform, während IT und Data Teams die Kundendaten in der bestehenden Datenplattform halten möchten. Entscheidend ist, welches System das führende Kundenprofil verwaltet und über welche Komponenten die Aktivierung erfolgt.
- Drei Aspekte sind für die Entscheidung besonders wichtig: Gesamtkosten, Verantwortung für Daten und Berechtigungen sowie der Weg in operative Kanäle.
- Eine hybride Architektur kann sinnvoll sein, wenn das Lakehouse die führende Datenbasis bleibt und die CDP ausschließlich Aktivierungsfunktionen übernimmt. Dadurch lässt sich vermeiden, dass beide Systeme eigene Kundenprofile und parallele Identity-Resolution-Prozesse aufbauen.
Inhaltsverzeichnis
Marketing will schneller aktivieren, IT will die Datenplattform konsistent halten
In einer typischen Steering-Runde treffen zwei berechtigte Perspektiven aufeinander. Marketing möchte Zielgruppen ohne lange Entwicklungszyklen in Kampagnen überführen. IT und Data Teams möchten Kundendaten, Berechtigungen und Datenmodelle in der bestehenden Plattform verwalten. Beide Ziele sind nachvollziehbar, werden aber häufig nicht in einer gemeinsamen Zielarchitektur zusammengeführt. Unter Zeitdruck fällt die Entscheidung deshalb oft zunächst zugunsten einer fertigen CDP. Später kann daraus eine Doppelstruktur entstehen: zwei Plattformen, zwei Identity-Resolution-Prozesse und unterschiedliche Versionen des Kundenprofils. Ohne klare Führungsverantwortung können sich diese Datenbestände zunehmend voneinander unterscheiden.
Dieses Muster tritt in vielen Customer-Intelligence-Initiativen auf, sobald neben Reporting auch operative Aktivierung gefordert wird. Aktivierung stellt andere Anforderungen als analytische Datenverarbeitung und bringt dadurch neue Architekturfragen mit sich. Die Entscheidung betrifft sowohl Marketingbudgets als auch Datenplattform, Governance und Betriebsaufwand.
Vor einer Produktentscheidung sollten vier Fragen beantwortet werden:
- Welches System verwaltet das führende Kundenprofil?
- Wo werden Identitäten zusammengeführt und Matchregeln gepflegt?
- Welche Kosten entstehen durch parallele Datenhaltung, Synchronisation und Qualitätssicherung?
- Geht es bei der CDP um ein vollständiges Kundendatenmodell oder nur um Aktivierung und Self-Service für Marketing?
Customer Intelligence ist mehr als eine einzelne Produktentscheidung. Es geht um Datenverantwortung, Aktivierung, Berechtigungen und den langfristigen Betrieb.
Was unterscheidet CDP, Warehouse und Lakehouse?
Eine Customer Data Platform bündelt Funktionen für Datenerfassung, Profilbildung, Segmentierung und Aktivierung. Sie führt Daten aus unterschiedlichen Kontaktpunkten zusammen, gleicht Identitäten anhand definierter oder vorkonfigurierter Regeln ab und bündelt die Ergebnisse in einem zentralen Kundenprofil. Anschließend lassen sich Segmente über vorhandene Connectoren an Marketing-, Sales- und Service-Systeme übertragen. Der Schwerpunkt liegt meist auf Marketingaktivierung und einfacher Nutzung durch Fachanwender. Datenmodell und Profilverwaltung hängen in der Regel vom jeweiligen Anbieter ab. Bei klassischen CDPs werden Kundendaten häufig in der Infrastruktur des Anbieters repliziert oder gespeichert.
Ein Data Warehouse dient vor allem der strukturierten Analyse, dem Reporting und der Bereitstellung kuratierter Daten. Direkte Aktivierung in operative Kanäle gehört nicht zum Kernumfang. Für die Übertragung in CRM-, E-Mail- oder Werbeplattformen sind zusätzliche Schnittstellen oder Reverse-ETL-Werkzeuge erforderlich.
Ein Lakehouse kombiniert strukturierte Datenmodelle und Governance mit flexibler Speicherung sowie Funktionen für Data Engineering und Machine Learning. Rohdaten, kuratierte Tabellen und ML-relevante Daten können in einer gemeinsamen Plattform verwaltet werden. Bei Databricks liegen sie beispielsweise als Delta Lake unter Unity Catalog und tragen BI, Data Engineering und ML auf demselben Modell.
Die Abgrenzung ist für die Entscheidung wichtig: Eine klassische CDP verwaltet häufig ein eigenes Kundenprofil und damit einen zusätzlichen führenden Datenbestand. Ein Lakehouse kann das führende Kundenprofil bereitstellen, wenn Datenmodell, Ownership und Qualitätsprozesse entsprechend aufgebaut sind. Problematisch wird es, wenn CDP und Lakehouse unabhängig voneinander Profile und Matchlogik pflegen. Wie das Datenmodell hinter einem belastbaren Kundenprofil aussieht, zeigen wir parallel im Artikel zu Customer 360 als Datenmodell.
Data & AI Beratung mit ruhrdot
Als offizieller Databricks-Partner begleiten wir dich von der Datenstrategie bis zur produktiven KI-Lösung.
Ist ein Lakehouse automatisch eine CDP?
Nein. Ein Lakehouse deckt nicht automatisch alle Funktionen einer CDP ab. Es kann Kundendaten speichern, Profile modellieren und Segmente berechnen. Fertige Connectoren in Werbeplattformen, E-Mail-Systeme, CRM oder Push-Dienste gehören jedoch nicht zwingend zum Kernumfang.
Aus dieser Lücke ist das Composable-CDP-Architekturmuster entstanden. Das führende Kundenprofil bleibt in der eigenen Datenplattform, und spezialisierte Werkzeuge übertragen ausgewählte Profile und Segmente in operative Zielsysteme. Hightouch beschreibt das Vorgehen als „Customer Studio" für Marketer auf der eigenen Datenbasis. Preise und Funktionspakete von Reverse-ETL-Anbietern ändern sich regelmäßig und sollten für den konkreten Bedarf aktuell geprüft werden (Hightouch-Pricing-Übersicht, RudderStack-Pricing). Markt- und Anbieterentwicklungen wie die Übernahme von Census durch Fivetran können die Produktstrategie verändern und sollten vor einer langfristigen Entscheidung aktuell verifiziert werden.
Ein Lakehouse mit Identity Resolution, Segmentierung, Fachanwenderoberfläche und Reverse ETL kann viele Funktionen einer CDP abdecken. Das führende Kundenprofil bleibt dabei in der eigenen Datenplattform. Die zentrale Architekturfrage lautet deshalb: Welches System verwaltet das Profil und welche Komponente übernimmt die Aktivierung?
Was können klassische CDPs gut?
Klassische CDPs bieten mehrere Funktionen als vorkonfiguriertes Gesamtpaket. Dazu gehören vorkonfigurierte Identity-Resolution-Mechanismen, ein breites Angebot an Aktivierungs- und Datenquellen-Connectoren sowie eine Fachanwenderoberfläche für Zielgruppen und Kampagnen ohne SQL. Einige Plattformen bieten zusätzlich niedrige Antwortzeiten für Echtzeitprofile und Entscheidungen.
Anwendungsfälle wie Websitepersonalisierung, Abbruchtrigger oder Next-Best-Action benötigen häufig kurze und planbare Reaktionszeiten. Ein Lakehouse ist ohne zusätzliche Serving- oder Caching-Komponenten primär auf analytische und datenverarbeitende Workloads ausgelegt. Für interaktive Echtzeitanwendungen können zusätzliche Online Stores, APIs oder Caches notwendig sein. Dadurch steigen Architektur- und Betriebsaufwand.
Im Markt gibt es unterschiedliche Schwerpunkte: API-first-Plattformen mit breiten Integrationskatalogen, mobile-Event-orientierte Anbieter, B2B-Plattformen mit Account-Hierarchien und CRM-Anbindung, Tag-Management-orientierte Enterprise-Lösungen sowie commerce-spezifische Suiten. Connectoranzahl, Funktionsumfang und Preise sollten als zeitabhängige Produkteigenschaften aktuell geprüft werden. Enterprisepreise hängen stark von Profilanzahl, Modulen, Nachrichtvolumen, Vertragslaufzeit und Services ab und sollten nicht als feste Marktwerte dargestellt werden.
Im deutschen Mittelstand kommt der Punkt Datenhoheit hinzu. Datenschutz- und Zertifizierungsversprechen sollten anhand von Vertrag, Region, Unterauftragnehmern und tatsächlicher Verarbeitung geprüft werden. Das zeigt, wo die Schmerzpunkte liegen, wenn Kundendaten in einen externen Storage gehen.
Ein möglicher Kostentreiber ist die Abrechnung nach Monthly Tracked Users oder vergleichbaren Nutzungsgrößen. Wachsende Profilbestände und zusätzliche Trackingquellen können zu deutlichen Preissprüngen führen. Der Begriff „MTU-Explosion" beschreibt das Risiko, dass identifizierte oder getrackte Nutzer schneller wachsen als ursprünglich geplant. Grenzen, Eskalationsstufen und Preisänderungen sollten vor Vertragsabschluss transparent vereinbart werden. Ohne diese Klausel entscheidet die nächste Kampagne unbemerkt über das CDP-Budget des nächsten Jahres.
Was leistet ein Lakehouse für Customer Intelligence?
Auf der anderen Seite steht das Lakehouse, hier am Beispiel Databricks. Ein typischer Aufbau trennt Rohdaten, kuratierte Entitäten und konsumierbare Kundenprofile. In der Rohschicht werden Quelldaten möglichst unverändert übernommen. In der kuratierten Schicht werden Daten bereinigt, vereinheitlicht und Identitäten zusammengeführt. Die fachliche Schicht stellt das nutzbare Kundenprofil und daraus abgeleitete Segmente bereit, dokumentiert als Referenzarchitektur unter anderem für Insurance. Unity Catalog kann Berechtigungen, Maskierung, Ownership und Lineage zentral verwalten.
MLflow, Feature Engineering und Model Serving unterstützen den Lebenszyklus von Churn-, CLV- oder Next-Best-Action-Modellen. Viele CDPs bieten integrierte Scores, decken jedoch nicht immer denselben Grad an Training, Versionierung, Evaluation und Monitoring ab wie eine ML-Plattform. Bei anspruchsvolleren eigenen Modellen steigt der Nutzen einer Plattform, die Daten und ML-Lifecycle gemeinsam verwaltet.
Identity Resolution muss im Lakehouse bewusst modelliert, getestet und betrieben werden. Die übliche Strecke kombiniert ein deterministisches Matching auf eindeutige Schlüssel (E-Mail, Kundennummer) mit probabilistischen Verfahren für Fuzzy-Matches und endet in einem Survivorship-Schritt, der nach Recency und Vollständigkeit ein Golden Record bildet. Databricks hat dafür einen Blueprint mit ER Accelerators und Zingg als ML-Komponente veröffentlicht. Der Eigenbau bietet Kontrolle über Matchregeln und Datenmodell, erfordert aber dauerhaftes Ownership und Qualitätsmonitoring.
Für die Aktivierung gilt die Reverse-ETL-Brücke aus dem vorigen Abschnitt. Databricks One kann abhängig vom aktuellen Produktstand eine vereinfachte Oberfläche für Businessanwender bereitstellen, in der AI/BI-Dashboards, Genie und Custom Apps zusammenlaufen. Eine Businessoberfläche ersetzt jedoch nicht die technische Synchronisation in operative Marketing- und CRM-Systeme.
Die Gesamtkosten setzen sich aus Databricks-Verbrauch, Cloud-Compute, Storage, Netzwerk und weiteren Plattformdiensten zusammen. Workload-spezifische Listenpreise liegen laut dem DBU-Pricing-Überblick von DoiT bei rund 0,55 USD pro DBU für All-Purpose-Compute und 0,70 USD pro DBU für Serverless SQL. Falsche Compute-Typen, dauerhaft laufende Cluster oder ungeeignete Konfigurationen können die Kosten erheblich erhöhen. Beides sind regelmäßig dokumentierte Muster in der Data-Engineering-Community.
Ein Lakehouse ist nicht automatisch günstiger als eine CDP. Die Wirtschaftlichkeit hängt stark von Architektur, Auslastung, Automatisierung und FinOps-Prozessen ab.
Wer hat die Governance-Hoheit?
Die Governance-Frage ist die Achse, die im Steering oft zu spät auf den Tisch kommt. Bei einer klassischen CDP werden Profilmodell, Identity Resolution und Zugriffe weitgehend innerhalb der Anbieterplattform verwaltet. Jede zusätzliche Datenkopie und Anbietergrenze erhöht den Prüfungs- und Vertragsumfang. Wer Mehrfach-CDPs einsetzt, fragmentiert das Modell weiter.
In einer Lakehouse-zentrierten Architektur können Berechtigungen, Maskierung und Lineage in Unity Catalog gebündelt werden. Zugriffs- und Maskierungsregeln werden zentral definiert, Lineage läuft über alle Workloads inklusive ML, Auditierbarkeit ist Teil der Plattform. Die Hoheit über das Kundenprofil wird damit zur Frage der IT-Plattform.
| Architektur | Zugriffshoheit | Profil-Definition | DSGVO-Risiko |
|---|---|---|---|
| Packaged CDP | CDP-eigen | Marketing in der CDP | CDP-Vendor + Auftraggeber |
| Lakehouse + Reverse ETL | Unity Catalog (IT) | Datenmodell-Owner | Auftraggeber, ein Audit-Pfad |
| Hybrid (CDP über Lakehouse) | UC für Daten, CDP für Aktivierung | gemeinsame Definition im UC | Auftraggeber, klare Trennung Daten / Aktivierung |
Ein Punkt fällt in der Diskussion oft hinten runter: Aktivierung bedeutet weiterhin, dass ausgewählte personenbezogene Daten in operative Zielsysteme übertragen werden. Das gilt sowohl für die Composable- als auch für die Hybrid-Variante. Sobald ein Segment in den ESP, das Ad-Network oder das CRM geht, liegen E-Mail-Adressen, Telefonnummern und Verhaltensattribute in einem weiteren Vendor-System. Die zentrale Datenbasis kann im Lakehouse bleiben, die für Kampagnen benötigten Attribute verlassen die Plattform jedoch weiterhin. Mit jedem zusätzlichen Zielsystem steigen Vertrags-, Berechtigungs- und Löschanforderungen. Das ist beherrschbar, wenn aktive Zielsysteme, übertragene Attribute, Zwecke und Aufbewahrungsregeln zentral dokumentiert werden. Sonst wächst die Audit-Surface leise.
Die Entscheidung ist nicht akademisch. Bei Daten unter deutscher Rechtslage liegt ein handfester Hebel darin, dass der Audit-Pfad über eine einzige Plattform und einen einzigen Catalog läuft. Die Hoheit beim Lakehouse zu behalten, ist deshalb eine messbare Risikoreduktion. Wie sich Profile darüber konsistent gruppieren lassen, vertiefen wir im Artikel zu Kundensegmentierung mit RFM, ABC und Clustering.
Was kostet CDP gegen Lakehouse?
Die TCO-Diskussion verläuft fast immer entlang einer Achse, die für beide Seiten unbequem ist. CDP-Kosten hängen häufig von Profilanzahl, getrackten Nutzern, Events, Modulen und Zielsystemen ab. Lakehouse-Kosten steigen vor allem mit Datenmenge, Verarbeitung, Abfragevolumen und ML-Workloads.
Drei Faktoren in der Kalkulation, die häufig untergehen:
Implementierung
Bei einer CDP kommen Implementierung, Datenanbindung, Connectorpflege und gegebenenfalls Beratungsleistungen hinzu, bei Enterprise-Plattformen im Jahresvergleich erhebliche Beträge.
Cloud-Nebenkosten
Bei Databricks müssen zusätzlich Cloud-Compute, Storage, Egress und weitere Services berücksichtigt werden. Ohne diese Trennung wird der Vergleich zum Äpfel-mit-Birnen-Vergleich.
Fehlende Steuerung
In beiden Architekturen entstehen unnötige Kosten häufig durch fehlende Steuerung und ungeeignete Konfiguration: bei der CDP nicht abgesicherte MTU-Caps, bei Databricks falsche Cluster-Typen. Beides ist beherrschbar, wenn jemand zuständig ist.
Die belastbare Frage für die TCO-Diskussion lautet deshalb „Wer steuert das Cost Model, und mit welcher Eskalationslogik?". Ohne FinOps und Ownership kann sowohl eine CDP als auch ein Lakehouse deutlich teurer werden als geplant.
Kundenprofil im Lakehouse, Aktivierung über CDP oder Reverse ETL
Hybride und composable Architekturen gewinnen an Bedeutung, weil sie Datenhoheit und Fachanwenderaktivierung verbinden sollen. Das führende Profil wird in der Datenplattform modelliert und verwaltet. Eine CDP oder ein spezialisiertes Tool übernimmt Fachanwenderoberfläche, Kampagnenaktivierung und Connectorbetrieb. Warehouse-native CDPs setzen darauf, dass die Datenwahrheit nicht repliziert werden muss.
- Self-Service-Segmentierung
- Marketer-UI
- Audience-Sync
Die Architektur ist besonders sinnvoll, wenn:
- Datenmodell, Berechtigungen und Governance zentral in der eigenen Plattform bleiben sollen (DSGVO, BDSG, Branche)
- ein Data-Engineering-Team vorhanden ist, aber nicht groß genug, um Aktivierungs-Connectoren selbst zu betreiben
- Marketing Segmente selbst erstellen und aktivieren soll, ohne für jede Änderung ein Entwicklungsticket zu benötigen
- eigene ML-Modelle, Features und Evaluation eine wichtige Rolle spielen
Die Vorteile verschwinden, wenn CDP und Lakehouse erneut parallele Profile und Matchlogiken aufbauen. Dann wird das Hybrid zur Doppelstruktur.
Die Dauer einer Migration aus einer Packaged CDP Richtung Composable oder Hybrid hängt von Datenumfang, Use Cases, Verträgen und Integrationen ab und sollte projektspezifisch geplant werden. Ein paralleler Aufbau des Kundenprofils im Lakehouse kann einen kontrollierten Vergleich mit der bestehenden CDP ermöglichen. Cutover-Kriterien werden je Use Case definiert, danach folgt der vertragliche Rückbau der Volumenstufen. Lizenz- und Volumenverträge müssen frühzeitig in die Migrationsplanung einbezogen werden. Ohne diesen Rückbau zahlt man im ersten Jahr für beides; genau darin liegt die teuerste Variante des Hybrids.
Welche Architektur passt zu welcher Ausgangslage?
| Situation | Empfehlung | Warum |
|---|---|---|
| Hoher Aktivierungsdruck, kleines Datenteam, kurze Time-to-Activation | Packaged CDP | Bei hohem Aktivierungsdruck und begrenztem Datenteam kann eine klassische CDP den schnelleren Einstieg bieten. |
| Datenhoheit Pflicht (Branche, DSGVO), ML-Tiefe gewollt, vorhandenes Lakehouse | Lakehouse mit Reverse ETL | Bei hohen Governanceanforderungen, vorhandener Plattform und eigenen ML-Anwendungsfällen ist eine Lakehouse-zentrierte Architektur häufig geeigneter. |
| Lakehouse vorhanden, Marketing braucht Self-Service-Aktivierung, IT will Hoheit | Hybrid (CDP über Lakehouse) | Eine Hybrid- oder Composable-CDP kann Fachanwenderzugang ergänzen, ohne das führende Profil aus dem Lakehouse zu verlagern. |
| Frischer Stack, kein Lakehouse, geringe ML-Anforderung | Packaged CDP, später hybrid wandern | Ohne bestehende Datenplattform und bei einfachen Marketinganforderungen kann eine CDP zunächst wirtschaftlicher sein. |
| Vollbild Customer Intelligence mit Churn, CLV, NBA, eigener Segmentierung | Lakehouse-zentriert | Für Churn, CLV, Next Best Action und eigene Segmentierungsmodelle bietet ein Lakehouse meist mehr technische Tiefe. |
Die Matrix erfüllt eine Aufgabe: Sie macht die Entscheidung weniger zur Tool-Geschmacksfrage. Wenn zentrale Kriterien wie Profilhoheit, Aktivierung, Ownership und Kosten nicht beantwortet sind, ist eine Produktauswahl verfrüht. Die Modelle dahinter, Churn, Customer Lifetime Value oder Segmentierung, laufen in beiden Architekturen, aber mit unterschiedlicher Tiefe.
Wisst ihr, wo euer Setup in dieser Matrix landet?
Grenzen
CDP deckt nicht alle ML-Anforderungen ab
Eine CDP deckt nicht automatisch alle analytischen, prognostischen und ML-bezogenen Anforderungen ab. Ihre Stärke liegt häufig in schneller Segmentierung und Aktivierung. Für eigene Datenmodelle, Feature Engineering und komplexe ML-Prozesse bleiben zusätzliche Plattformkomponenten notwendig.
Lakehouse bringt keine fertigen Aktivierungswege
Ein Lakehouse stellt nicht automatisch fertige Schnittstellen und Fachanwenderprozesse für Marketingkanäle bereit. Es speichert, modelliert und rechnet. Die Strecke vom Profil in den Mailprovider muss jemand betreuen. Reverse ETL ist eine zusätzliche Komponente mit eigenen Kosten, Berechtigungen und Betriebsprozessen.
Hybrid braucht klare Verantwortungsgrenzen
Eine hybride Architektur kann viele Anforderungen verbinden, benötigt jedoch klare Verantwortungsgrenzen: Daten im Lakehouse, Aktivierung in der CDP, Identity Resolution genau an einer Stelle. Ohne klare Trennung entstehen doppelte Datenhaltung, widersprüchliche Profile und zusätzlicher Betriebsaufwand.
Preise und Produktstände ändern sich
Preise, Produktpakete und Preview-Status sind zeitabhängig und sollten vor Vertragsabschluss aktuell verifiziert werden. Die Größenordnungen tragen, die Detailzahlen sollten vor jedem Vertragsabschluss verifiziert werden.
Fazit
Die teuerste Architektur ist die, die niemand entschieden hat: CDP und Lakehouse parallel für dieselbe Aufgabe.
Die reine Gegenüberstellung von CDP und Lakehouse greift häufig zu kurz, sobald Customer Intelligence über reine Marketing-Aktivierung hinausgeht. Wichtiger ist die Aufteilung zwischen führendem Kundenprofil, Identity Resolution, Segmentierung und Aktivierung. Für viele Unternehmen ist eine Architektur sinnvoll, in der das Lakehouse die führende Datenbasis stellt und spezialisierte Werkzeuge die Aktivierung übernehmen. Ob dieser Ansatz passt, hängt von bestehender Plattform, Teamkompetenz, Aktivierungsdruck und regulatorischen Anforderungen ab.
Relevant ist die Architekturarbeit für Unternehmen, die bereits ein Lakehouse oder Data Warehouse betreiben und gleichzeitig unter Marketing-Druck stehen, schneller zu aktivieren. Genauso für Unternehmen, bei denen Datenhoheit als Pflicht aus Compliance, Branche oder Audit gefordert wird.
Typische Hinweise auf Klärungsbedarf sind:
- Parallele Matchlogik in CDP und Lakehouse
- Wachsende CDP-Kosten ohne nachvollziehbare Zuordnung zu Aktivierungsfällen
- ML-Modelle, die Profile aus der CDP exportieren, weil die CDP-Analyse nicht reicht
- Aktivierung hängt regelmäßig an fehlenden oder individuell zu entwickelnden Schnittstellen
- Ein Datenschutz-Audit, das CDP und Lakehouse parallel prüft
Ohne diese Punkte braucht es keine vertiefte Architekturdiskussion. Mit diesen Punkten sollte die Entscheidung fallen, bevor der nächste Vertrag verlängert wird.
Die Architekturarbeit sollte mit Profilhoheit, Ownership und benötigten Aktivierungswegen beginnen. Wo soll das unified Profile leben? Welche Rollen schreiben darauf, welche lesen? Welche Aktivierungswege braucht ihr wirklich, und wie viele davon rechtfertigen ein eigenes Tool? Erst auf dieser Grundlage sollte die passende Produktkombination ausgewählt werden.
Am teuersten ist meist eine Doppelstruktur, in der CDP und Lakehouse dieselben Aufgaben unabhängig voneinander übernehmen.
Profilhoheit und Aktivierungsweg klären, bevor der nächste CDP-Vertrag verlängert wird.
Welche Customer-Intelligence-Architektur passt zu eurer Ausgangslage?
Welche Customer-Intelligence-Architektur für eure Ausgangslage sinnvoll ist, lässt sich in einem strukturierten Data & AI Assessment bewerten.
- welche eurer Customer-Intelligence-Use-Cases echte CDP-Kandidaten sind und welche besser im Lakehouse leben
- welche Governance-, Compliance- und TCO-Risiken vor dem nächsten Vertrag geprüft werden müssen
- welche Zielarchitektur und Migrationsreihenfolge realistisch umsetzbar sind
FAQ
Eine CDP führt Kundendaten aus verschiedenen Quellen zusammen und stellt sie für Segmentierung und Aktivierung bereit. Wie echtzeitnah dies erfolgt, hängt vom Produkt und der Datenanbindung ab. Ein Data Warehouse speichert strukturierte Daten für Analytics und Reporting. Die CDP ist auf Aktivierung optimiert, das Warehouse auf Analyse. Die Stärken liegen in unterschiedlichen Aufgaben und kollidieren erst, wenn das Warehouse selbst zur Aktivierungsschicht ausgebaut werden soll.
