Ein Datensatz pro Kunde, die Einwilligung dabei, und jedes Kampagnentool liest daraus

Ein Kunde, ein Datensatz, und jedes Tool liest daraus

Die meisten kleinen Shops haben keinen Marketing Stack. Sie haben eine Sammlung von Abos, die jedes für sich gewachsen sind. Das Newsletter Tool weiß, wer was geöffnet hat. Die Werbekonten wissen, wer geklickt hat. Der Shop weiß, wer bezahlt hat. Keiner weiß alle drei, und keiner weiß sicher, wer wozu ja gesagt hat.

Ein einheitlicher Stack für die Kampagnenautomatisierung, im Englischen gern "unified campaign automation stack" genannt, löst das mit einer einzigen Idee. Es gibt einen Datensatz pro Kunde und einen Datensatz pro Handlung, und jedes Tool, das etwas tut (das Newsletter Tool, die Werbeplattformen, die Analyse), liest aus diesen Datensätzen, statt eine eigene Fassung zu führen. Die Erlaubnis, die jemand gegeben hat, reist mit seinem Datensatz mit. So sieht ein Tool nur die Menschen, die es sehen darf.

Ich automatisiere Kampagnen nicht isoliert, und dieser Artikel ist der Grund dafür. Es geht um die Architektur: welche Teile du brauchst, was jedes kostet, ob du es baust oder kaufst, was kaputtgeht und wem die Daten gehören, wenn du einen Anbieter verlässt. Die einzelnen Teile haben jeweils einen eigenen Artikel, und ich verlinke sie unterwegs, statt sie hier zu wiederholen.

Durchgehend nutze ich ein erfundenes Unternehmen. Das Teekontor Plagwitz ist ein Onlineshop für losen Tee in Leipzig, geführt von Lena, auf Shopify, unter teekontorplagwitz.example. Es hat rund 1.000 Bestellungen im Monat mit durchschnittlich 28 €, behält von jeder Bestellung etwa 14 € nach Tee, Verpackung und Versand und hat 6.000 Kontakte im Newsletter Tool. Pro Monat gibt es etwa 3.000 € für Meta und 2.000 € für Google aus. Niemand davon ist echt, und jede Zahl ist ausgedacht, damit ich jeden Schritt zeigen kann.

Der Stack besteht aus fünf Aufgaben, nicht aus fünf Produkten

Die alte Fassung dieses Artikels hat Produkte aufgezählt: Zapier, Segment, Python, die Google Ads API, Postmark, BigQuery. Produkte wechseln jedes Jahr, die Aufgaben bleiben. Es sind fünf.

1. Events erfassen. Etwas zeichnet auf, was Besucher und Kunden tun, Seitenaufrufe, Artikel in den Warenkorb, Käufe, zusammen mit dem Einwilligungsstatus des Browsers in diesem Moment. Darum geht es in meinem Artikel über Event Tracking und Consent Mode, und Server Side Tracking ist ein Weg, es umzusetzen.
2. Den Datensatz führen. Ein Ort hält eine Zeile pro Kunde, mit seinen Kennungen, seinen Bestellungen und seinen Erlaubnissen. Bei einem kleinen Shop ist das oft die Shopplattform plus das Newsletter Tool. Bei einem größeren ist es ein Data Warehouse.
3. Mails versenden. Ein Email Service Provider (ESP), etwa Klaviyo oder Postmark, verschickt die Nachrichten.
4. Werbezielgruppen erreichen. Kundenlisten und Conversion Daten gehen an Google und Meta. Darum geht es in Anzeigen aus Mailaktivität auslösen und in Auto Bidding auf First Party Daten.
5. Daten zwischen allem bewegen. Fertige Integrationen, ein Tool wie Zapier oder eigener Code auf Webhooks und Serverless Funktionen.

Die Reihenfolge zählt. Alles fließt von der Erfassung über den Datensatz zu den Tools, die handeln, und die Erlaubnis wird am Datensatz geprüft, bevor irgendetwas hinausgeht.

Die Entscheidung in der Mitte ist das Herzstück: eine Frage, pro Zweck gestellt, bevor Daten den Shop verlassen. Ein Ja schickt die Person an genau dieses eine Tool. Ein Nein lässt sie in den eigenen Bestellunterlagen des Shops, die er ohnehin zum Arbeiten braucht. Der letzte Schritt ist der langweilige, der am meisten Geld spart, und er bekommt weiter unten einen eigenen Abschnitt.

Rechenbeispiel: die fünf Aufgaben im Teekontor

Lena schreibt die fünf Aufgaben auf und setzt neben jede, wofür sie schon bezahlt.

