Data Warehousing für smarte Marketing Automation: von vier Tools zu einem Kunden

Jedes Tool kennt ein Stück vom Kunden, keins kennt ihn ganz

Wachsende Onlineshops landen fast immer beim selben Aufbau. Der Shop weiß, wer was gekauft hat. Das E Mail Tool weiß, wer welche Mail geöffnet hat. Google Ads weiß, was jede Kampagne gekostet hat, Google Analytics, welche Seiten jemand besucht hat. Jedes macht seine eigene Arbeit gut und sieht von den anderen nichts.

Das geht so lange gut, bis eine Frage zwei davon berührt. Welche Kunden aus der Frühjahrskampagne bestellen nicht mehr? Keins der Tools hat beide Hälften, also kommt die Antwort von jemandem, der am Freitagnachmittag Tabellen exportiert. Bis sie da ist, ist der richtige Moment zum Handeln vorbei.

Mein Mittel dagegen ist ein Data Warehouse: ein Ort, an dem eine Kopie jeder Quelle nach Zeitplan landet, über den Kunden verknüpft wird und zu Listen wird, die zurück in die Tools fließen, die handeln. In diesem Artikel gehe ich diesen Kreislauf einmal von Anfang bis Ende durch.

Dabei begleitet mich ein erfundenes Unternehmen. Die Auwald Rösterei ist eine Onlinerösterei in Leipzig. Hannah führt sie und verkauft einzelne Tüten Bohnen und ein Monatsabo. Der Shop läuft unter auwaldroesterei.example. Niemand davon ist echt, und jede Zahl unten ist ausgedacht, damit ich jeden Schritt zeigen kann.

Rechenbeispiel: eine Frage, vier Tools

Hannah will wissen, welche Kunden mindestens zweimal gekauft haben, seit sechs Wochen nicht mehr bestellt haben und Werbemails bekommen dürfen. Die Bestellhistorie liegt in der Shopdatenbank. Für die sechs Wochen braucht sie das heutige Datum und die letzte Bestellung jedes Kunden, auch das steht im Shop. Die Erlaubnis für Werbemails liegt im E Mail Tool. Und um zu wissen, ob diese Leute über bezahlte Suche kamen, braucht sie das Kampagnenkennzeichen ihres ersten Besuchs, und das steht in Google Analytics.

Von Hand sind das drei Exporte, ein SVERWEIS zwischen zwei Tabellen über die E Mail Adresse und ein Filter: ungefähr eine Stunde. Sie macht es einmal und dann nie wieder, denn eine Stunde pro Woche ist eine Stunde, die sie lieber am Röster steht. Im Warehouse ist es eine Abfrage, die jeden Morgen von selbst läuft.

Ein Data Warehouse ist eine Datenbank für Fragen, nicht für den Shopbetrieb

Die Datenbank deines Shops ist dafür gebaut, Bestellungen anzunehmen: eine Zeile schnell schreiben, einen Warenkorb zurücklesen. Ein Warehouse ist für das Gegenteil gebaut. Es liest Millionen Zeilen auf einmal, um eine Frage über alle zu beantworten.

Google beschreibt BigQuery als vollständig verwaltetes, serverloses Data Warehouse, bei dem Speicher und Rechenleistung voneinander getrennt sind und unabhängig arbeiten.¹ Auf gut Deutsch: Du betreibst keinen Server, du zahlst für das, was du speicherst, und für das, was deine Fragen lesen, und eine große Abfrage bremst den Speicher nicht aus. Snowflake ist die andere verbreitete Wahl und erledigt dieselbe Aufgabe. Für die meisten kleinen und mittleren Shops nehme ich BigQuery, weil der Export aus Google Analytics dort ohne zusätzliche Leitungen ankommt, deshalb zeige ich es hier. Die Ideen lassen sich fast eins zu eins auf Snowflake übertragen.

Der Kniff, der ein Warehouse schnell macht, heißt spaltenorientierte Speicherung. BigQuery speichert jede Spalte einer Tabelle getrennt, weil eine Analysefrage meist nur wenige von vielen Spalten braucht.² Eine Shopdatenbank legt jede Bestellung als eine Zeile ab, mit allem, was dazugehört, nebeneinander. Ein Warehouse legt alle Bestelldaten zusammen ab, alle Summen zusammen und so weiter. Wer den Umsatz pro Monat wissen will, berührt dann nur zwei Spalten.

Rechenbeispiel: warum zwei Spalten weniger kosten als 30

Die Bestelltabelle der Auwald Rösterei hat 30 Spalten: Bestellnummer, Kunde, Datum, Summe, Lieferadresse und 25 weitere. Angenommen, die ganze Tabelle ist 6 GB groß und, der Einfachheit halber, die Spalten sind ungefähr gleich groß, also jeweils etwa 0,2 GB.

