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 österreichische Recht vom deutschen 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 Österreich und beim österreichischen Recht.

Ein erfundenes Unternehmen trägt alle Beispiele. Die Rösterei Urfahr ist eine Kaffeerösterei in Linz, die Jana führt. Sie verkauft Bohnen und Brühzubehör online unter roestereiurfahr.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 zahlt 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 Wels kauft ein 1 kg Sackerl Hausespresso um € 24,00 und eine Handmühle um € 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: 'RU-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 österreichische Recht von dem Code verlangt, der es sendet

Die österreichische Regel ist § 165 Absatz 3 des Telekommunikationsgesetzes 2021 (TKG 2021). Anbieter eines Dienstes der Informationsgesellschaft, also auch dein Shop, müssen den Nutzer informieren, welche personenbezogenen Daten sie verarbeiten, auf welcher Rechtsgrundlage, zu welchen Zwecken und wie lange. Ermitteln dürfen sie diese Daten nur, wenn der Nutzer seine Einwilligung aktiv und auf Grundlage klarer und umfassender Informationen erteilt hat.³ Das Wort "aktiv" steht bei uns ausdrücklich im Gesetz.

Der österreichische Wortlaut ist anders gebaut als der deutsche. Er spricht von personenbezogenen Daten und ihrer Ermittlung, nicht von Informationen in der Endeinrichtung, also dem Handy oder dem Laptop deines Besuchers. Die Datenschutzbehörde (DSB) liest ihn trotzdem weit, als Umsetzung von Artikel 5 Absatz 3 der europäischen Datenschutzrichtlinie für elektronische Kommunikation. Sie schreibt in ihren FAQ zu Datenschutz und Cookies, dass § 165 Absatz 3 nicht nur für Cookies gilt, sondern allgemein für die technische Speicherung oder den Zugang auf Endgeräten, und dass die Informationspflicht für nicht notwendige Cookies laut Europäischem Gerichtshof gilt, egal ob es um personenbezogene Daten geht oder nicht.⁴ Der Europäische Datenschutzausschuss (EDSA) sagt in seinen Leitlinien zum technischen Anwendungsbereich derselben europäischen Regel 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.

Danach folgen die Ausnahmen, und es sind genau zwei. Keine Einwilligung braucht, was allein der Übertragung einer Nachricht über ein Kommunikationsnetz dient, und was unbedingt erforderlich ist, damit der Anbieter einen vom Nutzer ausdrücklich gewünschten 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, Österreich nicht, und der Unterschied steht im Artikel über Cookies und Consent im DACH Raum.

Die DSB legt "unbedingt erforderlich" als technisch notwendig aus. Ihre Liste ist kurz: die notwendige Sitzungsverwaltung, etwa Cookies für den Warenkorb bei einem Onlinekauf oder für den Login Status, Eingaben in einem Formular, das über mehrere Unterseiten geht, und die Information über den Einwilligungsstatus, solange dafür keine eindeutige Online Kennung vergeben wird. Nicht notwendig sind laut DSB vor allem Dienste, die das Verhalten von Besuchern auf der Website oder über mehrere Websites aufzeichnen und auswerten, allen voran Plugins von Social Media Diensten und Werbenetzwerken. Und nach der Judikatur der DSB und des Bundesverwaltungsgerichts wird ein Werbecookie nicht notwendig, bloß weil die Werbung den Betrieb der Website finanziert.⁴ Im Zweifel empfiehlt die DSB die Kriterien der früheren Artikel 29 Datenschutzgruppe aus deren Stellungnahme 4/2012.⁴ Auch der Zeitpunkt ist geregelt: erst die Einwilligung, dann die Cookies. Beim Bau einer Website ist laut DSB dringend darauf zu achten, dass kein technisch nicht notwendiges Cookie gesetzt wird, bevor die Einwilligung da ist.⁴

