![\"Vergleich](\"https:\/\/taggrs.io\/wp-content\/uploads\/2026\/05\/google-tag-gateway-vs-server-gtm-setup.svg\" "\\"\\"")
<\/figure>\n\n\n\nWas ist Google Tag Gateway?<\/h2>\n\n\n\n
Google Tag Gateway ist ein von Google verwalteter Proxy f\u00fcr\u00a0deine\u00a0Google-Tags<\/strong>. Anstatt von googletagmanager.com geladen zu werden, wird dein\u00a0GTM-Skript von einer von\u00a0dir\u00a0kontrollierten Subdomain geladen, etwa\u00a0gtg.deineseite.de. Die GA4-Datenerfassung wird vom Erfassungsendpunkt von Google auf dieselbe Subdomain verlagert.<\/p>\n\n\n\n Die Subdomain geh\u00f6rt dir<\/strong>. Google verwaltet die Infrastruktur dahinter. Die Einrichtung besteht haupts\u00e4chlich aus einer DNS-\u00c4nderung und einem Container-Update.<\/p>\n\n\n\n Eine harte Einschr\u00e4nkung, die wir im Voraus erw\u00e4hnen sollten: GTG deckt nur Google-Produkte ab<\/strong>. GA4, Google Ads, Floodlight und Google Tag sind also eingeschlossen. Wenn du Meta, TikTok, Klaviyo oder irgendetwas anderes au\u00dferhalb dieses \u00d6kosystems verwenden, hat GTG keinen Einfluss auf diese Ereignisse.<\/p>\n\n\n\n Die meisten Werbeblocker blockieren Anfragen an bekannte Hostnamen von Drittanbietern. googletagmanager.com steht auf jeder wichtigen Blockierliste. GTG umgeht dies, indem es diese Anfragen \u00fcber deine Domain leitet, die auf keiner Liste steht.<\/p>\n\n\n\n Das ist eine echte Verbesserung. Aus der Praxis wissen wir, dass die Verbesserung etwa 1,5 bis 2,5 Prozentpunkte f\u00fcr Google-Daten betr\u00e4gt, die sonst auf der Skriptebene untergehen w\u00fcrden. <\/p>\n\n\n\n Erstens: GTG l\u00f6st das Pfadproblem nicht. GTG \u00e4ndert den Dom\u00e4nenanteil der Anfrage-URL, aber die Pfadmuster bleiben gleich. Eine GA4-Datenerfassungsanfrage trifft immer noch auf \/g\/collect<\/strong> auf deiner Subdomain, etwa so gtg.yoursite.com\/g\/collect\/?id=G-12345678 <\/strong>. Werbeblocker wie Ghostery und uBlock Origin suchen nicht nur nach dem Hostnamen. Sie filtern auch nach bekannten Pfadsignaturen, und \/g\/collect<\/strong> ist ein gut dokumentiertes Muster, das in den meisten gro\u00dfen Blockierlisten auftaucht. Das Verschieben der Anfrage auf deine Subdomain \u00e4ndert daran nichts. Ausgefeilte Blocker fangen diese Anfragen immer noch ab, was die M\u00f6glichkeiten von GTG einschr\u00e4nkt, die Daten wiederherzustellen.<\/p>\n\n\n\n Cookies werden immer noch von JavaScript im Browser gesetzt. Wenn dein GTM-Container auf der Client-Seite ausgef\u00fchrt wird, schreibt er Cookies \u00fcber 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 \u00e4ndert diese Ebene nicht.<\/p>\n\n\n\n F\u00fcr jede Attributionsreise, die l\u00e4nger als eine Woche dauert, oder f\u00fcr jeden Besucher, der nach 7 Tagen in Safari zur\u00fcckkommt, 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. <\/p>\n\n\n\n Serverseitiges GTM nimmt die Ereignisverarbeitung komplett aus dem Browser heraus und verlagert sie auf einen von dir kontrollierten Server.<\/p>\n\n\n\n Dein Browser sendet ein Ereignis an deinen Server. Der Server empf\u00e4ngt es, verarbeitet es und leitet es \u00fcber Server-zu-Server-API-Aufrufe an jede Plattform weiter. Wenn du das Enhanced Tracking Script<\/a> zusammen mit deinem Server-Container verwenden, haben die Werbeblocker keinen Einblick in diese Aufrufe. Im Browser l\u00e4uft nichts, was sie blockieren k\u00f6nnten.<\/p>\n\n\n\n Die Cookie-Situation \u00e4ndert sich erheblich. Dein Server schreibt Cookies mit HTTP Set-Cookie Antwort-Headern. Die 7-Tage-Beschr\u00e4nkung von ITP gilt f\u00fcr Cookies, die von JavaScript geschrieben werden. Cookies, die \u00fcber Header von einem Erstanbieter gesetzt werden, unterliegen dieser Beschr\u00e4nkung nicht. Eine korrekt konfigurierte serverseitige Einrichtung kann First-Party-Cookies<\/strong> schreiben , die 365 Tage oder l\u00e4nger g\u00fcltig sind<\/strong>.<\/p>\n\n\n\n F\u00fcr 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\u00e4ndigen Zuordnung.<\/p>\n\n\n\n Die Abdeckung<\/strong> ist eine weitere L\u00fccke, die das serverseitige GTM f\u00fcllt. 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\u00fcbergreifende Kampagnen<\/strong> Signale verlieren und sich dies in deiner Retargeting-Performance bemerkbar macht (hier erf\u00e4hrst du, wie du Datenverluste beheben<\/a> k\u00f6nnen), ist eine Ereignis-Pipeline zu allen Plattformen die strukturelle L\u00f6sung.<\/p>\n\n\n\n Der Kompromiss? GTM ben\u00f6tigt Hosting, Konfiguration und GTM-Kenntnisse, um gut zu funktionieren. Es ist nicht einfach umzuschalten. <\/p>\n\n\n\n Es gibt auch einen technischen Unterschied zwischen GTG und sGTM, den\u00a0du\u00a0verstehen solltest, wenn\u00a0du\u00a0dich\u00a0f\u00fcr das Verhalten zwischen gleicher Website und gleicher Herkunft interessierst. GTG wird von einer Subdomain wie gtg.ihre-seite.com ausgef\u00fchrt. Das ist zwar seitengleich, aber nicht herkunftsgleich mit deiner Hauptdomain. Eine vollst\u00e4ndige sGTM-Einrichtung kann Ereignisse \u00fcber einen Pfad auf deiner Stammdom\u00e4ne 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\u00f6\u00dfere Rolle spielt.<\/p>\n\n\n\nWas wird durch GTG behoben?<\/h3>\n\n\n\n
Zwei Dinge, die GTM nicht behebt<\/h3>\n\n\n\n
1. Das Pfadproblem<\/h4>\n\n\n\n
2. Lebensdauer des Cookies<\/h4>\n\n\n\n
Was ist Server-seitiges GTM?<\/h2>\n\n\n\n
Wie funktioniert das serverseitige GTM anders?<\/h3>\n\n\n\n
Google Tag Gateway vs. Server-Side GTM: ein direkter Vergleich<\/h2>\n\n\n\n
![\"\"](\"https:\/\/taggrs.io\/wp-content\/uploads\/2026\/05\/image-3-1024x535.webp\" "\\"\\"")
<\/figure>\n\n\n\n<\/td> Google Tag Gateway<\/strong><\/td> Server-seitiges GTM<\/strong><\/td><\/tr> Was \u00e4ndert sich<\/td> Woher Skripte geladen werden<\/td> Wo die Ereignisverarbeitung stattfindet<\/td><\/tr> Cookie-Einstellung<\/td> JavaScript (Browser)<\/td> HTTP-Kopfzeilen (Server)<\/td><\/tr> ITP Auswirkungen<\/td> Keine Ver\u00e4nderung<\/td> Cookies k\u00f6nnen mehr als 365 Tage halten (mit einer ordnungsgem\u00e4\u00dfen Einrichtung)<\/td><\/tr> Umgehung des Werbeblockers<\/td> Nur Skript laden<\/td> Vollst\u00e4ndige Server-zu-Server-Aufrufe<\/td><\/tr> Abdeckung der Plattform<\/td> Nur Google-Produkte<\/td> Jede Plattform mit einer Server-API<\/td><\/tr> Komplexit\u00e4t der Einrichtung<\/td> Niedrig<\/td> Mittel bis Hoch<\/td><\/tr> Typischer Daten-Uplift<\/td> 4-6%*<\/td> 14-20%*<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n