Google Tag Gateway: wat is het, waarom en wanneer gebruikt u het?

De afgelopen maanden is Google Tag Gateway (ook wel GTG genoemd) van een stille uitrol uitgegroeid tot een regelmatig besproken onderwerp. Ik denk dat dit komt doordat Google het tijdens gesprekken steeds vaker onder de aandacht brengt en doordat de vraag naar tracking via het eigen domein toeneemt.

Ik ben Manisha Mistry, Technical Lead bij MeasureU. Ik leg graag onderwerpen zoals tracking aan de serverzijde uit, waardoor ik steeds meer vragen over Google Tag Gateway krijg. Meer specifiek zijn mij de afgelopen maanden de volgende vier vragen meerdere keren gesteld.

• Wat is Google Tag Gateway?
• Moet ik het gebruiken?
• Wat is het verschil met tracking aan de serverzijde?
• Heb ik het nodig als ik al tracking aan de serverzijde gebruik?

Mijn doel met dit blogartikel is om alle vier de vragen te beantwoorden. Zoals altijd begin ik met de basis en ga ik daarna dieper in op hoe Google Tag Gateway werkt en hoe het verschilt van tracking aan de serverzijde. Ik sluit af met een besliskader waar u van tijd tot tijd op kunt terugkomen om te bepalen welke trackingoplossing voor u en uw klant het beste werkt.

Nog één korte opmerking voordat we erin duiken: dit artikel is geschreven op basis van mijn eigen GTG-configuratie en tests op het moment dat dit artikel werd geschreven. Google blijft GTM, GTG, sGTM en het bredere tagging-ecosysteem ontwikkelen, dus onderdelen hiervan kunnen in de loop van de tijd veranderen naarmate Google het product verbetert. De basisconcepten blijven hetzelfde; de exacte paden, schakelaars en schermen kunnen veranderen.

Elke Analytics-configuratie begint met tracking aan de clientzijde.

Meestal houdt dit in dat u GA4 op uw website installeert, via Google Tag Manager (mijn voorkeur) of via een website-integratie. In beide gevallen draaien de scripts in de browser van de bezoeker en zijn de domeinen voor deze scripts meestal van Google.

Ze kunnen er bijvoorbeeld als volgt uitzien...

• www.googletagmanager.com (voor het GTM-container-script)
• www.google-analytics.com (voor GA4-collect-events)
• googleads.g.doubleclick.net (voor Google Ads-conversies)

Het belangrijkste om op te merken is dat de hostnamen Google-domeinen zijn en niet het domein van uw website. Vanuit het perspectief van de browser van de bezoeker zijn dit dus van derden-requests en geen requests via het eigen domein.

Third-party-requests zijn op zichzelf geen probleem, totdat u gegevens begint te verliezen door adblockers, Safari Intelligent Tracking Prevention (ITP) en alles wat ze verder blokkeert.

Wanneer u net met tracking begint of een website met weinig verkeer en lage advertentie-uitgaven heeft, is tracking aan de clientzijde een goede plek om te beginnen en te blijven. Naarmate het verkeer toeneemt en marketingbudgetten stijgen, gaat u (of uw klant) echter steeds meer letten op het verschil tussen 'wat er werd geactiveerd' en 'wat daadwerkelijk werd geregistreerd'. Dan komt tracking via het eigen domein in beeld.

Voordat we specifiek ingaan op Google Tag Gateway, staan we even stil bij wat een gateway precies is en hoe het werkt.

De technische definitie van een gateway is een reverse proxy. Deze bevindt zich tussen uw bezoekers en het endpoint van een leverancier en presenteert de request opnieuw alsof deze van uw domein afkomstig is. De inhoud van de request verandert HELEMAAL NIET; alleen de carrier, oftewel de hostname, verandert.

Gateways zijn tegenwoordig overal te vinden. Meta heeft bijvoorbeeld de Conversions API Gateway, TikTok heeft de Events API Gateway en ook veel andere platforms bouwen gateways. Ze zijn populair omdat elke leverancier met hetzelfde probleem te maken heeft: het script draait in de browser, wordt geblokkeerd en we verliezen signalen. Een gateway instellen is de snelste manier om requests van van derden naar via het eigen domein om te zetten.

Zoals altijd houd ik van analogieën. Om gateways beter te begrijpen en aan klanten uit te leggen, gebruik ik een analogie die naar mijn ervaring goed werkt.

We zijn allemaal op enig moment in ons leven naar school geweest of hebben vandaag kinderen op school. Soms bestelde een docent om iets te vieren pizza voor de klas en liet die op school bezorgen.

Waar ik woon, laten scholen een bezorger niet door de voordeur naar binnen lopen, door de gang lopen en rechtstreeks naar een klaslokaal gaan. Dat komt doordat de bezorger een derde partij voor de school is. Er is geen achtergrondcontrole uitgevoerd en de bezorger heeft geen schoolpas.