Hannah fragt nach dem Umsatz pro Monat. Dafür braucht sie das Bestelldatum und die Summe, zwei Spalten. Ein zeilenorientierter Speicher muss ganze Zeilen lesen, also liest er alle 6 GB. Ein spaltenorientierter liest zwei Spalten zu je 0,2 GB, zusammen 0,4 GB. Das ist ein Fünfzehntel der Daten für dieselbe Antwort, und beim On Demand Preismodell von BigQuery richtet sich die Rechnung nach den gelesenen Bytes.³ Die Lehre daraus ist schlicht: Nenn die Spalten, die du brauchst, und schreib bei einer großen Tabelle nie aus Gewohnheit SELECT *.

Daten hinein: jede Quelle nach Zeitplan kopieren, dann formen

Daten kommen in ein Warehouse, indem sie nach Fahrplan aus jedem Tool kopiert werden. Das übliche Muster heißt ELT (Extract, Load, Transform): die Rohdaten unverändert laden und dann im Warehouse mit SQL (Structured Query Language) bereinigen. Weil die Rohkopie erhalten bleibt, behebst du einen Fehler beim Bereinigen, indem du eine Abfrage neu laufen lässt, und nicht, indem du zurück zur Quelle gehst.

Manche Quellen bringen ihre eigene Leitung mit. Google Analytics 4 kann seine Rohereignisse einmal täglich nach BigQuery exportieren, und Standardproperties können Ereignisse zusätzlich innerhalb weniger Minuten streamen, was Google als Best Effort Dienst ohne Zusage zur Vollständigkeit bezeichnet. Für den täglichen Export gilt bei Standardproperties ein Limit von einer Million Ereignissen pro Tag.⁴ Daten aus Google Ads kommen über einen BigQuery Connector, der höchstens einmal alle 24 Stunden läuft und standardmäßig bei jedem Lauf die letzten sieben Tage neu lädt, weil Werbeplattformen jüngste Zahlen noch nachträglich anpassen.⁵ Für die übrigen Quellen übernimmt ein Connector Tool das Kopieren. Airbyte zum Beispiel ist Open Source und nennt mehr als 600 fertige Connectoren.⁶

Hier ist der ganze Kreislauf, den dieser Artikel aufbaut, von den Quellen bis zu den Aktionen.

Lies es von oben. Jedes Kästchen ist eine Stufe, und der Pfeil heißt, dass die untere Stufe auf die obere wartet. Die Entscheidungsraute ist die Prüfung der Einwilligung, auf die ich gegen Ende zurückkomme. Die Erkenntnis: Das ist ein Kreislauf, keine Linie. Was das E Mail Tool und die Anzeigen heute tun, sind morgen Rohdaten.

Rechenbeispiel: der Ladefahrplan der Auwald Rösterei

Hannahs Aufbau kopiert vier Quellen. Die Shopdatenbank kopiert ein Connector stündlich, weil Bestellungen das sind, worauf es den Segmenten am meisten ankommt. Der tägliche Export aus Google Analytics landet über Nacht, also enthält jeder Morgen die Besuche von gestern. Der Google Ads Connector läuft einmal am Tag und lädt die letzten sieben Tage neu. Öffnungen und Abmeldungen aus dem E Mail Tool werden einmal täglich kopiert.

Die frischeste verlässliche Verknüpfung von Anzeigen, Besuchen und Bestellungen ist also die von gestern. Die alte Fassung dieses Artikels versprach Verknüpfungen "jede Stunde" und Entscheidungen "nahezu in Echtzeit". Mit diesen Quellen geht das nicht: Die Anzeigendaten kommen täglich, und Google Analytics aktualisiert die Tabelle eines Tages noch bis zu drei Tage nach dem Ereignis.⁷ Stündlich ist ehrlich für die eigenen Bestellungen des Shops. Für alles, was Werbekosten berührt, ist täglich die Wahrheit, und für Kaffee reicht täglich völlig.

Ein Kunde, ein Schlüssel: zuerst die Identität klären

Eine Verknüpfung braucht etwas, das beide Tabellen gemeinsam haben. Bei Kunden ist das meist eine E Mail Adresse oder eine Kundennummer. Das Problem: Jedes Tool speichert die Adresse ein bisschen anders. Im Shop steht Hannah.Becker@Example.com mit einem verirrten Leerzeichen, im E Mail Tool hannah.becker@example.com. Für einen Computer sind das zwei verschiedene Menschen.

Deshalb baut die erste bereinigende Abfrage in jedem meiner Aufbauten eine Kundentabelle mit normalisierter E Mail: Leerzeichen an beiden Enden entfernt, alles klein geschrieben. Genau diese Normalisierung verlangt Google, bevor E Mail Adressen für Zielgruppen in Google Ads gehasht werden, dazu komme ich später.⁸ Wer das einmal an einer Stelle erledigt, sorgt dafür, dass jede spätere Abfrage sich einig ist, wer wer ist.

