Google Tag Gateway vs. Server-seitiges GTM: was braucht Ihr 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 Ihrer 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 erfahren Sie, was Google Tag Gateway an Ihrer Einrichtung ändert und was es unangetastet lässt, wie das serverseitige 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 Ihrem 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 werden deine Google-Skripte von einem Pfad auf deiner eigenen Domain geladen, etwa yoursite.com/metrics. Die GA4-Datenerfassung wird von Googles Erfassungsendpunkt auf denselben Pfad verlagert.

Die Domain gehört dir. Google verwaltet die Infrastruktur dahinter. Dein CDN oder Load Balancer (Cloudflare, Fastly, Akamai, Google Cloud) leitet diesen Pfad an Google weiter. Die Einrichtung besteht hauptsächlich aus einer Änderung der CDN-Konfiguration und einem Container-Update.

Es gibt noch eine zweite Möglichkeit, GTG auszuführen: Du aktivierst es innerhalb eines bestehenden server-seitigen GTM-Containers. In diesem Fall wird GTG dort ausgeführt, wo dein Container läuft, in der Regel auf einer Subdomain wie data.yourite.com.

Eine harte Einschränkung sollte im Voraus genannt werden: GTG deckt nur Google-Produkte ab. Das heißt, GA4, Google Ads, Floodlight und Google Tag sind eingeschlossen. Wenn du Meta, TikTok, Klaviyo oder etwas anderes außerhalb dieses Ökosystems verwendest, hat GTG keinen Einfluss auf diese Events.

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 Ihre Domain leitet, die auf keiner Liste steht.

Das ist eine echte Verbesserung. In der realen Welt liegt der Uplift bei etwa 4-6 % für Google-Daten, die sonst auf Skriptebene wegfallen würden(siehe die Vergleichsdaten von Niek Schlepers).

Zwei Dinge, die GTG nicht behebt

1. Das Pfadproblem

Erstens: GTG löst das Pfadproblem nicht. GTG ändert die Domäne und lässt dich ein eigenes Pfadpräfix wählen, aber die bekannten Endpunktmuster bleiben in der URL. Eine GA4-Datenerfassungsanfrage trifft immer noch auf /g/collect hinter deinem Präfix, etwa so yoursite.com/metrics/g/collect?v=2&tid=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 in den meisten großen Blockierlisten, unabhängig davon, welche Domain sie bedient. Ausgefeilte Blocker fangen diese Anfragen trotzdem ab, was die Möglichkeiten von GTG einschränkt.

2. Lebensdauer des Cookies

Cookies werden immer noch von JavaScript im Browser gesetzt. Wenn dein GTM-Container auf dem Client ausgeführt wird, schreibt er Cookies über document.cookie. Die intelligente Tracking-Prävention 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 Ihnen kontrollierten Server.

Dein Browser sendet ein Event 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 verwendest, 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 der 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 server-side 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 serverseitiges GTM schließt. Ein und derselbe Container kann Events an GA4, Google Ads Enhanced Conversions, Meta Conversions API, TikTok Events API und die meisten anderen Plattformen weiterleiten, die eine server-seitige API anbieten. Wenn kanalübergreifende Kampagnen an Signalstärke verlieren und sich das in deiner Retargeting-Performance niederschlägt(hier erfährst du, wie du Datenverluste beheben kannst), ist eine einzige Event-Pipeline für alle 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 auf Hostnamen-Ebene (bekannte Pfade wie /g/collect bleiben offen)	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%*

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

Es gibt auch einen technischen Unterschied, den du verstehen solltest, wenn du dich für Same-Site- und Same-Origin-Verhalten interessierst. GTGs CDN-Einrichtung erfordert einen Pfad auf deiner Root-Domain (deine.de/metrics), die denselben Ursprung hat wie deine Website. Ein typischer sGTM-Einsatz läuft auf einer Subdomain wie data.deineSeite.com. Das ist zwar same-site, aber nicht same-origin. Du kannst sGTM auch hinter einem Root-Domain-Pfad einsetzen, aber dafür ist ein Reverse Proxy vor deinem Container erforderlich. Einige Browser und Blocker behandeln Subdomains und Root-Domain-Pfade unterschiedlich. Wo deine Endpunkte liegen, ist also eine architektonische Entscheidung, keine kosmetische.

Welches Setup ist das richtige für Ihren Anwendungsfall?

GTG ist die richtige Wahl, wenn:

