Google Tag Gateway vs. Server-seitiges GTM: was braucht dein Unternehmen wirklich?

Google Tag Gateway kam im Jahr 2024 auf den Markt und spaltete sofort die Meinungen. Einige Teams betrachteten es als das Ende der Diskussion über Server-seitiges Tracking. Andere taten es als leichtgewichtigen Workaround ab.

Keines von beidem ist wirklich korrekt.

Die Realität ist, dass die 2 Tools unterschiedliche Probleme auf verschiedenen Ebenen deiner Einrichtung angehen. GTG ändert, von wo aus Skripte geladen werden. Serverseitiges GTM ändert, wo die Daten verarbeitet und wo Cookies geschrieben werden. Das ist nicht dasselbe, und wenn man sie verwechselt, führt das zu Konfigurationen, die auf dem Papier vollständig aussehen, aber in Wirklichkeit Lücken in der Nachverfolgung offen lassen.

In diesem Artikel erfährst du, was Google Tag Gateway an deiner Einrichtung ändert und was es unangetastet lässt, wie das server-seitige GTM die Ereignisverarbeitung, die Cookie-Lebensdauer und die plattformübergreifende Abdeckung unterschiedlich handhabt, einen direkten Vergleich beider Tools über 7 Dimensionen hinweg und einen klaren Rahmen, um zu entscheiden, welche Einrichtung (oder welche Kombination) zu deinem Tracking-Stack passt.

Was ist Google Tag Gateway?

Google Tag Gateway ist ein von Google verwalteter Proxy für deine Google-Tags. Anstatt von googletagmanager.com geladen zu werden, wird dein GTM-Skript von einer von dir kontrollierten Subdomain geladen, etwa gtg.deineseite.de. Die GA4-Datenerfassung wird vom Erfassungsendpunkt von Google auf dieselbe Subdomain verlagert.

Die Subdomain gehört dir. Google verwaltet die Infrastruktur dahinter. Die Einrichtung besteht hauptsächlich aus einer DNS-Änderung und einem Container-Update.

Eine harte Einschränkung, die wir im Voraus erwähnen sollten: GTG deckt nur Google-Produkte ab. GA4, Google Ads, Floodlight und Google Tag sind also eingeschlossen. Wenn du Meta, TikTok, Klaviyo oder irgendetwas anderes außerhalb dieses Ökosystems verwenden, hat GTG keinen Einfluss auf diese Ereignisse.

Was wird durch GTG behoben?

Die meisten Werbeblocker blockieren Anfragen an bekannte Hostnamen von Drittanbietern. googletagmanager.com steht auf jeder wichtigen Blockierliste. GTG umgeht dies, indem es diese Anfragen über deine Domain leitet, die auf keiner Liste steht.

Das ist eine echte Verbesserung. Aus der Praxis wissen wir, dass die Verbesserung etwa 1,5 bis 2,5 Prozentpunkte für Google-Daten beträgt, die sonst auf der Skriptebene untergehen würden.

Zwei Dinge, die GTM nicht behebt

1. Das Pfadproblem

Erstens: GTG löst das Pfadproblem nicht. GTG ändert den Domänenanteil der Anfrage-URL, aber die Pfadmuster bleiben gleich. Eine GA4-Datenerfassungsanfrage trifft immer noch auf /g/collect auf deiner Subdomain, etwa so gtg.yoursite.com/g/collect/?id=G-12345678 . Werbeblocker wie Ghostery und uBlock Origin suchen nicht nur nach dem Hostnamen. Sie filtern auch nach bekannten Pfadsignaturen, und /g/collect ist ein gut dokumentiertes Muster, das in den meisten großen Blockierlisten auftaucht. Das Verschieben der Anfrage auf deine Subdomain ändert daran nichts. Ausgefeilte Blocker fangen diese Anfragen immer noch ab, was die Möglichkeiten von GTG einschränkt, die Daten wiederherzustellen.

