SM/RSoftware Marketing Resource Subscribe

Google's server-side ad tags will accept full IP addresses starting January 2027

A Google notice to advertisers flips the default in server-side Tag Manager containers from blanket IP redaction to tag-by-tag processing, and re-masking ad tags becomes the advertiser's job.

Sienna McphersonSienna Mcpherson✓Contributing writer
Nov 4, 2026 · 4 min read
X in f
A row of tall black server racks with cable trays overhead in a data center aisle, with a wheeled mobile workstation cart and monitor in the foreground.
Server racks and cable trays in a data center — the kind of infrastructure server-side tag containers run on. Photo: Brett Sayles / Pexels

Google will let ad tags inside server-side Google Tag Manager containers collect full, unredacted IP addresses starting Jan. 11, 2027, reversing the blanket redaction those containers have applied by default — unless marketers build a workaround first.

The change comes from a notice Google sent to advertisers about changes to network signal processing in server-side tagging, and it first surfaced publicly when Google Ads specialist Adriaan Dekker posted it to LinkedIn on Nov. 2. As of Nov. 3, Search Engine Journal reported that the notice carried no issue date and that Google's own Tag Manager release notes still made no mention of it, which is unusual for a change that resets a default this far in advance.

What changes, and what doesn't

Right now, a server container in Google Tag Manager applies one redaction setting to every tag inside it. Google's notice replaces that with tag-level processing: starting in January, tags that send data to Google Ads, Display & Video 360, Search Ads 360 and Campaign Manager 360 from a server container will be able to read a visitor's full IP address instead of a masked one.

Google Analytics tags are the exception. Google's own Tag Manager help documentation on IP address redaction confirms Analytics server tags keep applying partial redaction by default, zeroing the final octet of an IPv4 address and the final 80 bits of an IPv6 address. Nothing about that default changes. What changes is everything else sharing the same server container, which is where most ad conversion and remarketing tags live.

Marketers who want ad tags to stay partially masked have to build that themselves: a Transformation in Tag Manager that overwrites the tag's IP field with an anonymized value before the tag fires. Third-party tags complicate this further, since many read IP data from custom headers or event parameters rather than the field Google's own tags use, which means each one may need its own separate Transformation, tested in Preview before it ships to production.

The notice also leaves real gaps. It doesn't say how long Google retains a full IP address once a tag has fired, doesn't address how the change interacts with the non-consenting requests that Tag Manager's release notes say Floodlight tags in server containers have been sending since July 2025, and gives no date for when the new tag-level controls will actually appear in the container interface ahead of the January switch.

Why this lands on marketing, not just engineering

Server-side tagging became popular with software companies specifically as a way to control what leaves the browser, a response to cookie restrictions, ad blockers and consent requirements. This update quietly moves the default in the opposite direction for ad tags specifically, without touching the privacy-protective reputation that server-side setups built on Analytics' own behavior. A marketer who migrated to server-side tagging for exactly that reason could end up sending more raw data to Google's ad products than before, not less, unless someone rebuilds the redaction manually.

Google's notice also puts a compliance obligation directly on the advertiser, stating that advertisers "must ensure that proper end-user notices and legally required consents are in place" before collecting this data, and that anyone with end users in the EEA, UK or Switzerland must follow Google's EU consent policy specifically. Google frames the change as a way to integrate privacy-protective technology and filter invalid traffic, and says it should improve campaign performance, a claim the notice doesn't quantify.

Server containers "will transition from container-wide IP address redaction to individual tag-level processing."

That's a separate project from the IP-related change Google has already flagged for Analytics itself: an encryption update to IPs collected by the Google tag and SDK before they reach linked Google Ads accounts, which Google says it will roll out on dates still to be announced. The two changes affect different data paths and different timelines, and conflating them is an easy way to misjudge how exposed a given setup actually is before the January deadline arrives.

What to do before Jan. 11

  • List every tag living in each server container, and note which IP field it reads. Google's own tags use ip_override; third-party tags often don't.
  • Build and Preview-test a Transformation for any tag that should keep a masked IP, rather than assuming Analytics' redaction habits carry over to ad tags.
  • Update consent language and banners to cover ad tags processing full IPs, not just analytics tags, especially for EEA, UK and Switzerland traffic.
  • Flag the Jan. 11 date to whoever owns the GTM container, whether that's ops, engineering or an agency, since Google isn't publishing this in its release notes.
  • Ask your server-side tagging vendor or agency whether they've already seen the notice, since Google appears to be sending it directly rather than through its usual channels.
Google AdsServer-Side TaggingPrivacyTag Manager
Share: X · LinkedIn · Facebook
↓Read next

One briefing, every Tuesday.

The week in software marketing: the news that matters, one unsponsored review, and the numbers behind both.

Free · Unsubscribe anytime