Event Tracking und Consent Mode: messen, was du sehen darfst, und den Rest schätzen

Der Punkt: miss, was du sehen darfst, und wisse, was dir fehlt

Ein Shop will wissen, welche Kampagnen verkaufen, und er will dabei im Rahmen des Gesetzes bleiben. Beides zieht in dem Moment auseinander, in dem ein Besucher auf Ablehnen drückt. Nach meiner Erfahrung lösen die meisten Setups diesen Konflikt aus Versehen: Die Tags feuern, bevor überhaupt jemand etwas gedrückt hat, oder der Shop liest ein Dashboard, dem still und leise ein Drittel seiner Verkäufe fehlt.

In diesem Artikel geht es um die Technik dazwischen, mit der Rechnung dazu. Wie sich das deutsche Recht vom österreichischen und vom britischen unterscheidet, steht in einem eigenen Artikel über Cookies und Consent für Shops im DACH Raum. Hier bleibe ich bei einem Shop in Deutschland und beim deutschen Recht.

Ein erfundenes Unternehmen trägt alle Beispiele. Die Rösterei Plagwitz ist eine Kaffeerösterei in Leipzig, die Jana führt. Sie verkauft Bohnen und Brühzubehör online unter roestereiplagwitz.example. Jede Zahl über die Rösterei ist ausgedacht. Das Recht und die Dokumentation von Google sind es nicht, beides ist mit Fußnoten belegt.

Ein Event ist eine Handlung eines Besuchers, aufgeschrieben

Analytics Tools filmen keinen Besuch. Sie halten kleine, benannte Tatsachen fest: hat dieses Produkt angesehen, hat es in den Warenkorb gelegt, hat bezahlt. Jede dieser Tatsachen ist ein Event, mit einem Namen und ein paar Parametern, etwa welches Produkt und zu welchem Preis.

Google Analytics 4 (GA4) veröffentlicht empfohlene Events für Onlineshops, darunter view_item, add_to_cart, begin_checkout, add_payment_info und purchase, und schreibt, dass du in den Berichten die meisten Details bekommst, wenn du sie mit den vorgesehenen Parametern sendest.¹ Nimm diese Namen und erfinde keine eigenen.

Das Event purchase bezahlt alles andere, also lohnt es sich, es genau richtig zu machen. Googles Referenz führt transaction_id und items als Pflichtfelder, und value und currency als Pflicht, sobald Umsatz berechnet werden soll. Die Transaktions ID verhindert, dass eine neu geladene Bestätigungsseite dieselbe Bestellung zweimal zählt.²

Rechenbeispiel: das Purchase Event der Rösterei

Eine Kundin aus Halle kauft eine 1 kg Tüte Hausespresso für 24,00 € und eine Handmühle für 45,00 €. Der Versand kostet 4,50 €. Laut Google soll value die Summe aus Preis mal Menge über alle Artikel sein, ohne Versand und Steuer.² Also:

$$\text{value} = \sum_{i} p_i \, q_i$$

Dabei ist $\text{value}$ die Zahl, die mit dem Event gesendet wird, $p_i$ der Preis von Artikel $i$, $q_i$ die gekaufte Menge von Artikel $i$, und $\sum_i$ heißt, dass du das Ergebnis über alle Artikel im Warenkorb aufaddierst. Es ist eine schlichte Summe von Produkten, und das Summenzeichen wird in Grundlagen: der Mittelwert eingeführt.

Schritt für Schritt: $24{,}00 \times 1 = 24{,}00$, dann $45{,}00 \times 1 = 45{,}00$, dann $24{,}00 + 45{,}00 = 69{,}00$. Der Versand bleibt draußen. Die Bestätigungsseite der Rösterei sendet:

gtag('event', 'purchase', {
  transaction_id: 'RP-10482',
  value: 69.00,
  currency: 'EUR',
  shipping: 4.50,
  items: [
    { item_id: 'ESP-HAUS-1KG', item_name: 'Hausespresso 1 kg', price: 24.00, quantity: 1 },
    { item_id: 'MHL-HAND-01', item_name: 'Handmühle', price: 45.00, quantity: 1 }
  ]
})

Im Code steht der Punkt als Dezimalzeichen, weil JavaScript es so verlangt.

Was das deutsche Recht von dem Code verlangt, der es sendet

Die deutsche Regel ist § 25 des Telekommunikation Digitale Dienste Datenschutz Gesetzes (TDDDG). Absatz 1 sagt: Die Speicherung von Informationen in der Endeinrichtung des Endnutzers oder der Zugriff auf Informationen, die dort bereits gespeichert sind, sind nur zulässig, wenn der Endnutzer auf der Grundlage klarer und umfassender Informationen eingewilligt hat. Information und Einwilligung richten sich nach der Datenschutz Grundverordnung (DSGVO).³ Endeinrichtung ist das Handy oder der Laptop deines Besuchers.

