Owners of server-side Google Tag Manager containers who want to stop Google's advertising tags receiving full visitor IP addresses from January 11, 2027 will have to build the block themselves. Google's Help Centre page on the opt-out describes no setting to switch off. Instead, it walks container owners through a custom template variable and an "Augment event" transformation that overwrites the IP address before selected tags read it. Analytics consultancy TRKKN set out the practical consequences in an undated post by Nikel Schubert, a senior topic lead for its solution architects, that sorts setups into affected and unaffected and argues that most advertisers do not face a new privacy problem - while noting that Google has not said what happens to requests sent without consent.

In Short

Google's ad tags in server-side Tag Manager containers will receive visitors' full IP addresses from January 11, 2027, and the only way to keep sending a shortened address is a custom transformation that each container owner has to set up and publish. The change reaches advertisers and agencies that run Google Ads, Display & Video 360, Search Ads 360 or Campaign Manager 360 tags on their own tagging server, while containers holding only Google Analytics tags keep redacting, according to TRKKN. Containers with no transformation in place on January 11 will send full addresses to the four advertising products, and Google has not said whether that includes requests made when a visitor has refused advertising consent.

What has changed since the email

PPC Land reported on November 2 that Google had told advertisers server containers would move from container-wide IP address redaction to tag-level processing on January 11, 2027. Tags for Google Ads, Display & Video 360, Search Ads 360 and Campaign Manager 360 would accept the full IP address; Google Analytics tags would keep redacting it. The email, which was undated and circulated publicly on LinkedIn that day, pointed to a Help Centre article for opt-out instructions without naming it, and PPC Land could not locate one at the time.

That article now exists. Headed "IP address redaction for server-side tagging," it sits in Google's Tag Manager Help Centre under answer number 18646937, and TRKKN's post links to it directly. The page carries no date. Nor does it mention January 11, 2027, the move to full addresses, or the phrase "network signals" that headed Google's email. It reads as standing technical documentation rather than a notice of change - which means the date and the default still rest on the email alone.

TRKKN's post compresses the change into one line. "From 11 January 2027, Google advertising tags in a server-side GTM container will receive the visitor's full IP address by default," according to the post. Its headline puts "Network Signals" in quotation marks, and the body deals only with the IP address.

Who is affected, on TRKKN's reading

The post sorts setups into four cases. A server container that holds Google Ads, Display & Video 360, Search Ads 360 or Campaign Manager 360 and Floodlight tags is affected. A server container with Google Analytics tags only is not: in TRKKN's words, "GA tags keep redacting the IP." Sites that tag only in the browser, with no server container at all, are also outside the change.

The fourth case is third-party tags in the server container, from vendors such as Meta or TikTok. These are "Not changed by Google; each vendor's tag decides which signals it uses," according to TRKKN. Google's Help Centre page adds a technical distinction. Third-party tags that read the standard ip_override field will pick up the same redaction transformation as Google's tags, according to the page; tags that read the address from a field of their own need that specific field overridden instead.

The distinction matters because of how server-side tagging works. A visitor's browser sends its request to a tagging server run by the site operator, usually on a first-party subdomain, rather than to each vendor. A component in the container, which Google calls a client, turns that request into an event data object, and every tag in the container reads from it. The IP address travels in that object as ip_override. Whatever sits in that field when a tag fires is what the tag can forward.

The opt-out is a transformation, not a toggle

"There is no simple switch," according to TRKKN. Google's page describes a sequence of steps. The container owner first creates a custom template variable built on getAnonymizedIpAddress(), a function in the sandboxed API that server-side Tag Manager templates use. In the Transformations section, the owner then creates a new transformation of the type Augment event, sets it to override the ip_override field and maps that field to the new variable. The last step is choosing which tags the transformation applies to, under the matching conditions or affected tags settings; Google's page gives Google Ads, Floodlight and non-Google tags as examples. The change is previewed, saved and published.