Google Analytics braucht einen eigenen Gedanken. Sein Export enthält eine user_pseudo_id, die beim ersten Besuch vergeben wird, und eine user_id, die nur gefüllt ist, wenn deine Website deine eigene Kundennummer mitschickt.⁷ Besucher, die sich nie anmelden, lassen sich keiner Bestellhistorie zuordnen. Das ist eine Grenze, kein Fehler, und du solltest sie kennen, bevor du irgendwem ein vollständiges Bild versprichst.

Rechenbeispiel: was das Normalisieren bringt

Die Auwald Rösterei hat 4.200 Kunden im Shop. Hannah verknüpft sie über die rohe E Mail mit den Kontakten im E Mail Tool und bekommt 3.100 Treffer. Nach dem Trimmen und Kleinschreiben auf beiden Seiten sind es 3.900. Außerdem prüft sie, wie viele Kunden sich im Export von Google Analytics über die user_id finden lassen, und kommt auf 1.700, weil nur Kunden eine mitschicken, die sich anmelden, um ihr Abo zu verwalten.

Jeder Balken ist ein Weg der Zuordnung. Die senkrechte Achse zeigt den Anteil der 4.200 Shopkunden der Auwald Rösterei, den die Methode findet, von 0 % bis 100 %. Die Erkenntnis: Zwei Zeilen Bereinigung haben die Trefferquote von 74 % auf 93 % gehoben, das sind 800 Kunden, die sonst für jedes Segment unsichtbar gewesen wären. Der Analytics Balken ist von Natur aus niedrig, deshalb baue ich nie ein Segment, das für alle Kunden das Verhalten auf der Website braucht.

Die Verknüpfung, die deinen Umsatz verdoppelt: erst verdichten, dann verknüpfen

Diesen Fehler finde ich in fremden Warehouses am häufigsten, und die alte Fassung dieses Artikels hat ihn auch gemacht. Verknüpfst du zwei Tabellen, die jeweils mehrere Zeilen pro Kunde haben, paart die Datenbank jede Zeile der einen Seite mit jeder Zeile der anderen. Ein Kunde mit drei Bestellungen und zwei Zeilen in einer anderen Tabelle kommt als sechs Zeilen heraus. Summierst du die Bestellsummen über diese sechs Zeilen, zählt jede Bestellung doppelt.

Das alte Beispiel hat außerdem Werbeausgaben über eine User ID mit Kunden verknüpft. Werbeplattformen melden Ausgaben aber nicht pro Person. Der Google Ads Connector bringt Berichte auf Ebene von Kampagne, Anzeigengruppe und Keyword, mit Kosten pro Kampagne und Tag.⁵ "Werbeausgaben pro Kunde über die ganze Kundenbeziehung" ist also keine Spalte, die du einfach dazuholen kannst. Werbekosten treffen Kunden über das Kampagnenkennzeichen ihres ersten Besuchs, auf Kampagnenebene.

Rechenbeispiel: der Kunde mit sechs Zeilen

Nimm einen Kunden der Auwald Rösterei, Jonas. Jonas hat drei Bestellungen: 24 €, 30 € und 36 €, zusammen also 90 €. Außerdem hat er zwei Zeilen in der Tabelle des E Mail Tools, weil er sich über zwei Formulare zweimal angemeldet hat. Eine Abfrage, die Bestellungen mit E Mail Kontakten verknüpft und dann die Summen addiert, liefert:

$$3 \times 2 = 6 \text{ Zeilen}, \quad (24 + 30 + 36) \times 2 = 180$$

Dabei ist $3$ die Zahl von Jonas' Bestellungen, $2$ die Zahl seiner E Mail Zeilen, $6$ die Zahl der Zeilen, die die Verknüpfung erzeugt, und $180$ der summierte Umsatz in Euro, genau das Doppelte der echten 90 €. Es ist schlichte Multiplikation, aber wenn eine Kennzahl, die darauf aufbaut, seltsam hoch aussieht, liegt es meistens daran. Was schiefgeht, wenn der Nenner eines Verhältnisses falsch gezählt wird, steht in Grundlagen: Verhältnisse und Raten.

Die Abhilfe: Bring jede Tabelle vor dem Verknüpfen auf eine Zeile pro Kunde, und nimm einen Left Join, damit Kunden ohne Treffer erhalten bleiben, statt still zu verschwinden:

WITH orders_per_customer AS (
  SELECT customer_id,
         COUNT(*)          AS order_count,
         SUM(total_eur)    AS revenue_eur,
         MAX(order_date)   AS last_order_date
  FROM shop.orders
  GROUP BY customer_id
),
email_per_customer AS (
  SELECT email_normalised,
         LOGICAL_OR(marketing_consent) AS marketing_consent
  FROM email_tool.contacts
  GROUP BY email_normalised
)
SELECT c.customer_id,
       c.email_normalised,
       o.order_count,
       o.revenue_eur,
       o.last_order_date,
       COALESCE(e.marketing_consent, FALSE) AS marketing_consent