De taak van de school is om derden zoals deze bezorger overdag uit de gangen te houden om de leerlingen te beschermen.

In plaats daarvan brengt de bezorger de pizza niet rechtstreeks naar de klas. De bezorger gaat naar de school, loopt naar de receptie, geeft de pizza aan een schoolmedewerker en die medewerker brengt de pizza de rest van de weg naar het klaslokaal.

De pizza die in het klaslokaal aankomt, is exact dezelfde pizza die de bezorger naar de school bracht. Het is nog steeds een pepperonipizza, nog steeds warm en nog steeds in dezelfde doos. Wat is veranderd, is de persoon die de pizza door de gang draagt. In plaats van een externe bezorger wordt de pizza gedragen door een schoolmedewerker die alle vereiste achtergrondcontroles heeft doorlopen en in de gangen mag komen. De klas krijgt exact dezelfde pizza, maar vanuit het perspectief van de school ziet de overdracht er volledig anders uit.

In eenvoudige termen is dat een gateway.

De inhoud van de request is niet veranderd. Het was nog steeds een pizza, maar de persoon die de pizza vervoerde, is veranderd. Iedereen die de pizza door de gang zag gaan, had daar geen probleem mee, omdat de schoolmedewerker via het eigen domein is voor de school. Die persoon werkt op de school en mag daar zijn.

Als de bezorger daarentegen door de school was gelopen, zou dat een probleem zijn geweest. De bezorger zou waarschijnlijk helemaal niet zijn binnengelaten of onderweg zijn tegengehouden, omdat die persoon niet in de school mag komen.

Nu we weten wat een gateway is, gaan we dieper in op Google Tag Gateway (GTG).

Hier is de definitie van Google zelf, rechtstreeks uit hun helpcentrum:

In eenvoudige termen is GTG een reverse proxy die de hostname van uw GA4- en Google Ads-requests verandert van Google-domeinen naar uw websitedomein. De inhoud van de requests, zoals events, parameters, cookies en de consentstatus, verandert niet; alleen de carrier verandert. Denk terug aan de pizza-analogie: de pizza bleef hetzelfde, alleen de vervoerder veranderde.

Voordat we dieper op GTG ingaan, zijn er een paar belangrijke details die u moet kennen...

• GTG is alleen voor Google - GTG is ontworpen om alleen Google-scripts zoals GA4 en Google Ads opnieuw via uw eigen domein aan te bieden. Dat betekent dat Meta Pixel, LinkedIn Insight en alle andere requests requests van derden blijven.
• Cookies blijven JavaScript-cookies - GTG verandert niet hoe cookies worden ingesteld. De browser voert het GA4-clientscript nog steeds uit en cookies worden nog steeds via JavaScript geschreven. U kunt dus nog steeds worden beperkt door Safari ITP's limiet van 7 dagen voor JavaScript-cookies.
• GTG transformeert of verwijdert op zichzelf geen gegevens - met GTG kunt u geen gegevens in de daadwerkelijke request aanpassen of wijzigen. Het past alleen de header aan; de request body (de inhoud van de request) blijft exact hetzelfde.

Het is belangrijk om deze drie details te begrijpen wanneer u Google Tag Gateway vs tracking aan de serverzijde overweegt.

Google's documentatiepagina beschrijft drie implementatieopties voor GTG. Elke optie verplaatst een ander deel van uw tracking van van derden naar via het eigen domein en heeft een eigen complexiteitsniveau. Ik heb ze alle drie ingesteld op mijn eigen demosite, datadrivenuniversity.com, zodat u per optie een echte voor-en-na-afbeelding ziet van hoe de tracking is veranderd.

Eén ding wil ik vooraf benadrukken. Google presenteert deze mogelijkheden als drie afzonderlijke opties, maar nadat ik ze alle drie heb ingesteld, zie ik ze niet zo. In plaats daarvan vind ik dat elke optie voortbouwt op de vorige. Dit is mijn persoonlijke mening op basis van mijn ervaring. Daarmee gezegd, laten we elke optie bekijken.

Dit is de eenvoudigste versie van GTG, omdat u niets aan uw bestaande configuratie hoeft aan te passen en het slechts een paar klikken kost.

Wat verandert: GA4-collects en Google Ads-conversies worden uitgevoerd via your-domain.com in plaats van google-analytics.com / googleads.g.doubleclick.net. Ze worden requests via het eigen domein.

Wat niet verandert: het GTM-container-script zelf wordt nog steeds geladen vanaf googletagmanager.com. Ik heb dit in mijn eigen configuratie bevestigd. De inhoud van uw GA4- en GAds-requests blijft ook exact hetzelfde.

