Composable-CDP nativ in Snowflake: mehr als nur Zero Copy

Zwei Wege zur gleichen Customer Data Platform (CDP)

Composable-CDPs sind seit einigen Jahren der Gegenentwurf zur klassischen „Packaged“-Lösung: Statt Kundendaten in eine weitere, proprietäre Datenbank zu kopieren, arbeitet die CDP direkt auf dem Data Warehouse des Unternehmens, bei den meisten ist das in der Regel Snowflake, BigQuery oder Databricks. Snowflake hat sich dabei zu einem bevorzugten Anbieter entwickelt, auf dem CDP-Anbieter zunehmend unterschiedlich tief integriert sind.

Worin sich die beiden Ansätze unterscheiden, wollen wir einmal am Beispiel von Zeotap, der europäischen Composable-CDP mit deutscher DNA, aufzeigen. Zeotap bietet inzwischen zwei Betriebsmodelle für dieselbe Plattform an: als Native App direkt im Snowflake-Account des Kunden oder als SaaS-Lösung, die aus der eigenen Google-Cloud-Umgebung(GCP) per Zero-Copy auf die Snowflake-Daten zugreift. Beide Varianten basieren auf derselben Codebasis, identischer Produktlogik und mit gleicher Identity Resolution Engine, Segmentierung und Journey-Orchestrierung. Sie unterscheiden sich aber deutlich darin, wo diese Logik ausgeführt und wie auf die Daten zugegriffen wird – und damit auch in Beschaffung, Governance und strategischer Bindung. Diese Unterschiede sollte man kennen, bevor man sich für eine CDP-Architektur entscheidet.

Packaged, Composable: zwei Betriebsmodelle einer CDP

Eine klassische Packaged-CDP kopiert Kundendaten vollständig in die eigene, meist proprietäre, Cloud-Umgebung, des Anbieters. Eine Composable-CDP mit Zero-Copy-Zugriff verzichtet je nach Use Case auf diese Kopie und liest beziehungsweise schreibt stattdessen direkt im Warehouse des Kunden. Die eigenen CDP-Prozesse aus Job-Steuerung, Identity-Resolution-Engine und Data Event Stream behält die CDP aber typischerweise in der eigenen SaaS-Umgebung. Ein nativer Composable-CDP-Ansatz geht noch einen Schritt weiter: Er verlagert nicht nur die Daten, sondern auch die komplette Kontrollebene in den Account des Kunden, bei Snowflake technisch über sogenannte Native Apps auf Basis von Snowpark Container Services.

Zeotap fasst diese Wahlfreiheit unter dem Begriff „InfraFlex“ zusammen: Kunden entscheiden sich für dasselbe Produkt, aber für unterschiedliche Betriebsmodelle, je nachdem, was für sie wichtiger ist: IT-Eleganz und Compliance oder maximale Warehouse-Unabhängigkeit.

Architektur A: Zeotap nativ in Snowflake

Läuft Zeotap als Native App, wird die komplette Plattform innerhalb des Snowflake-Accounts des Kunden ausgeführt: Identity Resolution, Profilbildung, Segmentierung, Journey-Orchestrierung und die KI-Agenten-Funktionen eingeschlossen. Bei dem Ansatz wandert nicht nur die Rechenlast, sondern die gesamte Kontrollebene inklusive Job-Steuerung, Secrets und Metadaten-Speicher ins Kundenkonto. Das ist ein deutlich konsequenterer Schritt als bei Wettbewerbern, die bislang nur Teilfunktionen nativ betreiben.

Vorteile auf einen Blick

• Schnellere Beschaffung: Snowflake ist bei den meisten Kunden bereits von Compliance und InfoSec freigegeben, sodass aus „wir prüfen einen neuen Anbieter“ ein „wir aktivieren ein zusätzliches Modul“ wird. Zeotap selbst spricht davon, Beschaffungszyklen von Quartalen auf Tage zu verkürzen. Das ist besonders relevant in regulierten Branchen wie Banking, Versicherung, Telekommunikation oder Gesundheitswesen.
• Kein Datentransit: Der bei externen Aktivierungen sonst übliche kurze Datendurchlauf durch die Systeme des Anbieters entfällt vollständig, weil keine Kontogrenze mehr überschritten wird.
• Geerbte Governance: Row-Access-Policies, Masking und rollenbasierte Zugriffsrechte gelten automatisch auch für die CDP, statt in einem zweiten System nachgebaut werden zu müssen.
• Einkaufssynergie: Der Verbrauch läuft über die bestehende Snowflake-Rechnung und zählt häufig auf laufende Spend Commitments ein.

Das gilt es zu bedenken

• Engere Cloud-Bindung: Wer sich noch nicht endgültig für Snowflake entschieden hat oder mehrere Warehouses parallel betreibt, gibt architektonische Flexibilität auf.
• Unabhängigkeitsfrage: Wenn ein Hyperscaler einen CDP-Anbieter so eng in die eigene Plattform einbindet, wie es bei Snowflake und Zeotap der Fall war, stellt sich die berechtigte Frage nach der Unabhängigkeit der Produkt-Roadmap. Außerdem wird es schwieriger, Kosten anbieterübergreifend zu vergleichen, wenn der Verbrauch in derselben Rechnung aufgeht.
• Warehouse-Reife vorausgesetzt: Governance-Lücken im Snowflake-Setup des Kunden wirken sich unmittelbar auf die CDP aus.
• Echtzeit bleibt Echtzeit: Auch „nativ“ heißt nicht, dass jede Anfrage live gegen das Warehouse läuft. Für low-latency (weniger als eine Sekunde) Use Cases wie Website-Personalisierung hält auch Zeotap weiterhin eine performante Cache-Schicht vor.

