Google Tag Gateway vs Server-side GTM: welke heeft jouw installatie echt nodig?

Google Tag Gateway landde in 2024 en verdeelde onmiddellijk de meningen. Sommige teams beschouwden het als het einde van het gesprek over server-side tracking. Anderen deden het af als een lichtgewicht workaround.

Geen van beide is echt accuraat.

De realiteit is: de 2 tools pakken verschillende problemen aan op verschillende lagen van je installatie. GTG verandert waar scripts vandaan worden geladen. Server-side GTM verandert waar gegevens worden verwerkt en waar cookies worden geschreven. Dat is niet hetzelfde en ze door elkaar halen leidt tot opstellingen die er op papier compleet uitzien, maar echte gaten in de tracering openlaten.

In dit artikel ontdek je wat Google Tag Gateway verandert in je setup en wat het ongemoeid laat, hoe server-side GTM anders omgaat met event processing, cookie lifetime en cross-platform dekking, een directe vergelijking van beide tools op 7 dimensies en een duidelijk kader om te beslissen welke setup (of welke combinatie) past bij je tracking stack.

Wat is Google Tag Gateway?

Google Tag Gateway is een door Google beheerde proxy voor je Google tags. In plaats van te laden vanaf googletagmanager.com, laden je Google scripts vanaf een pad op je eigen domein, zoiets als yoursite.com/metrics. GA4 gegevensverzameling verschuift van Google's verzamelpunt naar datzelfde pad.

Het domein is van jou. Google beheert de infrastructuur erachter. Je CDN of loadbalancer (Cloudflare, Fastly, Akamai, Google Cloud) stuurt dat pad door naar Google. De installatie is meestal een CDN-configuratiewijziging en een containerupdate.

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.

Eén harde beperking die het waard is om vooraf te noemen: GTG heeft alleen betrekking op Google-producten. Dus GA4, Google Ads, Floodlight en Google Tag zijn inbegrepen. Als je Meta, TikTok, Klaviyo of iets anders buiten dat ecosysteem gebruikt, raakt GTG die events niet aan.

Wat lost GTG op?

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.

Dat is een echte verbetering. Uit geaggregeerde gegevens uit de echte wereld blijkt dat de uplift rond de 4-6% ligt voor Google-gegevens die anders op scriptniveau zouden wegvallen(zie de vergelijkende gegevens van Niek Schlepers).

Twee dingen die GTG niet oplost

1. Het padprobleem

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 achter je voorvoegsel, iets als yoursite.com/metrics/g/collect?v=2&tid=G-12345678 . 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.

2. Levensduur van cookies

Cookies worden nog steeds ingesteld door JavaScript in de browser. Wanneer je GTM-container client-side wordt uitgevoerd, worden cookies weggeschreven via document.cookie. Safari's Intelligent Tracking Prevention beperkt die cookies tot 7 dagen. Het maakt niet uit van welk domein het script afkomstig is. De oorsprong van de cookies is de JavaScript-omgeving van de browser. GTG verandert die laag niet.

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.

Wat is server-side GTM?

Server-side GTM haalt het verwerken van gebeurtenissen helemaal weg van de browser en plaatst het op een server die jij beheert.

Je browser stuurt een event naar je server. De server ontvangt het, verwerkt het en stuurt het door naar elk platform via server-naar-server API-oproepen. Als je het Enhanced Tracking Script samen met je servercontainer gebruikt, hebben de advertentieblokkers geen zicht op die oproepen. Er draait niets in de browser om te blokkeren.

Hoe werkt server-side GTM anders?

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.

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.

Dekking is een ander gat dat server-side GTM vult. Dezelfde container kan events routeren naar GA4, Google Ads Enhanced Conversions, Meta Conversions API, TikTok Events API en de meeste andere platforms die een server-side API bieden. Als cross-channel campagnes signaal verliezen en dit zichtbaar begint te worden in je retargetingprestaties(hier lees je hoe je gegevensverlies kunt herstellen), dan is één event pipeline naar alle platforms de structurele oplossing.