Om dit in de praktijk te laten zien, heb ik Google Tag Gateway met Cloudflare ingesteld op mijn testsite datadrivenuniversity.com. Hieronder ziet u hoe mijn GA4-requests eruitzagen voordat ik Google Tag Gateway activeerde.

Daarna heb ik GTG ingesteld met Cloudflare en GTM. De volledige configuratie duurde ongeveer drie klikken. Daarna ziet u dat dezelfde GA4-hit nu via mijn eigen domein datadrivenuniversity.com/bppc binnenkomt.

Note: u zult merken dat de GA4-hits nu beginnen met c? in plaats van collect?; dit komt door GTG.

Met deze implementatie heb ik mijn GA4-requests van van derden naar via het eigen domein verplaatst. Ze lopen nu via datadrivenuniversity.com/bppc in plaats van google-analytics.com. Hetzelfde geldt voor mijn Google Ads-conversies, die van googleads.g.doubleclick.net naar hetzelfde pad via het eigen domein gaan.

Tijdens het testen van optie 1 merkte ik dat mijn Google Ads- en GA4-requests naar via het eigen domein gingen, maar dat het script van mijn Google Tag Manager-container nog steeds vanaf googletagmanager.com werd geladen. GTM bleef een request van derden. Dit is waar optie 2 in beeld komt, en Google Tag Gateway vs Google Tag Manager wordt hier relevant.

Wat verandert: gtm.js wordt nu vanaf uw eigen domein geladen, bijvoorbeeld datadrivenuniversity.com/metrics/custom-path, in plaats van googletagmanager.com. Nu zijn uw GTM-, GA4- en Google Ads-hits vanuit het perspectief van de browser van de bezoeker allemaal via het eigen domein.

Ik heb dit ingesteld met een sGTM-container, met behulp van een Google Tag Manager: web container client waarmee ik de web-GTM-container vanuit de servercontainer kan laden en een aangepast pad kan instellen. Er zijn andere manieren om GTM via het eigen domein te maken, maar sGTM is de methode die ik heb getest.

Wat niet verandert: uw niet-Google-hits, zoals Meta Pixel, TikTok Pixel, LinkedIn Insight en andere niet-Google-tags, blijven requests van derden.

Om dit in de praktijk te laten zien, ziet u hier hoe het script van mijn web-GTM-container eruitzag in DevTools voordat ik de sGTM-container toevoegde en mijn webcontainer daarmee liet laden.

Nadat ik een server en de sGTM-container had ingericht, een client had ingesteld en het tag-servingpad had opgegeven, gebruikt de request nu mijn domein en aangepaste pad.

Op dit punt komen mijn GA4- en Google Ads-requests via Cloudflare binnen als via het eigen domein en laadt mijn sGTM-container mijn web-GTM-container ook vanaf een eigen domein. Alle andere platforms blijven van derden.

Optie 3 is de door Google aanbevolen GTG-implementatie, en eerlijk gezegd was dit de meest verwarrende optie om in te stellen en te begrijpen. Het veranderde ook hoe ik naar Google Tag Gateway aan de serverzijde versus tracking aan de serverzijde kijk, maar ik bewaar die conclusie voor het einde, zodat deze beter landt nadat u de volledige configuratie hebt gezien.

Een korte samenvatting van waar we staan:

• In optie 1 hebben we onze GA4-/Google Ads-requests via de gateway (bijvoorbeeld Cloudflare) van van derden naar via het eigen domein verplaatst. Dit betekent dat requests voor zowel GA4/GAds-scripts (alleen Google) als dataverzameling naar via het eigen domein zijn verplaatst.
• In optie 2 hebben we ons GTM-container-script via een servercontainer van van derden naar via het eigen domein verplaatst; onze dataverzameling voor alleen Google-tracking bleef de gateway gebruiken.
• In optie 3 blijven onze scripts op precies dezelfde manier laden (GA4-scripts via de gateway, GTM via de sGTM-container). Wat verandert, is dat de dataverzameling via de server loopt, zodat u deze kunt transformeren voordat de data downstream wordt verzonden.

Wat verandert: in plaats van dat onze eventdata als hits via het eigen domein via het CDN rechtstreeks naar Google gaan, loopt de data nu via onze sGTM-container. De sGTM-container ontvangt de events en van daaruit kunnen we de data transformeren, verrijken of verwijderen voordat deze downstream wordt verzonden. In feite draait tagging aan de serverzijde parallel aan GTG. We gebruiken beide tegelijkertijd.

Deze configuratie maakt het ook mogelijk om niet-Google-tags, zoals Facebook, LinkedIn en TikTok, naar via het eigen domein te verplaatsen. Daarvoor moeten we die tags wel in onze sGTM-container instellen en een volledige implementatie aan de serverzijde uitvoeren. Zodra die configuratie in de sGTM-container is voltooid, lopen ook deze hits via de server en worden ze hits via het eigen domein.

