Server-Side GTM IP Address: Google Ads Gets the Full IP in 2027

You moved to server-side tagging to control what leaves for Google? On January 11, 2027, Google rewrites part of the rulebook inside your own container. According to an email sent to advertisers in early November 2026, server-side GTM will move from IP redaction applied to the whole container to tag-level processing, and Google Ads, Display & Video 360, Search Ads 360 and Campaign Manager 360 tags will receive your visitors’ full IP address by default. GA4 tags will keep redacting it. Do nothing, and the new behavior is what you get. Here is what changes in practice, how to tell whether your server-side GTM IP address handling is affected, and how to stay in control with a transformation you test before the deadline.

The usual framing on these topics: I describe the mechanics and what Google announced. Whether you should send the IP, and on what legal basis, is your DPO’s call.

What changes in server-side GTM on January 11, 2027

The information comes from an email titled “Updates to network signal processing in server-side tagging”, shared on LinkedIn by Google Ads consultant Adriaan Dekker on November 2, 2026, then covered by PPC Land, Search Engine Journal and Search Engine Roundtable. One word of caution up front: the email is undated, and as I write, neither the Tag Manager release notes nor the IP redaction help page mention the January 11 date. Everything below rests on Google’s word in that email, not yet on its documentation.

Before: redaction at container level

Until now, think of a single doorman at the building entrance: the server container could redact the IP for every tag in one go. The email describes exactly that switch, from “container-wide IP address redaction” to “individual tag-level processing”.

After: each tag decides

On January 11, the doorman leaves and every tenant handles their own door. Here is what the email announces, tag by tag:

Google frames it as “improvements to ads measurement and personalisation”, plus spam and invalid traffic filtering. In plain terms: the IP is a valuable deterministic signal for matching a conversion to a click, and Google wants it back from the server-side setups that were stripping it.

What about third-party tags

The email only says third-party tags keep independent control over the signals they accept. It does not say whether their behavior changes. In practice, many third-party templates already read the standard ip_override field, so your Meta CAPI or TikTok Events API tag most likely receives the IP today. January 11 changes nothing for them, but it is a good moment to check.

Server-side GTM IP address: are you affected?

Three conditions together put you in scope:

1. you run a server container (according to the email, web containers and the browser Google tag are not affected);
2. that container holds at least one Google Ads, Floodlight, DV360 or SA360 tag;
3. you relied on container-level redaction, or never looked.

The test takes ten minutes. Open your server container in Preview, send a conversion event from your site, then select the Google Ads tag in the left column. In the outgoing requests tab, look at what goes to Google: is the client IP there, and in what form (full, or with the last octet zeroed)? Do the same for the GA4 tag, which works as a control since it partially redacts by default. Write the result down: that is your baseline, the one that must still hold on January 12.

If you use a hosting provider (Stape, Addingwell, Taggrs), also check the IP options it exposes. Some offer their own settings, which do not replace a documented transformation inside the container.

The consent side in Europe

An IP address is personal data

The Court of Justice of the European Union settled it in 2016 in the Breyer ruling: a dynamic IP address can be personal data. Google’s email does not frame the IP that way, but it reminds advertisers to have “legally required consents” in place before collection and to strictly follow the EU user consent policy for the EEA (the policy also covers the UK and Switzerland).

This change stacks on top of another one, a few months older. Since August 3, 2026, Google uses the IP for ad measurement and personalization in the EEA, which I cover in Google Ads IP Address Consent: What the August 3 Change Means. August 3 was about purpose. January 11 is about plumbing: your container stops filtering by default. Put the two together and a European visitor’s full IP reaches Google Ads and feeds personalization, unless you step in.

Server-side consent mode: what it covers and what it doesn’t

Consent mode drives how Google tags behave based on the ad_storage, ad_user_data and ad_personalization states sent by the browser. It is your first line of defense and it stays essential. But two grey areas remain.