Die Datenschutzkonferenz (DSK), also die gemeinsame Runde der Aufsichtsbehörden des Bundes und der Länder, hat im November 2024 ihre Orientierungshilfe für Anbieter digitaler Dienste in Version 1.2 veröffentlicht, und sie liest den Paragrafen weit. Die Vorschrift ist technikneutral, sie erfasst jede Technik, mit der gespeichert oder ausgelesen wird, auch den Local Storage. Liest ein JavaScript aktiv Eigenschaften eines Geräts aus und schickt sie an einen Server, ist auch das ein Zugriff. Und es kommt nicht darauf an, ob die Information einen Personenbezug hat.⁴ Der Europäische Datenschutzausschuss (EDSA) sagt in seinen Leitlinien zum technischen Anwendungsbereich derselben europäischen Regel, die § 25 umsetzt, dasselbe in noch deutlicheren Worten: Ein JavaScript, das den Browser anweist, Anfragen mit den gewünschten Informationen zu senden, fällt eindeutig darunter, ebenso ein Tracking Pixel, das Informationen an Werbedienste Dritter schickt.⁵ Ein Pixel, Local Storage, ein Fingerprint und ein Skript, das die Bildschirmgröße ausliest, zählen also alle, nicht nur Cookies.

Absatz 2 enthält die Ausnahmen, und es sind genau zwei. Keine Einwilligung braucht, was allein der Übertragung einer Nachricht über ein öffentliches Telekommunikationsnetz dient, und was unbedingt erforderlich ist, damit der Anbieter einen vom Nutzer ausdrücklich gewünschten digitalen Dienst zur Verfügung stellen kann.³ Eine Ausnahme für Statistik gibt es nicht. Großbritannien hat sich 2026 eine solche Ausnahme ins Gesetz geschrieben, Deutschland nicht, und der Unterschied steht im Artikel über Cookies und Consent im DACH Raum.

Die DSK legt "unbedingt erforderlich" streng aus. Gemeint ist technische Erforderlichkeit für den gewünschten Dienst, und dass ein Zugriff für das Geschäftsmodell wirtschaftlich nötig ist, begründet keine Ausnahme. Ein Warenkorbcookie ist erst erforderlich, wenn tatsächlich ein Artikel im Korb liegt, nicht schon beim Stöbern. Selbst die einfache Messung von Besucherzahlen gehört nicht per se zum Dienst, und ob eine Messung ohne Einwilligung geht, lässt sich allenfalls für eine genau definierte Konfiguration und einen genau definierten Zweck sagen.⁴ Auch der Zeitpunkt ist geregelt: Die Einwilligung muss vorliegen, bevor zugegriffen wird. Cookies beim ersten Seitenaufruf setzen und erst danach fragen ist unzulässig, und solange das Banner angezeigt wird, laden keine Skripte, die auf das Gerät zugreifen könnten, soweit dafür eine Einwilligung nötig ist.⁴

Was danach mit personenbezogenen Daten geschieht, regelt nicht mehr § 25, sondern die DSGVO. Die DSK trennt die beiden Schritte ausdrücklich: erst der Zugriff auf das Gerät, dann die Verarbeitung der Daten.⁴ Für Tracking taugt das berechtigte Interesse nach Artikel 6 Absatz 1 Buchstabe f DSGVO laut DSK nur in wenigen Konstellationen, und verarbeitet ein eingebundener Dienstleister die Daten auch für eigene Zwecke, ist es für die Übermittlung in der Regel keine wirksame Grundlage, nicht einmal für die IP Adresse.⁴⁶ Eine Liste, auf der wie beim britischen ICO das Wort Conversions steht, hat die DSK nicht geschrieben. Sie braucht sie auch nicht: Werbung erfüllt keine der zwei Ausnahmen, und die DSK nennt die Wirtschaftlichkeit von Werbeanzeigen ausdrücklich als Interesse des Betreibers, nicht des Besuchers.⁴ Conversion Tracking für Werbung braucht in Deutschland ein Ja.

Die Orientierungshilfe ist kein Gesetz, das letzte Wort haben die Gerichte. Sie ist aber der Maßstab, mit dem die Aufsichtsbehörden prüfen, und sie sagt das selbst.⁴

Rechenbeispiel: die Tags der Rösterei auf drei Stapel sortieren

Janas Seite setzt oder liest sieben Dinge.

1. Das Warenkorbcookie, sobald etwas im Korb liegt: unbedingt erforderlich, keine Einwilligung. Vorher nicht.⁴
2. Die Login Session, sobald sich jemand einloggt: unbedingt erforderlich, weil der Besucher die Funktion bewusst nutzt.⁴
3. Das Cookie, das die Einwilligungsentscheidung speichert: unbedingt erforderlich, solange es nur die Entscheidung enthält und keine eindeutige Kennung.⁴
4. Ein selbst gehosteter Seitenzähler, der nur Tagessummen pro Seite behält und nichts teilt: Eine Statistik Ausnahme, unter die er fallen könnte, gibt es nicht. Ohne Einwilligung geht er nur, wenn er das Gerät gar nicht berührt, also die Seitenaufrufe auf dem Server aus dem Log zählt, ohne Cookie, ohne Skript, ohne Pixel. Dann wird nichts gespeichert und nichts ausgelesen, und übrig bleibt eine DSGVO Frage für die IP Adresse im Log: berechtigtes Interesse, Hinweis in der Datenschutzerklärung, Widerspruchsrecht.⁴⁶ Läuft er als JavaScript im Browser oder setzt er ein Cookie, braucht er ein Ja.
5. GA4: braucht eine Einwilligung. Es setzt Cookies und liest per Skript aus dem Gerät, und eine Ausnahme, unter die es fallen könnte, gibt es in Deutschland nicht.
6. Das Google Ads Conversion Tag: braucht eine Einwilligung, denn Werbung ist keine der zwei Ausnahmen.⁴
7. Das Meta Pixel: braucht eine Einwilligung, aus demselben Grund.⁵

