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 Ihre Google-Tags. Anstatt von googletagmanager.com geladen zu werden, wird Ihr GTM-Skript von einer von Ihnen kontrollierten Subdomain geladen, etwa gtg.yoursite.com. Die GA4-Datenerfassung wird vom Erfassungsendpunkt von Google auf dieselbe Subdomain verlagert.

Die Subdomain gehört Ihnen. 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 Sie 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 Ihre 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 Ihrer 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 Ihre 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 Ihr 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 Ihnen kontrollierten Server.

Ihr Browser sendet ein Ereignis an Ihren Server. Der Server empfängt es, verarbeitet es und leitet es über Server-zu-Server-API-Aufrufe an jede Plattform weiter. Wenn Sie das Enhanced Tracking Script zusammen mit Ihrem 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. Ihr 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 Ihrer Retargeting-Performance bemerkbar macht(hier erfahren Sie, wie Sie 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 Sie verstehen sollten, wenn Sie sich für das Verhalten zwischen gleicher Website und gleicher Herkunft interessieren. GTG wird von einer Subdomain wie gtg.ihre-seite.com ausgeführt. Das ist zwar seitengleich, aber nicht herkunftsgleich mit Ihrer Hauptdomain. Eine vollständige sGTM-Einrichtung kann Ereignisse über einen Pfad auf Ihrer Stammdomäne bereitstellen: yoursite.com/collect. Gleicher Ursprung. Einige Browser und einige Tracking-Mechanismen behandeln diese unterschiedlich, und der sGTM-Ansatz gibt Ihnen 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 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.

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

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

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

Sie brauchen eine Datenkontrolle, die über die Datenwiederherstellung hinausgeht. Mit sGTM können Sie entscheiden, was an die einzelnen Plattformen weitergeleitet wird, die Zustimmungslogik serverseitig anwenden und PII entfernen, bevor die Daten Ihre 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?

Ja, Google Tag Gateway und der Server Google Tag Manager arbeiten auf verschiedenen Ebenen und können ohne Konflikt nebeneinander laufen. Es handelt sich nicht um eine Entweder-Oder-Entscheidung.

Wenn sGTM bereits installiert ist, lädt Ihr browser-seitiger Container weiterhin Skripte und löst Ereignisse aus. GTG kümmert sich speziell um die Bereitstellung von Skripten für Google-Tags. Der Container selbst kann von Ihrer sGTM-Subdomain oder Ihrem Domainpfad aus bedient werden. Das Hinzufügen von GTG beeinträchtigt dies nicht.

Ein konkretes Beispiel: Wenn Sie das TAGGRS Enhanced Tracking Script für das serverseitige Schreiben von Cookies verwenden, wird das Problem der Cookie-Lebensdauer dadurch gelöst. GTG kümmert sich um das Laden des Skripts. Zwei verschiedene Aufgaben, dieselbe Domäne, keine Überschneidungen.

Für die meisten Setups, die über die Grundkonfiguration hinausgehen, ist die praktische Kombination:

• GTG für die Bereitstellung von Google Tag-Skripten
• sGTM für die Ereignis-Pipeline, die Cookie-Persistenz und das Multiplattform-Routing.

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 Sie GA4 und Google Ads ohne serverseitiges Tracking betreiben, ist GTG eine praktische Verbesserung, die Sie einrichten sollten. Es stellt Daten wieder her, die durch Hostnamen-basiertes Blockieren verloren gegangen sind, und das mit sehr geringem Implementierungsaufwand. Wenn Sie bereits mit sGTM arbeiten, ist der zusätzliche Nutzen von GTG geringer. Ihre Ereignisse werden bereits von Server zu Server übertragen. GTG hilft vor allem bei der Skriptladeschicht, die Ihr sGTM-Setup je nach Konfiguration Ihres 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-seitigem Tagging?

Google Tag Gateway ändert den Ort, von dem Ihre Google-Skripte geladen werden. Von einer Subdomain, die Sie kontrollieren, 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.

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