# Google Tag Gateway vs. Server-seitiges GTM: was braucht Ihr Unternehmen wirklich? GTG ändert den Ort, von dem aus Google-Skripte geladen werden. sGTM ändert den Ort, an dem die Ereignisverarbeitung stattfindet. Erfahren Sie, welches Setup Sie für Ihr Tracking benötigen und wann Sie beide verwenden sollten. ![Illustration eines Tablets und eines Laptops unter einem Netz verbundener Knoten, als Bild für zwei Wege, Tracking-Daten zu leiten](https://taggrs.io/_astro/hero.BV5cfOYB_ZTnCFy.webp?dpl=dpl_AzPzciij3XxAdVcvxKopSYAzbo1C) Source: https://taggrs.io/de/google-tag-gateway-vs-server-side-gtm/ Author: Mariusz Brucki, Analytics Engineer · [LinkedIn](https://www.linkedin.com/in/mariusz-brucki/) · [Website](https://mariuszbrucki.pl) Published: 2026-05-13 · Updated: 2026-10-02 --- Google hat dies 2024 als First-Party-Modus eingeführt, 2025 in Google Tag Gateway for advertisers umbenannt und seitdem stetig ausgebaut. Die Meinungen gingen sofort auseinander. Manche Teams sahen darin das Ende der Diskussion über Server-side Tracking. Andere taten es als leichtgewichtige Notlösung 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. ![Datenfluss im Vergleich: Bei Google Tag Gateway ist der Weg zu GA4, Meta und Google Ads blockiert, mit Server-side GTM kommen alle Daten an](https://taggrs.io/_astro/google-tag-gateway-vs-server-gtm-setup.CX4vFJSb_Z1Tvzwv.webp?dpl=dpl_AzPzciij3XxAdVcvxKopSYAzbo1C) ## Was ist Google Tag Gateway? Google Tag Gateway ist ein **von Google verwalteter Proxy für Ihre Google-Tags**. Statt von googletagmanager.com laden Ihre Google-Skripte von einem Pfad auf Ihrer eigenen Domain, etwa yoursite.com/metrics. Die Datenerfassung von [GA4](/ga4-server-side-tracking/) verlagert sich vom Erfassungs-Endpunkt von Google auf denselben Pfad. **Die Domain gehört Ihnen.** Google verwaltet die Infrastruktur dahinter. Ihr CDN oder Load Balancer leitet diesen Pfad an Google weiter. Cloudflare war zuerst dabei, gefolgt von Akamai und Fastly, dann Google Cloud Platform, das [am 1. Juni 2026 allgemein verfügbar wurde](https://support.google.com/tagmanager/answer/4620708?hl=en-gb) und dafür den globalen externen Application Load Balancer von GCP nutzt. Danach kam die Unterstützung für Amazon CloudFront hinzu, die über Tag Assistant eingerichtet wird. Die Einrichtung besteht im Wesentlichen 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 man vorab nennen: GTG **deckt nur Google-Produkte ab**. Dazu gehören GA4, [Google Ads](/google-ads-server-side-tracking/), Floodlight und das Google-Tag. Wenn Sie Meta, TikTok, Klaviyo oder etwas anderes außerhalb dieses Ökosystems nutzen, lässt GTG diese Events unberührt. ### 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. Aggregierte Praxisdaten beziffern den Zuwachs auf etwa 4-6 % bei Google-Daten, die sonst auf Skriptebene verloren gingen. Weitere Details finden Sie in [den Vergleichsdaten von Niek Schlepers](https://speakerdeck.com/taggrs131/measurecamp-amsterdam-2026-google-tag-gateway-vs-server-google-tag-manager). Google selbst nannte zum Start einen höheren Wert von rund 11 % mehr Signal. **Die Differenz zu unabhängigen Messungen bedeutet nicht unbedingt, dass eine Seite falschliegt**. Googles Zahl spiegelt Setups wider, in denen das Gateway gut konfiguriert war, auf Websites, die vorher überhaupt kein First-Party-Routing hatten. Unabhängige Tests messen eher den zusätzlichen Gewinn auf Websites, die bereits einen gewissen Schutz hatten. Wo Ihre Website landet, hängt davon ab, wie viel Ihres Traffics Blocker nutzt, die nur nach dem Hostnamen filtern. Genau diesen Verlust behebt GTG. ### 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 weiterhin von JavaScript im Browser gesetzt. Wenn Ihr GTM-Container clientseitig auslöst, schreibt er Cookies über document.cookie. Safaris Intelligent Tracking Prevention begrenzt diese Cookies auf 7 Tage. Dabei spielt es keine Rolle, von welcher Domain das Skript kam. Der Ursprung des Cookies ist die JavaScript-Umgebung des Browsers. An dieser Ebene ändert GTG nichts. 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. Safari verschärft das immer weiter. [Safari 27, erschienen im September 2026, blockiert jetzt auch auf der Netzwerk-Transportebene](/safari-27-tracking-protection/): Es prüft die Ziel-IP ausgehender Verbindungen, nicht nur die Domain, von der ein Skript kam. Das lohnt sich zu lesen, wenn Sie gezielt GTG in Betracht ziehen, denn es ist das deutlichste Beispiel für eine Änderung auf Browserebene, die eine First-Party-Domain nicht löst. ### Was sich im August 2026 in GTM geändert hat Google führt Google Tag und Google Tag Manager zu einem einzigen System zusammen. Die GTM-Oberfläche hat jetzt eine überarbeitete Übersichtsseite, die Containerkonfiguration ist in einen Bereich Einstellungen umgezogen, und Trigger, Variablen, Vorlagen und Ordner liegen in einem einklappbaren Bereich Erweitert. Außerdem hat Google visuelles Tagging eingeführt, mit dem Sie manche Events konfigurieren, indem Sie Elemente direkt auf der Seite auswählen. Relevant ist hier die Architektur. Laut Google können Tag-Manager-Container durch das Update Daten direkt an Google-Ziele senden. Das verzahnt GTM, das Google-Tag und das Gateway enger und macht den reinen Google-Weg reibungsloser als zu der Zeit, als dieser Vergleich zuerst geschrieben wurde. An den beiden Grenzen oben ändert das nichts. Cookies werden weiterhin von JavaScript geschrieben, ITP gilt also weiterhin, und die Abdeckung beschränkt sich weiterhin auf Google-Produkte. Wenn Sie aber den Aufwand in Ihre Entscheidung einbeziehen: Der reine Google-Weg ist im August einfacher geworden. ## Was ist serverseitiges GTM? Serverseitiges GTM nimmt die Ereignisverarbeitung komplett aus dem Browser heraus und verlagert sie auf einen von Ihnen kontrollierten Server. Ihr Browser sendet ein Event 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](/enhanced-tracking-script-against-ad-blockers/) zusammen mit Ihrem Server-Container nutzen, sehen Werbeblocker diese Aufrufe nicht. 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. **Abdeckung** ist eine weitere Lücke, die serverseitiges GTM schließt. Derselbe Container kann Events an GA4, [Google Ads Enhanced Conversions](/google-ads-enhanced-conversions-explained/), die Meta Conversions API, die [TikTok Events API](/tiktok-server-side-tracking/) und die meisten anderen Plattformen mit einer serverseitigen API weiterleiten. Wenn **kanalübergreifende Kampagnen** Signal verlieren und sich das in Ihrer Retargeting-Performance bemerkbar macht, liegt die strukturelle Lösung in einer einzigen Event-Pipeline zu allen Plattformen. Der Kompromiss? GTM benötigt Hosting, Konfiguration und GTM-Kenntnisse, um gut zu funktionieren. Es ist nicht einfach umzuschalten. ## Google Tag Gateway vs. serverseitiges GTM: ein direkter Vergleich ![Google Tag Gateway leitet nur Google-Skripte per Proxy und ist leicht einzurichten, Server-side GTM deckt 90 % der Plattformen ab, braucht aber GTM-Wissen](https://taggrs.io/_astro/image-3.Bv6dGLg5_Z1RgWNc.webp?dpl=dpl_AzPzciij3XxAdVcvxKopSYAzbo1C) | | **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%\* | \* Die Daten und den Vergleich finden Sie in [GTG or server-side GTM? The server-side dilemma von Niek Schlepers](https://speakerdeck.com/taggrs131/measurecamp-amsterdam-2026-google-tag-gateway-vs-server-google-tag-manager) Diese Zuwächse sind Durchschnittswerte. Ein Blick auf Ihre eigenen Zahlen gibt Ihnen ein besseres Bild davon, was Sie erwarten können. [Dieser Rechner schätzt, was ein serverseitiges Setup für Ihren Traffic zurückholen würde](/calculate-server-side-tracking-roi/), basierend auf Ihrem Plattform-Mix und der Browserverteilung. 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. Mehr über [Same-Origin-Tracking und wie es die Cookie-Lebensdauer wiederherstellen kann](/same-origin-tracking-full-cookie-lifetime/). ## 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 Manche Branchen stoßen früher an diese Grenzen als andere. [iGaming](/server-side-tracking-for-igaming-online-gambling-operators/) und [Marken aus Gesundheit und Wellness](/server-side-tracking-for-wellness-and-health-brands/) treffen beide früh auf die Grenzen bei Cookie-Lebensdauer und Einwilligung, weil ihre Conversion-Zyklen lang sind und ihre Werbeplattformen einschränken, was clientseitig getrackt werden darf. Wenn Sie [WooCommerce](/woocommerce-server-side-tracking/) oder [Shopify](/shopify-server-side-tracking/) nutzen, behandeln die plattformspezifischen Setup-Anleitungen das Mapping der E-Commerce-Events ausführlicher. Hier ist ein Beispiel. Du verfolgst plattformübergreifend. Eine [server-seitige Meta-Einrichtung](/de/facebook-server-side-tracking/) 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 serverseitiges GTM 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. Sie sind nicht sicher, auf welcher Seite Ihr Setup steht? [Dieser Leitfaden zeigt, wie widerstandsfähig Ihr aktuelles Tracking-Setup ist](/de/server-side-tracking-how-resilient-is-your-setup/) und was es wahrscheinlich durch Blockierung, Cookie-Limits und Lücken bei der Einwilligung verliert. ## GTG und sGTM: Wo passt TAGGRS ins Bild? Serverseitiges GTM braucht einen Server, auf dem es läuft. Für die meisten Teams geht es dabei nicht um die Verwaltung von Infrastruktur, sondern um Performance, Zuverlässigkeit und eine saubere Consent-Konfiguration ohne eigene DevOps-Kapazität. 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? Die meisten Teams, die Conversion-Tracking ernst nehmen, landen irgendwann bei serverseitigem Tracking. Die Frage ist meist, wann, nicht ob. [Erstellen Sie ein kostenloses TAGGRS-Konto](https://dashboard.taggrs.io/register), um einen Server-Container zu betreiben, ohne die Infrastruktur selbst zu verwalten, oder [führen Sie zuerst ein kostenloses Audit durch](https://taggrs.io/website-tracking-checker/), um zu sehen, was Ihr aktuelles Setup verliert. ## FAQ **Brauche ich Google Tag Gateway?**\ \ Wenn Sie GA4 und Google Ads ohne jegliches serverseitiges Tracking betreiben, ist GTG eine praktische Verbesserung, deren Einrichtung sich lohnt. Es holt Daten zurück, die durch Blockierung auf Hostnamen-Ebene verloren gehen, mit sehr wenig Implementierungsaufwand. Wenn Sie bereits sGTM nutzen, ist der zusätzliche Gewinn durch GTG kleiner. Ihre Events laufen bereits von Server zu Server. GTG hilft vor allem beim Laden der Skripte, und das übernimmt Ihr sGTM-Setup je nach Konfiguration Ihres Containers möglicherweise schon. **Löst Google Tag Gateway das Problem mit 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 kam. **Was ist der Unterschied zwischen Google Tag Gateway und serverseitigem Tagging?**\ \ Google Tag Gateway ändert, von wo Ihre Google-Skripte geladen werden: von Ihrer eigenen Domain statt von der Domain von Google. Die Skripte laufen weiterhin im Browser, Cookies werden weiterhin von JavaScript geschrieben, und ITP gilt weiterhin. Ausgefeilte Werbeblocker, die nach Pfadmustern statt nur nach Hostnamen filtern, können die Anfragen weiterhin 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 Auslieferung der Skripte für Google-Tags; sGTM übernimmt die Event-Pipeline, die Cookie-Lebensdauer und die Weiterleitung der Signale an mehrere Plattformen. Grundsätzlich sind sie kompatibel, aber beides parallel zu betreiben kann eine bestehende serverseitige Konfiguration auf nicht immer vorhersehbare Weise stören. Wir empfehlen daher, sich für eines zu entscheiden, statt beide übereinanderzulegen. **Brauche ich serverseitiges GTM, wenn ich bereits Google Tag Gateway nutze?**\ \ GTG verbessert die Auslieferung der Skripte für Google-Tags. Wenn Sie Plattformen außerhalb von Google nutzen, Cookies brauchen, die länger als 7 Tage halten, oder Werbeblocker auf allen Plattformen vollständig umgehen möchten, schließt sGTM diese Lücken.\ \ **Hilft Google Tag Gateway bei modellierten Conversions?**\ \ Indirekt. [Conversion-Modellierung](/what-conversion-modeling-is-and-can-you-really-trust-it/) füllt Lücken, wo beobachtete Daten fehlen. Alles, was die Zahl der beobachteten Conversions erhöht, verringert also, wie viel die Plattform schätzen muss. GTG holt einen Teil davon auf Skriptebene zurück. Ein serverseitiges Setup holt mehr zurück und liefert Ihnen außerdem First-Party-Cookies, die über die 7-Tage-Grenze von Safari hinaus bestehen. Genau dort entsteht ein großer Teil des modellierten Anteils. **Welche CDNs unterstützen Google Tag Gateway?**\ \ Cloudflare, Akamai, Fastly, Google Cloud Platform und Amazon CloudFront. Die GCP-Integration ist seit dem 1. Juni 2026 allgemein verfügbar und nutzt den globalen externen Application Load Balancer; CloudFront wird über Tag Assistant eingerichtet. Sie können das Gateway auch in einem bestehenden serverseitigen GTM-Container betreiben statt über ein CDN. **Funktioniert Google Tag Gateway mit Meta oder TikTok?**\ \ Nein. GTG deckt nur Google-Produkte ab: GA4, Google Ads, Floodlight und das Google-Tag. Events an Meta, TikTok, Klaviyo oder andere Plattformen bleiben davon unberührt. Um sie serverseitig weiterzuleiten, brauchen Sie einen Server-Container und die API der jeweiligen Plattform, etwa die Meta Conversions API oder die TikTok Events API.