FROM core.customers AS c
LEFT JOIN orders_per_customer AS o ON o.customer_id = c.customer_id
LEFT JOIN email_per_customer  AS e ON e.email_normalised = c.email_normalised;

Jetzt ist Jonas eine Zeile mit 90 €, und er gilt nur dann als einverstanden, wenn eine seiner Anmeldungen ja gesagt hat. Die Probe, die ich nach jeder Verknüpfung mache: Zeilen heraus müssen gleich Kunden hinein sein. Wenn nicht, hat sich irgendwo etwas vervielfacht.

Rechenbeispiel: Werbekosten auf Kampagnenebene

Hannah hat im Frühjahr eine Kampagne für sortenreine Bohnen aus einem einzigen Anbaugebiet geschaltet. Laut Google Ads Connector hat sie im April 1.800 € gekostet. Im Analytics Export haben 60 Menschen, deren erster Besuch das Kennzeichen dieser Kampagne trug, im April eine erste Bestellung aufgegeben. Die Kosten pro Neukunde sind:

$$\text{CAC} = \frac{S}{N} = \frac{1.800}{60} = 30$$

Dabei ist $\text{CAC}$ die Kundenakquisitionskosten (Customer Acquisition Cost) in Euro, $S$ die Ausgaben der Kampagne in Euro und $N$ die Zahl der Neukunden, die ihr zugeordnet werden. Jeder Neukunde hat also 30 € gekostet. Das ist eine Rate wie jede andere, erklärt in Grundlagen: Verhältnisse und Raten. Mit dem Warehouse kann sie diese 60 Kunden dann weiter verfolgen und sehen, ob ihre zweite und dritte Bestellung die 30 € wieder hereinholen, was kein einzelnes Tool kann.

Ein Segment ist eine Abfrage, die jeden Morgen läuft

Sobald die Kundentabelle sauber ist, ist ein Segment nichts anderes als eine Frage in SQL, deren Antwort eine Liste von Menschen ist. Entscheidend ist, dass sie von selbst läuft. In BigQuery heißt das geplante Abfrage: Sie führt eine beliebige SQL Anweisung nach Zeitplan aus, in Abständen bis hinunter zu fünf Minuten, und kann dabei jedes Mal eine Ergebnistabelle überschreiben (die Einstellung heißt WRITE_TRUNCATE).⁹ In Snowflake übernimmt diese Aufgabe ein Task, der SQL in einem festen Intervall oder nach einem Zeitplan im Cron Stil ausführt.¹⁰

Die alte Fassung dieses Artikels zeigte eine "Plateau" Abfrage, die in einer WHERE Klausel auf SUM(value) und MAX(event_date) filterte. Die läuft nicht. WHERE filtert Zeilen, bevor sie gruppiert werden, und Bedingungen auf Summen gehören in HAVING, das nach dem Gruppieren filtert.¹¹ Das passiert schnell, und es ist ein guter Grund, jede Abfrage an echten Daten zu testen, bevor sie in den Zeitplan kommt.

Rechenbeispiel: eingeschlafene Wiederkäufer

Hannahs Segment sind Kunden, die mindestens zweimal bestellt haben, deren letzte Bestellung mehr als 42 Tage zurückliegt, die kein Abo haben und die Werbung per E Mail erlaubt haben. Hier ist es, direkt gegen die Rohbestellungen geschrieben, damit das Gruppieren sichtbar wird:

SELECT o.customer_id,
       c.email_normalised,
       COUNT(*)          AS order_count,
       MAX(o.order_date) AS last_order_date
FROM shop.orders AS o
JOIN core.customers AS c ON c.customer_id = o.customer_id
WHERE c.has_active_subscription = FALSE
  AND c.marketing_consent = TRUE
GROUP BY o.customer_id, c.email_normalised
HAVING COUNT(*) >= 2
   AND DATE_DIFF(CURRENT_DATE('Europe/Berlin'), MAX(o.order_date), DAY) > 42;

Die WHERE Zeilen filtern Kunden vor dem Gruppieren, weil sie Tatsachen über den Kunden sind. Die HAVING Zeilen filtern danach, weil es die Zahl der Bestellungen und das Datum der letzten Bestellung erst gibt, wenn die Bestellungen zusammengezählt sind. Täglich um 6:00 Uhr mit WRITE_TRUNCATE geplant, schreibt sie eine Tabelle namens segments.lapsed_repeat_buyers neu.

Beim ersten Lauf haben 1.150 Kunden mindestens zwei Bestellungen, und 420 davon haben seit 42 Tagen nicht bestellt. Zieh die 70 Abonnenten ab (nicht eingeschlafen, sie bekommen ja geliefert) und die 40 ohne Erlaubnis für Werbung, dann bleiben 310. Morgen bestellen einige und fallen heraus, andere überschreiten die Linie und kommen dazu. Niemand muss daran denken, irgendetwas neu zu starten.

Segmente zurück in die Tools schicken, die handeln

