IP Anonymisation and Geo Headers in Server-Side GTM

Why IP Data Matters in sGTM

When your website sends events to your sGTM server, those requests include the user's IP address in the standard HTTP headers. Your server can then do several things with this IP: pass it to analytics platforms (GA4, Meta), use it for geolocation, or discard it.

Under GDPR, IP addresses are considered personal data. How you handle them in your sGTM setup affects your compliance posture.

IP Anonymisation: What It Means

IP anonymisation means removing or masking the last octet (IPv4) or the last 80 bits (IPv6) of an IP address before it is stored or forwarded. For example: 192.168.1.123 becomes 192.168.1.0. The truncated IP can still be used for approximate geolocation (country, city level) but cannot identify an individual.

GA4 has automatic IP anonymisation — Google does not store full IP addresses. However, your sGTM server receives the full IP in incoming requests. If you log these requests or pass the IP in event parameters, you may be storing full IPs unnecessarily.

Anonymising IPs in sGTM

In your sGTM server container, create a Custom Variable that anonymises the IP before use:

// Custom JavaScript Variable: "Anonymised IP"
function() {
  var ip = getRequestHeader('X-Forwarded-For') || '';
  // For IPv4: replace last octet with 0
  if (ip.indexOf('.') !== -1) {
    return ip.replace(/\.\d+$/, '.0');
  }
  // For IPv6: simple truncation approach
  return ip.substring(0, ip.lastIndexOf(':')) + ':0000';
}

Use this variable wherever you pass IP addresses to downstream platforms — in Meta CAPI's client_ip_address field, for example.

Geo Headers from Cloud Run

Google Cloud Run adds geographic headers to incoming requests based on IP-to-geo lookup performed at the edge:

• X-AppEngine-Country or X-Geoip-Country: ISO country code (e.g. "GB", "US", "DE")
• X-AppEngine-Region: region/state code
• X-AppEngine-City: city name

These headers give you geolocation data derived from the IP address, without you needing to store or forward the IP itself. You can pass the country code to GA4 as a parameter while discarding the full IP.

Using Geo Headers for Compliance

For businesses operating in the EU, geo headers enable a useful pattern:

1. Read the country header from the incoming request
2. If country is in the EU/EEA, apply stricter data handling: check consent before forwarding, strip additional identifiers
3. Forward to GA4 and Meta with country-appropriate data minimisation applied

This server-side geo-based consent filtering is more reliable than browser-based approaches because the server always knows the country — even if the user changes their browser language or uses a VPN that does not match their actual location exactly.

Best Practices for IP Handling in sGTM

• Never log raw IP addresses in your sGTM server's application logs unless specifically needed and documented
• Use geo headers for location data — pass the derived country/city rather than the raw IP to analytics platforms
• If you must pass IP to Meta CAPI (for Event Match Quality), pass the anonymised version unless your privacy policy and consent allow full IP storage
• Document your IP handling approach in your Privacy Policy and DPIA (Data Protection Impact Assessment)

Summary

sGTM gives you direct control over how IP addresses are handled before analytics data reaches third parties. Use IP anonymisation for GDPR compliance, leverage Cloud Run's geo headers for country-level geolocation without storing full IPs, and implement server-side consent filtering based on the user's country. These controls make server-side tracking a powerful tool for privacy-by-design analytics architecture.

See our Server-Side Tracking service for privacy-compliant implementation.

Need privacy-compliant server-side tracking? Contact Adslytics.