1. Events erfassen: der Shopify Shop, sein Einwilligungsbanner und die Tags von Google.
2. Den Datensatz führen: die Kundenliste in Shopify, die Klaviyo über seine Shopify Integration kopiert. Klaviyo dokumentiert, dass es Kundenprofile und Bestelldaten übernimmt und Kunden, die an der Kasse Marketingmails zustimmen, einer Liste hinzufügen kann.¹
3. Mails versenden: Klaviyo.
4. Werbezielgruppen erreichen: die Apps von Meta und Google für Shopify, dazu die Zielgruppensynchronisierung von Klaviyo.
5. Daten bewegen: zwei Zapier Automationen, eine schickt große Bestellungen auf ihr Handy, die andere kopiert Großhandelsanfragen in eine Tabelle.

Sie hat also schon einen Stack. Was ihr fehlt, ist eine einzige Antwort auf die Frage "wer darf was bekommen", denn drei Tools führen jeweils ihre eigene Fassung davon.

Die Einwilligung ist ein Feld im Datensatz, keine Einstellung in einem Tool

Stützt du dich auf eine Einwilligung, musst du nach Artikel 7 der Datenschutz Grundverordnung (DSGVO) nachweisen können, dass die Person eingewilligt hat, und der Widerruf muss so einfach sein wie die Erteilung.² Dieser eine Satz entscheidet die Architektur. Liegt der Nachweis in einem Newsletter Tool, kann die Synchronisierung zu den Werbeplattformen ihn nicht sehen. Und widerruft jemand in einem Tool, arbeiten die anderen mit der alten Antwort weiter.

Darum ist jede Erlaubnis ein Feld im Kundendatensatz: was vereinbart wurde, wo, wann und mit welchem Wortlaut. Es gibt zwei Arten, und sie verhalten sich verschieden.

Die Erlaubnis für Mails gehört zu einer Person. Nach § 7 des Gesetzes gegen den unlauteren Wettbewerb (UWG) braucht Werbung per Mail grundsätzlich eine vorherige ausdrückliche Einwilligung. Die Ausnahme für Bestandskunden in § 7 Absatz 3 greift nur, wenn alle vier Bedingungen erfüllt sind: Du hast die Adresse im Zusammenhang mit einem Verkauf vom Kunden selbst bekommen, du bewirbst eigene ähnliche Waren oder Dienstleistungen, der Kunde hat nicht widersprochen, und du hast ihn bei der Erhebung und bei jeder Verwendung klar darauf hingewiesen, dass er jederzeit widersprechen kann, ohne dass ihm dafür mehr als die üblichen Übermittlungskosten entstehen.³

Die Erlaubnis für Cookies und Tags gehört zu einem Browser. In Deutschland regelt § 25 des Telekommunikation Digitale Dienste Datenschutz Gesetzes (TDDDG), dass das Speichern von Informationen auf dem Endgerät und das Auslesen von dort gespeicherten Informationen nur mit Einwilligung erlaubt sind, mit zwei Ausnahmen: die Übertragung einer Nachricht und das, was unbedingt erforderlich ist, um einen ausdrücklich gewünschten Dienst bereitzustellen.⁴ Die Antwort im Banner ist eine Momentaufnahme an jedem Event, keine Eigenschaft der Person. Was genau ein Ja braucht, steht in meinem Artikel über Event Tracking und Consent Mode, und wie du nach der Erlaubnis für Mails fragst, ohne Anmeldungen zu verlieren, in DSGVO vs Growth.

Die Werbeplattformen legen eine eigene Schicht darüber. Googles Richtlinie zur Einwilligung der Nutzer in der EU gilt für Endnutzer im Europäischen Wirtschaftsraum, also auch in Deutschland, und verlangt eine rechtlich wirksame Einwilligung für die Nutzung personenbezogener Daten zur Personalisierung von Anzeigen, mit Aufzeichnungen darüber.⁵ Bei Uploads von Kundenlisten lehnt Googles API die Anfrage ab, wenn das Einwilligungsfeld ad_user_data oder ad_personalization auf verweigert steht.⁶

In Deutschland kommt eine Hürde vor der Technik. Das Bayerische Landesamt für Datenschutzaufsicht (BayLDA) hat einem Onlinehändler den Upload seiner Kundenliste zu Facebook ohne Einwilligung untersagt, und der Bayerische Verwaltungsgerichtshof hat die Anordnung bestätigt: Die Kunden rechnen nicht damit, dass ihre Mailadresse an Facebook geht, also trägt das berechtigte Interesse die Übermittlung nicht, und das Hashen mit SHA256 anonymisiert die Daten nicht.⁷ Die sichere Grundlage für den Upload ist hier also die Einwilligung. Die ganze Geschichte, mit dem Verfahren und den Folgen für Google und Meta, steht in meinem Artikel über Anzeigen aus Mailaktivität auslösen. Der Datensatz braucht darum ein eigenes Feld für Werbezielgruppen, denn ein Kunde kann deinen Newsletter gern lesen und trotzdem nicht mit seinem Facebook Konto abgeglichen werden wollen.

Rechenbeispiel: Jonas' Datensatz, drei Ziele

Jonas kauft eine Dose Ostfriesische Mischung, setzt an der Kasse das Häkchen für Marketingmails und schaltet eine Woche später in den Einstellungen "meine Mailadresse für Werbung nutzen" aus. Sein Datensatz in Lenas Shop sieht jetzt so aus:

