Google Tag Gateway: Was es an einer Messanfrage ändert und worin es sich vom Server-Side Tagging unterscheidet

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.

Update vom 19.10.2026: Die folgenden Skriptpfade sind Beispiele für ein eigenständiges Google Tag. Ein optimierter GTM-Container kann Google-Messungen ohne zusätzlich geladenes gtag.js senden. Den tatsächlichen Skriptpfad bestimmt das bereitgestellte Gateway-Snippet; ein Pfad auf der eigenen Domain wählt oder optimiert die Tag-Konfiguration nicht selbst. Einordnung der Oktoberänderungen bei Google Tag und GTM.

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.

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 gilt

Dieselbe 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.goog für einen Google-Tag, gtm-abcdef.fps.goog für einen Tag-Manager-Container. Der Host-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-CountryRegion mit einem Code nach ISO 3166-2 wie US-CA, sonst X-Forwarded-Country zusammen mit X-Forwarded-Region. Kommen beide Varianten an, hat der kombinierte Header Vorrang. Die echte Client-IP wird unverändert in einem Standard-Header wie X-Forwarded-For weitergereicht.

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=healthy

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