Ein Segment, das im Warehouse liegt, bewirkt nichts, bis es das Tool erreicht, das die Mail verschickt oder die Anzeige ausspielt. Das Zurückkopieren heißt oft Reverse ETL: Entweder du kaufst dafür ein Tool, oder du schreibst einen kleinen Job, der die Segmenttabelle liest und die API jedes Tools aufruft.

Für die E Mail Seite zeige ich hier Klaviyo, weil die Dokumentation klar ist. Der Endpunkt für den Profilimport legt eine Person an oder aktualisiert sie, erkannt an der E Mail, und erlaubt eigene Eigenschaften.¹² Eine Eigenschaft wie segment kann das E Mail Tool dann zum Filtern und Auslösen nutzen.

import requests

API_KEY = "pk_your_private_key"   # liegt in einem Secret Store, nie im Code

def push_profile(email, properties):
    response = requests.post(
        "https://a.klaviyo.com/api/profile-import",
        headers={
            "Authorization": f"Klaviyo-API-Key {API_KEY}",
            "revision": "2026-10-15",
            "Content-Type": "application/vnd.api+json",
        },
        json={"data": {"type": "profile",
                       "attributes": {"email": email,
                                      "properties": properties}}},
        timeout=10,
    )
    response.raise_for_status()

push_profile("jonas.weber@example.com",
             {"segment": "lapsed_repeat_buyer", "last_order_date": "2026-09-14"})

Die alte Fassung dieses Artikels schickte Daten an eine Customer.io Adresse, die nicht zur dokumentierten Track API passt. Die liegt auf track.customer.io und aktualisiert eine Person mit einer PUT Anfrage.¹³ Egal welches Tool du nutzt: Nimm Adresse und Authentifizierung aus der aktuellen Dokumentation, nicht aus einem Blogbeitrag, diesen hier eingeschlossen.

Für die Werbeseite nimmt Google Ads Kundenlisten über eine Funktion namens Kundenabgleich (Customer Match) an. E Mail Adressen werden vor dem Abgleich mit SHA256 gehasht, entweder von dir oder beim Hochladen von Google, und Google bittet dich, vorher Leerzeichen zu entfernen und jede Adresse klein zu schreiben.⁸ Hashen macht aus einer E Mail Adresse eine feste Folge aus Buchstaben und Ziffern, die sich nicht zurückverwandeln lässt. So kann die Plattform sie mit ihren eigenen Nutzern abgleichen, ohne dass du die Adresse im Klartext übergibst.

Rechenbeispiel: Jonas, auf beiden Wegen

Die Abfrage um 6:00 Uhr nimmt Jonas ins Segment auf. Um 6:30 Uhr liest ein kleiner Job die 310 Zeilen und ruft für jede push_profile auf, mit segment auf lapsed_repeat_buyer. Im E Mail Tool hat Hannah einen Flow, der startet, sobald ein Profil diesen Wert trägt, und Jonas bekommt noch am selben Morgen eine Nachricht über die neue Röstung aus Kolumbien.

Für den Kundenabgleich nimmt derselbe Job Jonas' normalisierte Adresse, jonas.weber@example.com, und hasht sie. Heraus kommt 0874a506e975e942d1f2555f3a6693e46e3da4c9ee73c704f43ffd493a6bc25a, für diese Adresse jedes Mal dieselben 64 Zeichen und für jede andere Adresse eine völlig andere Folge. Diese Hashes gehen in eine Liste für den Kundenabgleich, aber nur für Kunden, deren Erlaubnis das abdeckt, und darum geht es im vorletzten Abschnitt. Wie sich E Mail und Anzeigen gegenseitig auslösen, wenn beide von hier gespeist werden, habe ich in einem eigenen Beitrag über Anzeigen, die von E Mail Aktivität ausgelöst werden beschrieben, und wie die Zustellung selbst verdrahtet wird, in Webhooks und Serverless Funktionen.

Auf Bewegung reagieren, nicht nur auf Klicks

Die meiste Marketing Automation reagiert darauf, dass eine Person eine Sache tut: ein Formular ausgefüllt, einen Warenkorb stehen gelassen. Das Warehouse fügt eine zweite Art Auslöser hinzu, eine, die bemerkt, dass sich eine Zahl bewegt: ein Einbruch der täglichen Conversion Rate, eine Kohorte, die nicht mehr nachbestellt.

Der einfachste Test auf "das ist ungewöhnlich" fragt, wie weit der heutige Wert vom Normalen entfernt ist, gemessen in Standardabweichungen. Qualitätsingenieure ziehen ihre Alarmlinien seit Langem drei Standardabweichungen über und unter dem Mittelwert.¹⁴

$$z = \frac{x - \bar{x}}{s}$$

Dabei ist $z$, wie ungewöhnlich der heutige Tag ist, in Standardabweichungen, $x$ der heutige Wert, $\bar{x}$ der Mittelwert der letzten Tage, die du als normal ansiehst, und $s$ deren Standardabweichung. Ein $z$ unter $-3$ oder über $3$ ist einen Blick wert. Mittelwert und Standardabweichung erkläre ich von Grund auf in Grundlagen: der Mittelwert und Grundlagen: die Streuung.