Drei Dinge laufen also, bevor das Banner angefasst wird, eines kann ohne Einwilligung laufen, aber nur in der serverseitigen Form, die nichts auf dem Gerät tut, und drei warten auf ein Ja. Die Zahl der Stapel ist dieselbe wie in Großbritannien, ihr Inhalt nicht ganz: Der Zähler hat in Deutschland keine Ausnahme, auf die er sich stützen kann, er muss sich aus dem Anwendungsbereich von § 25 heraushalten, und für GA4 gibt es kein "es sei denn".

Ablehnen muss gleichwertig neben Akzeptieren stehen, nach der DSK ein in Größe, Farbe, Kontrast und Schriftbild vergleichbarer Button, und ein Button "Einstellungen oder Ablehnen", der auf eine zweite Ebene führt, reicht nicht. Gespeichert oder ausgelesen wird erst nach der aktiven Handlung.⁴ Warum es eine Haftung ist, Leute in ein Ja zu schubsen, steht im Artikel über Dark Patterns im Consent Design.

Der Consent Mode ist ein Bote zwischen Banner und Tags

Das Banner holt die Antwort ein. Der Consent Mode, auf Deutsch Einwilligungsmodus, ist Googles Schnittstelle, die diese Antwort zu jedem Google Tag auf der Seite trägt, und die Tags ändern daraufhin ihr Verhalten.⁷

Für Messung und Werbung zählen vier Signale.⁷

• ad_storage: Dürfen Werbecookies gespeichert werden?
• analytics_storage: Dürfen Analytics Cookies gespeichert werden?
• ad_user_data: Dürfen Nutzerdaten für Werbung an Google gesendet werden?
• ad_personalization: Dürfen diese Daten für personalisierte Werbung genutzt werden?

Die letzten beiden meinen alle, wenn sie Consent Mode v2 sagen. Google hat sie eingeführt, um seine Richtlinie zur Einwilligung der Nutzer in der EU durchzusetzen.⁸ Diese Richtlinie gilt für Endnutzer im Europäischen Wirtschaftsraum, in Großbritannien und in der Schweiz. Sie verlangt eine rechtswirksame Einwilligung für Cookies, wo das Gesetz sie verlangt, eine Einwilligung für personalisierte Werbung, und Nachweise über die eingeholten Einwilligungen.⁹ Das ist eine Vertragsbedingung von Google, kein Gesetz, aber ein deutscher Shop mit Google Ads ist trotzdem daran gebunden.

Google führt außerdem functionality_storage, personalization_storage und security_storage als Einwilligungstypen.⁷ Die alte Fassung dieses Artikels hat einen davon zu den Kernsignalen gezählt und die zwei Signale aus v2 weggelassen. Das war falsch.

Jede Seite braucht zwei Befehle. Einen Default, der den Zustand festlegt, bevor irgendetwas gemessen wird, und ein Update, das das Banner sendet, sobald der Besucher entschieden hat.¹⁰

Rechenbeispiel: Default und Update der Rösterei

Auf jeder Seite von roestereiplagwitz.example, ganz oben im Head, vor dem Google Tag:

window.dataLayer = window.dataLayer || []
function gtag() { dataLayer.push(arguments) }
gtag('consent', 'default', {
  ad_storage: 'denied',
  ad_user_data: 'denied',
  ad_personalization: 'denied',
  analytics_storage: 'denied',
  wait_for_update: 500
})

Alles beginnt auf verweigert, weil in Deutschland nichts außerhalb der Ausnahmen vor der Einwilligung laufen darf.⁴ Der Wert von wait_for_update ist in Millisekunden angegeben. Er sagt den Tags, eine halbe Sekunde zu warten, falls das Banner langsam lädt und eine gespeicherte Antwort weitergeben will.¹⁰ Google erlaubt außerdem pro Region einen eigenen Default über einen ISO 3166 Code, was nützlich ist, wenn eine Seite mehrere Länder mit unterschiedlichen Regeln bedient.¹⁰ Jana verkauft nur in Deutschland, also reicht ein Default für alle.

Drückt ein Besucher auf Akzeptieren, ruft das Banner auf:

gtag('consent', 'update', {
  ad_storage: 'granted',
  ad_user_data: 'granted',
  ad_personalization: 'granted',
  analytics_storage: 'granted'
})

Wer Analytics akzeptiert, Werbung aber ablehnt, bekommt analytics_storage auf erteilt, und die drei Werbesignale bleiben auf verweigert. Das Banner sollte das Update senden, sobald der Besucher damit interagiert, und auf jeder weiteren Seite die gespeicherte Antwort erneut senden.¹⁰