Wat niet verandert: ons GTM-container-script wordt nog steeds vanaf onze sGTM-server aangeboden (overgenomen uit optie 2). De GA4-configuratieaanroepen worden nog steeds via ons CDN aangeboden (overgenomen uit optie 1).

Om dit in de praktijk te laten zien, ziet u hier hoe mijn GA4-collect-hits eruitzagen in optie 2, toen ze via mijn Cloudflare-pad liepen.

Nadat ik de URL van de servercontainer in mijn configuratietag van de web-GTM-container heb ingesteld en een GA4-client en -tag in mijn sGTM-container heb geconfigureerd, lopen mijn collects nu via de sGTM-server.

Met deze implementatie loopt mijn GA4-eventdataverzameling nu via mijn sGTM-container, waar ik de data kan routeren, verrijken of verwijderen voordat deze downstream wordt verzonden. Hetzelfde kan worden toegepast op elk ander platform, inclusief niet-Google-platforms, zolang ik de vereiste tags en triggers in mijn web-/servercontainer instel.

Nu we begrijpen wat Google Tag Gateway is en welke drie manieren er zijn om het te implementeren, is de volgende logische vraag die ik altijd krijg: wat is het verschil tussen Google Tag Gateway en tracking aan de serverzijde?

Naar mijn mening zijn het geen concurrerende producten.

Google Tag Gateway, specifiek optie 1, draait om het routeren van uw events zodat ze op het niveau van de request-header van van derden naar via het eigen domein gaan. Server-side tracking draait om controle: meer controle over uw data en daardoor overstappen op tracking via het eigen domein. Dit ziet u ook in de eigen documentatie van Google: in optie 3 hierboven moet u een servercontainer introduceren en uw events via die container routeren om meer controle over uw data te krijgen.

Om het verschil tussen de twee uit te leggen, vindt u hieronder een korte vergelijkingstabel:

Kort samengevat zijn Google Tag Gateway en tracking aan de serverzijde geen concurrerende producten. Het ene brengt u snel naar tracking via het eigen domein, puur vanuit het perspectief van de request. Het andere geeft u volledige controle over uw data. U kunt met het ene beginnen en later naar het andere overstappen wanneer uw behoeften veranderen; precies daar komt het besliskader in beeld.

De keuze bij Google Tag Gateway vs serverzijde is een van de meest voorkomende vragen die ik krijg, zowel bij MeasureU als vanuit de LinkedIn-community. Het is ook een van de eerste dingen waar klanten naar vragen wanneer we met implementatiewerk beginnen. Daarom heb ik een besliskader opgesteld om u te helpen die keuze te maken.

Het belangrijkste om te weten is dat dit framework niet bedoeld is om één keer te worden gebruikt. U doorloopt het één keer en komt er daarna steeds opnieuw op terug naarmate uw meettraject zich verder ontwikkelt. U kunt beginnen met tracking aan de clientzijde, overstappen op GTG en later naar tracking aan de serverzijde gaan wanneer uw behoeften veranderen.

Doorloop het framework vandaag en bepaal waar u zich in uw traject bevindt. Kom er vervolgens na een paar weken of maanden werk op terug en doorloop het opnieuw. Gebruik het als leidraad voor wanneer u uw metingen voor uw eigen website of die van uw klant moet verbeteren.

Naar mijn persoonlijke mening is Google Tag Gateway, na het uitproberen en testen, een geweldige quick win voor uitsluitend Google-tracking. Als u alleen optie 1 gebruikt, worden uw GA4- en Google Ads-requests in ongeveer drie klikken van van derden naar via het eigen domein omgezet.

Zoals we in de eigen documentatie van Google zagen, moet u echter naar optie 3 wanneer u meer controle over uw data wilt. Dat betekent dat u een server en servercontainer opzet en vervolgens uw dataverzameling via de sGTM-container laat lopen. Elke organisatie heeft een eigen measurement stack, een ander verkeersniveau en eigen vereisten voor controle over data. Daarvoor is het besliskader bedoeld, en daarom heb ik het zo ontwikkeld dat u het meerdere keren kunt gebruiken.

Omdat ik beide heb gedaan, kan ik zeggen: Google Tag Gateway, specifiek optie 1, is een geweldige quick win voor uitsluitend Google-tracking. Mijn persoonlijke mening is echter dat optie 3 meer werk is dan direct met tracking aan de serverzijde beginnen als u echt controle over uw data op elk platform wilt, omdat u toch het grootste deel van dat werk zou moeten doen. Als dat uw doel is, raad ik aan direct met tracking aan de serverzijde te beginnen. U kunt uw eigen server en container hier opzetten.