Was danach mit personenbezogenen Daten geschieht, regelt nicht mehr das TKG 2021, sondern die Datenschutz Grundverordnung (DSGVO). Die DSB trennt die beiden Schritte ausdrücklich: Die Einwilligung muss das Setzen und Auslesen der Cookies abdecken und die darauffolgende Datenverarbeitung, und beides misst sie an den Bedingungen der DSGVO.⁴⁶ Getrennt ist auch die Zuständigkeit. Einen Verstoß gegen § 165 Absatz 3 vollziehen die Fernmeldebehörden, die DSB wird zuständig, sobald als Folge der Cookies personenbezogene Daten verarbeitet werden, und bei Tracking ist das der Normalfall.⁴ Eine Liste, auf der wie beim britischen ICO das Wort Conversions steht, hat die DSB nicht geschrieben. Sie braucht sie auch nicht: Werbung erfüllt keine der zwei Ausnahmen, und dass Werbung Geld bringt, macht sie laut DSB nicht notwendig.⁴ Conversion Tracking für Werbung braucht in Österreich ein Ja.

Die FAQ sind kein Gesetz, das letzte Wort haben die Gerichte, und die DSB rät selbst, im Zweifel einen Rechtsberater zu fragen. Sie sind aber die Sicht der Behörde, bei der deine Besucher Beschwerde einbringen.⁴

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. Die DSB nennt den Warenkorb ausdrücklich, und die Artikel 29 Datenschutzgruppe begründet die Ausnahme damit, dass das Cookie an eine Handlung des Besuchers geknüpft ist, den Klick auf "in den Warenkorb". Vorher nicht.⁴⁷
2. Die Login Session, sobald sich jemand einloggt: unbedingt erforderlich, die DSB nennt den Login Status ausdrücklich.⁴
3. Das Cookie, das die Einwilligungsentscheidung speichert: unbedingt erforderlich, solange es nur die Entscheidung enthält und keine eindeutige Online 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. Die Artikel 29 Datenschutzgruppe hält solche First Party Statistik zwar für wenig riskant, sagt aber ausdrücklich, dass sie nicht unbedingt erforderlich ist und unter keine Ausnahme fällt, weil der Besucher die Seite auch ohne sie voll nutzen kann.⁷ 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, es zeichnet das Verhalten der Besucher auf und wertet es aus, und genau solche Dienste zählt die DSB zu den nicht notwendigen.⁴
6. Das Google Ads Conversion Tag: braucht eine Einwilligung, denn Werbenetzwerke stehen ausdrücklich auf der Liste der DSB, und Werbung ist keine der zwei Ausnahmen.⁴
7. Das Meta Pixel: braucht eine Einwilligung, aus demselben Grund, und der EDSA nennt das Tracking Pixel beim Namen.⁴⁵

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 Stapel sehen genauso aus wie in Deutschland, nur die Belege sind österreichisch: die FAQ der DSB statt der Orientierungshilfe der deutschen Aufsichtsbehörden. Im Vergleich zu Großbritannien hat der Zähler bei uns keine Ausnahme, auf die er sich stützen kann, er muss sich aus dem Anwendungsbereich von § 165 Absatz 3 heraushalten, und für GA4 gibt es kein "es sei denn".