2. Lebensdauer des Cookies

Cookies werden immer noch von JavaScript im Browser gesetzt. Wenn dein GTM-Container auf der Client-Seite ausgeführt wird, schreibt er Cookies über document.cookie. Die intelligente Tracking-Verhinderung von Safari begrenzt diese Cookies auf 7 Tage. Es spielt keine Rolle, von welcher Domain das Skript stammt. Der Ursprung der Cookies ist die JavaScript-Umgebung des Browsers. GTG ändert diese Ebene nicht.

Für jede Attributionsreise, die länger als eine Woche dauert, oder für jeden Besucher, der nach 7 Tagen in Safari zurückkommt, um zu konvertieren, gilt weiterhin die 7-Tage-Obergrenze. So wie zuvor. Das Laden des Skripts hat sich verbessert, das Cookie-Problem hat sich nicht verschoben.

Was ist Server-seitiges GTM?

Serverseitiges GTM nimmt die Ereignisverarbeitung komplett aus dem Browser heraus und verlagert sie auf einen von dir kontrollierten Server.

Dein Browser sendet ein Ereignis an deinen Server. Der Server empfängt es, verarbeitet es und leitet es über Server-zu-Server-API-Aufrufe an jede Plattform weiter. Wenn du das Enhanced Tracking Script zusammen mit deinem Server-Container verwenden, haben die Werbeblocker keinen Einblick in diese Aufrufe. Im Browser läuft nichts, was sie blockieren könnten.

Wie funktioniert das serverseitige GTM anders?

Die Cookie-Situation ändert sich erheblich. Dein Server schreibt Cookies mit HTTP Set-Cookie Antwort-Headern. Die 7-Tage-Beschränkung von ITP gilt für Cookies, die von JavaScript geschrieben werden. Cookies, die über Header von einem Erstanbieter gesetzt werden, unterliegen dieser Beschränkung nicht. Eine korrekt konfigurierte serverseitige Einrichtung kann First-Party-Cookies schreiben , die 365 Tage oder länger gültig sind.

Für Websites, bei denen Kunden Wochen brauchen, um sich zu entscheiden, ist dieser Unterschied in der Cookie-Lebensdauer der Unterschied zwischen einer genauen Zuordnung und einer absichtlich unvollständigen Zuordnung.

Die Abdeckung ist eine weitere Lücke, die das serverseitige GTM füllt. Derselbe Container kann Ereignisse an GA4, Google Ads Enhanced Conversions, Meta Conversions API, TikTok Events API und die meisten anderen Plattformen weiterleiten, die eine serverseitige API anbieten. Wenn kanalübergreifende Kampagnen Signale verlieren und sich dies in deiner Retargeting-Performance bemerkbar macht (hier erfährst du, wie du Datenverluste beheben können), ist eine Ereignis-Pipeline zu allen Plattformen die strukturelle Lösung.

Der Kompromiss? GTM benötigt Hosting, Konfiguration und GTM-Kenntnisse, um gut zu funktionieren. Es ist nicht einfach umzuschalten.

Google Tag Gateway vs. Server-Side GTM: ein direkter Vergleich

	Google Tag Gateway	Server-seitiges GTM
Was ändert sich	Woher Skripte geladen werden	Wo die Ereignisverarbeitung stattfindet
Cookie-Einstellung	JavaScript (Browser)	HTTP-Kopfzeilen (Server)
ITP Auswirkungen	Keine Veränderung	Cookies können mehr als 365 Tage halten (mit einer ordnungsgemäßen Einrichtung)
Umgehung des Werbeblockers	Nur Skript laden	Vollständige Server-zu-Server-Aufrufe
Abdeckung der Plattform	Nur Google-Produkte	Jede Plattform mit einer Server-API
Komplexität der Einrichtung	Niedrig	Mittel bis Hoch
Typischer Daten-Uplift	4-6%*	14-20%*