Rechenbeispiel: der Dienstag, an dem der Checkout kaputtging

Über die letzten 28 Tage hat die tägliche Conversion Rate der Auwald Rösterei (Bestellungen geteilt durch Besuche) einen Mittelwert von 2,4 % und eine Standardabweichung von 0,3 Prozentpunkten. Am Dienstag liegt sie bei 1,4 %.

$$z = \frac{1{,}4 - 2{,}4}{0{,}3} = \frac{-1{,}0}{0{,}3} = -3{,}33$$

Dabei ist $1{,}4$ die Rate vom Dienstag, also $x$, $2{,}4$ der Mittelwert über 28 Tage, also $\bar{x}$, und $0{,}3$ die Standardabweichung $s$, alles in Prozent. Der Dienstag liegt 3,33 Standardabweichungen unter dem Normalen, jenseits der Linie bei drei. Die geplante Abfrage schreibt eine Zeile in eine Tabelle mit Warnungen, und ein Job schickt Hannah eine Nachricht. Sie findet heraus, dass ein Update beim Zahlungsanbieter die Kartenzahlung in einem Browser lahmgelegt hat.

Die waagrechte Achse zeigt die Tage über zwei Wochen, die senkrechte die tägliche Conversion Rate. Die obere Linie ist die tägliche Rate, die flache Linie der Alarm bei 1,5 %, also der Mittelwert von 2,4 % minus dreimal 0,3. Die Erkenntnis: 13 gewöhnliche Tage schwanken zwischen 2,1 % und 2,7 % und kommen der Linie nie nahe, also weckt das Rauschen niemanden. Tag 14 fällt glatt hindurch. Eine Regel, einmal geschrieben, wacht jeden Tag für sie.

Rechenbeispiel: lohnt sich der Gutschein zur Rückgewinnung

Ein Auslöser braucht auch eine Entscheidung darüber, was zu tun ist. Nimm die 310 eingeschlafenen Wiederkäufer. Aus früheren Aussendungen schätzt Hannah, dass 7 % innerhalb eines Monats nach einer einfachen Mail zurückkommen und 12 % nach einer Mail mit einem Gutschein über 5 €. Eine Rückkehrbestellung bringt ihr 14 € Marge, und den Gutschein bezahlen nur die, die ihn einlösen. Der Erwartungswert pro angeschriebener Person ist:

$$E[\text{einfach}] = 0{,}07 \times 14 = 0{,}98, \qquad E[\text{Gutschein}] = 0{,}12 \times (14 - 5) = 1{,}08$$

Dabei ist $E[\cdot]$ die erwartete Marge in Euro pro angeschriebener Person, $0{,}07$ und $0{,}12$ sind die Wahrscheinlichkeiten einer Rückkehr, $14$ ist die Marge einer Rückkehrbestellung in Euro und $5$ der Gutschein in Euro. Der Gutschein gewinnt, aber nur um 10 Cent pro Person, 31 € über alle 310. Knapp genug, dass ich es testen würde, statt es anzunehmen, und leicht auszurechnen, weil Margen und frühere Antwortquoten am selben Ort liegen. Den Erwartungswert erkläre ich in Grundlagen: der Erwartungswert. Wenn du weiter gehen und vorhersagen willst, wer gerade dabei ist abzuspringen, statt 42 Tage zu warten, ist das Survival Analyse, und die hat einen eigenen Artikel über Churn und Customer Lifetime Value.

Die Erlaubnis gehört ins Warehouse, nicht nur ins E Mail Tool

Liegen alle Quellen an einem Ort, wird es sehr leicht, Daten für etwas zu nutzen, wofür sie nie erhoben wurden. Das Recht ist da eindeutig. Nach der DSGVO müssen personenbezogene Daten für festgelegte, eindeutige und legitime Zwecke erhoben werden und dürfen nicht in einer Weise weiterverarbeitet werden, die mit diesen Zwecken unvereinbar ist (Art. 5 Abs. 1 lit. b, die Zweckbindung). Ob ein neuer Zweck noch vereinbar ist, prüfst du ohne Einwilligung nach Art. 6 Abs. 4, unter anderem daran, wie eng die Zwecke verbunden sind und in welchem Zusammenhang die Daten erhoben wurden.¹⁵ Außerdem müssen die Daten auf das für den Zweck notwendige Maß beschränkt sein (Art. 5 Abs. 1 lit. c, die Datenminimierung).¹⁶

