Snowflake im Commerce: Vom Datensilo zur gemeinsamen Architektur

Commerce-Daten leben in Silos. Der Shop kennt die Bestellung, das ERP kennt die Lieferung, das CRM kennt den Ansprechpartner, der Marketing-Stack kennt die Kampagne, das Service-Tool kennt den Fall — und jede dieser Welten hat eine eigene Definition davon, was "Kunde" und "Umsatz" eigentlich bedeuten. Aus Sicht von CDOs und CIOs wird das spürbar, sobald CLV-Reports, Margenanalysen und Kampagnen-ROI nebeneinanderliegen und sich gegenseitig widersprechen. Eine Data Foundation auf Snowflake mit dbt-Modellierung ist die Antwort, die wir in den letzten Jahren in DACH-Commerce-Projekten am häufigsten gebaut haben — weil sie genau diesen Widerspruch auflöst, ohne dass das Operating Model umgebaut werden muss. Dieser Beitrag zeigt, warum Commerce-Daten fragmentiert sind, was sich mit einer gemeinsamen Architektur ändert und wie Snowflake sich von BigQuery, Databricks und Redshift abgrenzt.

Die Datenlandschaft im Commerce ist über Jahre gewachsen, nicht entworfen. Typisch sehen wir bei Retailern und Industrie-Herstellern fünf bis sieben operative Systeme, von denen jedes für sich gut funktioniert, aber kein gemeinsames Datenmodell teilt: Shop-Plattform (Shopware, commercetools, Spryker), ERP (SAP S/4HANA, Microsoft Dynamics, Infor), CRM (Salesforce, HubSpot, Dynamics 365), Marketing-Stack (Klaviyo, Emarsys, Adobe Campaign), Service-Tool (Zendesk, Salesforce Service Cloud), PIM und in vielen Fällen ein Subscription- oder Loyalty-System.

Jedes dieser Systeme schreibt seine eigene Wahrheit. Der Shop schließt eine Bestellung mit Brutto-Umsatz ab; das ERP verbucht sie netto, mit Rabatten, Storno- und Retourpositionen; das CRM kennt nur das Kontaktereignis. Die Folge ist nicht nur ein Reporting-Problem — sie ist ein Definitions-Problem. Marketing optimiert auf Brutto-Umsatz, Controlling rechnet mit Netto-Marge, Vertrieb misst Pipeline. Drei Säulen, drei Wahrheiten.

Dazu kommt das Identitäts-Problem. Im B2C heißt ein Kunde in fünf Systemen oft fünfmal anders — Gast-Bestellung im Shop, eMail-Hash im Marketing-Stack, Kundennummer im ERP, Account im CRM, Ticket-ID im Service. Im B2B wird es komplexer: Buying Center, Mehr-Niederlassungs-Strukturen und kontraktbasierte Sortimente bedeuten, dass ein "Kunde" auch eine Hierarchie sein kann. Wer CLV ohne saubere Identity-Resolution rechnet, summiert systematisch falsch.

Solange diese Systeme nur untereinander Daten austauschen — Punkt-zu-Punkt-Integrationen, nächtliche Exporte, BI-Tools mit eigenen Connectoren — wächst die Komplexität quadratisch. Jede neue Quelle bedeutet n neue Verbindungen. Eine gemeinsame Datenebene reduziert diese Komplexität auf 1:n.

Snowflake ist eine Cloud-Datenplattform mit getrennter Compute- und Storage-Architektur: Daten liegen einmal, Workloads laufen in unabhängigen Virtual Warehouses. Das ist die technische Voraussetzung dafür, dass Marketing, Controlling, Data Science und BI gleichzeitig auf demselben Datenbestand arbeiten können, ohne sich gegenseitig zu blockieren. dbt (data build tool) ergänzt diese Plattform um eine deklarative Modellierungsschicht in SQL — versionierbar in Git, mit Tests, Lineage und Dokumentation.

