Waarom GTM Server Side je budgetverspilling niet voorkomt (en wat wél werkt)

Elke dag fik je onnodig advertentiebudget af, omdat je data in GA4 en Google Ads niet klopt. Je weet dat er iets mis is. Maar het lukt je niet om het probleem op te lossen. Misschien helpt GTM Server Side, denk je. Of je hebt het al geprobeerd, maar bent teleurgesteld in het resultaat. Je bent niet de enige, elke week krijg ik vragen van specialisten die tegen precies dit probleem aanlopen.
Daarom deel ik in dit artikel mijn inzichten, gebaseerd op tientallen GTM Server Side-implementaties bij onder andere Mediahuis, Van Mossel en Moco Museum.
Je ontdekt:
- De 2 echte oorzaken van missende data
- Waarom GTM Server Side het probleem meestal niet oplost
- Hoe je wél je missende data terugkrijgt
- Hoe je voorkomt dat je geld steekt in iets dat niet werkt
Na dit artikel:
- Weet je wat er nodig is om je data terug te krijgen
- Kun je realistisch beoordelen of een oplossing gaat werken
- En maak je een onderbouwde businesscase vóór je (verder) investeert
De 2 echte oorzaken van missende data
1. Een webshop met verzendproblemen
Online dataverzameling kun je vergelijken met het verzenden van bestellingen in een webshop. Precies wat ik 10 jaar geleden deed met mijn webshop in speelkaarten. De bestellingen verstuurde ik via bestelbusjes naar mijn eindklanten. Net zoals de metingen op jouw website verstuurd worden via de GA4-tag naar GA4.
Maar er was één groot probleem. 8 van de 10 bestelbusjes werden onderschept door de maffia, waardoor de bestellingen nooit aankwamen. En dat is precies zoals het gaat met jouw metingen. Tracking blockers onderscheppen jouw GA4-tag waardoor je 20% van je data mist.
2. Een webshop zonder voorraad
Er is nog een cruciaal onderdeel dat vaak over het hoofd wordt gezien. Dat zit zo: ik heb voorraad nodig om mijn bestellingen te versturen. Maar die voorraad komt binnen via bestelbusjes. En ook die worden onderschept.
Op jouw website staat die voorraad symbool voor de code van GTM Web en de Google Tag. En beide codes zijn een voorwaarde om metingen naar GA4 en Google Ads te sturen.
Een ondiepe duik in de techniek
Om het probleem goed te begrijpen, is een beetje technische context nodig. Op je site staat een datalaag die informatie bevat. GTM Web leest die uit en gebruikt tags om er datapakketjes van te maken. Bijvoorbeeld voor GA4 of Google Ads. Die pakketjes worden als zogenaamde netwerkverzoeken verstuurd.
Wat is een netwerkverzoek?
Een netwerkverzoek bestaat uit twee onderdelen:
1. Het adres. Dat is de url waar het verzoek naartoe gaat. Een paar voorbeelden:
GTM Web: https://www.googletagmanager.com/gtm.js?id=GTM-XXXXX.
De Google Tag van GA4: https://www.googletagmanager.com/gtag/js?id=G-XXXXX
De metingen van GA4: https://region1.google-analytics.com/g/collect?v=2&tid=G-XXXXX
2. De inhoud. Dat is de data of code in het pakketje.
In het voorbeeld van GTM Web en de Google Tag is dat de JavaScript-code.
Verwarrend genoeg gebruikt GA4 soms ook de URL om informatie te versturen. Dat noemen ze het measurement protocol. In andere gevallen, als er meerdere metingen tegelijk zijn, dan stopt GA4 een bundel van die metingen wel als inhoud in het pakket.
Hoe werken tracking blockers?
Een tracking blocker kijkt naar de URL en de inhoud van het pakket en probeert zo trackers te herkennen. GTM Web, de Google Tag en GA4 zijn makkelijk te herkennen. Voor jou én voor tracking blockers.
GTM Web: gtm.js
Google Tag: /gtag/js
GA4: /g/collect
Elke tracking blocker heeft eigen methodieken. GTM Web kun je bijvoorbeeld ook herkennen aan de code zelf. Om te checken of iets wordt geblokkeerd, gebruik ik Ghostery en AdBlock.
Waarom GTM Server Side het probleem meestal niet oplost
Je weet nu hoe tracking blockers trackers herkennen. De oplossing lijkt simpel: zorg dat je niet herkend wordt. Maar juist dáár schiet GTM Server Side in de basis tekort.
Wat er gebeurt bij een standaard-implementatie
Er worden meestal twee dingen aangepast:
- De GA4-tag stuurt data niet meer direct naar GA4, maar eerst naar GTM Server Side.
- De Google Ads-tag wordt uit GTM Web gehaald. Die data wordt dan vanuit GTM Server Side doorgestuurd, op basis van wat GA4 aanlevert.
Dat ziet er zo uit:
Dit is waarom het niet werkt
1. De GA4-tag blijft herkenbaar
Voor: https://region1.google-analytics.com/g/collect?v=2&tid=G-XXXXX
Na: https://sst.jouwwebsite.nl/g/collect?v=2&tid=G-XXXXX
De tracking blocker herkent nog steeds /g/collect.
2. GTM Web blijft herkenbaar
Je laadt nog steeds GTM Web in via https://www.googletagmanager.com/gtm.js?id=GTM-XXXXX. Ook deze wordt nog herkend.
3. De Google Tag blijft herkenbaar
Zowel de GA4-tag als de Google Ads-tag worden geblokkeerd, omdat ze herkend worden op basis van de url https://www.googletagmanager.com/gtag/js?id=.
Hoe je wél je missende data terugkrijgt
Begin bij het begin: GTM Web beschermen
Laten we beginnen bij het begin: het inladen van GTM Web. De oplossing is om de herkenbare URL te verbergen via een proxy. Wij gebruiken GTM Server Side als proxy en dat ziet er zo uit:
De url https://pipeline.jouwwebsite.nl/assets/g-t-m?id=GTM-XXXXX wordt niet herkend door tracking blockers. Daardoor blijft GTM Web nog werken.
Let op: er zit wel wat complexiteit in de GTM Server Side client die gebruikt wordt. Je moet er namelijk voor zorgen dat de preview modus blijft werken en dat de code goed gecached wordt.
GA4 beschermen? Helaas niet realistisch
In theorie kun je ook GA4 verbergen via een proxy, maar In praktijk blijkt dat onwerkbaar.
Waarom?
- De structuur van GA4-data is complex en afhankelijk van instellingen in de UI (zoals key events en referral exclusions).
- Elke wijziging in GA4 leidt tot een andere pakketstructuur.
- Het pakket exact namaken is daardoor bijna onmogelijk.
- Zelfs als het lukt, verandert het continu – en ben je constant aan het bijsturen.
We hebben in het verleden geprobeerd om GA4-verkeer na te bouwen op basis van onze eigen webtracker, maar dat bleek te complex en instabiel. Kortom: GA4 beschermen hebben we opgegeven.
Alternatief: betrouwbare rapportages in Looker Studio via BigQuery
Daarom hebben we gekozen voor een andere route. Eén die het probleem écht oplost en bovendien veel meer mogelijkheden biedt.
Stap 1. Zet je eigen webtracker op
- Wordt niet herkend door tracking blockers.
Combineer met de beschermde GTM Web-setup. - Resultaat: tot wel 98% datadekking
Stap 2. Stream de data via GTM Server Side naar BigQuery
Stap 3. Visualiseer je data in Looker Studio
Bonus stap 4. Integreer je backend data
Door je backend te integreren:
- Sluiten je rapportages 100% aan op je financiële realiteit.
- Zie je exact welke conversies niet herleidbaar zijn.
- Analyseer je niet alleen omzet en leads, maar ook contracten en nettowinst.
Bonus stap 5. Voeg je Google Ads-data toe
Door Google Ads-data te koppelen krijg je volledige inzicht. Van advertentieweergave tot klant en winst. Zo bouw je stap voor stap richting één dashboard dat alles overziet. Volledige handleiding vind je hier.
Je Google Ads-conversies beschermen
De standaard Google Ads-tag in GTM Server Side is gebaseerd op GA4-data. Om die tag werkend te krijgen, zul je hem aan moeten sluiten op je eigen webtracker. In de praktijk heb je dan met dezelfde complexiteit te maken als bij het namaken van de GA4-tag in GTM Server Side. Daarom heb ik ook hier gekozen voor een alternatief.
Je kunt ervoor kiezen om de Google Ads conversies vanuit BigQuery naar Google Ads te versturen via de API. En dat heeft de volgende voordelen:
- Je hebt geen last van tracking blockers.
- Je kunt precies bepalen welke conversies je wél en niet verstuurd.
- Je hebt inzicht in of Google Ads de conversies geaccepteerd heeft.
- Je kunt eenvoudig conversiewaardes toevoegen op basis van berekeningen die je uitvoert op backend data.
- Je kunt eenvoudig conversies toevoegen gebaseerd op wat er na de website gebeurd. Zoals dat een lead klant is geworden.
Waarom GA4 nog wel laten staan?
GA4 kan nog steeds waardevol zijn, maar met een andere rol: niet meer als campagnetool, maar als gedragsanalyse-oplossing. Uiteindelijk zie je vaak dat ook die rol verdwijnt, zodra je overstapt op je eigen infrastructuur.
Maak een businesscase voor je (verder) investeert
Je weet wat betrouwbare data je oplevert. En je weet nu ook wat ervoor nodig is om dat voor elkaar te krijgen.
Stel jezelf daarom altijd deze drie vragen vóór je begint:
- Wat levert het op?
- Wat zijn de kosten (implementatie, onderhoud, support)?
- Wat zijn de risico’s (privacy, datakwaliteit, veiligheid)?
De antwoorden bepalen of de oplossing écht de moeite waard is.