Die Reihenfolge entscheidet: Der Default muss zuerst kommen

Googles eigene Dokumentation sagt es ohne Umschweife: Die Reihenfolge des Codes ist entscheidend, und wird der Einwilligungscode in der falschen Reihenfolge aufgerufen, funktionieren die Defaults nicht. Der Default muss vor jedem Befehl laufen, der Messdaten sendet, etwa config oder event. Für gtag.js heißt das: erst das Default Snippet, dann das Google Tag, dann dein Consent Tool.¹⁰

Hier finde ich die meisten Fehler. Das GA4 Tag feuert beim Seitenaufruf, das Consent Template ein paar Millisekunden später, und dazwischen hat das Tag getan, was Tags eben tun. Das Banner sieht perfekt aus, und das Gesetz ist schon gebrochen. Die DSK verlangt genau das Gegenteil: Die Einwilligung liegt vor, bevor zugegriffen wird.⁴

Lies den Ablauf von oben. Die ersten beiden Kästen passieren, bevor der Besucher irgendetwas gesehen hat, und sie entscheiden, ob das Setup rechtmäßig ist. Der Entscheidungskasten ist das Banner. Erst danach handeln die Tags nach einer echten Antwort. Der letzte Kasten erinnert daran, dass die Bestellung in der Datenbank des Shops steht, egal was der Besucher gedrückt hat. Wenn du nach deutschem Recht den Basic Mode wählst, wovon gleich die Rede ist, lädt das Google Tag im zweiten Kasten noch gar nicht, sondern erst nach dem Update.

Rechenbeispiel: den Fehler auf der Produktseite der Rösterei finden

Ich öffne eine Produktseite in einem privaten Fenster, mit offenem Netzwerk Tab, und rühre das Banner nicht an. Erster Schritt: Ich filtere die Anfragen nach collect. Eine geht nach 140 Millisekunden an GA4. Zweiter Schritt: Ich lese ihre Parameter. Der Consent Mode kodiert den Speicherzustand im Parameter gcs und den detaillierten Zustand in gcd.⁷ Zeigt die erste Anfrage Analytics Speicherung als erteilt, oder taucht ein _ga Cookie im Speicher Tab auf, bevor ich irgendetwas gedrückt habe, kam der Default zu spät. Dritter Schritt: Ich öffne Janas Google Tag Manager Container und finde die Ursache, eine Trigger Ausnahme aus einem Test, die das Consent Template auf Produktseiten nicht feuern lässt. Vierter Schritt: Ich entferne sie, lade neu und prüfe, dass die erste Anfrage jetzt verweigert trägt und kein _ga Cookie existiert, bis ich auf Akzeptieren drücke. Zehn Minuten, und nach meiner Erfahrung der häufigste Fehler im Tracking eines deutschen Shops.

Basic und Advanced Mode senden bei einem Nein Unterschiedliches

Den Consent Mode gibt es in zwei Formen, und am stärksten unterscheiden sie sich, wenn ein Besucher ablehnt.⁷

Im Basic Mode sind die Google Tags blockiert, bis der Besucher mit dem Banner interagiert. Lehnt er ab, geht überhaupt nichts an Google, nicht einmal die Tatsache, dass er abgelehnt hat.

Im Advanced Mode laden die Tags sofort, die Einwilligung steht standardmäßig auf verweigert, und solange sie verweigert ist, senden sie das, was Google Messungen ohne Cookies nennt, meist cookielose Pings genannt. Google listet auf, was diese Pings enthalten: funktionale Informationen wie einen Zeitstempel, den User Agent und den Referrer, ob die aktuelle oder eine frühere Seite der Session Informationen zu einem Anzeigenklick in der URL hatte, den Einwilligungsstatus, und eine Zufallszahl, die bei jedem Seitenaufruf neu erzeugt wird.⁷ Google nutzt die Pings, um die Conversions zu modellieren, die es nicht beobachten kann, und schreibt, dass der Advanced Mode ein werbetreibendenspezifisches Modell liefert statt eines allgemeinen.⁷

Jetzt der ehrliche Teil für einen Shop in Deutschland, und hier komme ich zu einem strengeren Ergebnis als für Großbritannien. Der Advanced Mode lädt ein JavaScript von Google, bevor der Besucher entschieden hat, und dieses Skript weist den Browser an, Informationen an Google zu senden. Genau das zählt der EDSA ausdrücklich zum Anwendungsbereich der Regel, die § 25 TDDDG umsetzt, und er nennt dabei sogar den User Agent als etwas, dessen Erfassung darunter fallen kann.⁵ Die DSK wertet das aktive Auslesen von Geräteeigenschaften per JavaScript als Zugriff und schreibt, dass während das Banner angezeigt wird, keine Skripte laden, die auf das Gerät zugreifen könnten, soweit dafür eine Einwilligung nötig ist.⁴ Dazu kommt die DSGVO Seite: Verarbeitet ein Dienstleister die Daten auch für eigene Zwecke, trägt laut DSK in der Regel nicht einmal für die IP Adresse das berechtigte Interesse.⁴ Ob Google die Pings nur für dich auswertet, kannst du von außen nicht prüfen.

