Server-side GTM: Google Ads gets your visitors' IP back on January 11
Google stops truncating the IP address for its ad tags in server-side tagging. What measurement gains back, and why your privacy policy may be wrong when you wake up.
The email Google is sending advertisers right now has the kind of subject line you archive unread: “changes to network signal processing in server-side tagging”. If you run a server-side GTM container, open it anyway.
On January 11, 2027, a Monday, those containers will stop truncating visitors’ IP addresses for four of Google’s ad products: Google Ads, Floodlight in Campaign Manager 360, Display & Video 360 and Search Ads 360. GA4 keeps the redaction. Meta, TikTok and the rest decide for themselves, as before.
It’s on by default.
To opt out, the email points to a help center article, with no title and no link. I looked for it tonight. Nothing, and nothing in the Tag Manager release notes either. The best summary out there for now is PPC Land’s; I’ll add the official link once the page exists.
A quick step back, because that’s where this gets interesting.
When the Google Ads conversion tag runs in the browser, Google sees the visitor’s IP without asking. The browser is the one opening the connection to its servers. Move the same tag server-side and your container calls Google instead: the visitor’s IP now travels in the event data (the ip_override field, if you open the preview), and until now it reached Google with its tail cut off.
Server-side migrations sell on two things, cookies that last longer than seven days on Safari and control over what leaves the site (I wrote about that here). The signal Google lost in the move rarely came up. Me included.
Meta never had the problem. Its Conversions API requires the IP and user agent for web events, both count toward match quality, and a properly set-up container sends them. TikTok and Pinterest take them too. The one big platform that came out of server-side worse off was Google, because of its own settings.
It fixes that in January.
To do what? The email mentions measurement, personalisation and invalid traffic filtering. Beyond that, I’m speculating. An IP on its own says little, there can be thousands of subscribers behind one mobile carrier address. Combined with the device model, the browser and the timestamp, though, it becomes a decent clue for tying a purchase back to a click when the gclid got lost on the way. Which happens a lot when the journey switches domains.
The textbook case is two sites that don’t link to each other: a brand discovered on one and bought on the other, or a booking flow hosted by a vendor. Google’s cross-domain parameter doesn’t survive that kind of trip, and the purchase reaches Google Ads with no click to attach to. If the same server container receives both visits, Google will get the same full address on both sides from January, a few minutes apart, from the same browser. For a matching algorithm, that counts.
Not every platform will get the same thing out of it. For Google Ads, I expect an effect on orphan conversions and on the modelled share. Floodlight gains where a gclid never existed, between a banner seen and a purchase three days later. DV360 uses the IP first to weed out invalid traffic, the kind that comes from data centres and proxies. GA4 won’t notice a thing, since the address stays truncated there: if you were counting on January to stitch sessions across two domains in GA4, you’ll have to do without.
I’m not expecting miracles either. iCloud Private Relay replaces the address for part of iPhone users, and a whole family goes out through one router. One more clue, then, which Google knows how to cross with plenty of others.
Switch chairs and read the notice the way your DPO would.
Since the Breyer ruling by the EU Court of Justice in 2016, an IP address, even a dynamic one, is personal data. I’ve seen server containers justified partly on privacy grounds: the server filters, Google gets less. On January 11 that stops being true for Google’s four ad products, without anyone touching your setup. A privacy policy that says Google gets an anonymised IP will be lying that morning.
The email reminds you that consent must be in place before any data is collected and points to Google’s EU user consent policy. On Consent Mode, nothing.
That bothers me for one specific reason. Since July 28, 2025, Floodlight tags in a server container have sent requests even when the visitor declined advertising. Will those carry the full IP from January? Nobody knows yet, and I’d rather not bet.
In the meantime, for my clients, I’ll set up a transformation that excludes ip_override from ad tags when ad_user_data is denied. That’s the Consent Mode v2 signal covering user data sent to Google. Two upsides: the rule fits in one sentence of a privacy policy, and you can check it in the preview.
Then there’s the paperwork. The record of processing should list the full IP among what goes to Google, the policy and the banner should stop promising the opposite, and the data protection terms you accepted in Google Ads are worth a reread. I’m not a lawyer. If you have a DPO, forward them the email this week rather than on the evening of January 10.
For the containers I look after, the plan comes down to four moves: an inventory of tags by platform, a decision with each client between full IP and opting out for Google Ads and Floodlight, the transformation, then a check of outgoing requests in the preview, before and after January 11. Until the help article is out, I only trust what I see leave.
This topic has one quirk: it concerns both the person who sets up tracking and the person who writes the consent texts, and those two rarely work together. I do both. If you want us to look at your container and your notices before January, book a slot.
Talk soon.