{
  "customer_id": "c_10482",
  "email": "jonas@example.com",
  "orders": 1,
  "consents": {
    "email_marketing": {
      "state": "granted",
      "basis": "consent",
      "source": "checkout",
      "wording": "checkout_box_v3",
      "at": "2026-10-14T19:02:11Z"
    },
    "ad_audiences": {
      "state": "denied",
      "source": "preference_centre",
      "at": "2026-10-21T08:15:40Z"
    }
  }
}

Die nächtliche Synchronisierung stellt die Frage aus dem Diagramm einmal pro Ziel.

1. Newsletter Tool: email_marketing ist erteilt, also bleibt Jonas auf der Newsletter Liste.
2. Kundenlisten bei Meta und Google: ad_audiences ist verweigert, also wird Jonas zu keiner der beiden hochgeladen, auch nicht auf die Liste der kürzlichen Käufer, mit der man Menschen von Neukundenanzeigen ausschließt.
3. Analyse: Hier entscheidet nichts im Personendatensatz. Jeder Seitenaufruf von Jonas trägt die Antwort, die sein Browser damals im Banner gegeben hat, und die Tags halten sich daran.

Schritt zwei hat einen Preis. Jonas sieht vielleicht eine Anzeige, die ihn einlädt, das Teekontor zum ersten Mal auszuprobieren, weil Lena Meta nicht sagen kann, ihn auszulassen. Das ist die Regel bei der Arbeit, kein Fehler. Ihn trotzdem hochzuladen, "nur zum Ausschließen", wäre in Deutschland genau die Übermittlung ohne Einwilligung, die das BayLDA untersagt hat,⁷ und Googles eigenes Einwilligungsfeld würde den Upload ohnehin ablehnen.

Was der Stack im Monat kostet, und wie viele Bestellungen ihn bezahlen

Die Rechnung eines kleinen Shops besteht vor allem aus Abos, und die meisten richten sich nach der Größe: Kontakte, Events oder Aufgaben. Hier steht, was die Seiten der Anbieter selbst sagen, geprüft im November 2026.

Klaviyo rechnet nach aktiven Profilen ab, also nach jedem Kontakt, den du anschreiben darfst. Der kostenlose Plan reicht bis 250 aktive Profile, der bezahlte Email Plan beginnt bei 20 US Dollar im Monat für 500 Profile und steigt über einen Schieberegler mit der Zahl.⁸ RudderStack, das Events sammelt und an Tools weiterleitet, ist bis 250.000 Events im Monat kostenlos, und der Growth Plan kostet 265 US Dollar im Monat für eine Million Events.⁹ Der Pro Plan von Zapier kostet bei monatlicher Abrechnung 29,99 US Dollar für 750 Aufgaben, wobei eine Aufgabe eine erfolgreiche Aktion ist.¹⁰ Ein Container für Server Side Tagging auf Google Cloud Run kostet etwa 45 US Dollar im Monat pro Server, und Google empfiehlt mindestens zwei.¹¹ BigQuery, das Data Warehouse von Google, enthält jeden Monat 1 TiB Abfrageverarbeitung kostenlos.¹² Twilio Segment, der bekannteste Event Router, nennt auf seiner Preisseite keine Preise und erstellt Angebote nach monatlich erfassten Nutzern.¹³

Rechenbeispiel: die Monatsrechnung des Teekontors

Die meisten Preise stehen in Dollar. Für runde Zahlen rechne ich mit 0,75 € pro Dollar. Das ist eine Annahme für das Beispiel, nicht der Tageskurs, prüf also den Kurs an dem Tag, an dem du rechnest. Mit 6.000 Profilen liegt Lena weit über der ersten Stufe von Klaviyo, und für dieses Beispiel setze ich ihren Preis am Schieberegler mit 110 € im Monat an. Lies deinen eigenen ab, denn er wandert mit deiner Zahl.

Ihre Website hat 30.000 Sitzungen im Monat mit jeweils etwa acht Events:

$$30{.}000 \times 8 = 240{.}000$$

Dabei ist $30{.}000$ die Zahl der Sitzungen im Monat und $8$ die Zahl der Events pro Sitzung, also 240.000 Events, knapp unter den kostenlosen 250.000 bei RudderStack. Dann die Rechnung, Zeile für Zeile:

1. Klaviyo: 110 €.
2. Zapier Pro: 29,99 Dollar zu je 0,75 € sind 22,49 €.
3. RudderStack: 0 €, innerhalb des kostenlosen Kontingents.
4. BigQuery: innerhalb des kostenlosen Abfragekontingents, und für die Speicherung von ein paar Gigabyte setze ich als Annahme des Beispiels 1 € an.
5. Server Side Tagging: zwei Server zu 45 Dollar, zu je 0,75 €, sind 67,50 €.

$$110 + 22{,}49 + 0 + 1 + 67{,}50 = 200{,}99$$