Für Werbemails gilt in Deutschland zusätzlich das UWG. Werbung per elektronischer Post ohne vorherige ausdrückliche Einwilligung gilt nach § 7 Abs. 2 Nr. 2 als unzumutbare Belästigung. Die Ausnahme für Bestandskunden in § 7 Abs. 3 greift nur, wenn alle vier Bedingungen erfüllt sind: Du hast die Adresse im Zusammenhang mit dem Verkauf einer Ware oder Dienstleistung vom Kunden bekommen, du bewirbst eigene ähnliche Waren oder Dienstleistungen, der Kunde hat nicht widersprochen, und du hast ihn bei der Erhebung und bei jeder Mail klar darauf hingewiesen, dass er jederzeit widersprechen kann, ohne dass ihm dafür mehr als die üblichen Übermittlungskosten entstehen.¹⁷ Die Datenschutzaufsichtsbehörden sehen es in ihrer Orientierungshilfe zur Direktwerbung genauso: Ohne diese Voraussetzungen braucht E Mail Werbung grundsätzlich eine Einwilligung, und du musst nachweisen können, dass eine Adresse wirklich die eines Bestandskunden ist.¹⁸ Für Zielgruppen in Google Ads verlangt Googles Richtlinie zum Kundenabgleich, dass deine Datenschutzerklärung die Weitergabe von Kundendaten an Dienstleister offenlegt, und eine Einwilligung, wo das Gesetz sie vorschreibt.¹⁹ Ich bin Ingenieur, kein Anwalt, also würde ich für alles, was über diese Grundlagen hinausgeht, einen fragen.

In der Praxis führe ich die Erlaubnis als Spalten in der Kundentabelle, eine pro Kanal, und baue die Prüfung in jede Segmentabfrage ein. Eine Liste, die das Warehouse verlässt, kann dann niemanden enthalten, der nicht darauf gehört. Außerdem kopiere ich nur die Spalten, die die Segmente brauchen, das ist Datenminimierung in der Praxis. Wie du die Tools prüfst, an die du Daten schickst, ist ein eigenes Thema, behandelt in wie Auftragsverarbeiter dir eine Strafe einbringen können.

Rechenbeispiel: zwei Erlaubnisse, zwei Listen

Von Hannahs 310 eingeschlafenen Wiederkäufern haben alle 310 die Prüfung der E Mail Erlaubnis schon in der Segmentabfrage bestanden. Für den Kundenabgleich führt sie eine eigene Spalte, ads_audience_ok, gesetzt aus ihrem Anmeldeformular, in dem Kunden erfahren, dass ihre Daten genutzt werden dürfen, um ihnen Anzeigen der Auwald Rösterei bei Google zu zeigen. 240 der 310 haben sie. Die E Mail Liste umfasst also 310 Menschen, die Liste für den Kundenabgleich 240. Die übrigen 70 bekommen trotzdem die Mail, und niemand muss daran denken, sie von Hand aus der Anzeigenliste zu nehmen, weil sie nie darauf standen.

Was es kostet, und wann du noch nicht so weit bist

Für ein Unternehmen in der Größe der Auwald Rösterei kostet das Warehouse selbst sehr wenig. Die kostenlose Stufe von BigQuery enthält 1 TiB verarbeitete Abfragedaten pro Monat, und die Sandbox, für die du kein Rechnungskonto brauchst, legt 10 GiB Speicher dazu.²⁰ Der Haken: Die Sandbox unterstützt den Data Transfer Service nicht, auf den geplante Abfragen und der Google Ads Connector angewiesen sind, und ihre Tabellen laufen nach 60 Tagen ab.²⁰ Sobald irgendetwas von selbst laufen soll, schaltest du also die Abrechnung ein. Abfragen werden nach den gelesenen Bytes berechnet, und ein LIMIT auf einer gewöhnlichen Tabelle verringert nicht, was gelesen wird.³

Rechenbeispiel: was die Auwald Rösterei im Monat liest

Hannahs Segmentabfrage liest die Bestell und Kundenspalten, die sie braucht, etwa 150 MB pro Lauf. Die Warnabfrage liest die täglichen Besuche und Bestellungen, etwa 50 MB. Beide laufen täglich, also lesen sie in einem Monat mit 30 Tagen:

$$(150 + 50) \times 30 = 6.000 \text{ MB} \approx 6 \text{ GB}$$

Dabei sind $150$ und $50$ die Megabytes, die jede Abfrage pro Lauf liest, und $30$ ist die Zahl der täglichen Läufe. Sechs Gigabyte gegenüber einem kostenlosen Kontingent von rund 1.000 liegen weit darunter. Die echten Kosten eines Warehouse stehen nicht auf der Rechnung. Es ist die Zeit, es ordentlich aufzusetzen, und die Disziplin, die bereinigenden Abfragen ehrlich zu halten.

Nach meiner Erfahrung holt ein Shop mit ein paar hundert Bestellungen im Monat und einem E Mail Tool den Großteil des Nutzens aus den eingebauten Integrationen, und ein Warehouse wäre eine sauber gebaute Antwort auf eine Frage, die noch niemand stellt. Es lohnt sich, wenn die Fragen über Tools hinweg gehen, jemand jede Woche Tabellen exportiert, um sie zu beantworten, und ein falsches Segment (ein "wir vermissen dich" Gutschein an eine treue Abonnentin etwa) in den Antworten auftaucht. Wenn du eines für einen Shop auf Rails und Solidus aufsetzt, habe ich das Aufsetzen von BigQuery selbst Schritt für Schritt beschrieben.

