- \n
- Google Tag Gateway changes where your Google scripts load from. It's a CDN configuration change that recovers data lost to hostname-based blocking, covers Google products only, and does nothing for Safari's 7-day cookie cap. <\/li>\n\n\n\n
- Server-side GTM changes where events get processed and where cookies get written. It moves the event pipeline off the browser entirely, writes cookies via HTTP headers so ITP doesn't apply, and works with any platform that has a server-side API.<\/li>\n<\/ul>\n\n
If your stack is Google-only and your conversion cycle is short, GTG is a reasonable low-effort win. If either of those isn't true, it won't address your issues.<\/p>\n\n
![\"Vergelijking](\"https:\/\/taggrs.io\/wp-content\/uploads\/2026\/05\/google-tag-gateway-vs-server-gtm-setup.svg\" "\\"\\"")
<\/figure>\n\nWat is Google Tag Gateway?<\/h2>\n\n
Google Tag Gateway is a Google-managed proxy for your Google tags<\/strong>. Instead of loading from\u00a0googletagmanager.com, your Google scripts load from a path on your own domain, something like\u00a0yoursite.com\/metrics. GA4<\/a> data collection shifts from Google's collection endpoint to that same path.<\/p>\n\n
The domain is yours. <\/strong>Google manages the infrastructure behind it. Your CDN or load balancer forwards that path to Google. Cloudflare came first, followed by Akamai and Fastly, then Google Cloud Platform, which reached general availability on 1 June 2026<\/a> using GCP's global external Application Load Balancer. Amazon CloudFront support arrived after that, configured through Tag Assistant. Setup is mostly a CDN configuration change and a container update.<\/p>\n\n
Er is ook een tweede manier om GTG te draaien: door het in te schakelen in een bestaande server-side GTM-container. In dat geval draait GTG waar je container ook draait, meestal een subdomein zoals data.yoursite.com. <\/p>\n\n
One hard constraint worth naming upfront: GTG covers Google products only<\/strong>. So GA4, Google Ads<\/a>, Floodlight, and Google Tag are included. If you run Meta, TikTok, Klaviyo, or anything outside that ecosystem, GTG doesn't touch those events.<\/p>\n\n
Wat lost GTG op?<\/h3>\n\n
De meeste advertentieblokkers werken door verzoeken naar bekende hostnamen van derden te blokkeren. googletagmanager.com staat op elke grote blokkadelijst. GTG omzeilt dat door deze aanvragen via jouw domein te routeren, dat op geen enkele lijst staat. <\/p>\n\n
That's a real improvement. Real-world aggregated data puts the uplift at around 4-6% for Google data that would otherwise get dropped at the script level. For more details, see the comparison data by Niek Schlepers<\/a>.<\/p>\n\n
Google's own launch figure was higher, at around 11% signal uplift. The gap between that and independent measurements isn't necessarily either side being wrong<\/strong>. Google's number reflects setups where the gateway was configured well on sites that previously had no first-party routing at all. Independent tests tend to measure incremental gain on sites that already had some protection in place. Where your site lands depends on how much of your traffic runs blockers that match on hostname only, which is the specific loss GTG addresses.<\/p>\n\n
Twee dingen die GTG niet oplost<\/h3>\n\n
1. Het padprobleem<\/h4>\n\n
Ten eerste lost GTG het padprobleem niet op. GTG verandert het domein en laat je een eigen padvoorvoegsel kiezen, maar de bekende eindpuntpatronen blijven in de URL staan. Een GA4 verzoek voor gegevensverzameling komt nog steeds terecht bij \/g\/collect<\/strong> achter je voorvoegsel, iets als yoursite.com\/metrics\/g\/collect?v=2&tid=G-12345678 <\/strong>. Ad blockers zoals Ghostery en uBlock Origin passen niet alleen op hostnamen. Ze filteren ook op bekende padhandtekeningen en \/g\/collect is een goed gedocumenteerd patroon in de meeste grote blokkadelijsten, ongeacht welk domein het aanbiedt. Geavanceerde blokkers vangen deze verzoeken nog steeds, waardoor GTG maar beperkt kan herstellen. <\/p>\n\n
2. Levensduur van cookies<\/h4>\n\n
Cookies are still set by JavaScript running in the browser. When your GTM container fires client-side, it writes cookies via document.cookie. Safari's Intelligent Tracking Prevention caps those cookies at 7 days. Doesn't matter which domain served the script. The cookie origin is the browser's JavaScript environment. GTG doesn't change that layer.<\/p>\n\n
Voor elk attributietraject dat langer duurt dan een week, of voor elke bezoeker die na 7 dagen in Safari terugkomt om te converteren, geldt nog steeds de limiet van 7 dagen. Hetzelfde als voorheen. Het laden van het script is verbeterd; het cookie-probleem is niet verholpen. <\/p>\n\n
Safari has kept tightening this. Safari 27, which shipped in September 2026, added blocking at the network transport layer<\/a> - it now checks the destination IP of outbound connections, not just the domain a script came from. That's worth reading if you're considering GTG specifically, because it's the clearest example of a browser-level change that a first-party domain doesn't solve.<\/p>\n\n
What changed in GTM in August 2026<\/h3>\n\n
Google has been merging Google Tag and Google Tag Manager into a single system. The GTM interface now has a redesigned Overview page, container configuration has moved into a Settings section, and triggers, variables, templates and folders sit under a collapsible Advanced section. Google also added visual tagging, which lets you configure some events by selecting elements directly on the page.<\/p>\n\n
The part relevant here is the architecture. Google says the update allows Tag Manager containers to send data directly to Google destinations. That tightens the integration between GTM, the Google tag and the gateway, and it makes the Google-only path smoother than it was when this comparison was first written.<\/p>\n\n
It doesn't change the two limits above. Cookies are still written by JavaScript, so ITP still applies, and the coverage is still Google products only. But if you're weighing effort as part of the decision, the Google-only route got easier in August.<\/p>\n\n
What is Server-side GTM?<\/h2>\n\n
Server-side GTM haalt het verwerken van gebeurtenissen helemaal weg van de browser en plaatst het op een server die jij beheert.<\/p>\n\n
Your browser sends one event to your server. The server receives it, processes it, and forwards it to each platform via server-to-server API calls. If you use the Enhanced Tracking Script<\/a> along with your server container, the ad blockers have no visibility into those calls. There's nothing running in the browser to block.<\/p>\n\n
Hoe werkt server-side GTM anders?<\/h3>\n\n
De cookie-situatie verandert aanzienlijk. Je server schrijft cookies met HTTP Set-Cookie response headers. ITP's limiet van 7 dagen is gericht op cookies die worden geschreven door JavaScript. Cookies die zijn ingesteld via headers van een first-party origin vallen buiten die beperking. Een correct geconfigureerde server-side setup kan first-party cookies schrijven die 365 dagen of langer meegaan<\/strong>. <\/p>\n\n
Voor sites waar klanten weken nodig hebben om te beslissen, is dat verschil in levensduur van cookies het verschil tussen nauwkeurige attributie en attributie die onvolledig is door het ontwerp.<\/p>\n\n
Coverage<\/strong> is another gap server-side GTM fills. The same container can route events to GA4, Google Ads Enhanced Conversions<\/a>, Meta Conversions API, TikTok Events API<\/a>, and most other platforms that offer a server-side API. If cross-channel campaigns<\/strong> are losing signal and it's starting to show up in your retargeting performance, one event pipeline to all platforms is where the structural fix sits.<\/p>\n\n
De tegenprestatie? GTM heeft hosting, configuratie en GTM-kennis nodig om goed te werken. Het is geen snelle omschakeling. <\/p>\n\n
Google Tag Gateway vs Server-Side GTM: A direct comparison<\/h2>\n\n
![\"\"](\"https:\/\/taggrs.io\/wp-content\/uploads\/2026\/05\/image-3-1024x535.webp\" "\\"\\"")
<\/figure>\n\n