Dabei ist $110$ Klaviyo, $22{,}49$ Zapier, $0$ RudderStack, $1$ BigQuery und $67{,}50$ der Tag Server, alles in Euro im Monat, zusammen also rund 201 €.

Jeder Balken ist ein Tool, und die senkrechte Achse zeigt, was es Lena im Monat in Euro kostet. Die Erkenntnis: Newsletter Tool und Tag Server machen fast neun Zehntel der Rechnung aus, und das Data Warehouse, der Teil, vor dem sich viele fürchten, ist in dieser Größe fast kostenlos. Der Balken von RudderStack bleibt nur bei null, solange sie unter 250.000 Events bleibt.

Sind 201 € das wert? Die Zahl der zusätzlichen Bestellungen, deren Marge die Kosten deckt, ist ein einfaches Verhältnis:

$$n^{*} = \frac{C}{m}$$

Dabei ist $n^{*}$ die Zahl der zusätzlichen Bestellungen im Monat an der Gewinnschwelle, $C$ die monatlichen Kosten des Stacks in Euro und $m$ die Marge pro Bestellung in Euro, also das, was nach Ware, Verpackung und Versand übrig bleibt. Es ist eine Rate wie jede andere, erklärt in Grundlagen: Quoten und Raten.

Für das Teekontor:

$$n^{*} = \frac{201}{14} = 14{,}4$$

Dabei sind $201$ die monatlichen Kosten und $14$ die Marge pro Bestellung, beides in Euro. Also bezahlen 15 zusätzliche Bestellungen im Monat, 1,5 % ihrer 1.000, den ganzen Stack. Die Latte liegt niedrig, und genau deshalb lohnt es sich, sie ehrlich mit einer Kontrollgruppe zu prüfen, statt sie einfach anzunehmen. Die Methoden stehen in meinem Leitfaden zu digitalen Marketing Testmethoden. Achte darauf, was die Formel weglässt: die Zeit für Einrichtung und Betrieb. Darum geht es im nächsten Abschnitt.

Bauen oder kaufen: die einmaligen Kosten gegen die monatlichen

Jedes Teil lässt sich als Abo kaufen oder als eigener Code auf einem Data Warehouse bauen. Das Abo ist schnell eingerichtet und kostet jeden Monat. Eigener Code braucht lange bis zum Start und kostet im Betrieb wenig. Beides will gepflegt werden, und bei dem, was man gekauft hat, vergisst man die Pflege gern mitzurechnen.

Der Vergleich stellt einmalige Kosten gegen eine monatliche Ersparnis. Kostet das Bauen am Anfang mehr, aber jeden Monat weniger, holt es auf nach

$$t^{*} = \frac{B_{\text{build}} - B_{\text{buy}}}{M_{\text{buy}} - M_{\text{build}}}$$

Dabei ist $t^{*}$ die Gewinnschwelle in Monaten, $B_{\text{build}}$ und $B_{\text{buy}}$ sind die einmaligen Einrichtungskosten fürs Bauen und fürs Kaufen in Euro, und $M_{\text{buy}}$ und $M_{\text{build}}$ sind ihre vollen monatlichen Kosten in Euro, also Abo oder Hosting plus die Zeit für die Pflege. Ist $M_{\text{buy}}$ nicht größer als $M_{\text{build}}$, holt das Bauen nie auf. Es ist das Verhältnis eines einmaligen Betrags zu einer monatlichen Rate, die Idee aus Grundlagen: Quoten und Raten. Über mehrere Jahre ist Geld später weniger wert als Geld heute, und das schiebt die Gewinnschwelle weiter hinaus, wie Grundlagen: Abzinsung und der Barwert erklärt.

Rechenbeispiel: die Datenweiterleitung im Teekontor, auf zwei Wegen

Der Verkehr im Teekontor wächst auf 600.000 Events im Monat, über das kostenlose Kontingent von RudderStack hinaus. Lena vergleicht zwei Wege, Events zu erfassen und Kundenlisten an Google und Meta zu schicken. Um Zeit zu bepreisen, nehme ich einen Tag erfahrene Entwicklungsarbeit mit 550 € an, eine runde Zahl für das Beispiel, kein Angebot von irgendwem.

Kaufen: RudderStack Growth zu 265 Dollar, bei 0,75 € pro Dollar also 198,75 € im Monat. Drei Tage für die Einrichtung und ein Viertel Tag im Monat, um ein Auge darauf zu haben.

$$B_{\text{buy}} = 3 \times 550 = 1{.}650$$

Dabei sind $3$ die Tage für die Einrichtung und $550$ der Tagessatz in Euro.

$$M_{\text{buy}} = 198{,}75 + 0{,}25 \times 550 = 336{,}25$$

Dabei ist $198{,}75$ das Abo in Euro und $0{,}25$ die Tage Pflege im Monat.

Bauen: ein eigener kleiner Collector, der in BigQuery schreibt, mit nächtlichen Synchronisierungsjobs. 15 Tage für die Einrichtung, etwa 10 € im Monat fürs Hosting (die Annahme des Beispiels) und ein halber Tag Pflege im Monat.

