IP-adres verbergen in sGTM en toch geodata in GA4: zo werkt het
Met een combinatie van geolocatieheaders, een Lookup Table-variabele en een Augment-transformatie in server-side Google Tag Manager kun je het echte IP-adres van een bezoeker vervangen door een generiek IP-adres uit hetzelfde land. GA4 lokaliseert de bezoeker dan nog steeds op landniveau, zonder dat het werkelijke IP-adres wordt doorgestuurd. De aanpak maakt gebruik van het ip_override-veld dat GA4 ondersteunt, maar kent beperkingen door de inherente onnauwkeurigheid van IP-geolokalisatie.
Het probleem: geodata versus privacybescherming
GA4 bepaalt de geografische locatie van bezoekers op basis van hun IP-adres, soms tot op stadsniveau. Wie dat IP-adres niet naar Google wil doorsturen — om privacy- of AVG-redenen — verliest daarmee ook de geodata. In een server-side GTM-setup heb je echter meer controle over welke gegevens je doorstuurt, en dat schept ruimte voor een tussenvorm.
Hoe de oplossing werkt
De infrastructuur vóór je sGTM-container — een App Engine-installatie of een Cloud Load Balancer voor Cloud Run — voegt automatisch geolocatieheaders toe aan inkomende HTTP-verzoeken. Voor App Engine is dat de header X-Appengine-Country, voor Cloud Load Balancer is dat X-Gclb-Country. Die header bevat een tweeletterige landcode, zoals FI voor Finland. Binnen de server-container lees je die landcode uit via een Request Header-variabele. Een Lookup Table-variabele mapt de landcode vervolgens naar een generiek IP-adres uit dat land. Een Augment Event-transformatie vervangt daarna de waarde van ip_override in de event data met dat generieke IP-adres, vóórdat het verzoek naar GA4 wordt verstuurd. GA4 ondersteunt ip_override als parameter om het IP-adres te overschrijven, waardoor de geolokalisatie op landniveau intact blijft zonder het echte IP-adres te delen.
Wat je nodig hebt in de server-container
De implementatie bestaat uit drie componenten: een Request Header-variabele die de landcode ophaalt, een Lookup Table-variabele die de landcode koppelt aan een generiek IP-adres, en een Augment-transformatie die ip_override overschrijft. Een kant-en-klare container-export is beschikbaar die je via de Merge-optie in een nieuwe workspace kunt importeren. Gebruik je Cloud Run met een Cloud Load Balancer, pas dan de Request Header-variabele aan zodat die X-Gclb-Country uitleest in plaats van X-Appengine-Country.
Testen in preview-modus
Zet de server-container in preview-modus en stuur een GA4-verzoek door. Controleer in het tabblad Incoming HTTP Request of de geolocatieheader aanwezig is en of X-Forwarded-For het verwachte IP-adres toont. Open vervolgens de transformatie in het Tags-tabblad en verifieer dat het werkelijke IP-adres is vervangen. Controleer tot slot in de uitgaande request of de URL-parameter _uip de getransformeerde waarde bevat. Let er ook op dat je in de GA4-taginstellingen het IP-adres niet apart redigeert — dat zou de werking van ip_override doorkruisen.
Beperkingen en nuances
De Lookup Table is gebouwd op basis van een publieke country IP-database waarvan de geolocatiedata afkomstig is van IP2Location. De IP-adressen per land zijn gevalideerd via de gratis API van ip-api.com. Cruciaal voorbehoud: het is onbekend welke geolocatiedienst Google intern gebruikt. Een IP-adres dat ip-api.com als Amerikaans beschouwt, kan door Google als Canadees of Vietnamees worden geïnterpreteerd. Bovendien verschuiven IP-adresbereiken over tijd, waardoor de Lookup Table binnen maanden verouderd kan raken. Daarnaast is IP-geolokalisatie sowieso onnauwkeurig — VPN's, proxies en Apple's Private Relay maken de data verder onbetrouwbaar. Een robuustere aanpak zou een eigen API-service zijn, bijvoorbeeld via een Google Cloud Function of Firestore, met een ingebouwde validator die IP-bereiken wekelijks controleert. Of dat de investering waard is, hangt af van hoeveel bezoekers hun IP-adres al aan de bron verbergen.
Praktische conclusie voor sGTM-beheerders
De oplossing is technisch valide en maakt slim gebruik van sGTM-transformaties en het ip_override-veld van GA4. Voor teams die om privacyredenen geen echte IP-adressen naar Google willen sturen maar toch geodata op landniveau willen behouden, is dit een werkbare aanpak. Houd rekening met de nauwkeurigheidsbeperkingen en plan onderhoud in voor de Lookup Table. Wie een productiewaardig systeem wil bouwen, overweegt beter een dynamische API-service dan een statische variabele.