Der gedankliche Kern lautet: Die Kundendaten bleiben dort, wo sie ohnehin liegen. In den vergangenen Jahren haben viele Unternehmen erhebliche Summen in moderne Cloud-Data-Warehouses und Lakehouses investiert. Dort liegen Bestell-, Verhaltens-, Produkt- und Kontaktdaten bereits modelliert und geprüft vor. Eine paketierte CDP würde diese Daten ein weiteres Mal kopieren, in ein eigenes, geschlossenes Datenmodell überführen und damit ein zweites Kundendaten-Silo schaffen. Die Composable CDP vermeidet genau diese Dopplung.
Drei Merkmale definieren den Ansatz:
Die Composable CDP ist kein akademisches Gedankenspiel, sondern eine Antwort auf zwei parallele Entwicklungen. Erstens sind Cloud-Data-Warehouses in den letzten Jahren so leistungsfähig, günstig und bedienbar geworden, dass sie mühelos die Datenmengen einer Kundendatenplattform tragen. Zweitens hat sich in vielen Unternehmen ohnehin ein Data-Team etabliert, das dieses Warehouse pflegt und modelliert. Die Frage lag also nahe: Warum die aufwendige Datenarbeit doppelt machen – einmal fürs Reporting im Warehouse und einmal in der CDP?
Hinzu kommt der Reifegrad von Reverse ETL. Was früher nur mit individueller Programmierung möglich war – Daten aus dem Warehouse zuverlässig in Dutzende Zielsysteme zu synchronisieren –, erledigen heute spezialisierte Dienste als konfigurierbaren Standard. Erst diese Werkzeugklasse hat die Composable CDP praxistauglich gemacht. Ohne sie bliebe das Warehouse ein Datensee ohne Abfluss ins operative Marketing.
Man kann sich eine paketierte CDP wie ein Kombigerät vorstellen, das Speicher, Rechenwerk und alle Anschlüsse fest verbaut in einem Gehäuse mitbringt – bequem, aber unflexibel. Die Composable CDP entspricht eher einem Baukasten mit klar definierten Steckplätzen: Das Warehouse liefert Speicher und Rechenleistung, die Modellierungsschicht definiert Profile und Segmente, Reverse ETL bildet die Anschlüsse nach außen. Jeder Steckplatz lässt sich einzeln aufrüsten oder ersetzen, ohne das ganze Gerät auszutauschen.
Für den Mittelstand ist dieses Bild wichtig, weil es die zentrale Konsequenz verdeutlicht: Eine Composable CDP ist weniger ein Kauf und mehr eine Konstruktion. Sie entsteht durch die bewusste Kombination vorhandener und neuer Bausteine – und setzt entsprechend eine gewisse Datenreife voraus. Genau hier liegt die Chance, aber auch die zentrale Hürde des Ansatzes.
Die paketierte CDP (englisch „packaged“ oder „all-in-one“) ist eine geschlossene Plattform. Sie sammelt Daten aus Quellsystemen ein, speichert sie in ihrem eigenen Datenmodell, führt Profile zusammen, bildet Segmente und aktiviert sie in den Kanälen – alles innerhalb einer Software eines Anbieters. Der Vorteil: Man kauft eine Lösung, nicht viele Teile. Der Preis dafür ist eine Kopie sämtlicher Kundendaten in einem System, das man nicht selbst kontrolliert, und ein Datenmodell, das den Vorgaben des Anbieters folgt.
Die Composable CDP zerlegt genau diese Plattform in ihre Funktionsschichten und ordnet jede der Schicht zu, die sie am besten erfüllt. Speicherung und Transformation übernimmt das Warehouse, die Aktivierung übernehmen Reverse-ETL-Werkzeuge, und die Modellierung geschieht in der Sprache, die das Data-Team ohnehin nutzt. Das Ergebnis ist funktional vergleichbar, aber architektonisch offen.
In der Praxis stehen sich Packaged und Composable nicht als reine Gegensätze gegenüber, sondern spannen ein Spektrum auf. Viele paketierte CDPs haben inzwischen „warehouse-native“ Betriebsarten ergänzt, in denen sie direkt auf dem Warehouse aufsetzen, statt Daten zu kopieren. Umgekehrt gibt es Composable-Werkzeuge, die so weit vorkonfiguriert sind, dass sie sich fast wie eine fertige Plattform anfühlen. Die entscheidende Frage ist deshalb selten „das eine oder das andere“, sondern: Wie viel Kontrolle über das Datenmodell will und kann ein Unternehmen selbst übernehmen?
Je mehr eigene Datenkompetenz vorhanden ist, desto weiter kann sich ein Unternehmen auf der Skala Richtung Composable bewegen und desto mehr Wert schöpft es aus dem Ansatz. Je weniger Datenreife da ist, desto attraktiver bleibt das paketierte Modell – zumindest als Einstieg, von dem aus später composable weitergebaut werden kann.
Wenn man alles auf einen Kern reduziert: Bei der paketierten CDP kommen die Daten zur Software, bei der Composable CDP kommt die Software zu den Daten. Diese Umkehrung klingt technisch, hat aber weitreichende Folgen für Datenschutz, Kosten, Betrieb und Abhängigkeit vom Anbieter. Alle folgenden Kapitel arbeiten diese Folgen konkret heraus.
Ein modernes Cloud-Data-Warehouse oder Lakehouse ist für die Rolle der zentralen Kundendatenschicht fast ideal geeignet. Es skaliert praktisch beliebig, trennt Speicher von Rechenleistung, verarbeitet sowohl strukturierte Tabellen als auch halbstrukturierte Ereignisdaten und lässt sich über SQL von jedem Data-Team bedienen. Vor allem aber ist es der Ort, an dem in vielen Unternehmen ohnehin schon die verlässlichsten Kundendaten liegen – geprüft, dokumentiert und für das Reporting genutzt.
Genau diese Doppelnutzung ist der eigentliche Gewinn: Dieselben Daten, die morgens das Management-Dashboard speisen, treiben nachmittags die Marketing-Kampagne. Es gibt keine Diskrepanz mehr zwischen den Zahlen, die das Controlling sieht, und den Segmenten, die das Marketing aktiviert. Der Begriff „Lakehouse“ beschreibt dabei eine Architektur, die die Flexibilität eines Data Lake mit den Verwaltungs- und Abfragefähigkeiten eines Warehouse verbindet – für Kundendaten oft die tragfähigste Grundlage.
Die Modellierungsschicht ist der Ort, an dem die eigentliche fachliche Intelligenz steckt. Hier werden verstreute Ereignisse und Datensätze zu einem einheitlichen Kundenprofil verdichtet. Die zentrale Aufgabe ist die Identitätsauflösung: Ein anonymer Website-Besucher, eine E-Mail-Adresse aus dem Newsletter und ein Bestellkonto im Shop müssen als derselbe Mensch erkannt und zu einem Profil zusammengeführt werden. In der Composable-Welt geschieht das transparent im Warehouse – die Regeln sind sichtbar, prüfbar und anpassbar, nicht in einer Blackbox versteckt.
Auf dieser Basis entstehen berechnete Attribute (etwa Kundenwert, Kauffrequenz, letzte Aktivität) und Segmente (etwa „Warenkorbabbrecher der letzten sieben Tage“ oder „inaktive Bestandskunden mit hohem Vorjahresumsatz“). Weil diese Logik in SQL oder einem Transformationswerkzeug definiert wird, kann sie versioniert, getestet und dokumentiert werden – wie jeder andere Programmcode auch. Das ist ein wesentlicher Reife- und Governance-Vorteil gegenüber Segmenten, die per Klick in einer geschlossenen Oberfläche entstehen.
Reverse ETL ist die Schlüsseltechnologie der Composable CDP. „ETL“ steht klassisch für den Weg der Daten in das Warehouse hinein (Extract, Transform, Load). „Reverse ETL“ dreht die Richtung um: Es nimmt fertig modellierte Daten aus dem Warehouse und synchronisiert sie zuverlässig in die operativen Zielsysteme – also genau dorthin, wo Marketing und Vertrieb tatsächlich handeln. Ohne Reverse ETL wäre das schönste Kundenmodell im Warehouse für die Aktivierung wertlos.
Gute Reverse-ETL-Dienste lösen dabei anspruchsvolle Detailprobleme: Sie erkennen, welche Datensätze sich seit dem letzten Lauf geändert haben, halten sich an die Grenzen der Ziel-Schnittstellen, behandeln Fehler robust und protokollieren jede Übertragung. Für den Mittelstand bedeutet das: Was früher ein fragiles Eigenbau-Skript war, wird zu einem überwachbaren, wartbaren Standardbaustein – die eigentliche Voraussetzung dafür, dass der composable Ansatz betriebssicher funktioniert.
In der paketierten Welt sind Vorhersagemodelle – etwa für Abwanderungsrisiko, Kaufwahrscheinlichkeit oder erwarteten Kundenwert – meist fest in die Plattform eingebaut. Man bekommt fertige Scores, aber wenig Einblick, wie sie zustande kommen, und kaum Möglichkeit, eigene Modelle einzusetzen. In der Composable-Welt kehrt sich das um: Die Vorhersagen entstehen dort, wo die Daten liegen, und fließen als weitere Attribute in dasselbe Kundenmodell ein, das auch die Aktivierung speist.
Der praktische Ablauf ist bestechend geradlinig. Ein Data-Team oder ein spezialisiertes Werkzeug trainiert ein Modell auf den historischen Daten im Warehouse – etwa: Welche Merkmale hatten Kunden, bevor sie abgewandert sind? Das Ergebnis ist ein berechneter Wert je Kunde, ein sogenanntes Predictive Attribute. Dieser Wert wird als zusätzliche Spalte im Kundenmodell abgelegt und steht damit sofort für Segmentierung und Aktivierung bereit – ohne Datenexport, ohne Medienbruch.
Das Marketing kann dann etwa ein Segment „Kunden mit hohem Abwanderungsrisiko und überdurchschnittlichem Wert“ bilden und per Reverse ETL gezielt in eine Rückgewinnungskampagne aktivieren. Weil Roh-, Modell- und Vorhersagedaten alle im selben System liegen, ist der Weg von der Analyse zur Handlung kurz. Genau diese Nähe zwischen Data Science und Aktivierung ist ein Kernargument für den composable Ansatz.
Ein zweiter, jüngerer Effekt betrifft die generative KI. Weil die Modellierung in einer Composable CDP wesentlich in SQL geschieht, profitieren Teams unmittelbar von KI-Assistenten, die SQL erklären, generieren und prüfen. Fachbereiche, die früher jede Segmentabfrage vom Data-Team schreiben lassen mussten, können mit KI-Unterstützung mehr selbst formulieren – wobei die fachliche Kontrolle und Freigabe beim Data-Team bleiben sollte. Das senkt die Einstiegshürde in die Modellierungsschicht spürbar.
Wir raten allerdings zur Nüchternheit: KI beschleunigt die Arbeit an einer Composable CDP, sie ersetzt aber weder ein sauberes Datenmodell noch das fachliche Verständnis, welche Vorhersage überhaupt geschäftlich sinnvoll ist. Ein präzise berechnetes Abwanderungsrisiko nützt wenig, wenn niemand definiert hat, welche Maßnahme daraus folgen soll. KI ist ein Werkzeug in der Composable CDP – kein Ersatz für die Strategie dahinter.
Man kann sich das Ökosystem als vier Ringe rund um das Warehouse vorstellen: die Datensammler, die das Warehouse füllen; das Warehouse selbst; die Modellierungs- und Audience-Werkzeuge, die Profile formen; und die Aktivierungswerkzeuge, die die Daten hinaustragen. In jedem Ring gibt es etablierte Kategorien, aus denen sich eine konkrete Composable CDP zusammensetzen lässt.
Die Werkzeugklasse, die die Composable CDP erst ermöglicht, ist der Reverse-ETL-Dienst. In dieser Kategorie haben sich mehrere spezialisierte Anbieter etabliert; einige davon behandelt die INAGRO-Wissensdatenbank in eigenen Fachartikeln – etwa Hightouch, Census und Polytomic. Diese Werkzeuge unterscheiden sich in Details wie der Bandbreite der unterstützten Ziele, der Art der fachlichen Oberfläche und der Betriebssicherheit, verfolgen aber alle dieselbe Grundidee: das Warehouse aktivierbar zu machen.
Daneben gibt es Anbieter, die aus der klassischen Datensammlung kommen und ihre Plattformen um warehouse-native Betriebsarten erweitert haben – etwa Segment oder RudderStack, ebenfalls mit eigenen Artikeln in dieser Kategorie. Sie zeigen, dass die Grenze zwischen „Datensammler“ und „Aktivierer“ zunehmend verschwimmt und viele Werkzeuge mehrere Ringe des Ökosystems abdecken.
Der Wert einer Composable CDP bemisst sich letztlich an der Breite und Qualität ihrer Aktivierungsziele. Typische Ziele sind Werbeplattformen (für Zielgruppen-Aussteuerung und Ausschlusslisten), E-Mail- und Marketing-Automatisierungssysteme (für personalisierte Strecken), CRM-Systeme (damit der Vertrieb dieselben Segmente sieht) sowie Support- und Analyse-Werkzeuge. Je mehr dieser Ziele ein Reverse-ETL-Dienst sauber bedient, desto vollständiger wird die Composable CDP.
Für den Mittelstand ist dabei weniger die schiere Zahl der möglichen Ziele entscheidend als die Frage, ob die eigenen, tatsächlich genutzten Kanäle zuverlässig unterstützt werden. Ein Werkzeug mit Hunderten Zielen nützt wenig, wenn ausgerechnet das im Haus verwendete E-Mail-System schlecht angebunden ist. Die Auswahl sollte deshalb immer von der vorhandenen Kanallandschaft aus gedacht werden, nicht von der Feature-Liste des Anbieters.
Die Composable CDP spielt ihre Stärken aus, wenn ein Unternehmen bereits in ein Warehouse investiert hat, ein Data-Team betreibt und Wert auf Datenhoheit legt. In dieser Konstellation wäre eine paketierte CDP ein Rückschritt: Sie würde ein zweites Silo schaffen, die vorhandene Datenkompetenz umgehen und die Kontrolle über das Datenmodell aus der Hand geben. Auch für datenschutzsensible Branchen, die genau steuern wollen, wo und wie Kundendaten verarbeitet werden, ist der Ansatz oft die überzeugendere Wahl.
Ein weiterer Gewinnfall ist die schrittweise Modernisierung: Unternehmen, die ihre Marketing-Datenlandschaft ohnehin um das Warehouse herum neu ordnen, können die Composable CDP baustein-für-baustein einführen, statt eine große Plattform in einem Zug einzukaufen. Das senkt Risiko und Anfangsinvestition und erlaubt es, mit einem einzigen, klar umrissenen Anwendungsfall zu starten.
Umgekehrt ist die paketierte CDP nicht überholt. Für ein Marketing-Team ohne eigenes Warehouse und ohne Data-Team ist sie oft der schnellere und sicherere Weg zu einem ersten vollständigen Kundenprofil. Wer in wenigen Wochen startklar sein muss, ohne zuvor eine Datenplattform aufzubauen, ist mit einer fertigen Lösung meist besser bedient. Auch für bestimmte Echtzeit-nahe Anwendungsfälle mit sehr niedrigen Latenzanforderungen kann eine paketierte, darauf spezialisierte Plattform der einfachere Weg sein.
Die ehrliche Antwort lautet auch hier: Es kommt auf die Datenreife an. Die Composable CDP ist kein universeller Fortschritt, sondern der bessere Ansatz für Organisationen, die bereit sind, mehr Verantwortung für ihre Daten zu übernehmen. Für alle anderen bleibt der paketierte Weg – zumindest als Einstieg – legitim und oft wirtschaftlich.
In unseren Projekten hat sich ein schrittweises Vorgehen bewährt, das mit einem einzigen, klar umrissenen Anwendungsfall startet und von dort ausbaut. Der häufigste Fehler ist der umgekehrte Weg: erst alle Werkzeuge kaufen, dann überlegen, was man damit tun will. Wer stattdessen vom Anwendungsfall her denkt, hält Aufwand und Risiko klein und zeigt schnell einen greifbaren Nutzen.
Drei Voraussetzungen entscheiden über den Erfolg. Erstens ein tragfähiges Data Warehouse oder Lakehouse, in dem die relevanten Kundendaten bereits liegen oder verlässlich landen können. Zweitens eine ausreichende Datenqualität – Identitätsauflösung setzt voraus, dass sich Datensätze überhaupt verknüpfen lassen; „Müll rein, Müll raus“ gilt hier besonders. Drittens ein handlungsfähiges Data-Team, das SQL beherrscht und die Modellierung dauerhaft pflegen kann.
Fehlt eine dieser Voraussetzungen, ist das kein Ausschlusskriterium, aber eine ehrliche Ansage: Dann ist zunächst am Fundament zu arbeiten. Manchmal ist der richtige erste Schritt zur Composable CDP gar keine CDP, sondern die Konsolidierung der Kundendaten im Warehouse. Diese Vorarbeit zahlt ohnehin auf viele andere Digitalvorhaben ein.
Weil in der Composable CDP alle Definitionen im Warehouse und als Code vorliegen, lässt sich Governance sauberer umsetzen als in vielen geschlossenen Plattformen. Zugriffsrechte, Datenherkunft, Löschregeln und die Definition, was ein „aktiver Kunde“ ist, liegen an einem Ort und folgen den Standards, die das Unternehmen für seine Daten ohnehin definiert hat. Das erleichtert Nachvollziehbarkeit, Prüfungen und die Zusammenarbeit zwischen Fachbereich und Datenschutz.
Damit diese Stärke trägt, braucht es allerdings klare Zuständigkeiten: Wer darf Segmente definieren, wer gibt sie frei, wer verantwortet die Aktivierung in welchem Kanal? Diese organisatorische Klarheit ist ebenso wichtig wie die Technik – und in der Praxis der häufigere Engpass. Der Betrieb einer Composable CDP ist deshalb immer auch eine Frage der Zusammenarbeit zwischen Marketing, Data-Team und Datenschutz.
Viele Mittelständler haben in den letzten Jahren still und leise ein Cloud-Warehouse eingeführt – oft zuerst fürs Reporting, für ein Management-Dashboard oder für die Zusammenführung von Shop- und Warenwirtschaftsdaten. Genau diese Unternehmen sitzen, ohne es zu wissen, auf dem Fundament einer Composable CDP. Für sie ist der Ansatz oft näher und günstiger, als sie vermuten, weil der teuerste Baustein – die zentrale Datenschicht – bereits steht.
Der Ansatz lohnt sich, wenn drei Dinge zusammenkommen: Es existiert ein genutztes Warehouse, es gibt zumindest eine Person oder ein kleines Team mit SQL- und Datenkompetenz, und das Marketing hat konkrete Aktivierungswünsche, die über einfache Newsletter-Verteiler hinausgehen. In dieser Konstellation kann ein mittelständisches Unternehmen mit einem einzigen Reverse-ETL-Baustein und einem klar umrissenen Anwendungsfall starten – etwa der Aussteuerung von Bestandskunden-Segmenten in die Werbeplattformen – und von dort organisch wachsen.
Besonders attraktiv ist der schlanke Einstieg: Anders als eine große Paketplattform verlangt die Composable CDP keine umfassende Vorabinvestition. Man ergänzt das vorhandene Warehouse um genau den einen fehlenden Baustein und erweitert erst, wenn der Nutzen erwiesen ist. Für die knappen Budgets und die pragmatische Kultur des Mittelstands passt dieses „klein anfangen, gezielt wachsen“ oft besser als ein großer Plattformkauf.
Ebenso ehrlich ist die Gegenseite: Ein Mittelständler ohne Warehouse, ohne Datenkompetenz und mit überschaubaren Aktivierungsanforderungen ist mit einer Composable CDP überfordert. Hier würde der Ansatz Aufwand erzeugen, bevor er Nutzen stiftet. In solchen Fällen ist entweder eine schlankere paketierte Lösung der bessere Einstieg – oder, häufig sinnvoller, der erste Schritt ist gar keine CDP, sondern der Aufbau einer sauberen Datenbasis.
Auch wer sehr schnell und ohne jede interne Datenarbeit ein vollständiges Kundenprofil braucht, sollte den composable Weg nicht erzwingen. Die Composable CDP belohnt Datenreife; sie erzeugt sie nicht. Der ehrlichste Rat aus unserer Praxis lautet deshalb: Prüfen Sie zuerst den Reifegrad Ihrer Datenlandschaft – die Architekturentscheidung folgt daraus fast von selbst.
Bei den Kosten unterscheidet sich die Composable CDP grundlegend von der paketierten Welt. Statt einer einzelnen Plattformlizenz entstehen mehrere Kostenblöcke, die zusammen betrachtet werden müssen: der Betrieb des Warehouses (Speicher und Rechenleistung), die Lizenz für den oder die Reverse-ETL-Dienste, gegebenenfalls Werkzeuge für Ingestion und Modellierung sowie der Personalaufwand für Aufbau und Pflege. Wir nennen bewusst keine konkreten Zahlen – sie hängen zu stark von Datenvolumen, Anzahl der Ziele und interner Kompetenz ab, als dass eine Pauschalangabe seriös wäre.
Wichtiger als jede Zahl ist das Verständnis der Kostenhebel. Der zentrale Vorteil: Weil das Warehouse ohnehin für Reporting und Analyse betrieben wird, verteilt sich sein Kostenblock auf viele Anwendungsfälle – die CDP „mietet“ gewissermaßen eine bereits bezahlte Infrastruktur mit. Statt für ein zweites, dediziertes CDP-Datensilo zu zahlen, nutzt man die vorhandene Datenschicht doppelt. Der zusätzliche Kostenblock beschränkt sich im Kern auf die Aktivierungswerkzeuge und den Betriebsaufwand.
Dem steht der reale Personalaufwand gegenüber: Die Composable CDP verlagert Arbeit von der eingekauften Plattform ins eigene Data-Team. Wo eine paketierte CDP viele Funktionen fertig mitbringt, muss hier modelliert, konfiguriert und überwacht werden. Ob der Ansatz günstiger ist, hängt deshalb stark davon ab, ob diese Datenkompetenz ohnehin vorhanden ist. Ist sie es, ist die Composable CDP oft die wirtschaftlichere Wahl; muss sie erst aufgebaut werden, verschiebt sich die Rechnung. Eine ehrliche Gesamtkostenbetrachtung berücksichtigt beide Seiten – Lizenzen und Personal.
Beim Datenschutz spielt die Composable CDP ihre vielleicht stärkste Karte aus. Weil die Kundendaten im eigenen Warehouse bleiben und nicht in eine fremde Plattform kopiert werden, behält das Unternehmen die volle Kontrolle über Speicherort, Zugriffsregeln und Verarbeitung. Es entsteht kein zweiter Ort, an dem personenbezogene Daten liegen und für den separate Verträge, Prüfungen und Löschprozesse nötig wären. Diese Vermeidung eines zusätzlichen Datensilos ist aus Datenschutzsicht ein echter, struktureller Gewinn.
Konkret lässt sich das Warehouse in einer EU-Region betreiben, sodass die zentrale Kundendatenschicht innerhalb der Europäischen Union verbleibt. Löschbegehren, Auskunftsrechte und Zugriffsbeschränkungen greifen an genau einer Stelle – dem Warehouse –, statt über mehrere Systeme hinweg koordiniert werden zu müssen. Auch die Aktivierung lässt sich datensparsam gestalten: Über Reverse ETL werden nur die tatsächlich benötigten Attribute in ein Zielsystem übertragen, nicht der gesamte Datensatz.
So überzeugend das Datenhoheits-Argument ist – es entbindet nicht von sorgfältiger Prüfung jedes einzelnen Bausteins. Reverse-ETL-Dienste, Ingestion-Werkzeuge und Zielsysteme verarbeiten teils ebenfalls personenbezogene Daten und benötigen entsprechende Verträge zur Auftragsverarbeitung sowie eine Bewertung möglicher Drittlandübermittlungen. Der Vorteil der Composable CDP ist, dass diese Prüfung auf klar abgegrenzte, austauschbare Bausteine begrenzt bleibt – nicht, dass sie entfällt.