$$B_{\text{build}} = 15 \times 550 = 8{.}250$$

Dabei sind $15$ die Tage für die Einrichtung zu je $550$ Euro.

$$M_{\text{build}} = 10 + 0{,}5 \times 550 = 285$$

Dabei ist $10$ das Hosting in Euro und $0{,}5$ die Tage Pflege im Monat.

Dann die Gewinnschwelle:

$$t^{*} = \frac{8{.}250 - 1{.}650}{336{,}25 - 285} = \frac{6{.}600}{51{,}25} = 128{,}8$$

Dabei sind $6{.}600$ die zusätzlichen Einrichtungskosten des Bauens und $51{,}25$ die monatliche Ersparnis, das Bauen holt also nach 129 Monaten auf, fast elf Jahre. Für das Teekontor gewinnt das Kaufen mit großem Abstand.

Die waagerechte Achse zeigt die Monate seit der Entscheidung, die senkrechte die bisherige Gesamtsumme in Euro, Einrichtung eingerechnet. Der Abstand schrumpft nur um 51,25 € im Monat, darum sehen die Linien fast parallel aus. Jetzt änderst du eine Zahl. Angenommen, das Teekontor verdreifacht sich noch einmal und das Angebot für das Abo steigt auf 700 € im Monat. Dann wird $M_{\text{buy}}$ zu $700 + 137{,}50 = 837{,}50$, und

$$t^{*} = \frac{6{.}600}{837{,}50 - 285} = \frac{6{.}600}{552{,}50} = 11{,}9$$

Dabei ist $552{,}50$ die neue monatliche Ersparnis, und das Bauen zahlt sich in weniger als einem Jahr aus. Die Lehre ist weder "bauen" noch "kaufen". Abos mit Mengenpreisen wachsen mit dir, eigener Code meist nicht, und so kippt die Antwort bei einer Größe, die du vorher ausrechnen kannst.

Kleine Werbekonten können noch nicht mit Kundenlisten ausrichten

Ein Kostenpunkt steht auf keiner Rechnung: die Funktionen, die du nicht nutzen kannst. Googles Richtlinie zum Kundenabgleich (Customer Match) sagt, dass das Ausrichten und Gebotsanpassungen mit Kundenlisten 90 Tage Verlauf in Google Ads und insgesamt mehr als 50.000 US Dollar Ausgaben brauchen. Konten darunter, mit sauberer Richtlinien und Zahlungshistorie, dürfen Kundenlisten trotzdem zum Ausschließen und zur Beobachtung nutzen.¹⁴ Klaviyo nennt in seiner Dokumentation für die Synchronisierung mit Google dieselben Schwellen.¹⁵

Auf derselben Seite von Klaviyo steht ein Detail, das man zweimal lesen sollte. Wer im Europäischen Wirtschaftsraum wirbt, also auch in Deutschland, soll bei Klaviyo bestätigen, nur Zielgruppen zu senden, die der Werbeausrichtung zugestimmt haben, und Klaviyo sendet die Einwilligung dann für jedes Profil der Synchronisierung als erteilt. Klaviyo schreibt ausdrücklich, dass die Einstellung die Einwilligung der einzelnen Profile nicht prüft.¹⁵ Der Filter muss also im Segment sitzen, das du synchronisierst, und genau deshalb gehört das Einwilligungsfeld in den Datensatz.

Ein Beispiel: Das Teekontor hat über die Jahre insgesamt etwa 28.000 € für Google Ads ausgegeben, beim Kurs des Beispiels rund 37.000 Dollar, und liegt damit unter der Schwelle. Lenas Käuferliste kann kürzliche Kunden aus ihren Google Kampagnen für Neukunden ausschließen, was nützlich ist, aber sie kann sie nicht ansprechen. Bei Meta lässt sich eine Zielgruppe aus einer Kundendatei zum Ausrichten nutzen, und die Dokumentation nennt keine Ausgabenschwelle.¹⁶ Ein Stack nach dem Muster "eine Zielgruppe, überallhin geschickt" tut also auf jeder Plattform etwas anderes. Ihr Plan muss das sagen, sonst verbringt sie eine Woche mit der Frage, warum die Google Kampagne nicht ausgespielt wird.

Was kaputtgeht, und was es dann kostet

Ein Stack fällt leise aus. Nichts stürzt ab. Eine Synchronisierung bleibt stehen, ein Feld fehlt, ein Event wird umbenannt, und die Tools arbeiten mit alten Daten weiter. Sinnvoll bepreisen lässt sich das mit dem Erwartungswert: wie wahrscheinlich jeder Ausfall in einem Monat ist, mal das, was er kostet, wenn er eintritt.

$$E = \sum_{i} p_i \, c_i$$

Dabei ist $E$ der erwartete Schaden durch Ausfälle in einem Monat, in Euro, $p_i$ die Wahrscheinlichkeit, dass Ausfall $i$ in einem bestimmten Monat eintritt, $c_i$ das, was er dann kostet, in Euro, und $\sum_i$ addiert die Produkte über alle Ausfälle auf der Liste. Die Idee steht in Grundlagen: der Erwartungswert.