Ich habe keine Stellungnahme einer deutschen Aufsichtsbehörde gefunden, die cookielose Pings ausdrücklich erlaubt, und keine, die sie beim Namen nennt und verbietet. Gemessen an dem, was DSK und EDSA geschrieben haben, halte ich den Advanced Mode vor der Einwilligung in Deutschland aber für schwer zu verteidigen. Für einen deutschen Shop ist der Basic Mode deshalb mein Standard, und wer den Advanced Mode will, sollte sich von seinem eigenen Anwalt schriftlich begründen lassen, warum er hier zulässig sein soll.

Rechenbeispiel: ein Besucher, zwei Modi

Ein Besucher aus Chemnitz klickt auf eine Anzeige der Rösterei, landet auf der Seite der Handmühle, drückt auf Ablehnen, sieht sich zwei weitere Seiten an und kauft die Handmühle für 45,00 €.

Im Basic Mode lädt das Google Tag auf keiner der vier Seiten. Google erhält nichts. Der Anzeigenklick erscheint in Google Ads, der Verkauf nicht. Janas Datenbank verbucht die Bestellung.

Im Advanced Mode sendet das Tag auf jeder der vier Seiten einen cookielosen Ping, mit Einwilligungsstatus, Zeitstempel, User Agent, Referrer, einem Hinweis auf den Anzeigenklick und einer frischen Zufallszahl. Es wird kein Cookie geschrieben, also verbindet keine gespeicherte Kennung die vier Pings. Der Verkauf wird trotzdem nicht beobachtet, auch wenn Google einen Teil solcher Verkäufe modellieren kann, falls das Konto die Schwellenwerte weiter unten erreicht. Janas Datenbank verbucht die Bestellung. So oder so beobachtet Google Ads hier null Conversions. Der einzige Unterschied ist, ob Google Material zum Schätzen bekommt, und in Deutschland ist genau dieses Material die rechtlich heikle Stelle.

Server Side Tagging verschiebt die Tags, nicht die Pflicht

Beim Server Side Tagging steht ein Tag Server auf deiner eigenen Domain zwischen Browser und Anbietern, und der Server entscheidet, was weitergeleitet wird. Google empfiehlt, den Server auf der eigenen First Party Domain zu betreiben, schreibt, dass du volle Kontrolle darüber hast, wie die Daten aussehen und wohin sie gehen, und dass nur du Zugriff auf die Daten im Server hast, bis du sie weiterschickst.¹¹

Diese Kontrolle ist echt. Du kannst die IP Adresse entfernen, Parameter streichen, die einen Anbieter nichts angehen, und das Skript eines Anbieters ganz aus dem Browser heraushalten. Weniger fremde Skripte im Browser heißt weniger Zugriffe auf das Gerät, und das ist ein echter Gewinn.

Was es nicht tut, ist das Recht ändern. Der Browser führt weiterhin Code aus, der Events sendet, also gilt § 25 TDDDG weiterhin für alles, was auf dem Gerät passiert.³⁴ Die DSK verlangt außerdem, dass Besucher erfahren, wer auf ihr Gerät zugreift, zu welchem Zweck und ob Dritte Zugriff erhalten, und das gilt auch dann, wenn die Daten erst auf deinem Server an diese Dritten gehen.⁴ Und der Server muss denselben Einwilligungsstatus respektieren, den der Browser hatte. Ein Tag Server, der abgelehnte Besucher an Meta weiterleitet, weil das Pixel nicht mehr im Browser läuft, hat kein Problem gelöst, er hat eines versteckt.

Es kostet auch Geld. Googles eigene Anleitung für Cloud Run setzt pro Server etwa 45 US Dollar im Monat an, empfiehlt mindestens zwei Instanzen, damit ein Ausfall keine Daten kostet, und rechnet damit, dass zwei bis zehn Server 35 bis 350 Anfragen pro Sekunde bewältigen.¹²

Rechenbeispiel: was der Tag Server der Rösterei kostet und tut

Janas Seite hat etwa 1.000 Sessions am Tag. Bei 20 Events pro Session sind das 20.000 Events am Tag, weniger als eine Anfrage pro Sekunde, also sind zwei Instanzen schlicht Googles Untergrenze. Kosten nach Googles Zahl: $2 \times 45 = 90$ US Dollar im Monat, vor Trafficgebühren, von Google in Dollar abgerechnet.

Was Jana dafür bekommt: Der Tag Server läuft unter tag.roestereiplagwitz.example. Kommt ein purchase mit Einwilligung an, leitet der Server es mit der Klick ID an GA4 und Google Ads weiter, und an Meta, jeweils ohne IP Adresse. Kommt ein purchase an, bei dem Werbung abgelehnt wurde, leitet der Server nichts an Google Ads oder Meta weiter. Für einen Shop dieser Größe kommt aus meiner Sicht zuerst ein korrektes Consent Setup im Browser, und der Tag Server ist das zweite Projekt, nicht die Reparatur des ersten. Den vollständigen Aufbau zeigt mein technischer Guide zum Server Side Tracking.

Deine eigene Datenbank sieht jede Bestellung, also lass sie