Architektur B: Zeotap extern (GCP) mit Zero-Copy-Zugriff

Läuft Zeotap dagegen als reguläre SaaS-Lösung (standardmäßig in der eigenen Google-Cloud-Umgebung), greift die Plattform per Zero-Copy auf die Daten im Warehouse zu, unabhängig davon, ob dieses auf Snowflake, BigQuery oder Databricks liegt. Ein kurzer Datendurchlauf entsteht nur im Moment der Aktivierung, wenn eine Audience über den Zeotap-eigenen Connector an einen Kanal ausgespielt wird.

Vorteile auf einen Blick

• Volle Warehouse-Agnostik: Dieselbe Architektur funktioniert unverändert für Snowflake-, BigQuery- oder Databricks-Kunden. Das ist relevant, wenn die Data-Cloud-Strategie noch nicht final entschieden ist oder mehrere Plattformen parallel im Einsatz sind.
• Schnellere Produktzyklen: Weil die Kontrollebene außerhalb der einzelnen Kundenaccounts liegt, kann der Anbieter neue Features einheitlicher ausrollen, statt sie in jedem Account einzeln zu aktualisieren.
• Single Source of Truth bleibt erhalten: Die Daten liegen weiterhin im Warehouse, auch wenn für Performance-Zwecke einzelne Ausschnitte zwischengespeichert werden.
• Passt zu Systempurismus: geeignet für Unternehmen, die bewusst eine klare Trennung zwischen Datenhaltung und Applikationslogik bevorzugen.

Das gilt es zu bedenken

• Minimaler Datentransit: technisch vorhanden, in der Praxis aber meist unkritisch. Für besonders strenge Compliance-Anforderungen kann er dennoch ein Ausschlusskriterium sein.
• Doppelte Governance-Pflege: Zugriffsregeln müssen zusätzlich im externen System gepflegt oder gespiegelt werden, statt automatisch geerbt zu werden.
• Physikalische Grenzen bei Echtzeit: reine Zero-Copy-Logik stößt bei Echtzeitanforderungen an ihre Grenzen. Auch hier bleibt ein lokaler Cache notwendig.

Wann passt welche Architektur?

In der Praxis entscheiden meist vier Fragen, welches Modell zu einem Unternehmen passt:

1. Wie reif ist das Data Warehouse des Kunden? Nur ein klar strukturiertes Snowflake-Setup mit sauberer Governance lässt eine native Integration ihre Vorteile wirklich ausspielen. Schwächen im Warehouse werden sonst eins zu eins in die CDP übernommen.
2. Ist die Data-Cloud-Entscheidung strategisch und auf Dauer angelegt? Wer sich klar und langfristig für Snowflake entschieden hat, profitiert am meisten von der nativen Variante. Wer noch mehrgleisig fährt oder die Warehouse-Wahl bewusst offenhalten will, ist mit der warehouse-agnostischen Zero-Copy-Variante besser beraten.
3. Wie kritisch sind Compliance- und Data-Residency-Anforderungen? Muss aus regulatorischen Gründen sichergestellt sein, dass Daten den eigenen Account nie verlassen, spricht das klar für die native Integration. In allen anderen Fällen ist der minimale Transit bei der Aktivierung meist zulässig.
4. Unabhängig von der gewählten Architektur bleibt eine Einschränkung bestehen: Für harte Echtzeitanforderungen braucht es in beiden Modellen eine zwischengespeicherte, nicht mehr Zero-Copy-reine Schicht nah an der Anwendung. Das ist keine Schwäche der einen oder anderen Architektur, sondern schlicht eine physikalische Grenze von Zero-Copy-Zugriffen.

Der Beschaffungsvorteil:

Für Unternehmen, die Zeotap einsetzen wollen und bereits Snowflake-Kunde sind, bringt der Bezug über den Snowflake-Marktplatz sowohl finanzielle als auch organisatorische Vorteile mit sich: Die Software gilt intern bereits als freigegeben, wodurch sich Sicherheits- und Compliance-Prüfungen auf ein Minimum reduzieren. Die Kosten erscheinen konsolidiert auf der ohnehin vorhandenen Snowflake-Rechnung und lassen sich in vielen Fällen auf bestehende Spend Commitments anrechnen. Das kommt Einkaufsabteilungen entgegen und vereinfacht Budgetgespräche. Wer eine Software ohnehin über einen bestehenden Vertragsrahmen bezieht, reduziert zudem die Zahl der Lieferanten- und Vertragsbeziehungen, die separat verwaltet werden müssen.

Diesen Vorteilen sollte allerdings die zuvor genannte Kehrseite gegenübergestellt werden: Konzentriert sich ein wachsender Teil der MarTech-Ausgaben auf die Snowflake-Rechnung, wird ein Vergleich der tatsächlichen CDP-Kosten über Anbieter hinweg schwieriger. Auch die Verhandlungsposition gegenüber einzelnen Anbietern kann sich verschieben, wenn die kommerzielle Beziehung stärker über die Data-Cloud-Plattform läuft als über den CDP-Anbieter selbst.