Die häufigen Ausfälle, aus der Dokumentation der Anbieter selbst:

• Doppelte Daten. Shopify schreibt, dass deine App denselben Webhook mehr als einmal bekommen kann, und rät, jede Zustellung zu überspringen, deren X-Shopify-Webhook-Id du schon gesehen hast.¹⁷ Meta entfernt doppelte Browser und Server Events nur, wenn Eventname und ID übereinstimmen, und nur innerhalb von 48 Stunden.¹⁸ Ohne das zählen Käufe doppelt, und die Gebotsstrategie jagt einem Phantom hinterher.
• Abschaltungen. Seit dem 1. April 2026 schlagen die älteren Dienste für den Kundenabgleich in der Google Ads API für Projekte fehl, die zwischen Oktober 2025 und März 2026 keine Aktivität im Kundenabgleich hatten, und Google verweist stattdessen auf die Data Manager API.⁶ Code, der letztes Jahr lief, kann dieses Jahr stehen bleiben, ohne dass jemand ihn angefasst hat.
• Umbenennungen und fehlende Felder. Ein Theme Update benennt das Kauf Event um, oder ein neuer Synchronisierungsjob vergisst, das Einwilligungsfeld mitzukopieren. Das steht in keiner Dokumentation eines Anbieters, denn es sind deine eigenen.

Rechenbeispiel: der erwartete Schaden im Teekontor pro Monat

Lena schreibt drei Ausfälle auf. Wahrscheinlichkeiten und Kosten sind Annahmen des Beispiels, plausibel gewählt, nicht gemessen.

1. Die Ausschlussliste der kürzlichen Käufer bei Meta wird eine Woche lang nicht aktualisiert. Wahrscheinlichkeit 10 % im Monat. Eine Woche Meta Budget sind $3{.}000 \times 7 / 30 = 700$ Euro, und sie nimmt an, dass 12 % davon bei kürzlichen Käufern landen, wenn die Liste veraltet ist, also $c_1 = 700 \times 0{,}12 = 84$.
2. Ein Theme Update benennt das Kauf Event um, und die Gebotsstrategie von Google läuft fünf Tage blind. Wahrscheinlichkeit 5 %. Kosten 350 €.
3. Ein neuer Synchronisierungsjob lässt das Einwilligungsfeld weg, und Menschen, die abgelehnt haben, landen in einer Zielgruppe. Wahrscheinlichkeit 2 %. Kosten zwei Tage Aufräumen und Prüfen, $2 \times 550 = 1{.}100$, bevor überhaupt die Frage nach Vertrauen oder der Datenschutzaufsicht aufkommt.

$$E = 0{,}10 \times 84 + 0{,}05 \times 350 + 0{,}02 \times 1{.}100 = 8{,}40 + 17{,}50 + 22{,}00 = 47{,}90$$

Dabei sind $0{,}10$, $0{,}05$ und $0{,}02$ die monatlichen Wahrscheinlichkeiten und $84$, $350$ und $1{.}100$ die Kosten in Euro, $E$ liegt also bei rund 48 € im Monat. Jetzt ergänzt sie eine tägliche Prüfung, die die Zahlen hinein mit den Zahlen hinaus vergleicht, Alarm schlägt, wenn sich eine Zielgruppe einen Tag lang nicht verändert hat, und jede Zeile ohne Einwilligungsfeld vom Upload ausschließt. Jeder Ausfall fällt jetzt innerhalb eines Tages auf. Der erste kostet nur noch ein Siebtel, 12 €. Der zweite ein Fünftel, 70 €. Der dritte wird vor dem Upload gestoppt und kostet einen halben Tag, 275 €.

$$E' = 0{,}10 \times 12 + 0{,}05 \times 70 + 0{,}02 \times 275 = 1{,}20 + 3{,}50 + 5{,}50 = 10{,}20$$

Dabei ist $E'$ der erwartete monatliche Schaden mit der Prüfung, rund 10 €. Die Prüfung spart etwa 38 € im Monat, braucht einen Tag zum Bauen und zahlt sich rein vom Geld her nach etwa 15 Monaten aus. Was sie wirklich kauft, ist die dritte Zeile: Der Ausfall, den du nicht vollständig bepreisen kannst, ist genau der, den sie verhindert.

Wem der Datensatz gehört, der kann gehen

Datenhoheit klingt nach einer juristischen Frage. In der Praxis ist sie ein Test: Könntest du nächsten Monat dein Newsletter Tool wechseln und alles mitnehmen?