• Ihr Stack besteht nur aus Google-Produkten (GA4, Google Ads, Floodlight)
• Die meisten Ihrer Benutzer benutzen Chrome
• Die Konvertierungszyklen sind kürzer als 7 Tage
• Sie möchten eine Verbesserung mit geringem Aufwand und minimaler Konfiguration

sGTM ist die richtige Wahl, wenn:

• Sie verfolgen mehrere Plattformen (Meta, TikTok, Klaviyo, Google)
• Ihre Kunden brauchen mehr als 7 Tage, um zu konvertieren
• Sie benötigen Cookies, die über das ITP-Limit von Safari hinaus bestehen bleiben
• Sie möchten eine serverseitige Durchsetzung der Zustimmung und eine Kontrolle der personenbezogenen Daten, bevor die Daten Ihre Infrastruktur verlassen.
• Sie möchten den vollen Umfang der serverseitigen Verfolgung verstehen

Hier ist ein Beispiel.

Du verfolgst plattformübergreifend. Eine server-seitige 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 brauchen Cookies, die über Tag 7 hinaus Bestand haben. GTG bietet das nicht.

Du willst sehen, was du tatsächlich verlierst. Was das server-side Tracking alles wiederherstellt, kannst du erst dann richtig einschätzen, wenn du beide Setups ausprobierst und vergleichst.

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 server-side GTM. GTG kann ein nützlicher erster Schritt sein. Es löst nur nicht die Frage nach der Infrastruktur.

Können GTG und Server-Side zusammenarbeiten?

Technisch gesehen arbeiten das Google Tag Gateway und das server-side GTM auf unterschiedlichen Ebenen, sodass sie nicht immer in Konflikt miteinander stehen. Wir empfehlen jedoch generell nicht, beides zusammen zu verwenden. In der Praxis kann die Kombination von GTG mit deiner server-side Einrichtung deine bestehende Serverkonfiguration beeinträchtigen. Und da das Risiko nicht immer vorhersehbar ist, raten wir dir, dich für einen Ansatz zu entscheiden und nicht beides übereinander zu legen.

Wenn du bereits serverseitiges GTM mit TAGGRS verwendest, brauchst du GTG nicht für die Skriptbereitstellung. Das Enhanced Tracking Script übernimmt diese Aufgabe bereits, indem es Google Tag-Skripte von deiner eigenen Domain aus bereitstellt und die Cookie-Persistenz serverseitig verwaltet. GTG würde ein Problem lösen, das du bereits gelöst hast, und dabei zusätzliche Komplexität und potenzielle Konflikte mit sich bringen.

Du willst herausfinden, welches Setup zu deinen Bedürfnissen 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. Sind Sie bereit, über die GTG-Ebene hinauszugehen, und möchten Sie verstehen, wie die Datenwiederherstellung für Ihre spezifische Einrichtung aussieht?

FAQ

Brauche ich Google Tag Gateway?

Wenn du GA4 und Google Ads ohne server-side Tracking betreibst, ist GTG eine praktische Verbesserung, die es wert ist, eingerichtet zu werden. Es stellt Daten wieder her, die durch die Hostnamen-basierte Sperrung verloren gegangen sind, und das mit sehr wenig Implementierungsaufwand. Wenn du bereits mit sGTM arbeitest, ist der Zugewinn durch GTG geringer. Deine events werden bereits von Server zu Server übertragen. GTG hilft hauptsächlich beim Laden von Skripten, was je nach Konfiguration deines Containers bereits von sGTM erledigt werden kann.

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-seitigem Tagging?

Google Tag Gateway ändert, von wo aus deine Google-Skripte geladen werden. Von deiner eigenen Domain und nicht von der Domain von Google. 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.

Serverseitiges Tagging verlagert die Ereignisverarbeitung vom Browser auf den Server. Cookies werden über HTTP-Header geschrieben, wodurch sie außerhalb der Reichweite von ITP liegen. Events 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 server-side API, nicht nur auf der von Google.

Sie arbeiten auf unterschiedlichen Ebenen. GTG verbessert die Skriptauslieferung für Google-Tags; sGTM kümmert sich um die Event-Pipeline, die Cookie-Lebensdauer und die Weiterleitung von Signalen auf mehreren 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 Sie Plattformen betreiben, die nicht von Google stammen, wenn Sie Cookies benötigen, die länger als 7 Tage halten, oder wenn Sie Werbeblocker für alle Plattformen vollständig umgehen möchten, dann schließt sGTM diese Lücken.