In foobar-Projekten arbeiten wir mit vier Schichten, die sich in der dbt-Community als Standard etabliert haben:

- raw — die unveränderten Ingestion-Tabellen aus den Quellsystemen, beladen über Connectoren wie Fivetran, Airbyte oder Snowpipe. - staging — typisierte, umbenannte, eindeutig referenzierte Versionen der Quelltabellen. Eine staging-Schicht pro Quellsystem. - intermediate — Joins, Identity-Resolution, Business-Logik, die noch nicht reportingfähig ist, aber als Baustein wiederverwendet wird. - marts — fachliche Modelle nach Domäne: `marts.commerce`, `marts.marketing`, `marts.finance`. Hier liegen die Tabellen, auf denen Dashboards und KI-Modelle aufsetzen.

Diese Schichtung ist konzeptionell nah an der "Bronze/Silver/Gold"-Logik aus dem Databricks-Lakehouse-Vokabular, in der dbt-Welt sind die Begriffe raw/staging/intermediate/marts üblicher. Inhaltlich gleich, terminologisch sauberer für ein Snowflake-Setup.

Was sich konkret ändert, sobald diese Foundation steht: CLV, Umsatz und Marge haben genau eine Definition. Die `dim_customer`-Tabelle in `marts.commerce` ist die Single Source of Truth — Marketing-Automation, Service-Routing, Forecasting und Vorstand-Reporting ziehen aus derselben Quelle. Metriken werden in dbt einmal definiert und überall identisch konsumiert. Diskussionen darüber, wessen Zahl stimmt, hören nicht auf, weil Menschen anders rechnen — sie hören auf, weil das Modell verbindlich ist.

Eine Commerce-Data-Foundation auf Snowflake lässt sich in drei Spalten denken — Quellen links, Snowflake-Schichten in der Mitte, Anwendungen rechts. Auf der Quellen-Seite stehen Shop, ERP, CRM, Marketing-Stack, Service und PIM. Über Connectoren landen ihre Tabellen in `raw` — als rohe, schemastabile Spiegelung der Quelle, idealerweise mit Change-Data-Capture, damit Veränderungen und nicht nur Endstände ankommen.

In der Mitte modelliert dbt die staging-Schicht (Typisierung, Umbenennung), die intermediate-Schicht (Joins, Identity-Resolution, Sessionizing) und die marts-Schicht (Dimensionen und Fakten je Domäne). Hier entstehen die zentralen Tabellen: `dim_customer`, `dim_product`, `fct_orders`, `fct_marketing_touchpoints`, `fct_service_cases`. dbt-Tests überwachen Eindeutigkeit, Vollständigkeit, Wertebereiche; die generierte Dokumentation zeigt, woher jede Spalte stammt.

Auf der Anwendungs-Seite konsumieren vier typische Zielgruppen das gleiche Datenmodell: BI-Tools (Looker, Tableau, Power BI) für Reporting; Marketing-Automation für Segmente und Kampagnen; Operations und Service für Echtzeit-Lookups; Data Science für Modelle wie CLV, Churn und Next-Best-Action. Snowflake Cortex ergänzt diese Schicht um native ML- und LLM-Funktionen, die direkt auf den modellierten Tabellen arbeiten — ohne Daten in eine separate ML-Plattform exportieren zu müssen.

Diese Architektur ist nicht spektakulär. Sie ist verankert in den Geschäftsprozessen, vernetzt zwischen Commerce und Intelligence-Layer und vorausgedacht, weil neue Quellen oder Anwendungen sich an die Foundation anhängen, statt einen weiteren Punkt-zu-Punkt-Connector zu erzeugen.

Die Frage, welche Plattform die richtige ist, lässt sich nicht aus dem Stand beantworten. Sie hängt an drei Kriterien, die wir in Architektur-Workshops konsequent durchgehen.