Ablehnen muss so einfach sein wie Akzeptieren. Die DSB verlangt, dass das Nein nicht mehr Klicks braucht als das Ja, und dass niemand erst auf einer zweiten oder dritten Ebene ablehnen kann. Ein Ablehnen Button, der weniger prominent gestaltet oder platziert ist, kann die Einwilligung ungültig machen, und die DSB zeigt das selbst am Beispiel eines weißen Buttons auf weißem Hintergrund neben einem roten. Voreinstellungen und vorangekreuzte Boxen sind unzulässig, und Weitersurfen ist kein Ja.⁴ 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 österreichischer 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 roestereiurfahr.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 Österreich nichts, was technisch nicht notwendig ist, 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 Österreich, 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 schaut perfekt aus, und das Gesetz ist schon gebrochen. Die DSB verlangt genau das Gegenteil: erst die Einwilligung, dann die Cookies.⁴

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 österreichischem 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, ist der Default zu spät gekommen. 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 österreichischen 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 Österreich, 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 § 165 Absatz 3 TKG 2021 umsetzt, und er nennt dabei sogar den User Agent als etwas, dessen Erfassung darunter fallen kann.⁵ Die DSB wendet § 165 Absatz 3 auf jede technische Speicherung und jeden Zugang auf Endgeräten an, nicht nur auf Cookies, und zählt Dienste, die das Verhalten von Besuchern aufzeichnen und auswerten, zu den nicht notwendigen.⁴ Man könnte einwenden, dass der österreichische Wortlaut von personenbezogenen Daten spricht und ein Ping ohne Kennung keine sei. Die DSB sagt aber, dass sich das nicht pauschal beantworten lässt, sondern von den Umständen des Einzelfalls abhängt, etwa davon, wie die Informationen miteinander kombiniert werden können.⁴ Ob und wie Google die Pings mit anderem verknüpft, kannst du von außen nicht prüfen.

Ich habe keine Stellungnahme der DSB gefunden, die cookielose Pings ausdrücklich erlaubt, und keine, die sie beim Namen nennt und verbietet. Gemessen an dem, was DSB und EDSA geschrieben haben, halte ich den Advanced Mode vor der Einwilligung in Österreich aber für schwer zu verteidigen. Für einen österreichischen 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 Steyr klickt auf eine Anzeige der Rösterei, landet auf der Seite der Handmühle, drückt auf Ablehnen, schaut sich zwei weitere Seiten an und kauft die Handmühle um € 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 Österreich 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 § 165 Absatz 3 TKG 2021 weiterhin für alles, was auf dem Gerät passiert.³⁴ Das Gesetz verlangt außerdem, dass Besucher erfahren, welche Daten verarbeitet werden, zu welchen Zwecken und wie lange, und die DSB macht klar, dass du als Betreiber verantwortlich bist, auch wenn du nur Code einbindest und selbst nie an die Daten kommst.³⁴ Das gilt auch dann, wenn die Daten erst auf deinem Server an Dritte 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.roestereiurfahr.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

Heuer 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 sind in Janas eigenem Reporting als purchase_nc geblieben. 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 ist gestanden, $\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 haben die 372 beobachteten Bestellungen gebracht. 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, passt also, 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 hat durch die Modellierung 18 % mehr Conversions zurückgeholt.¹⁴

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 österreichischen 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, mit 630 geht es sich nicht aus. 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 Österreich.

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 so einfach wie Akzeptieren und auf derselben Ebene, nichts technisch Unnötiges 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 Datenschutzbehörde in Wien 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. Telekommunikationsgesetz 2021 (TKG 2021), § 165 Datenschutz, Allgemeines, Absatz 3, Bundeskanzleramt, Rechtsinformationssystem des Bundes (RIS), https://www.ris.bka.gv.at/Dokumente/Bundesnormen/NOR40238623/NOR40238623.html

4. Datenschutzbehörde (Österreich), Datenschutz und Cookies, Fragen und Antworten, dsb.gv.at, https://dsb.gv.at/faqs/datenschutz-cookies

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 4, 6 Absatz 1 Buchstaben b und f, Artikel 7, 13 und 21, EUR Lex, 2016, https://eur-lex.europa.eu/legal-content/DE/TXT/HTML/?uri=CELEX:32016R0679

7. Artikel 29 Datenschutzgruppe, Opinion 04/2012 on Cookie Consent Exemption, WP 194, Abschnitte 3.1 und 4.3, angenommen am 7. Juni 2012, Kopie beim Hessischen Beauftragten für Datenschutz und Informationsfreiheit, https://datenschutz.hessen.de/sites/datenschutz.hessen.de/files/2022-11/wp_194.pdf

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

9. 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

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

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

12. 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

13. 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

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

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