Google's developer reference defines exactly what the function returns. For IPv4 addresses, the last octet is set to zero, according to the documentation, so 198.51.100.42 becomes 198.51.100.0. For IPv6 addresses, the last 80 bits are set to zero and the first 48 are kept. If an address is invalid or cannot be resolved, the function returns "::", which Google describes as always safe to use as ip_override. It takes no parameters, and a template that calls it needs the user_ip permission. TRKKN's own example, in which 203.0.113.25 becomes 203.0.113.0, follows the same IPv4 pattern.

How much does a zeroed final octet hide? An IPv4 address with its last octet removed still points to a block of 256 possible addresses. AdSense also truncates addresses by default, under the publisher control Google introduced this year when AdSense made full IP sharing an option that starts switched off. In AdSense, publishers must act to send the full address. In server-side Tag Manager, from January 11, container owners must act to keep it truncated.

Google's page adds one more point: Google Analytics server tags already apply partial IP redaction by default, which is the reason TRKKN places Analytics-only containers outside the change.

Timing is the other constraint. "To avoid a gap, your transformation must be published before January 11, 2027," according to TRKKN. By PPC Land's count, that leaves 60 days from November 12, and 70 days from the date the email first circulated. TRKKN suggests testing in December. A transformation scoped to named tags covers only those tags, so a Google advertising tag added to the container later would not be redacted unless it is added to the transformation's scope as well. Transformation rules have been able to target entire tag types since August 2023, which would avoid that gap. Google's opt-out page does not address the point.

Google has added data controls of this kind before without a formal announcement. In January, PPC Land reported that Google tag settings had gained data transmission controls covering advertising, behavioral analytics and diagnostic data, with options such as transmitting only limited advertising data and blocking advertising data when ad_storage is denied. For server-side setups, Google pointed to transformations as the way to redact or block event parameters then too.

TRKKN's reading of the privacy question

The post asks whether the change creates a data privacy problem. "Most likely not," according to TRKKN. Its argument has two parts. "The existing Google data protection terms already list IP addresses among the personal data Google processes for these products, so no new contract is needed," according to the post. And "In many setups, the visitor's browser also contacts Google directly once advertising consent is given, and Google sees the IP on those requests anyway."

TRKKN also reads the email as adding nothing to existing duties. "Google's email does not create new requirements," according to the post. Notices to users and consent for Google advertising, covering measurement and personalization, are already the advertiser's responsibility, and in the European Economic Area they fall under Google's EU User Consent Policy, according to TRKKN. The post lists three areas to check: that Google advertising tags send data only after advertising consent; that privacy notices and internal records do not claim IP addresses are shortened before they reach Google; and that requests sent without consent keep a redacted address. It recommends involving a data protection officer and carries a disclaimer that the post "does not constitute legal advice."

The second check deserves attention. A business that told users, or wrote into its records of processing, that IP addresses are truncated before reaching Google would find that statement untrue for the four advertising products from January 11 unless a transformation is in place. Under the GDPR, an IP address can be personal data, which is why that kind of documentation exists in the first place.

What the data protection terms actually list

TRKKN's contract point can be checked against Google's own service information page for its Ads Data Protection Terms, last updated on October 23, 2025. A table headed "Types of personal data" lists, product by product, the personal data Google processes as a data processor. The entry for Google Tag Manager names online identifiers, including cookie identifiers and internet protocol addresses. Search Ads 360 lists online identifiers including cookie identifiers, IP addresses and device identifiers, along with client identifiers. Display & Video 360 and Campaign Manager 360 also include IP addresses.

Google Ads itself has no row in that table. The only Google Ads entries are Customer Match and store sales uploads, neither of which lists IP addresses. Google Ads appears elsewhere on the same page, in a separate list of controller services - products for which Google acts as a data controller in its own right rather than processing data on the advertiser's behalf. TRKKN's statement therefore holds for three of the four advertising products and for Tag Manager. For Google Ads, the full address goes to a service Google lists as a controller service, outside the processor table on which TRKKN's argument rests.

The question Google has not answered

