Google Is About To Hand Your Ad Tags Full IP Addresses

What actually changed

If you own a server-side Google Tag Manager container, you got an email on 2 November 2026 with the subject "Updates to network signal processing in server-side tagging". Most people will have filed it under routine platform housekeeping. It is not.

According to the reporting on it, the notice says that from 11 January 2027, tags in server containers will be able to process standard network signals, including IP addresses. The scope is specific: Google Ads, Display & Video 360, Search Ads 360 and Campaign Manager 360. Google Analytics tags are reported to continue applying IP redaction.

That distinction is the whole story. Analytics, where Google has spent years telling the market that it does not store IP addresses, keeps the redaction. Advertising, where IP addresses are commercially useful for geography, device graphs and match rates, gets them in full.

Why this is not a neutral technical change

A full IP address is personal data. Not "arguably" personal data, not "in some circumstances" personal data. The ICO treats it as personal data, and the final guidance it published in April 2026 goes further than cookies to cover tracking pixels and device fingerprinting, which is precisely the category of technique that an IP address feeds.

Here is the part that matters commercially. In a server-side setup, you own the container. It runs on your subdomain, under your Google Cloud project or your managed provider, and the data arrives there because your website sent it. When an advertising tag inside that container forwards a full IP address to Google, you are the controller of that processing. Google is your processor for parts of it and a controller in its own right for others, and in either reading the accountability for the lawful basis sits with you.

That is the trade people quietly accepted when they moved measurement server-side: you get control, and control is another word for responsibility.

The gap nobody has explained

Consent Mode v2 gives you two signals, ad_storage and ad_user_data. When a visitor refuses, those go to denied, and the expectation across the industry is that advertising data about that visitor is either not sent or is sent in a cookieless, non-identifying form.

So: on 11 January, with ad_user_data set to denied, does the Google Ads tag in your server container still process the full IP address?

The notice does not say. At the time of writing, neither Google's documentation on server-side Transformations nor its Consent Mode documentation references IP addresses at all. There is no stated mechanism tying the new capability to the consent signals that are supposed to govern it.

We are not alleging that Google intends to ignore consent. We are pointing out something narrower and more awkward: a capability is being enabled on a fixed date without a published explanation of how it behaves under refusal, in a product whose entire selling point to privacy-conscious advertisers was that the server container is where you get to control exactly this.

There is a pattern here, and it is worth naming

This is not the first time the server container has been used to widen what reaches Google without the website owner doing anything.

Since 28 July 2025, Floodlight tags in server-side Tag Manager have transmitted unconsented requests server to server, in order to improve the accuracy of modelled conversions. Read that again: unconsented requests, sent deliberately, as a documented feature, to make modelling better.

There is a defensible argument for it. Modelled conversions need a denominator, and a request that carries no identifiers is not the same thing as tracking a person. But notice the shape of the thing. The server container is increasingly a place where the platform can change what leaves your infrastructure, on its own schedule, and the change arrives as a release note.

Meanwhile, the UK got stricter first

The timing is unhelpful for anyone hoping to leave this until it becomes a problem.

Date	What happened
5 February 2026	The Data (Use and Access) Act 2025 changes took effect. The ICO can now fine for unlawful cookie and tracking use under PECR without having to show the breach was serious and likely to cause substantial damage or distress.
29 April 2026	The ICO published its final guidance on the use of storage and access technologies. It covers tracking pixels and device fingerprinting, not only cookies.
Ongoing	The ICO has said separate work on PECR regulation 6 as it applies to online advertising is still in progress.
11 January 2027	Advertising tags in server containers can process full IP addresses.

The maximum penalty under the enlarged regime is £17.5 million or 4% of annual worldwide turnover. No fine at that level has been issued for cookies, and we are not predicting one. The relevant change is simpler: the threshold for the ICO to act at all came down, and the scope of what it is looking at went up.

What to do before 11 January

None of this is difficult. It is just work that has to happen before the date rather than after it.

1. Find out whether you are affected

Open Tag Manager and check whether you have a server container, not just a web container. Then list the tags in it. If any of them are Google Ads conversion tags, Google Ads remarketing, Floodlight, DV360 or SA360 tags, this applies to you. If your server container only has a GA4 client and GA4 tags, the reported change does not touch you.

2. Read your own copy of the email

Everything above comes from secondary reporting. The notice went to container owners, so if you have a server container, you have the primary source in your inbox. Read it before you act on anyone's summary of it, including this one.

3. Decide what your container should do with IP addresses

You do not have to accept the default. Server-side Tag Manager has Transformations, which let you modify or remove fields in the event data before tags see them. Redacting or truncating the IP address for specific tags, or for events where consent was refused, is a configuration decision you control. Make it deliberately and write down why.

4. Test the refusal path, not the acceptance path

Almost everyone tests what happens when a visitor clicks accept. Far fewer test what happens when they click reject. Set ad_user_data to denied, trigger a conversion, and inspect what your server container actually forwards. Do it now to get the baseline, and again in January.

5. Update the paperwork to match reality

If your privacy notice does not say that IP addresses may be processed by advertising tags, and your record of processing activities does not mention it, then on 11 January your documentation becomes wrong. This is the cheapest item on the list and the one most likely to be skipped.

6. If you run this for clients, tell them now

In a server-side engagement the client is usually the controller and you are the processor. A change in what their infrastructure sends to a third party is their decision, not yours. Put it in front of them in writing, before the date, with the options.

The uncomfortable conclusion

Server-side tracking is sold, including by agencies that should know better, as a privacy improvement. It is not. It is an architectural improvement, and a measurement improvement, and often a very large one. What it does to privacy is move the decision from the browser, where Safari and Firefox and the ad blockers were making it for you, to your own server, where you now make it yourself.

That is not a smaller obligation. It is a bigger one wearing a technical costume. The browser used to be an inconvenient third party that limited what you could collect. Removing it did not remove the limit, it removed the thing that enforced the limit on your behalf.

This change is the clearest illustration yet. A platform updated a default inside infrastructure you are accountable for, gave eight weeks' notice over the Christmas period, and left the consent question unanswered. If your answer to "what does your server container do with IP addresses when a visitor refuses consent" is "I would have to check", that is the finding, and you have until 11 January to turn it into a sentence you can say out loud.

trendfingers builds and operates server-side measurement infrastructure, including our own managed server-side tagging platform. If you do not know what your server container forwards when a visitor refuses consent, that is exactly what the first review looks at. Request an audit.