CDP vs. Data Warehouse: Warum Banken beides brauchen — und wie sie zusammenspielen

"Wir haben doch schon ein Data Warehouse — wozu brauchen wir zusätzlich eine CDP?" Diese Frage ist legitim, und sie hat eine präzise Antwort. Aber die Antwort ist nicht die, die viele erwarten.

Customer Data Platforms und Data Warehouses sind keine Konkurrenten. Sie sind architek-tonisch komplementaer — mit fundamental verschiedenen Zwecken, verschiedenen Stärken und verschiedenen operativen Verwendungszwecken. Banken, die das verstehen, vermeiden sowohl die Fehlinvestition ("wir brauchen kein CDP, wir haben ein DWH") als auch die umgekehrte Fehleinschätzung ("wir bauen eine CDP und ersetzen damit das DWH").

Was ein Data Warehouse leistet

Ein Data Warehouse ist ein zentrales Datenlager, das historische Daten aus verschiedenen Quellsystemen in einer strukturierten, abfrageeffizienten Form speichert. Es ist optimiert für:

• Analytische Abfragen über große Datenmengen: Aggregationen, Zeitreihenanalysen, Kohortenauswertungen

• Berichtswesen: Standardisierte Reports, Dashboards, regulatorische Meldungen

• Historische Tiefe: Speicherung von Daten über Jahre oder Jahrzehnte

• Batch-Verarbeitung: Nächtliche oder wöchentliche Ladeprozesse, die Daten in das Warehouse übertragen

Ein DWH ist das Gedächtnis einer Bank. Es weiß, was in der Vergangenheit passiert ist — präzise, reproduzierbar, revisionssicher.

Was ein DWH nicht ist: ein System für Echtzeitentscheidungen. Es ist nicht dafür gebaut, dass eine Trigger-Engine in Millisekunden abfragt, ob Kunde X gerade eine relevante Transaktion durchgeführt hat. Es ist nicht dafür optimiert, Kundensegmente täglich neu zu berechnen und sofort in eine Kampagnen-Engine zu propagieren. Und es ist nicht designed für die Art von flexiblen, schnell veränderlichen Kundenprofilen, die ein modernes CLM-System benötigt.

Was eine CDP leistet

Eine Customer Data Platform ist kein Datenlager. Sie ist eine Echtzeit-Verarbeitungsschicht, die Daten aus verschiedenen Quellen kontinuierlich zusammenführt, anreichert und in operative Systeme propagiert.

Eine CDP ist optimiert für:

• Echtzeit-Kundenprofil: Das Profil eines Kunden ist zu jedem Zeitpunkt aktuell — inklusive der letzten Transaktion, des letzten Kanalzugriffs, des aktuellen Consent-Status

• Operative Aktivierung: Segmente und Propensity-Scores fließen direkt in Kampagnen-Engines, Journey-Orchestrierung und NBA-Systeme

• Datennormalisierung: Kundendaten aus verschiedenen Quellsystemen (Core-Banking, CRM, Kreditkarte) werden in ein einheitliches Profil-Schema zusammengeführt

• Consent-Management: Der aktuelle Einwilligungsstatus eines Kunden ist nativ Teil jedes Kundenprofils

Was eine CDP nicht ist: ein System für tiefe historische Analysen, komplexe Multi-Jahres-Kohortenauswertungen oder regulatorisches Reporting. Dafür ist ein DWH gebaut.

Die konkrete Arbeitsteilung

In einer gut strukturierten Banking-Datenarchitektur haben DWH und CDP klar getrennte Verantwortungsbereiche, die sich ergänzen:

Die Datenflüsse zwischen beiden Systemen sind typischerweise bidirektional: Das DWH liefert historische Daten als Basis für das Modelltraining in der CDP. Die CDP liefert Echtzeit-Ereignisse und aggregierte Verhaltensdaten zurück ins DWH für langfristige Analysen.

Das "Wir haben schon ein DWH"-Problem

Wenn eine Bank sagt, "wir haben schon ein DWH, wozu brauchen wir eine CDP", dann verwechselt sie zwei verschiedene Architekturzwecke.

Das DWH beantwortet die Frage: "Was ist in der Vergangenheit passiert?"

Die CDP beantwortet die Frage: "Was passiert gerade — und was sollen wir jetzt tun?"

Ein Marketingteam, das auf Basis von DWH-Daten Kampagnen steuert, arbeitet mit Daten, die mindestens stunden-, oft tagealt sind. Segmente werden wöchentlich oder monatlich aktualisiert. Trigger-Logiken können nicht in Echtzeit auf Transaktionssignale reagieren.

Das ist kein DWH-Problem. Das ist ein Architekturmuster, das für Echtzeit-CLM strukturell nicht geeignet ist.

Was eine CDP-Implementierung neben einem bestehenden DWH bedeutet

Eine CDP ersetzt das DWH nicht — sie ergänzt es um die operative Echtzeitschicht. Das hat folgende praktische Konsequenzen:

Doppelte Datenhaltung ist kein Fehler: Bestimmte Daten — zum Beispiel aktuelle Kundensegmente — existieren in beiden Systemen, aber mit verschiedenen Aktualisierungsrhythmen und verschiedenen Zwecken. Das ist kein Redundanzproblem, sondern eine bewusste Architekturentscheidung.

Die CDP ist dünner als das DWH: Eine CDP hält typischerweise nur die Daten, die für operative Entscheidungen relevant sind — 12 bis 24 Monate Transaktionshistorie, aktuelle Profilmerkmale, Consent-Status. Das DWH hält alles, auf unbegrenzte Zeit.

Die Integration zwischen beiden ist der Schlüssel: Wie gut DWH und CDP zusammenarbeiten, bestimmt die Qualität des Gesamtsystems. Modelle, die im DWH trainiert werden, müssen ihre Feature-Logik in die CDP-Echtzeit-Pipeline übertragen. Ereignisse aus der CDP müssen zuverlässig ins DWH zurückfließen.

Fazit: Nicht entweder-oder, sondern richtig konfiguriert

Die Frage ist nicht CDP oder DWH. Die Frage ist: Welche Architektur braucht eine Bank, um sowohl tiefe historische Analysen als auch Echtzeit-Kundenpersonalisierung zu betreiben?

Die Antwort ist fast immer: beides — korrekt integriert, mit klaren Verantwortungsbereichen.

ACCELERAID ist als CDP-Schicht konzipiert, die neben bestehenden DWH-Architekturen betrieben wird — mit definierten Datenflüssen in beide Richtungen und einer Integrationsarchitektur, die auf vorhandene Banking-IT aufbaut.

Demo anfragen