Das Recht legt die Untergrenze fest. Verarbeitet ein Anbieter die Daten deiner Kunden in deinem Auftrag, tut er das nach Artikel 28 DSGVO auf Grundlage eines Vertrags, und dieser Vertrag muss festlegen, dass der Anbieter nach dem Ende der Leistung alle personenbezogenen Daten nach deiner Wahl löscht oder zurückgibt.¹⁹ In welcher Form, sagt er nicht. Genau hier kommt die Architektur ins Spiel. Liegt die einzige vollständige Kopie der Einwilligungshistorie bei einem Anbieter, heißt Gehen, seinem Export zu vertrauen. Hält dein eigener Datensatz sie, hat der Anbieter eine Kopie und du das Original. Diese Anbieter auszuwählen und zu prüfen ist eine eigene Aufgabe, beschrieben in Vendor Vetting, bevor sie deine Compliance untergraben.

Rechenbeispiel: Lena verlässt ihr Newsletter Tool

Angenommen, Lena will weg von Klaviyo. Der Export einer Liste oder eines Segments als CSV Datei kann für jedes Profil den Einwilligungsstatus für Mail und SMS samt Zeitstempel enthalten, aber nicht die vollständige Eventhistorie.²⁰ Die Events kommen stattdessen über die API heraus, die standardmäßig 200 Events pro Seite liefert und bis zu 1.000.²¹

Liegt ihre Einwilligungshistorie nur in Klaviyo, bekommt sie aus der CSV Datei den aktuellen Stand und einen Zeitstempel, aber weder den Wortlaut noch die Quelle noch die früheren Änderungen. Führt sie den Datensatz in ihrem eigenen Shop, wie im Beispiel von Jonas, geht nichts verloren, und ihre Bestellungen liegen ohnehin schon in Shopify und in ihrem Data Warehouse. Derselbe Anbieter, eine ganz andere Woche.

Wo eigener Code seinen Platz verdient

Das heißt nicht, dass du alles selbst schreiben sollst. In der alten Fassung dieses Artikels habe ich die Aufteilung beschrieben, die ich nutze, und sie gilt noch. Zapier oder n8n sind gut genug als Kleber für Reaktionen, die nicht kritisch sind und nicht in derselben Sekunde passieren müssen. Wird die Logik ernst, etwa die Marge prüfen, bevor ein Rabatt rausgeht, oder nach Retouren filtern, schreibe ich sie in Python oder Node, direkt gegen den Datensatz.

Bei einem Shop, an dem ich gearbeitet habe, hatte die Regel für die Rückgewinnung drei Bedingungen: seit 45 Tagen keine Bestellung, ein Kundenwert über die gesamte Laufzeit von mehr als 100 und der letzte Artikel nicht zurückgeschickt. Das Newsletter Tool in diesem Projekt konnte keine Retouren sehen, also lief die Regel als geplanter Job gegen das Data Warehouse und verschickte jede Mail über Postmark. Der alte Artikel hat diesen Code gezeigt, und er war falsch: Er nutzte die Adresse und das Nachrichtenformat eines anderen Anbieters. Die API von Postmark erwartet einen POST an https://api.postmarkapp.com/email mit dem Server Token im Header X-Postmark-Server-Token.²² Marketingmails gehören außerdem in einen Broadcast Stream, den Postmark auf einer von Transaktionsmails getrennten Infrastruktur betreibt und der einen Abmeldelink verlangt.²³

Ein Beispiel: der Job für das Teekontor, mit der Prüfung der Einwilligung dort, wo sie hingehört, vor dem Versand.

import os
import requests

def send_winback(customer):
    consent = customer["consents"]["email_marketing"]
    if consent["state"] != "granted":
        return "skipped: no email permission"
    response = requests.post(
        "https://api.postmarkapp.com/email",
        headers={
            "Accept": "application/json",
            "X-Postmark-Server-Token": os.environ["POSTMARK_SERVER_TOKEN"],
        },
        json={
            "From": "lena@teekontorplagwitz.example",
            "To": customer["email"],
            "Subject": "Deine Ostfriesische Mischung geht zur Neige",
            "HtmlBody": render_winback(customer),
            "MessageStream": "winback",
        },
        timeout=10,
    )
    response.raise_for_status()
    return "sent"

Dabei ist winback ein Broadcast Stream, den Lena in Postmark angelegt hat, und render_winback baut die Nachricht samt Abmeldelink. Jonas, dessen Erlaubnis für Mails erteilt ist, würde sie bekommen. Ein Kunde, bei dem email_marketing auf verweigert steht, endet am ersten if, und keine noch so schlaue Segmentierung davor kann daran etwas ändern.

Was ich zuerst einrichten würde

Der Reihe nach, für einen Shop in der Größe des Teekontors:

1. Die Einwilligungsfelder in den Kundendatensatz legen, mit Quelle, Wortlaut und Zeitpunkt. Alles andere hängt davon ab.
2. Die fertigen Integrationen zwischen Shop, Newsletter Tool und Werbeplattformen nutzen und jedes synchronisierte Segment nach den Einwilligungsfeldern filtern.
3. Die tägliche Prüfung ergänzen, die die Zahlen hinein und hinaus vergleicht. Sie ist der unscheinbarste Teil und der mit dem besten Wert.
4. Server Side Tagging oder einen Event Router dazunehmen, wenn das Setup im Browser stimmt und es eine Frage gibt, die er beantwortet.
5. Eigenen Code nur dort bauen, wo die Gewinnschwelle es sagt, oder wo die Logik wirklich deine ist, wie die Regel für die Rückgewinnung.

