Das Tag Gateway ändert den Host, nicht die Nutzlast

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.

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, wenn man prüft, 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. 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.