De tegenprestatie? GTM heeft hosting, configuratie en GTM-kennis nodig om goed te werken. Het is geen snelle omschakeling.

Google Tag Gateway vs Server-Side GTM: een directe vergelijking

	Google Tag Gateway	Server-kant GTM
Wat verandert er?	Waar scripts vandaan komen	Waar gebeurtenisverwerking plaatsvindt
Cookie-instelling	JavaScript (browser)	HTTP-headers (server)
ITP-impact	Geen verandering	Cookies kunnen 365+ dagen meegaan (met een goede sst setup)
Advertentieblokkering omzeilen	Alleen hostnaam-niveau (bekende paden zoals /g/collect blijven zichtbaar)	Volledige server-naar-server oproepen
Platform dekking	Alleen Google-producten	Elk platform met een server-API
Instelcomplexiteit	Laag	Gemiddeld tot hoog
Typische gegevensstijging	4-6%*	14-20%*

*Controleer de gegevens en vergelijking in GTG of server-side GTM? Het server-side dilemma door Niek Schlepers

Er is ook een technisch onderscheid dat je moet begrijpen als je je zorgen maakt over hetzelfde site vs. hetzelfde oorsprongsgedrag. GTG's CDN setup vereist een pad op je hoofddomein (yoursite.com/metrics), dat dezelfde oorsprong heeft als je site. Een typische sGTM implementatie draait op een subdomein zoals data.yoursite.com. Dat is same-site, maar niet same-origin. Je kunt sGTM ook implementeren achter een root-domein pad, maar dat vereist een reverse proxy voor je container. Sommige browsers en sommige blokkers behandelen subdomeinen en root-domein paden verschillend, dus waar je eindpunten zich bevinden is een architectonische keuze, geen cosmetische.

Welke opstelling is geschikt voor jouw toepassing?

GTG is de juiste keuze als:

• Je stapel bestaat alleen uit Google-producten (GA4, Google Ads, Floodlight)
• De meeste van uw gebruikers gebruiken Chrome
• Conversiecycli zijn korter dan 7 dagen
• Je wilt een verbetering met weinig overhead en minimale configuratie

sGTM is de juiste keuze als:

• Je volgt op meerdere platforms (Meta, TikTok, Klaviyo, Google)
• Je klanten doen er meer dan 7 dagen over om te converteren
• Je hebt cookies nodig die langer meegaan dan de ITP-limiet van Safari
• U wilt toestemming afdwingen aan de serverkant en controle over PII voordat gegevens uw infrastructuur verlaten
• U wilt de volledige reikwijdte begrijpen van wat server-side tracking terugvindt

Hier is een voorbeeld.

Je volgt op verschillende platforms. Een Meta server-side setup is afhankelijk van sGTM, niet van GTG. TikTok, Klaviyo en al het andere buiten het ecosysteem van Google doen dat ook.

Je klanten hebben tijd nodig om te converteren. Reizen van meerdere weken in Safari hebben cookies nodig die dag 7 overleven. GTG biedt dat niet.

Je wilt zien wat je werkelijk verliest. Het volledige beeld van wat server-side tracking terugwint is moeilijk te begrijpen totdat je beide opstellingen gebruikt en vergelijkt.

Je hebt gegevenscontrole nodig die verder gaat dan gegevensherstel. Met sGTM kun je beslissen wat er naar elk platform wordt doorgestuurd, logica voor toestemming server-side toepassen en PII strippen voordat gegevens je infrastructuur verlaten.

De meeste teams die conversie-tracking serieus nemen, komen uiteindelijk uit bij server-side GTM. GTG kan een nuttige eerste stap zijn. Het sluit alleen de infrastructuurkwestie niet.

Kunnen GTG en Server-Side samenwerken?