Erstens: Multi-Cloud. BigQuery ist eng an Google Cloud gebunden, Redshift an AWS, Azure Synapse an Microsoft. Snowflake läuft nativ auf AWS, Azure und GCP — derselbe Account kann Workloads auf verschiedenen Cloud-Providern haben. Für DACH-Konzerne mit hybriden Cloud-Strategien (z. B. SAP-Welt auf Azure, Analytics auf AWS) ist das ein realer Unterschied. Databricks ist ebenfalls Multi-Cloud, aber funktional ein Lakehouse, kein klassisches Warehouse — die Stärken liegen bei Streaming, Spark-Workloads und ML-Plattformen.

Zweitens: Workload-Trennung. Snowflakes getrennte Virtual Warehouses bedeuten, dass ein BI-Dashboard, ein nightly dbt-Run und ein ad-hoc Data-Science-Notebook unabhängig voneinander skalieren. Bei BigQuery teilen sich Slots; bei Redshift skaliert man Cluster oder nutzt Serverless. Wer viele konkurrierende Workloads hat — Reporting, Marketing-Automation, Forecasting, ML-Training — bekommt mit Snowflake die einfachste Isolation.

Drittens: Data Sharing. Snowflake teilt Daten Account-übergreifend, ohne sie zu kopieren. Im Commerce-Kontext heißt das: Lieferanten-Daten, POS-Daten von Filialpartnern oder Marktforschungs-Quellen können live eingebunden werden. Für Retailer mit Marktplatz-Strategien oder Industrie-Hersteller mit Händlernetz ist das eine Funktion, die in BigQuery (Analytics Hub) und Databricks (Delta Sharing) zwar Pendants hat, in Snowflake aber am längsten ausgereift ist.

Keines dieser Argumente macht Snowflake universell zur richtigen Wahl. Aber sie sind die drei Fragen, an denen sich Entscheidungen meistens belastbar festmachen lassen.

Ein Multi-Channel-Händler aus dem DACH-Raum mit eigener TV-, Online- und App-Präsenz hat mit foobar Agency eine Customer-Lifetime-Value-Prediction auf Snowflake mit dbt umgesetzt. Die Ausgangslage war typisch: Bestelldaten im ERP, Kontaktereignisse in mehreren Marketing-Tools, Stammdaten im CRM, Kundenservice-Daten in einem dritten System. Eine konsistente Aussage über Kundenwert war über Reports hinweg nicht herstellbar.

Die Foundation entstand in drei Schritten. Erstens: Identity-Resolution. Bestellungen, Kontaktpunkte und Service-Fälle wurden über deterministische Schlüssel (Kundennummer, Hash-eMail, Telefonnummer) und probabilistische Fallbacks zu einer eindeutigen `dim_customer`-Identität zusammengeführt. Zweitens: RFM-Berechnung. Auf der Fakten-Tabelle `fct_orders` werden in dbt Recency, Frequency und Monetary Value pro Kunde berechnet — deterministisch, nachvollziehbar, mit dbt-Tests gegen Definitions-Drift abgesichert. Drittens: Probabilistische CLV-Prediction. Auf Basis der RFM-Features läuft ein Modell der BG/NBD- und Gamma-Gamma-Familie, das die erwartete Anzahl und den erwarteten Wert zukünftiger Käufe pro Kunde schätzt.

Das Ergebnis ist nicht ein Dashboard, sondern eine Tabelle: `marts.commerce.customer_clv` enthält für jeden Kunden einen Recency-Wert, ein RFM-Segment, einen historischen Wert und eine probabilistische Vorhersage. Marketing nutzt sie für Segmente und Aussteuerung, Service nutzt sie für Eskalations-Routing, Controlling nutzt sie für Kohorten-Reporting. Dieselbe Tabelle, dieselbe Definition — kein Datenbank-Tourismus mehr zwischen den Teams. Wie die RFM-basierte CLV-Logik im Detail funktioniert und warum sie probabilistischen Modellen den Vorzug vor reinen ML-Black-Boxes gibt, behandelt Post 2 dieser Serie.