Es gibt auch einen technischen Unterschied zwischen GTG und sGTM, den du verstehen solltest, wenn du dich für das Verhalten zwischen gleicher Website und gleicher Herkunft interessierst. GTG wird von einer Subdomain wie gtg.ihre-seite.com ausgeführt. Das ist zwar seitengleich, aber nicht herkunftsgleich mit deiner Hauptdomain. Eine vollständige sGTM-Einrichtung kann Ereignisse über einen Pfad auf deiner Stammdomäne bereitstellen: yoursite.com/collect. Gleicher Ursprung. Einige Browser und einige Tracking-Mechanismen behandeln diese unterschiedlich, und der sGTM-Ansatz gibt dir mehr Kontrolle, da dies eine größere Rolle spielt.

*Prüfen Sie die Daten und den Vergleich in GTG oder Server-seitiges GTM? Das Server-seitige Dilemma von Niek Schlepers

Welches Setup ist das richtige für deinen Anwendungsfall?

GTG ist die richtige Wahl, wenn:

• Dein Stack besteht nur aus Google-Produkten (GA4, Google Ads, Floodlight)
• Die meisten deiner Nutzer benutzen Chrome
• Die Konvertierungszyklen sind kürzer als 7 Tage
• Du eine Verbesserung mit geringem Aufwand und minimaler Konfiguration möchtest

sGTM ist die richtige Wahl, wenn:

• Du mehrere Plattformen verfolgst (Meta, TikTok, Klaviyo, Google)
• Deine Kunden mehr als 7 Tage brauchen, um zu konvertieren
• Du Cookies benötigst, die über das ITP-Limit von Safari hinaus bestehen bleiben
• Du eine server-seitige Durchsetzung der Zustimmung und eine Kontrolle der personenbezogenen Daten möchtest, bevor die Daten deine Infrastruktur verlassen
• Du den vollen Umfang des server-seitigen Trackings verstehen möchtest

Hier ist ein Beispiel.

Du verfolgst plattformübergreifend. Eine server-side Meta-Einrichtung hängt von sGTM ab, nicht von GTG. TikTok, Klaviyo und alles andere außerhalb des Google-Ökosystems tut es auch.

Deine Kunden brauchen Zeit, um zu konvertieren. Mehrwöchige Reisen in Safari benötigen Cookies, die über Tag 7 hinaus bestehen bleiben. GTG bietet das nicht.

Du möchtest sehen, was du tatsächlich verlierst. Das vollständige Bild dessen, was die serverseitige Nachverfolgung wiederherstellt, ist schwer zu erkennen, bis du beide Setups ausführen und vergleichen.

Du brauchst eine Datenkontrolle, die über die Datenwiederherstellung hinausgeht. Mit sGTM kannst du entscheiden, was an die einzelnen Plattformen weitergeleitet wird, die Zustimmungslogik server-seitig anwenden und PII entfernen, bevor die Daten deine Infrastruktur verlassen.

Die meisten Teams, die das Conversion Tracking ernst nehmen, kommen irgendwann zum serverseitigen GTM. GTG kann ein nützlicher erster Schritt sein. Es löst nur nicht die Frage der Infrastruktur.

Können GTG und Server-side zusammenarbeiten?

Technisch gesehen arbeiten Google Tag Gateway und server-seitiges GTM auf verschiedenen Ebenen, daher kommt es nicht immer zu Konflikten. Wir empfehlen jedoch generell nicht, beide gleichzeitig einzusetzen. In der Praxis kann die Kombination von GTG mit deinem Server-side-Setup deine bestehende Serverkonfiguration durcheinanderbringen. Und weil das Risiko nicht immer vorhersehbar ist, lautet unser Rat: Entscheide dich für einen Ansatz, anstatt beide übereinander zu schichten.

