English
Deutsch
PolskiGoogle Tag Gateway: Was es an einer Messanfrage ändert und worin es sich vom Server-Side Tagging unterscheidet
Inhalt
- Was sich tatsächlich verschiebt
- Was er bewusst nicht tut
- Die Cookie-Frage und wie sie sich klären lässt
- Sperren sehen den Pfad, nicht nur den Host
- Wo er neben einem Servercontainer steht
- Die Zuwachszahl ist eine Behauptung, keine Messung
- Manuelle Einrichtung: Was die Weiterleitungsregel mitbringen muss
- Fragen und Antworten
- Quellen
Das Google Tag Gateway begann auf Cloudflare, wurde am 1. Juni 2026 auf Google Cloud über einen externen Application Load Balancer allgemein verfügbar und bekam im selben Monat einen Einrichtungsweg für Amazon CloudFront. Es ist damit eine gewöhnliche Möglichkeit statt eines Versuchs – und wird gewöhnlich als leichtere Alternative zum serverseitigen Tagging beschrieben.
Eine Alternative dazu ist es nicht. Beide ändern verschiedene Dinge, und ein Blick auf die Anfrage selbst macht den Unterschied in etwa einer Minute deutlich.
Was sich tatsächlich verschiebt
Der Gateway ist ein Vorschaltdienst auf einem Pfad der eigenen Domain. Sowohl das Skript als auch die Messtreffer laufen darüber – das Tag wird von etwas wie /metrics/gtag/js geladen statt von googletagmanager.com, und die Treffer gehen an /metrics/g/collect auf demselben Host. Das CDN, der Load Balancer oder der Webserver schreibt den Pfad um und leitet die Anfrage an Google weiter.
Aus Sicht des Browsers ist jede dieser Anfragen jetzt erstanbieterisch. Das ist der ganze Mechanismus. Am Anfragekörper ändert sich unterwegs nichts, und es soll sich auch nichts ändern: Die Dokumentation hält fest, dass nur Google-Erstanbieter-Cookies durchgehen und alle anderen durchgereichten Erstanbieter-Cookies verworfen statt verarbeitet werden.
Was er bewusst nicht tut
Das Tag läuft weiterhin im Browser, baut die Nutzlast im Browser und sendet die Nutzlast, die es gebaut hat. In dieser Anordnung gibt es keine Stelle, an der sich ein Parameter entfernen ließe, der gar nicht hätte erhoben werden dürfen, an der sich ein Kundenwert aus einem internen System nachschlagen ließe oder an der auf dem Server entschieden würde, dass ein Treffer überhaupt nicht weitergereicht wird. Genau dafür gibt es einen Servercontainer, und der Gateway hat zu all dem keine Meinung.
| Tag Gateway | Serverseitiges GTM | |
|---|---|---|
| Host in der Anfrage | Eigene Domain | Eigene Domain |
| Wo das Tag läuft | Im Browser | Auf dem Server |
| Darf die Nutzlast ändern | Nein | Ja |
| Schwärzen und Minimieren | Nein | Ja |
| Anreichern aus eigenen Systemen | Nein | Ja |
| Was zu betreiben ist | Eine Weiterleitungsregel | Ein Container mit Lebenszyklus |
Die Cookie-Frage und wie sie sich klären lässt
Die Behauptung, die am häufigsten an der Erstanbieter-Auslieferung hängt, lautet, sie stelle die Cookie-Frist unter Safari wieder her. Das hängt vollständig davon ab, welcher Mechanismus das Cookie schreibt, und die Unterscheidung ist scharf. Ein von JavaScript geschriebenes Cookie wird von der Intelligent Tracking Prevention auf sieben Tage gekappt, gleichgültig welcher Host das Skript geliefert hat, während ein vom Server in einem Set-Cookie-Antwortkopf geschriebenes Cookie die Frist behält, die er beantragt.
Googles Seite zur Cookie-Behandlung im Tag Gateway beschreibt, welche Cookies durchgehen und welche verworfen werden. Welcher der beiden Mechanismen sie schreibt, sagt sie nicht. Das ist kein Grund, in irgendeine Richtung zu raten – es ist ein Grund nachzusehen, und Nachsehen kostet eine Anfrage.
# was der Browser jetzt anfordert, durchweg erstanbieterisch
GET https://shop.example/metrics/gtag/js?id=G-XXXXXXX
GET https://shop.example/metrics/g/collect?v=2&tid=G-XXXXXXX&...
# die Frage, die die Dokumentation offenlässt
curl -sI 'https://shop.example/metrics/g/collect?v=2&tid=G-XXXXXXX' \
| grep -i '^set-cookie'
# keine Zeile → das Skript schreibt ihn, sieben Tage unter ITP
# eine Set-Cookie-Zeile → der Server schreibt ihn, die Max-Age giltDieselbe Antwort steht im Browser unter Anwendung, sobald geprüft wird, ob das Cookie vor oder erst nach dem Lauf des Tags auftaucht. Wie sie auch ausfällt – das Ergebnis ist eine Tatsache über diese Installation und keine allgemeine Eigenschaft des Produkts, und es gehört in die Notizen für den, der die Einrichtung erbt.
Sperren sehen den Pfad, nicht nur den Host
Ein Erstanbieter-Pfad schlägt die gröbste Form der Sperre, nämlich eine Liste von Hostnamen. Er schlägt keine Regel, die auf den Pfadabschnitt, den Skriptinhalt oder die Form des Anfragekörpers passt – und die verbreiteten Filterlisten bekamen pfadbasierte Regeln für genau dieses Muster bald nach seinem Auftauchen.
Zu erwarten ist deshalb eine Rückgewinnung und keine Wiederherstellung: Ein Teil des zuvor gesperrten Verkehrs taucht wieder auf, der Anteil hängt davon ab, welche Listen das Publikum betreibt, und er schwindet mit jeder Aktualisierung. Ein unauffälliger Pfadname erkauft etwas Zeit und ist keine Strategie.
Wo er neben einem Servercontainer steht
Googles eigene Empfehlung lautet, beides zu tun, und der Grund ist, dass sie benachbarte Probleme lösen: Der Gateway richtet den Zustellweg, der Container richtet, was darauf reist. Ein Auftritt mit Servercontainer und ohne Gateway lädt sein Tag weiterhin von einem fremden Host, sofern der Container die Google-Skripte nicht selbst ausliefert. Ein Auftritt mit Gateway und ohne Container hat einen Erstanbieter-Pfad, auf dem eine ungeprüfte Nutzlast unmittelbar zu Google fährt.
Lässt sich nur eines bauen, folgt die Reihenfolge aus dem, was der Auftritt wirklich braucht. Liegt das Problem im Datenschutz – ein Parameter, der nicht hinaus darf, ein Wert, der vorher zu streuen ist -, löst es nur der Container, und ein Gateway vor einer ungefilterten Nutzlast löst gar nichts. Liegt das Problem im Messverlust auf einem Auftritt ohne Empfindliches in der Nutzlast, ist der Gateway weit billiger und erledigt die ganze Aufgabe.
Die Zuwachszahl ist eine Behauptung, keine Messung
Anbieter melden nach einer Gateway-Einführung Zuwächse bei den Abschlüssen im Bereich von neun bis achtzehn Prozent. Diese Zahlen stammen von denen, die die Einführung verkaufen, sie sind Mittelwerte über ungenannte Auftritte, und sie werfen drei gleichgerichtete Wirkungen zusammen: weniger gesperrte Anfragen, längere Cookie-Fristen dort, wo das Cookie vom Server kommt, und die gewöhnliche saisonale Drift des jeweils verglichenen Zeitraums.
Die ehrliche Probe ist eine Vergleichsgruppe: Ein Teil des Verkehrs bleibt auf dem alten Weg, beides läuft zwei Wochen nebeneinander, und verglichen werden die beiden Gruppen statt zweier Zeiträume. Das ist mehr Arbeit als das Lesen einer Fallstudie, und es ist die einzige Fassung der Zahl, die eine Rückfrage übersteht.
Manuelle Einrichtung: Was die Weiterleitungsregel mitbringen muss
Die Integrationen für Cloudflare und Google Cloud richten den Weg selbst ein. Wird der Gateway dagegen von Hand auf einem anderen CDN oder Load Balancer eingerichtet, nennt Googles Einrichtungsanleitung eine Handvoll Anforderungen, und jede davon verursacht einen bestimmten Fehler, wenn sie fehlt.
- Ursprung. Der vorgelagerte Host leitet sich aus der Kennung ab:
G-12345.fps.googfür einen Google-Tag,gtm-abcdef.fps.googfür einen Tag-Manager-Container. DerHost-Header der weitergeleiteten Anfrage wird mit diesem Namen überschrieben, Cookies und Query-Strings gehen vollständig mit. - Pfad. Der Pfad ist in Grenzen frei wählbar: nicht die Wurzel
/, höchstens 100 Zeichen lang und auf der Domain nicht schon belegt. - Standort. Ohne Gateway leitet Google den Standort aus der IP-Adresse des Besuchers ab. Dahinter erhält Googles Backend stattdessen die Adresse des CDN, deshalb muss das CDN den Standort als Header mitgeben: bevorzugt
X-Forwarded-CountryRegionmit einem Code nach ISO 3166-2 wieUS-CA, sonstX-Forwarded-Countryzusammen mitX-Forwarded-Region. Kommen beide Varianten an, hat der kombinierte Header Vorrang. Die echte Client-IP wird unverändert in einem Standard-Header wieX-Forwarded-Forweitergereicht.
Fehlende Standort-Header halten die Messung nicht auf. Die Treffer kommen weiter an, und der Schaden zeigt sich erst später als ungenaue Geografie in den Berichten. Deshalb lohnt die Prüfung direkt nach dem Livegang und nicht erst im Monatsbericht:
# beide antworten mit dem Text "ok", wenn der Weg stimmt
https://shop.example/metrics/healthy
https://shop.example/metrics/?validate_geo=healthyDie erste Adresse bestätigt den Weg, die zweite, dass die Standort-Header ankommen. Im Tag Assistant sollten die gesendeten Treffer anschließend den eigenen Pfad zeigen. Ein Teil bleibt außerhalb des Gateways: Den <noscript>-Schnipsel des Tag Managers unterstützt er nicht, dieser zeigt weiterhin auf www.googletagmanager.com.
Fragen und Antworten
Warum verwirft der Gateway alle Erstanbieter-Cookies außer denen von Google?
Weil der Browser an jede Anfrage auf der eigenen Domain alle Cookies hängt, die zu Domain und Pfad passen, also auch Anmelde-, Warenkorb- oder Sitzungscookies des Shops. Seit die Messtreffer über /metrics/ auf demselben Host laufen, reisen diese Cookies bis zum Gateway mit. Würden sie an Google weitergegeben, verließen Daten den eigenen Bereich, die mit der Messung nichts zu tun haben; das Verwerfen verhindert genau das.
Ändert der Gateway etwas an der Einwilligung oder am Einwilligungsbanner?
An der Einwilligungspflicht nichts. Ob eine Einwilligung nötig ist, hängt am Zugriff auf das Endgerät und an der Verarbeitung der Daten, nicht am Hostnamen, von dem das Skript kommt. Das Tag läuft weiterhin im Browser, liest und schreibt dieselben Cookies und schickt dieselbe Nutzlast an Google; an der Logik des Consent Mode ändert sich deshalb ebenfalls nichts.
Am Banner kann sich dagegen sehr wohl etwas ändern, und zwar dort, wo es Skripte selbst blockiert. Manche Einwilligungswerkzeuge erkennen Tags an ihrer Adresse und halten alles zurück, was von googletagmanager.com kommt, bis eine Einwilligung vorliegt. Unter /metrics/gtag/js auf der eigenen Domain passt diese Regel nicht mehr. Das Tag lädt dann womöglich schon vor der Entscheidung, obwohl das Banner äußerlich unverändert aussieht.
Nach der Umstellung lohnt deshalb ein Blick auf die Netzwerkanfragen in den Entwicklertools des Browsers, und zwar bei abgelehnter und bei noch offener Einwilligung. Taucht dort eine Anfrage an den neuen Pfad auf, die vorher fehlte, braucht die Blockierregel den neuen Pfad. Es ist dieselbe Logik wie bei den Filterlisten, nur in umgekehrter Richtung.
Wie lässt sich prüfen, ob verbreitete Filterlisten den Pfad bereits sperren?
Mit einem Browser, in dem ein verbreiteter Werbeblocker mit seinen Standardlisten läuft. Die Netzwerkansicht der Entwicklertools zeigt dann, ob die Anfrage an /metrics/gtag/js oder /metrics/g/collect durchgeht oder vom Blocker abgefangen wird; Chrome kennzeichnet solche Anfragen mit net::ERR_BLOCKED_BY_CLIENT. Weil die Listen laufend nachgezogen werden, beschreibt das Ergebnis nur den Stand zum Zeitpunkt der Prüfung und lohnt eine Wiederholung in regelmäßigen Abständen.
Was ändert der Gateway an einer Content Security Policy?
Er verschiebt die Einträge, die das Tag braucht, auf die eigene Herkunft. Skript und Messtreffer kommen jetzt vom selben Host wie die Seite, und in script-src und connect-src deckt 'self' beides ab.
Ob die bisherigen Einträge für googletagmanager.com und die Messhosts entfallen dürfen, zeigt allerdings erst der Betrieb. Solange irgendein anderes Tag oder ein weiterer Google-Dienst noch direkt einen Google-Host anspricht, werden dessen Anfragen ohne diese Einträge blockiert, und auf der Seite ist davon nichts zu sehen. Ein Probelauf, bei dem die Policy im Header Content-Security-Policy-Report-Only steht, meldet solche Verstöße, ohne etwas zu sperren, und erst wenn dort nichts mehr auftaucht, lässt sich die Liste kürzen.
Passend dazu
