Braucht das Google Tag Gateway eine Cookie-Einwilligung?

Alle Beiträge

Ja. Google tag gateway ändert, von wo Ihr Google-Tag lädt, nicht, welche Einwilligung es braucht. Das Tag wird über einen Pfad auf Ihrer eigenen Domain ausgeliefert, liest aber weiterhin Consent Mode. Ihr Banner, Ihre Consent-Standardwerte und die Consent-Einstellungen jedes Tags gelten also weiter. Prüfen müssen Sie nur die Ladereihenfolge: Ihre Standardwerte müssen weiterhin gesetzt sein, bevor irgendein Google-Tag feuert.

Dieser letzte Punkt verdient Ihre Zeit. Die rechtliche Seite der Frage hat eine kurze Antwort, die praktische Seite eine kurze Checkliste. Beides finden Sie unten.

Was ändert Google tag gateway tatsächlich?

Google tag gateway for advertisers lädt Ihr Google-Tag oder Ihren Tag-Manager-Container über einen Pfad auf Ihrer eigenen Domain, etwa /metrics/, statt von googletagmanager.com. Auch die Messanfragen gehen an diesen Pfad, und Ihr CDN oder Load Balancer leitet sie an Google weiter. Googles Entwicklerseite beschreibt das so, dass Ihr Tag auf Ihrer eigenen First-Party-Infrastruktur läuft.

Es gibt zwei Wege, es einzuschalten. Wenn Ihre Website hinter Cloudflare liegt, geht das in Tag Manager unter Admin, Google tag gateway. Danach autorisieren Sie Google in Cloudflare und wählen die Domains aus. Bei jedem anderen CDN leiten Sie den Messpfad an die fps.goog-Adresse Ihres Tags weiter, reichen die Standort-Header des Besuchers durch und setzen das Attribut src in Ihrem Snippet auf den neuen Pfad.

So oder so ändern sich drei Dinge: die Adresse, von der das Skript kommt, die Adresse, an die die Anfragen gehen, und wer sie weiterleitet. Nichts davon berührt die Einwilligung.

Ändert die Auslieferung von Tags über Ihre eigene Domain Ihre Consent-Pflichten?

Nein. Die EU-Einwilligungsregel in Artikel 5 Absatz 3 der ePrivacy-Richtlinie betrifft das Speichern oder Auslesen von Informationen auf dem Gerät des Besuchers. Von welcher Domain das Skript kam, spielt dort keine Rolle. Ein Google-Analytics-Cookie, das ein von /metrics/ geladenes Tag setzt, ist weiterhin ein Cookie, das dort eine Einwilligung braucht, wo sie vorgeschrieben ist.

Google sagt dasselbe auf seiner eigenen Einrichtungsseite. Die Cloudflare-Anleitung für das Tag Gateway warnt, dass die Funktion beeinflusst, wie Google-Tags feuern, und empfiehlt, Consent Mode einzusetzen und Ihre Consent-Einstellungen zu prüfen, falls die Einwilligung Ihre Tags bereits steuert.

Ein Gateway ist also kein Weg am Cookie-Banner vorbei. Wenn Ihr Banner vor der Umstellung nötig war, ist es auch danach nötig.

Kann das Tag Gateway Ihr Consent-Setup stören?

Ja, durch die Reihenfolge, nicht durch das Recht. Consent Mode funktioniert nur, wenn der Standard-Consent-Status gesetzt ist, bevor irgendein Google-Tag feuert. Das steht ausdrücklich in Googles Anleitung zur Consent-Einrichtung. Ob das Gateway diese Reihenfolge stört, hängt davon ab, woher Ihre Standardwerte kommen.

• Ihre Consent-Plattform läuft in Tag Manager. Das Template hängt am Trigger Consent Initialization, der vor allen anderen Triggern im Container läuft. Der Container lädt weiterhin als Ganzes, nur von einer anderen Adresse. Die Standardwerte kommen also weiterhin zuerst.
• Ihre Consent-Plattform ist ein separates Skript auf der Seite. Hier hängt die Reihenfolge von der Seite ab. Wenn das CDN das Google-Tag jetzt früher ausliefert oder einfügt als vorher, kann es vor Ihrem Consent-Skript laufen. Googles Tools melden den Standardwert dann als zu spät gesetzt.

Den ersten Fall sehen wir auf unserer eigenen Website. veloconsent.com lädt seinen Tag-Manager-Container über einen Cloudflare Worker von einem Pfad auf der eigenen Domain. Das ist unser eigener Proxy und nicht Googles Gateway, aber das Prinzip ist dasselbe. Und das Velo-Template auf Consent Initialization setzt die abgelehnten Standardwerte weiterhin, bevor irgendein anderes Tag läuft.

Wenn Sie im zweiten Fall sind, liegt die Lösung in Ihrer Seite oder Ihrem Setup, nicht in den Consent-Regeln. Jede dieser Maßnahmen stellt die Reihenfolge wieder her:

• Laden Sie das Consent-Skript oberhalb des Google-Snippets, damit seine Standardwerte zuerst greifen.
• Verlegen Sie die Consent-Standardwerte in Tag Manager, auf den Trigger Consent Initialization.
• Wenn die automatische Cloudflare-Einrichtung das Tag verschoben hat, nutzen Sie stattdessen die manuelle Einrichtung. Dort bearbeiten Sie das Snippet selbst und entscheiden damit, wo es steht.

Bestätigen Sie das anschließend in Tag Assistant, wie in den Prüfungen unten beschrieben. Unser Beitrag dazu, ob Sie Google-Tags bis zur Einwilligung blockieren sollten, erklärt, wie Basic und Advanced Consent Mode mit Tags umgehen, die vor einer Entscheidung laden.

Was bleibt nach der Umstellung gleich?

Fast alles, was Sie für die Einwilligung konfiguriert haben, bleibt erhalten, und nichts davon übernimmt das Gateway für Sie.

• Google-Analytics-, Google-Ads- und Floodlight-Tags lesen Consent Mode von selbst. Benutzerdefinierte HTML-Tags und die meisten Community-Templates tun das nicht. Deren Consent-Einstellungen in Tag Manager sind also weiterhin wichtig.
• Enhanced Conversions hängen weiterhin von ad_user_data ab. Lehnt der Besucher Werbung ab, sollten diese Daten nicht gesendet werden, egal welchen Pfad das Tag nutzt.
• Das Skript Ihrer Consent-Plattform lädt weiter von dort, wo es bisher geladen hat. Bei Velo ist das die Adresse von Velo, und das ist so gewollt.
• Ein Server-Container erhält den Consent-Status weiterhin mit jeder Anfrage. Googles Server-Tags halten sich daran. Server-Tags anderer Anbieter brauchen eigene Consent-Prüfungen, wie unser Leitfaden zur Übergabe der Einwilligung an einen Server-side-Container erklärt.

Unser Hilfe-Leitfaden geht die Einrichtung der Reihe nach durch, vom Ausliefern von Google-Tags über das Tag Gateway bis zur Weitergabe der Einwilligung ins Server-side Tagging.

Wie prüfen Sie, ob die Einwilligung nach der Umstellung noch funktioniert?

Führen Sie denselben Consent-Test durch wie vor der Umstellung, plus zwei Prüfungen für das Gateway selbst. Beginnen Sie jeden Test in einer frischen Browser-Sitzung auf der veröffentlichten Website.

1. Prüfen Sie, ob das Gateway funktioniert

   Öffnen Sie /metrics/healthy und /metrics/?validate_geo=healthy auf Ihrer Domain mit Ihrem eigenen Pfad. Beide sollten ok zurückgeben. Schlägt nur der zweite fehl, werden die Standort-Header nicht weitergeleitet.

2. Prüfen Sie, ob der neue Pfad genutzt wird

   Im Netzwerk-Tab Ihres Browsers sollten das Google-Tag und seine Anfragen an Ihren Messpfad gehen. Gehen sie weiterhin an googletagmanager.com, steht noch eine alte Kopie des Snippets auf der Seite.

3. Prüfen Sie, ob die Standardwerte zuerst kommen

   In Tag Assistant sollte der Consent-Standardwert erscheinen, bevor irgendein Google-Tag feuert. Wird der Standardwert als zu spät gemeldet, lädt Ihr Consent-Skript jetzt nach dem Tag.

4. Testen Sie Zustimmung, Ablehnung und eine Teilauswahl

   Prüfen Sie für alle drei den Consent-Status jedes Tags. Tags mit zusätzlichen Consent-Einstellungen sollten nach einer Ablehnung blockiert bleiben.

5. Entscheidung auf einer späteren Seite ändern

   Öffnen Sie das Banner erneut, ändern Sie die Auswahl und prüfen Sie, ob die Änderung auf der nächsten Seite bei den Tags ankommt.

Holt das Tag Gateway die Daten zurück, die eine Ablehnung verbirgt?

Nein. Ein Besucher, der ablehnt, wird gleich behandelt, egal von welcher Domain das Tag lädt. Google stellt das Gateway als Weg vor, die Messung robuster zu machen. Dabei geht es darum, ob das Skript überhaupt lädt, zum Beispiel dort, wo ein Blocker es stoppen würde. Das ist ein anderes Problem als die Einwilligung, und daran ändert das Gateway nichts. Wenn Sie verstehen möchten, was eine Ablehnung mit Ihren Berichten macht, beginnen Sie mit Was mit GA4-Daten passiert, wenn Nutzer Cookies ablehnen.

Das Tag-Manager-Template von Velo hängt an Consent Initialization. Die Standardwerte kommen also zuerst, egal von welcher Adresse Ihr Container ausgeliefert wird. Das Gateway einzuschalten, ist dann eine Routing-Änderung mit einer anschließenden Testrunde.