Nutzt du bereits server-seitiges GTM über TAGGRS, brauchst du GTG nicht für die Script-Auslieferung. Das Enhanced Tracking Script übernimmt das bereits — es liefert Google Tag-Scripts von deiner eigenen Domain aus und verwaltet die Cookie-Persistenz server-seitig. GTG würde in dem Fall ein Problem lösen, das du schon gelöst hast, und dabei nur zusätzliche Komplexität und potenzielle Konflikte mitbringen.

Du willst herausfinden, welches Setup am besten zu dir passt? Schau dir die Vergleichstabelle oben an.

GTG und sGTM: wo passt TAGGRS hin?

Serverseitiges GTM benötigt einen Server, auf dem es läuft. Für die meisten Teams ist die eigentliche Anforderung nicht das Infrastrukturmanagement. Es geht um Leistung, Zuverlässigkeit und die korrekte Konfiguration der Zustimmung, ohne dass DevOps dafür Zeit aufwenden müssen.

TAGGRS bietet eine gehostete sGTM-Infrastruktur mit integrierten Konnektoren für die wichtigsten Werbeplattformen, Integration des Consent Mode und Datenschutzkontrollen. Bist du bereit, über die GTG-Ebene hinauszugehen, und möchtest du verstehen, wie die Datenwiederherstellung für deine spezifische Einrichtung aussieht?

FAQ

Brauche ich Google Tag Gateway?

Wenn du GA4 und Google Ads ohne server-seitiges Tracking betreibst, ist GTG eine praktische Verbesserung, die du einrichten solltest. Es stellt Daten wieder her, die durch Hostnamen-basiertes Blockieren verloren gegangen sind, und das mit sehr geringem Implementierungsaufwand. Wenn du bereits mit sGTM arbeitest, ist der zusätzliche Nutzen von GTG geringer. Deine Ereignisse werden bereits von Server zu Server übertragen. GTG hilft vor allem bei der Skriptladeschicht, die dein sGTM-Setup je nach Konfiguration deines Containers möglicherweise bereits erledigt.

Behebt Google Tag Gateway Safari ITP?

Nein. GTG ändert nicht, wie Cookies geschrieben werden. ITP gilt für Cookies, die von JavaScript geschrieben werden, unabhängig davon, von welcher Domain das Skript stammt.

Was ist der Unterschied zwischen Google Tag Gateway und Server-side Tagging?

Google Tag Gateway ändert den Ort, von dem deine Google-Skripte geladen werden. Von einer Subdomain, die du kontrollierst, statt von der Google-Domain. Die Skripte werden immer noch im Browser ausgeführt, Cookies werden immer noch von JavaScript geschrieben und ITP gilt immer noch. Ausgefeilte Werbeblocker, die auf Pfadmustern und nicht nur auf Hostnamen basieren, können die Anfragen immer noch erkennen und blockieren.

Server-side Tagging verlagert die Ereignisverarbeitung vom Browser auf einen Server. Cookies werden über HTTP-Header geschrieben, wodurch sie außerhalb der Reichweite von ITP liegen. Ereignisse erreichen Plattformen über Server-zu-Server-API-Aufrufe, die von Werbeblockern nicht erreicht werden können. Und im Gegensatz zu GTG funktioniert sGTM auf jeder Plattform mit einer serverseitigen API, nicht nur auf der von Google.

Sie arbeiten auf verschiedenen Ebenen. GTG verbessert die Skriptbereitstellung für Google-Tags; sGTM kümmert sich um die Ereignis-Pipeline, die Lebensdauer von Cookies und die Weiterleitung von Signalen über mehrere Plattformen. Bei Konfigurationen, bei denen beide Probleme wichtig sind, laufen sie zusammen.

Brauche ich ein serverseitiges GTM, wenn ich bereits Google Tag Gateway verwende?

GTG verbessert die Skriptbereitstellung für Google-Tags. Wenn du Plattformen betreibst, die nicht von Google stammen, wenn du Cookies benötigst, die länger als 7 Tage halten, oder wenn du Werbeblocker für alle Plattformen vollständig umgehen möchtest, dann schließt sGTM diese Lücken.