The weakest point in the published material concerns traffic without consent. Under consent mode in its advanced form, Google tags still send requests when a visitor declines advertising consent, without cookies, and Google uses them for modeling. Server containers carry that traffic too. Since July 28, 2025, Floodlight tags in server-side Tag Manager have sent unconsented requests server-to-server to improve modeled conversions.

Will those requests carry the full IP address after January 11? TRKKN does not know. "Google has not yet said whether they will carry the full IP," according to the post, which recommends keeping the address redacted for requests made without consent. Google's Help Centre page does not mention consent at all, and the email tied the change to consents required by law without distinguishing between consented and unconsented traffic.

The answer matters most for the EEA, the UK and Switzerland, where Google's consent policy applies and where Google has shown it will enforce. From July 21, 2025, Google began disabling personalized and non-personalized ads, remarketing and conversion tracking for EU advertisers without consent mode version 2 in place. Misconfiguration in the other direction has costs as well: one agency client's Google Ads conversions fell 90% overnight in August 2025 when a consent banner collected choices without passing them to Google tags.

Why server-side containers sit at the center

Server-side tagging was never only a privacy tool. Google launched it in Tag Manager in August 2020, and it spread as a response to browser restrictions and ad blockers, giving site operators control over what each vendor receives. Part of that control was the ability to strip identifiers before they left the server. The January change does not remove that ability, but it reverses the starting point for Google's four advertising products: protection that was applied once, across the container, becomes something the owner has to configure tag by tag.

The infrastructure is already under pressure from other directions. By May, ad blockers were targeting server-side GTM subdomains by name, with AdGuard's first-party tracking list holding more than 3,400 rules, 83 of them for gtm. patterns and 42 for sgtm. prefixes. And moving tags to a server never removed the consent question, as iubenda argued in October when it said server-side tracking still needs consent.

Google, for its part, has spent 2026 widening its use of IP addresses across the ad stack. In June it told publishers it would bring IP-based measurement and personalization to the EEA, the UK and Switzerland from August 3. In September, Customer Match uploads gained an IP address column, with IP matching excluded for users in 32 countries. The server-side change differs from both: it reaches into infrastructure that advertisers pay for and run themselves.

TRKKN's post ends with an offer to review server containers and implement the opt-out for clients. That is a reminder of who carries the work. The default is Google's, the documentation is Google's, and the transformation, its testing and its upkeep fall to every container owner who decides the full address should not reach Google's ad products.

Timeline

Summary

Who: Google, which is changing how server-side Tag Manager containers handle IP addresses for its Google Ads, Display & Video 360, Search Ads 360 and Campaign Manager 360 tags, and TRKKN (Trakken GmbH), whose senior topic lead Nikel Schubert published an analysis of the change. Advertisers, agencies and site operators who run server containers with Google advertising tags are affected.

What: From January 11, 2027, those tags will receive visitors' full IP addresses by default. Google's Help Centre page "IP address redaction for server-side tagging" describes the opt-out as a custom template variable built on getAnonymizedIpAddress(), applied through an "Augment event" transformation that overrides ip_override for selected tags; the function zeroes the last IPv4 octet and keeps the first 48 bits of an IPv6 address. TRKKN says Analytics-only and browser-only setups are unaffected and that no new contract is needed. PPC Land's check of Google's data protection terms supports that point for Tag Manager, Search Ads 360, Display & Video 360 and Campaign Manager 360, but Google Ads sits in a separate list of controller services. Google has not said whether requests sent without consent will carry the full address.

When: Google's email circulated publicly on November 2, 2026. The Help Centre page and TRKKN's post carry no dates. The change takes effect on January 11, 2027, and TRKKN says a redaction transformation has to be published before then to avoid a gap.

Where: Server-side Google Tag Manager containers worldwide, with Google's EU User Consent Policy governing advertising consent in the European Economic Area.

Why: Google's email presented the change as improving ads measurement and personalization. For container owners, it moves IP protection for Google's advertising products from a container-wide default to a per-tag setup they must build and maintain, and it leaves the treatment of unconsented traffic undefined less than two months before the date.