Ein Besucher, der Cookies ablehnt, bestellt trotzdem. Die Bestellung ist ein Vertrag zwischen ihm und dem Shop, und der Shop speichert sie in seiner eigenen Datenbank, um ihn zu erfüllen, auf der Vertragsgrundlage der DSGVO.⁶ Dieser Datensatz hängt an keinem Tag.

Das ist die nützlichste Tatsache im ganzen Thema. Die Plattformen sehen den Anteil der Verkäufe mit Einwilligung, der Shop sieht alle. Trägt die Bestellung außerdem den Einwilligungsstatus zum Zeitpunkt des Kaufs, den der Shop kennt, weil er die Entscheidung im unbedingt erforderlichen Consent Cookie speichert, dann kann der Shop Bestellungen mit und ohne Einwilligung getrennt zählen.

Was der Shop aus diesen Datensätzen weitergibt, regelt meine eigene Regel, und ich formuliere sie als meine Praxis, nicht als Auslegung des Gesetzes. Eine Bestellung mit Einwilligung geht als Standardevent an die Plattformen, purchase, mit ihren Kennungen. Eine Bestellung ohne Einwilligung wird aus allem herausbenannt, worauf eine Werbeplattform optimiert oder woraus sie Zielgruppen baut. Sie wird zu purchase_nc, ohne Klick ID, ohne Cookie ID, ohne gehashte Mailadresse. Sie wird nie auf eine Conversion Aktion gemappt und ist nie für eine Remarketing Zielgruppe zugelassen. Ihr einziger Zweck ist, dass die Summe im eigenen Bericht des Shops zur Datenbank passt.

Warum eine Umbenennung statt eines Flags: Die Leute, die Werbekonten betreuen, wechseln, und ein anderer Name lässt sich viel schwerer aus Versehen missbrauchen als eine vergessene Einstellung.

Rechenbeispiel: der Oktober der Rösterei in der Datenbank

Im Oktober enthält Janas Datenbank 470 Webbestellungen. Jede trägt den Einwilligungsstatus, der beim Checkout gespeichert war. Die Abfrage ist eine einfache Zählung, gruppiert nach diesem Status:

SELECT ads_consent, COUNT(*) AS orders, SUM(item_total) AS revenue
FROM orders
WHERE completed_at >= '2026-10-01' AND completed_at < '2026-11-01'
GROUP BY ads_consent

Sie liefert 372 Bestellungen mit Werbeeinwilligung und 98 ohne. Die 98 blieben in Janas eigenem Reporting als purchase_nc. Die Summe, 470, ist die Wahrheit für Oktober, und sie braucht kein Modell. Willst du die Daten in einem Data Warehouse mit den Kampagnenkosten zusammenführen, zeigt das BigQuery Setup für einen Rails und Solidus Shop die Verrohrung.

Schätzen, was die Plattformen nicht sehen

Die Datenbank liefert die Summe. Die Werbeplattform liefert den Teil mit Einwilligung, zugeordnet zu Kampagnen. Die Lücke auf Kampagnen zu verteilen, oder sie dort zu schätzen, wo Bestellungen keinen Einwilligungsstatus tragen, braucht eine ehrliche Annahme.

Die alte Fassung dieses Artikels hatte dafür diese Formel, und sie ist gut:

$$C_{\text{total}} \approx C_{\text{obs}} + S_{\text{ref}} \times CR_{\text{con}} \times \alpha$$

Dabei ist $C_{\text{total}}$ die geschätzte Gesamtzahl der Conversions, $C_{\text{obs}}$ die Zahl, die bei einwilligenden Besuchern beobachtet wurde, $S_{\text{ref}}$ die Zahl der Sessions ablehnender Besucher, $CR_{\text{con}}$ die Conversion Rate der einwilligenden Sessions, und $\alpha$ gibt als Bruchteil an, wie die Conversion Rate der Ablehnenden im Vergleich zu der der Einwilligenden ausfällt. Der Term $S_{\text{ref}} \times CR_{\text{con}} \times \alpha$ ist eine Quote, angewandt auf eine Anzahl, das steht in Grundlagen: Verhältnisse und Quoten, und $\alpha$ zu wählen ist eine Frage bedingter Wahrscheinlichkeit, das steht in Grundlagen: Wahrscheinlichkeit.

Falsch war in der alten Fassung die Größe von $\alpha$. Dort stand, $\alpha$ liege typischerweise zwischen 0,7 und 0,9. Googles eigene Seite zur Modellierung sagt, dass Nutzer mit Einwilligung typischerweise zwei bis fünf Mal so oft konvertieren wie Nutzer ohne, je nach Einwilligungsquote, Branche und Art der Conversion.¹³ Zwei bis fünf Mal so oft heißt $\alpha$ zwischen $1/5 = 0{,}2$ und $1/2 = 0{,}5$. So oder so überschätzen 0,7 bis 0,9 die verborgenen Verkäufe, also habe ich es korrigiert.

Rechenbeispiel: der Oktober der Rösterei, dreimal geschätzt

Janas Banner protokolliert nur die Entscheidung, aggregiert gezählt. Sie weiß also, dass von 30.000 Sessions im Oktober 18.600 eine Werbeeinwilligung hatten und 11.400 nicht. Der Anteil der Einwilligenden ist:

$$r = \frac{S_{\text{con}}}{S_{\text{con}} + S_{\text{ref}}}$$

$r$ ist die Einwilligungsquote, $S_{\text{con}}$ die Zahl der einwilligenden Sessions und $S_{\text{ref}}$ die Zahl der ablehnenden. Also $r = 18.600 / 30.000 = 0{,}62$, oder 62 %. Die Grundlage dafür ist Grundlagen: Verhältnisse und Quoten.

Die einwilligenden Sessions brachten die 372 beobachteten Bestellungen. Ihre Conversion Rate ist $CR_{\text{con}} = 372 / 18.600 = 0{,}02$, oder 2 %.

Kauften Ablehnende genauso oft, $\alpha = 1$, hätten sie $11.400 \times 0{,}02 \times 1 = 228$ Bestellungen gebracht, und die Summe wäre $372 + 228 = 600$.

Am oberen Ende von Googles Spanne, $\alpha = 0{,}5$: $11.400 \times 0{,}02 \times 0{,}5 = 114$, Summe $372 + 114 = 486$.

Am unteren Ende, $\alpha = 0{,}2$: $11.400 \times 0{,}02 \times 0{,}2 = 45{,}6$, also etwa 46, Summe $372 + 46 = 418$.

Die Datenbank sagt 470.

Die horizontale Achse zeigt drei Schätzungen, jede mit einem anderen $\alpha$, und die gezählte Zahl. Die vertikale Achse zeigt Bestellungen. Aus denselben Sessionzahlen wandert die Schätzung je nach einer einzigen Annahme von 418 auf 600, und wer annimmt, dass Ablehnende sich wie Einwilligende verhalten, überschätzt den Monat um 130 Bestellungen. Die Datenbank entscheidet.

Sie erlaubt Jana auch, $\alpha$ für ihren eigenen Shop zu messen, statt eine fremde Zahl zu borgen. Dreh die Formel um:

$$\alpha = \frac{O_{\text{ref}}}{S_{\text{ref}} \times CR_{\text{con}}}$$

$O_{\text{ref}}$ ist die Zahl der Bestellungen ablehnender Besucher, gezählt in der Datenbank, und $S_{\text{ref}}$ und $CR_{\text{con}}$ sind wie oben. Mit den Oktoberzahlen: $\alpha = 98 / (11.400 \times 0{,}02) = 98 / 228 \approx 0{,}43$. Das liegt innerhalb von Googles Spanne von 0,2 bis 0,5, was beruhigt, und es ist Janas Zahl, kein Branchendurchschnitt. Monatlich gemessen sagt sie ihr, wie weit sie das hochrechnen muss, was die Werbeplattform meldet. Grundlagen: Verhältnisse und Quoten erklärt das Umstellen.

Googles Modellierung hat Schwellenwerte, die ein kleiner Shop vielleicht nie erreicht

Google füllt einen Teil der Lücke selbst, aber nicht für jeden. Für die Conversion Modellierung in Google Ads nennt die Hilfeseite einen Schwellenwert von 700 Anzeigenklicks über einen Zeitraum von sieben Tagen, pro Land und Domaingruppe. Sie beschreibt die Modellierung als Analyse beobachtbarer Daten und historischer Trends, mit dem Ziel, Überschätzung möglichst gering zu halten, und nennt eine Illustration: Ein Werbetreibender mit 50 % Einwilligungsquote holte durch die Modellierung 18 % mehr Conversions zurück.¹³

Für GA4 braucht die Verhaltensmodellierung ablehnender Besucher den Consent Mode in der Advanced Form auf jeder Seite, also Tags, die vor dem Banner laden, mindestens 1.000 Events am Tag mit verweigerter Analytics Speicherung an mindestens sieben Tagen, und mindestens 1.000 Nutzer am Tag mit erteilter Analytics Speicherung an mindestens sieben der letzten 28 Tage. Selbst dann ist die Berechtigung nicht garantiert, und die modellierten Daten erscheinen nur, wenn die Identität für die Berichterstellung der Property auf Zusammengeführt steht.¹⁴ Für einen deutschen Shop, der aus den oben genannten Gründen im Basic Mode bleibt, ist die GA4 Modellierung damit ohnehin vom Tisch.

Rechenbeispiel: Erfüllt die Rösterei die Voraussetzungen?

Zuerst Google Ads. Jana kauft etwa 2.700 Anzeigenklicks im Monat, rund 90 am Tag. Über sieben Tage sind das $90 \times 7 = 630$ Klicks. Ob du Googles Formulierung als 700 am Tag oder als 700 in der Woche liest, 630 reichen nicht. Keine Modellierung in Google Ads.

Dann GA4. Etwa 1.000 Sessions am Tag, davon lehnen 38 % ab, also rund 380 ablehnende Sessions am Tag. Bei etwa 20 Events pro Session sind das $380 \times 20 = 7.600$ Events am Tag mit verweigerter Speicherung, deutlich über 1.000. Einwilligende Nutzer sind es aber höchstens etwa $1.000 \times 0{,}62 = 620$ am Tag, und als Nutzer gezählt weniger als als Sessions. Das liegt unter den 1.000 Nutzern am Tag, die Google verlangt. Auch keine Modellierung in GA4, und im Basic Mode wäre sie sowieso ausgeschlossen.