First, the email says nothing about how consent mode interacts with this new IP processing, and Google’s developer documentation for server-side consent mode does not mention IP addresses. Second, since July 28, 2025, Floodlight tags in a server container send non-consented requests server to server: nobody knows yet whether those requests will carry the full IP after January 11. Until Google documents it, I would not bet on the most comfortable answer.

Redact the IP address with a server-side GTM transformation, step by step

The email names transformations as the way to redact these signals “before any tag accesses the data”. The help page IP address redaction for server-side tagging gives the recipe. It has two parts: a variable that computes a truncated IP, and a transformation that swaps it in for the real one.

Step 1: the variable. In your server workspace, create a custom variable template with this code:

const getAnonymizedIpAddress = require('getAnonymizedIpAddress');
return getAnonymizedIpAddress();

This API, recently added to the server-side API reference, zeroes the last octet of an IPv4 address and the last 80 bits of an IPv6 address. It is partial redaction: the IP keeps its rough geolocation value and loses its individual precision.

Step 2: the transformation. In Transformations, create an “Augment event” transformation that overrides the ip_override field with the step 1 variable.

Step 3: the scope. Under affected tags, explicitly select your Google Ads and Floodlight tags, plus any third-party tag that reads ip_override. Do not let the transformation apply to “everything” without knowing what that covers.

Step 4: third-party tags that read elsewhere. Some templates don’t read ip_override but a custom field or a header. Inspect their outgoing request in Preview, find the field carrying the IP, and create a second transformation for that field.

Step 5: QA. Back in Preview, trigger a conversion and check in each tag’s outgoing request that the IP ends in .0 (for IPv4). Then publish.

One detail that matters: the help page documents partial redaction, not removal. If your DPO requires that no IP at all, even truncated, reaches ad tags, you will need to test an “Exclude parameters” transformation on ip_override and confirm in Preview that the tag does not fall back on another IP source. Google does not document that case today: test it, don’t assume it.

Keeping the full IP for Google Ads: when it makes sense

I won’t tell you redaction is always the right answer. The full IP improves click to conversion matching, feeds Smart Bidding and helps filter invalid traffic. Outside Europe, on traffic where the legal framework allows it, letting Google Ads receive it can be a rational choice.

What doesn’t hold up is sending it by default because nobody looked. If you keep the full IP, do it deliberately: your CMP and privacy policy must cover that processing, your consent mode must be clean, and you can make the transformation conditional on region or consent state (a consent or country variable in the transformation conditions). And to make up for lost signal where you do redact, lean on first-party data collected with consent, such as server-side Enhanced Conversions.

For the record, this is not the first time Google has quietly rewired your server container around its own needs: I covered it with parallel browser signals. Server-side gives you control, provided you keep rereading what Google changes by default. The same goes for your customer data uploads, now that Google Ads Data Manager hashing becomes optional on November 16.

Checklist before January 11, 2027

With the Black Friday and holiday code freeze, the real working window is shorter than it looks. Plan now:

• List your server containers and, in each, the Google Ads, Floodlight, DV360, SA360 and third-party tags.
• Run the Preview test and write down, tag by tag, what goes out today (full IP, truncated, absent).
• For each third-party tag, identify the field that carries the IP (ip_override or other).
• Get your DPO to decide: full IP, partially redacted or removed, possibly by region.
• Create the getAnonymizedIpAddress variable and the “Augment event” transformation(s), scoped to the chosen tags.
• QA in Preview, publish, and document the container version.
• Check again in Preview after January 11: it is the only way to confirm Google’s new logic actually honors your transformation.
• Watch the Tag Manager help page and release notes, which should eventually document the change and any opt-out setting.

If you don’t have a server container yet and are weighing the move, my guide on why and how to migrate to server-side GTM covers the basics. This change is no reason to run away from server-side: it is a reason to actually steer it, instead of leaving it on an autopilot Google configures for you.