Businesses using server-side Google Tag Manager should ask their tracking supplier a specific question: which IP address information reaches each advertising tag? A newly reported Google notice points to a change from 11 January 2027, while Google’s live help documentation explains how to keep IP addresses partially redacted before selected tags receive them.
This concerns a particular tracking setup, rather than every website running Google Ads. For organisations in Bath and the South West, the useful next step is to establish whether it applies, then review the data flow with the person responsible for measurement.
What has been reported?
Search Engine Journal reports that a Google advertiser notice shared by Adriaan Dekker says server-side Tag Manager will move from container-wide IP redaction towards processing at individual tag level. The reported start date is 11 January 2027. Tags for Google Ads, Display & Video 360, Search Ads 360 and Campaign Manager 360 are described as accepting full IP addresses.
The distinction matters: Google Analytics server tags will continue applying partial IP redaction by default. Google’s own IP redaction guidance confirms that Analytics behaviour and describes controls for other tags. An Analytics setting should therefore not be treated as evidence of what a separate advertising tag receives.
The timing comes from the shared notice and reporting, rather than a dated rollout announcement on that help page. Check current Google guidance and any notice sent to your organisation before scheduling implementation work.
Does your website use this setup?
Server-side tagging uses a server container to process incoming information and make event data available to tags. A tag is a component that sends information to a measurement or advertising service. This is different from assuming that every tag runs only in a visitor’s browser.
Ask your developer or agency whether you have a server-side Google Tag Manager container, who manages it and which destinations it serves. If you only use browser-based tags, this particular notice does not establish that their IP handling is changing too.
A hypothetical Somerset retailer might use a server container for both Analytics and advertising measurement. Reviewing only its Analytics configuration would leave the advertising branch unchecked. A small Bath organisation without a server container may simply need confirmation that this notice is outside its current setup.
What Google’s redaction control does
Google documents a feature called Transformations, which can change event parameters before tags access them. Its IP guidance describes creating a variable using the supplied IP anonymisation function, then using an Augment event transformation to replace the ip_override field with that result.
The transformation must cover the intended tags. Google calls the result a partially redacted IP address; avoid describing it as proof that a person or request is completely anonymous. This is a specific technical control, not a complete privacy assessment.
There is also a third-party caveat. Some vendors read ip_override, while others obtain addresses from different headers or event parameters. Google’s instructions say to establish which field each vendor uses and apply the relevant transformation where necessary. One rule cannot be assumed to cover every destination.
Ask for a checked plan, not a hurried switch
For businesses reviewing their Google Ads measurement, a short written inventory is a sensible starting point. Ask the supplier to:
- List the server containers, active tags and advertising destinations involved.
- Record which IP fields each tag uses and the current redaction controls.
- Explain the proposed treatment for each destination and who approves it.
- Use Preview to verify the transformed event data and outgoing requests before deployment.
- Confirm that required measurement events still work, with a record of the published version and a rollback plan.
Google’s developer documentation warns that changing or removing parameters can stop tags working as expected. Testing should therefore check both the intended data restriction and the measurement behaviour, rather than merely confirming that a new rule exists.
Keep the privacy review separate
Server-side processing does not settle what an organisation should collect or send. Have the responsible people review the proposed data flow alongside existing privacy notices, consent arrangements and supplier responsibilities. Where the appropriate treatment is unclear, obtain qualified advice before changing collection.
There is no need to rebuild a working tracking system simply because a new capability has been announced. First establish whether you are affected. Then make an explicit, tested decision about each tag, rather than relying on an assumption that a single container or Analytics setting covers everything.