Die modellierten Zahlen, die Agenturen gern in ihre Präsentationen packen, wird Jana also schlicht nicht zu sehen bekommen. Die Schätzung, die auf ihrer eigenen Datenbank aufsetzt, ist die einzige, die sie hat, und nach meiner Erfahrung gilt das für die meisten unabhängigen Shops in Deutschland.

Was ich bauen würde, in dieser Reihenfolge

Käme Jana zu mir, würde ich in dieser Reihenfolge arbeiten.

1. Die Ladereihenfolge: der Consent Default zuerst auf jeder Seite, dann das Google Tag, dann das Banner, getestet Seitentyp für Seitentyp.
2. Das Banner: Ablehnen und Akzeptieren gleichwertig auf der ersten Ebene, nichts außerhalb der Ausnahmen vor dem Klick, ein Link im Footer, um die Entscheidung zu ändern, die Entscheidung für die Bestellung gespeichert.⁴
3. Der Eventplan: Googles empfohlene Namen und ein korrektes purchase.¹²
4. Der Basic Mode als Standard, und der Advanced Mode nur, wenn der eigene Anwalt schriftlich begründet, warum die cookielosen Pings vor der Einwilligung zulässig sein sollen.
5. Die eigene Zählung des Shops: Einwilligungsstatus an jeder Bestellung, die Umbenennungsregel, und $\alpha$ monatlich gegen die Datenbank gemessen.
6. Nur wenn der Shop die Kontrolle braucht, ein Tag Server, der denselben Einwilligungsstatus respektiert und seine Drittanbieter offenlegt.⁴¹¹

Nichts davon ist exotisch. Es ist sorgfältige Verrohrung, und sie bringt Zahlen, auf die Jana Budgets setzen kann, und ein Setup, das sie der sächsischen Datenschutzaufsicht erklären kann, ohne ins Schwitzen zu kommen. Die Strategie darüber steht in meinem Artikel über Privacy First Growth Hacking.

Quellen

Footnotes

1. Google, [GA4] Empfohlene Ereignisse, Google Analytics Hilfe, https://support.google.com/analytics/answer/9267735?hl=de

2. Google, Empfohlene Ereignisse, Referenz, purchase, Google for Developers, Google Analytics, https://developers.google.com/analytics/devguides/collection/ga4/reference/events?hl=de

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

4. Konferenz der unabhängigen Datenschutzaufsichtsbehörden des Bundes und der Länder (DSK), Orientierungshilfe der Aufsichtsbehörden für Anbieter:innen von digitalen Diensten (OH Digitale Dienste), Version 1.2, Randnummern 2, 21 bis 26, 36, 37, 74 bis 81, 84, 88 bis 90, 109 bis 111, 121, 122 und 135 bis 137, DSK, November 2024, https://www.datenschutzkonferenz-online.de/media/oh/OH_Digitale_Dienste.pdf

5. Europäischer Datenschutzausschuss, Leitlinien 2/2023 zum technischen Anwendungsbereich von Artikel 5 Absatz 3 der Datenschutzrichtlinie für elektronische Kommunikation, Version 2.0, Randnummern 33, 34, 43 und 51, EDSA, 7. Oktober 2024, https://www.edpb.europa.eu/system/files/documents/2025-02/edpb_guidelines_202302_technical_scope_art_53_eprivacydirective_v2_de.pdf

6. Verordnung (EU) 2016/679 (Datenschutz Grundverordnung), Artikel 6 Absatz 1 Buchstaben b und f, Artikel 13 und Artikel 21, EUR Lex, 2016, https://eur-lex.europa.eu/legal-content/DE/TXT/HTML/?uri=CELEX:32016R0679

7. Google, Einwilligungsmodus, Übersicht, Google for Developers, Tag Platform, https://developers.google.com/tag-platform/security/concepts/consent-mode?hl=de

8. Google, Aktualisierung des Einwilligungsmodus für Traffic im Europäischen Wirtschaftsraum (EWR), Google Ads Hilfe, https://support.google.com/google-ads/answer/13695607?hl=de

9. Google, Richtlinie zur Einwilligung der Nutzer in der EU, Google, https://www.google.com/about/company/user-consent-policy/?hl=de

10. Google, Einwilligungsmodus auf Websites einrichten, Google for Developers, Tag Platform, https://developers.google.com/tag-platform/security/guides/consent?hl=de

11. Google, Einführung in das serverseitige Tagging, Google for Developers, Tag Manager, https://developers.google.com/tag-platform/tag-manager/server-side/intro?hl=de

12. Google, Serverseitiges Tagging mit Cloud Run einrichten, Google for Developers, Tag Manager, https://developers.google.com/tag-platform/tag-manager/server-side/cloud-run-setup-guide?hl=de

13. Google, Modellierung für den Einwilligungsmodus, Google Ads Hilfe, https://support.google.com/google-ads/answer/10548233?hl=de

14. Google, [GA4] Verhaltensmodellierung für den Einwilligungsmodus, Google Analytics Hilfe, https://support.google.com/analytics/answer/11161109?hl=de