From January 11, 2027, Google ad tags and Google Analytics tags in the same server-side Google Tag Manager container will treat IP addresses differently. A Google Ads notice to advertisers, shared on LinkedIn by Google Ads specialist Adriaan Dekker on November 2, says tags sending data to Google Ads, Display & Video 360, Search Ads 360 and Campaign Manager 360 “will now accept the full IP address”, while Google Analytics tags “will continue to apply IP redaction”. Server-side GTM IP address handling becomes a per-tag choice, and masking the address an ad tag receives is something the advertiser has to set up.
What changes for IP addresses in server-side Google Tag Manager on January 11?
A Google Ads notice titled “Updates to network signal processing in server-side tagging” says from January 11, 2027, tags for Google Ads, DV360, SA360 and CM360 will accept the full IP address, while Google Analytics tags keep redacting. Advertisers can opt out per tag with a Transformation. Google’s release notes did not mention it as of November 4, 2026.
The notice says server containers “will transition from container-wide IP address redaction to individual tag-level processing”. It is public as a screenshot in Dekker’s LinkedIn post, and Search Engine Journal covered it on November 3. The notice addresses server containers only.
| Tag in your server container | What the notice says | What to check |
|---|---|---|
| Google Ads, DV360, SA360, CM360 | “will now accept the full IP address” | Decide per tag: full or masked |
| Google Analytics | “will continue to apply IP redaction” | No change described |
| Third-party | “independent control over the signals that they accept” | Which field each vendor reads |
How do you give an ad tag a partially redacted IP?
Google’s Help page, “IP address redaction for server-side tagging”, describes a Transformation that changes the address before any tag reads it. The January 11 date and the DV360, SA360 and CM360 list come from the notice. The page’s examples of tags to select are Google Ads, Floodlight and other non-Google tags.
- Create a Custom Template Variable that anonymizes the IP address, using the code below.
- Create an Augment event transformation that overrides the
ip_overridefield with that variable, and pick the tags that should receive the partially redacted IP.
const getAnonymizedIpAddress = require('getAnonymizedIpAddress');
return getAnonymizedIpAddress();Then open Preview, trigger your tags and verify the address is redacted before the data leaves the server. Save the transformation and publish the container.
The API reference sets the masking rules. For IPv4, the last octet becomes 0, so 198.51.100.42 becomes 198.51.100.0. For IPv6, the last 80 bits are zeroed and the first 48 are kept. If the address is invalid or cannot be resolved, the function returns “::”, “so the result is always safe to use as ip_override”. The function was not in the Internet Archive’s October 12 capture of the reference; the live page, updated October 30, lists it.
Why third-party tags need their own check
According to the Help page, “many major third-party tag templates are designed to read the IP address directly from the standard ip_override field”, so your Transformation reaches them too. However, “not all third-party vendors use the ip_override field”. Some tags may take the address from alternative custom headers or specific event parameters.
So for third-party tags the check comes down to one question: which field does this vendor read? If it is not ip_override, the Help page says to apply a transformation to the vendor’s custom field. Campaign URLs are a separate layer: the notice concerns network signals, not UTM parameters. If your review also covers ad landing pages, build consistent campaign URLs with our UTM builder so they carry matching UTM parameters.
The change also sits next to an earlier one. Customer Match uploads already accept raw IP addresses in an unhashed “User IP address” column, per Google Ads Help. Two separate changes, no link between them that we can show.
What do Google’s notice and documentation not say?
- Storage and retention. Neither the notice nor the Help page says where Google stores full IP addresses or how long it keeps them.
- Consent mode. The notice says advertisers “must ensure that proper end-user notices and legally required consents are in place before data collection begins”, and that in the EEA the EU user consent policy applies. It does not say how this interacts with consent mode or with pings sent without consent.
- The issue date. The screenshot shows none.
- Release notes. As of November 4, no 2026 entry in the Google Tag Manager release notes mentions IP addresses or network signal processing.
The notice says the change is meant “to facilitate improvements to ads measurement and personalisation”. It presents privacy-enhancing technologies (PETs) as a way “to safeguard user privacy” and says spam and invalid traffic filtering maintains data integrity, “ultimately driving improved campaign performance”. It offers no numbers for any of it.