Technisch gezien werken Google Tag Gateway en server-side GTM op verschillende lagen, dus ze conflicteren niet altijd. Over het algemeen raden we echter niet aan om beide samen te gebruiken. In de praktijk kan het combineren van GTG met je server-side setup interfereren met je bestaande serverconfiguratie. En omdat het risico niet altijd voorspelbaar is, is ons advies om één benadering te kiezen in plaats van ze over elkaar heen te leggen.

Als je al server-side GTM gebruikt met TAGGRS, heb je GTG niet nodig voor het leveren van scripts. Het Enhanced Tracking Script voert deze taak al uit door Google-tagscripts vanaf je eigen domein aan te bieden en de cookie persistentie server-side te beheren. GTG zou een probleem oplossen dat je al hebt opgelost, met extra complexiteit en potentiële conflicten onderweg.

Wil je evalueren welke opstelling past bij jouw behoeften? Bekijk de vergelijkingstabel hierboven.

GTG en sGTM: waar past TAGGRS in?

Server-side GTM heeft een server nodig om op te draaien. Voor de meeste teams is infrastructuurbeheer niet de werkelijke vereiste. Het gaat om prestaties, betrouwbaarheid en de juiste configuratie van de toestemming zonder speciale DevOps-tijd.

TAGGRS biedt een gehoste sGTM-infrastructuur met ingebouwde connectoren voor de belangrijkste advertentieplatforms, integratie van de Consent Mode en privacycontroles. Ben je klaar om de GTG-laag achter je te laten en wil je begrijpen hoe het gegevensherstel er voor jouw specifieke opstelling uitziet?

FAQ

Heb ik Google Tag Gateway nodig?

Als je GA4 en Google Ads draait zonder server-side tracking, dan is GTG een praktische verbetering die de moeite waard is om in te stellen. Het herstelt gegevens die verloren zijn gegaan door hostnaam-gebaseerde blokkering met zeer weinig implementatie-overhead. Als je al sGTM draait, is de incrementele winst van GTG kleiner. Je events bewegen al van server naar server. GTG helpt vooral bij het laden van scripts, wat je sGTM setup misschien al afhandelt, afhankelijk van hoe je container is geconfigureerd.

Lost Google Tag Gateway Safari ITP op?

Nee. GTG verandert niet hoe cookies worden geschreven. ITP is van toepassing op cookies die worden geschreven door JavaScript, ongeacht het domein dat het script serveert.

Wat is het verschil tussen Google Tag Gateway en server-side tagging?

Google Tag Gateway verandert waar je Google-scripts vandaan worden geladen. Je eigen domein in plaats van het domein van Google. De scripts draaien nog steeds in de browser, cookies worden nog steeds geschreven door JavaScript en ITP is nog steeds van toepassing. Geavanceerde advertentieblokkers die matchen op padpatronen in plaats van alleen hostnamen kunnen de verzoeken nog steeds detecteren en blokkeren.

Server-side tagging verplaatst de verwerking van events van de browser naar een server. Cookies worden geschreven via HTTP-headers, waardoor ze buiten het bereik van ITP vallen. Events bereiken platforms via server-to-server API calls waar ad blockers niet bij kunnen. En in tegenstelling tot GTG werkt sGTM op elk platform met een server-side API, niet alleen die van Google.

Ze werken op verschillende lagen. GTG verbetert de scriptlevering voor Google tags; sGTM handelt de event pipeline, levensduur van cookies en multi-platform signaalroutering af. Voor opstellingen waarbij beide problemen van belang zijn, werken ze samen.

Heb ik server-side GTM nodig als ik Google Tag Gateway al gebruik?

GTG verbetert de scriptlevering voor Google-tags. Als je niet-Google platforms gebruikt, cookies nodig hebt die langer dan 7 dagen meegaan of een volledige advertentieblokkeringsomzeiling voor alle platforms wilt, dan biedt sGTM een oplossing voor deze problemen.