Why Your Server-Side GTM Needs IPv6 (Meta CAPI Impact)
Without IPv6, your sGTM sends false IPs to Meta CAPI. Impact on dedup, match rate, and the complete GCP solution.
If your GTM server does not support IPv6, you are silently degrading the quality of your Meta conversions without knowing it. The problem is technical, poorly documented, and its impact is measurable. Here is why, based on Simo Ahava’s research.
The Problem: NAT64 and False IP Addresses
A growing number of users connect via IPv6. When an IPv6 user reaches your GTM server that only supports IPv4, the connection goes through a translation mechanism called NAT64. This process converts the user’s IPv6 address into a synthetic IPv4 address that does not match the visitor’s real address.
Your server-side container then extracts this false IPv4 address and sends it to Meta via the Conversions API. The problem: on the client side, the Meta pixel has already recorded the user’s real IPv6 address.
The Impact on Meta Conversions API
Meta uses the IP address as one of the deduplication signals between client-side events (pixel) and server-side events (CAPI). When the pixel’s IP address (real IPv6) does not match CAPI’s (IPv4 translated by NAT64), Meta cannot make the match. Two direct consequences emerge.
First, the Conversions API match rate drops. Tests show a 10 to 15% degradation of the Event Match Quality score in Meta’s Events Manager. Second, the deduplication mechanism partially fails, which can lead to double counting of certain conversions or, more often, an undervaluation of server-side data quality.
The Solution on Google Cloud Platform
The fix on GCP requires several steps that touch the HTTPS load balancer of your server-side container.
Start by reserving a global static IPv6 address in the GCP console. Then add a AAAA DNS record pointing your sGTM domain to this IPv6 address. Create a certificate map so the SSL certificate covers IPv6 connections. Finally, add an IPv6 HTTPS frontend to your existing load balancer, using the reserved IPv6 address and the configured certificate.
Cloud Run itself does not need modification. The load balancer terminates the IPv6 connection internally and forwards the request to the container in IPv4. The key is that the load balancer captures the visitor’s real IPv6 address before any translation.
Verifying Everything Works
After configuration, test from an IPv6-capable device or network. Check in your sGTM container logs that the X-Forwarded-For header contains an IPv6 address (recognizable by the colons). In Meta’s Events Manager, monitor the Event Match Quality: it should improve in the days following deployment.
For businesses that take server-side tracking seriously, IPv6 support is no longer optional. It is a prerequisite for maintaining the quality of data sent to Meta and maximizing advertising ROI. Also check our server-side vs client-side comparison and our server-side tracking overview for 2026 for a complete picture.