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 het laden vanaf googletagmanager.com, komt uw GTM-script vanaf een subdomein dat u beheert, zoals gtg.yoursite.com. Het verzamelen van GA4-gegevens verschuift van Google's verzamelpunt naar datzelfde subdomein.

Het subdomein is van jou. Google beheert de infrastructuur erachter. De installatie bestaat voornamelijk uit een DNS-wijziging en een containerupdate.

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, heeft GTG geen betrekking op die evenementen.

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. Op basis van verzamelde gegevens uit de praktijk wordt de verbetering geschat op ongeveer 1,5 tot 2,5 procentpunten voor Google-gegevens die anders op scriptniveau zouden worden verwijderd.

Twee dingen die GTM niet oplost

1. Het padprobleem

Ten eerste lost GTG het padprobleem niet op. GTG verandert het domeingedeelte van de URL van het verzoek, maar de padpatronen blijven hetzelfde. Een GA4 verzoek voor gegevensverzameling komt nog steeds terecht bij /g/collect op je subdomein, zoiets als gtg.uwsite.nl/g/verzameling/?id=G-12345678 . Ad blockers zoals Ghostery en uBlock Origin zoeken niet alleen overeenkomsten op hostnamen. Ze filteren ook op bekende padhandtekeningen en /g/collect is een goed gedocumenteerd patroon dat voorkomt in de meeste grote blokkadelijsten. Het verzoek verplaatsen naar je subdomein verandert daar niets aan. Geavanceerde blokkeerders vangen deze verzoeken nog steeds, waardoor GTG minder kan herstellen.

2. Levensduur van cookies

Cookies worden nog steeds ingesteld door JavaScript in de browser. Als je GTM-container client-side wordt uitgevoerd, worden cookies weggeschreven via document.cookie. Safari's Intelligent Tracking Prevention beperkt deze cookies tot 7 dagen. Het maakt niet uit van welk domein het script afkomstig is. De oorsprong van de cookie 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 gebeurtenis 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 gebeurtenissen 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-channelcampagnes signaal verliezen en dit zichtbaar wordt in je retargetingprestaties(hier lees je hoe je gegevensverlies kunt herstellen), 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 script laden	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%*

Er is ook een technisch onderscheid tussen GTG en sGTM dat je moet begrijpen als je je zorgen maakt over gedrag op dezelfde site versus gedrag op dezelfde oorsprong. GTG wordt uitgevoerd vanaf een subdomein zoals gtg.yoursite.com. Dat is same-site, maar niet same-origin met uw hoofddomein. Een volledige sGTM-installatie kan gebeurtenissen weergeven via een pad op je hoofddomein: yoursite.com/collect. Zelfde oorsprong. Sommige browsers en sommige trackingmechanismen behandelen dat anders, en de sGTM-aanpak geeft je meer controle als dat er meer toe doet.

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

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 vereisen cookies die langer dan dag 7 meegaan. GTG biedt die niet.

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

U hebt gegevenscontrole nodig die verder gaat dan gegevensherstel. Met sGTM kunt u beslissen wat naar elk platform wordt doorgestuurd, toestemmingslogica aan de serverzijde toepassen en PII strippen voordat gegevens uw infrastructuur verlaten.

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

Kunnen GTG en Server-Side samenwerken?

Ja, Google Tag Gateway en server Google Tag Manager werken op verschillende lagen en kunnen naast elkaar werken zonder conflicten. Het is geen of/of keuze.

Als sGTM al is geïnstalleerd, laadt je browser-side container nog steeds scripts en vuurt events af. GTG zorgt specifiek voor de levering van scripts voor Google-tags. De container zelf kan worden geserveerd vanaf uw sGTM-subdomein of domeinpad. Het toevoegen van GTG heeft daar geen invloed op.

Een concreet voorbeeld: als u het TAGGRS Enhanced Tracking Script gebruikt voor het schrijven van cookies op de server, dan zorgt dat voor het probleem van de levensduur van cookies. GTG zorgt voor het laden van het script. Twee verschillende taken, hetzelfde domein, geen overlapping.

Voor de meeste opstellingen die verder zijn gegaan dan de basisconfiguratie, is de praktische combinatie:

• GTG voor Google tag script levering
• sGTM voor de event pipeline, cookie persistentie en multi-platform routing.

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, 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 gebeurtenissen verplaatsen zich al van server naar server. GTG helpt voornamelijk de scriptlaadlaag, die 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. Een subdomein dat jij beheert 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 het verwerken van gebeurtenissen van de browser naar een server. Cookies worden geschreven via HTTP-headers, waardoor ze buiten het bereik van ITP vallen. Gebeurtenissen bereiken platforms via server-to-server API-aanroepen 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 scriptaflevering voor Google-tags; sGTM handelt de gebeurtenispijplijn, cookielevensduur en multiplatformsignaalroutering 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.