Und wenn du unter ein paar hundert Bestellungen im Monat liegst und ein einziges Newsletter Tool hast, sind die Schritte eins und zwei das ganze Projekt. Der Rest wäre eine sauber gebaute Antwort auf eine Frage, die du noch gar nicht hast.

Die Tools sind gemietet, der Datensatz gehört dir

Der Kleber steckt nicht in den Tools. Er steckt in der Orchestrierung, und die ruht auf einem Datensatz pro Kunde, der sagt, wer er ist, was er getan hat und was er erlaubt hat. Steht das, wird jedes Tool austauschbar, jede Synchronisierung prüfbar, und jeder neue Kanal startet mit denselben Erlaubnissen. Fehlt es, ist jedes neue Abo ein weiterer Ort, an dem die Wahrheit auseinanderläuft.

Footnotes

1. Klaviyo, Getting started with Shopify, Klaviyo Help Center, 2026, https://help.klaviyo.com/hc/en-us/articles/115005080407

2. Europäisches Parlament und Rat, Verordnung (EU) 2016/679 (Datenschutz Grundverordnung), Artikel 7 Absätze 1 und 3 Bedingungen für die Einwilligung, EUR Lex, 2016, https://eur-lex.europa.eu/legal-content/DE/TXT/HTML/?uri=CELEX:32016R0679

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

4. Bundesministerium der Justiz, Telekommunikation Digitale Dienste Datenschutz Gesetz (TDDDG), § 25 Schutz der Privatsphäre bei Endeinrichtungen, Absätze 1 und 2, Gesetze im Internet, https://www.gesetze-im-internet.de/ttdsg/__25.html

5. Google, EU user consent policy, Google, 2026, https://www.google.com/about/company/user-consent-policy/

6. Google, Get started with Customer Match, Google Ads API documentation, Google for Developers, 2026, https://developers.google.com/google-ads/api/docs/remarketing/audience-segments/customer-match/get-started

7. Bayerisches Landesamt für Datenschutzaufsicht, 8. Tätigkeitsbericht für die Jahre 2017 und 2018, Abschnitt 8.7 Facebook Custom Audience über die Kundenliste, Seiten 58 und 59, 2019, https://www.lda.bayern.de/media/baylda_report_08.pdf

8. Klaviyo, Pricing, Klaviyo, 2026, https://www.klaviyo.com/uk/pricing

9. RudderStack, Pricing, RudderStack, 2026, https://www.rudderstack.com/pricing/

10. Zapier, Plans and pricing, Zapier, 2026, https://zapier.com/pricing

11. Google, Cloud Run setup guide for server side tagging, Tag Platform, Google for Developers, 2026, https://developers.google.com/tag-platform/tag-manager/server-side/cloud-run-setup-guide

12. Google Cloud, Try BigQuery using the sandbox, BigQuery documentation, 2026, https://docs.cloud.google.com/bigquery/docs/sandbox

13. Twilio, Customer data pricing (Segment), Twilio, 2026, https://www.twilio.com/en-us/pricing/customer-data

14. Google, Customer Match policy, Google Ads Help, 2026, https://support.google.com/google-ads/answer/6299717

15. Klaviyo, Getting started with Google Ads, Klaviyo Help Center, 2026, https://help.klaviyo.com/hc/en-us/articles/6353315757211

16. Meta, Customer file Custom Audiences, Marketing API documentation, Meta for Developers, 2026, https://developers.facebook.com/docs/marketing-api/audiences/guides/custom-audiences

17. Shopify, Ignore duplicate webhooks, Shopify developer documentation, 2026, https://shopify.dev/docs/apps/build/webhooks/ignore-duplicates

18. Meta, Handling duplicate Pixel and Conversions API events, Meta for Developers, 2026, https://developers.facebook.com/docs/marketing-api/conversions-api/deduplicate-pixel-and-server-events

19. Europäisches Parlament und Rat, Verordnung (EU) 2016/679 (Datenschutz Grundverordnung), Artikel 28 Absatz 3 Buchstabe g Auftragsverarbeiter, EUR Lex, 2016, https://eur-lex.europa.eu/legal-content/DE/TXT/HTML/?uri=CELEX:32016R0679

20. Klaviyo, How to export a list or segment to a CSV file, Klaviyo Help Center, 2026, https://help.klaviyo.com/hc/en-us/articles/115005078687

21. Klaviyo, Get Events, Klaviyo developer documentation, 2026, https://developers.klaviyo.com/en/reference/get_events

22. Postmark, Sending email with API, Postmark developer documentation, 2026, https://postmarkapp.com/developer/user-guide/send-email-with-api

23. Postmark, Message streams, Postmark, 2026, https://postmarkapp.com/message-streams