Das Warehouse ist das Gedächtnis, die Tools sind die Hände

Die alte Fassung dieses Artikels nannte das Warehouse das Gehirn. Heute würde ich es bescheidener sagen. Es ist das Gedächtnis, der eine Ort, an dem alles, was mit einem Kunden passiert ist, so aufgeschrieben steht, dass du es befragen kannst. Das E Mail Tool, die Werbeplattformen und dein Team sind die Hände.

Nichts an diesem Kreislauf ist raffiniert. Nach ehrlichem Zeitplan hineinkopieren, die E Mail bereinigen, vor dem Verknüpfen verdichten, die Erlaubnis in der Abfrage prüfen, über die dokumentierte API verschicken. Das ist der Unterschied zwischen einer Automation, die jeden Tag still das Richtige tut, und einer, die deinen besten Abonnenten schreibt und fragt, wo sie geblieben sind.

Footnotes

1. Google Cloud, BigQuery Übersicht, BigQuery Dokumentation, 2026, https://docs.cloud.google.com/bigquery/docs/introduction?hl=de

2. Google Cloud, BigQuery Speicher, BigQuery Dokumentation, 2026, https://docs.cloud.google.com/bigquery/docs/storage_overview?hl=de

3. Google Cloud, Kosten schätzen und kontrollieren, BigQuery Dokumentation, 2026, https://docs.cloud.google.com/bigquery/docs/best-practices-costs?hl=de

4. Google, BigQuery Export, Google Analytics Hilfe, 2026, https://support.google.com/analytics/answer/9358801?hl=de

5. Google Cloud, Google Ads Daten in BigQuery laden, BigQuery Dokumentation, 2026, https://docs.cloud.google.com/bigquery/docs/google-ads-transfer?hl=de

6. Airbyte, Platform, Airbyte Dokumentation, 2026, https://docs.airbyte.com/platform/

7. Google, [GA4] BigQuery Export Schema, Google Analytics Hilfe, 2026, https://support.google.com/analytics/answer/7029846?hl=de

8. Google, Kundenabgleich, Google Ads Hilfe, 2026, https://support.google.com/google-ads/answer/7474263?hl=de

9. Google Cloud, Scheduling queries, BigQuery Dokumentation, 2026, https://docs.cloud.google.com/bigquery/docs/scheduling-queries

10. Snowflake, Einführung in Aufgaben, Snowflake Dokumentation, 2026, https://docs.snowflake.com/de/user-guide/tasks-intro

11. Google Cloud, Query syntax (GoogleSQL), BigQuery Dokumentation, 2026, https://docs.cloud.google.com/bigquery/docs/reference/standard-sql/query-syntax

12. Klaviyo, Create or Update Profile, Klaviyo Entwicklerdokumentation, 2026, https://developers.klaviyo.com/en/reference/create_or_update_profile

13. Customer.io, Track API Reference, Customer.io Dokumentation, 2026, https://docs.customer.io/api/track/

14. NIST und SEMATECH, What are control charts?, Engineering Statistics Handbook, National Institute of Standards and Technology, 2012, https://www.itl.nist.gov/div898/handbook/pmc/section3/pmc31.htm

15. Europäische Union, Verordnung (EU) 2016/679 (Datenschutz Grundverordnung), Art. 5 Abs. 1 lit. b und Art. 6 Abs. 4, EUR Lex, 2016, https://eur-lex.europa.eu/legal-content/DE/TXT/HTML/?uri=CELEX:32016R0679

16. Europäische Union, Verordnung (EU) 2016/679 (Datenschutz Grundverordnung), Art. 5 Abs. 1 lit. c, EUR Lex, 2016, https://eur-lex.europa.eu/legal-content/DE/TXT/HTML/?uri=CELEX:32016R0679

17. Bundesministerium der Justiz, Gesetz gegen den unlauteren Wettbewerb (UWG), § 7 Unzumutbare Belästigungen, Gesetze im Internet, 2026, https://www.gesetze-im-internet.de/uwg_2004/__7.html

18. Datenschutzkonferenz (DSK), Orientierungshilfe der Aufsichtsbehörden zur Verarbeitung von personenbezogenen Daten für Zwecke der Direktwerbung, Abschnitt 1.4.1, 2022, https://www.datenschutzkonferenz-online.de/media/oh/OH-Werbung_Februar%202022_final.pdf

19. Google, Richtlinie zum Kundenabgleich, Google Ads Werberichtlinien Hilfe, 2026, https://support.google.com/adspolicy/answer/6299717?hl=de

20. Google Cloud, BigQuery mit der Sandbox ausprobieren, BigQuery Dokumentation, 2026, https://docs.cloud.google.com/bigquery/docs/sandbox?hl=de