Google Ads IP Address Consent: What the August 3 Change Means

Your sGTM server already forwards your visitors’ IP address to Google Ads. That part is not new. What is new: since August 3, 2026, that IP address is no longer just a networking detail. It now feeds ad measurement and personalization for users in the EEA, the UK, and Switzerland. And that shift in purpose pulls the IP address into the scope of Google Ads consent, without a single alert showing up anywhere in your dashboards. The twist is that going server-side, sold as a control upgrade, is precisely the architecture that exposes you most. Let’s look at why, how to test it in five minutes, and what to fix depending on your setup.

One framing note before we start: this article describes what Google does and what the technical setup allows or blocks. The legal reading of your situation (are you compliant, should you cut the signal, on what legal basis) is for your DPO and your counsel. I give you the facts and the mechanics, not legal advice.

What changed on August 3, and what did not

The most misunderstood point in this whole story fits in one sentence: the IP address itself did not change, its purpose did. Google already received your visitors’ IP on every request, because that is physically required for a server to answer a browser. What Google announced is a new use of that same data.

Here is the shift, purpose by purpose:

The first three rows are so-called necessary uses that do not trigger a consent requirement. The last two do. That is the whole difference: identifying a device from its IP to serve it personalized advertising is no longer routing, it is processing that requires consent in the EEA, the UK, and Switzerland. Google itself phrases the rollout as August 3 “or shortly after,” so treat that date as the start of a window, not a single switch.

TCF Feature 3: the real tipping point for Google Ads consent

To legitimize this new use inside the European ecosystem, Google is registering under Feature 3 of IAB Europe’s Transparency and Consent Framework. Its exact wording: “Identify devices based on information transmitted automatically.” In plain terms, Feature 3 covers building an identifier from what a device sends on its own when it connects, IP address and user-agent first. That is exactly what Google intends to do with your IP.

Why it matters for you concretely: if your CMP (the platform running your consent banner) does not expose Feature 3 in its TCF chain, then the consent signal you pass to Google is incomplete. You think you are collecting full advertising consent, but the brick that specifically covers the IP use is missing. And nothing, anywhere, flags it.

This is the direct sequel to June’s shift on the ad_user_data and ad_personalization signals. If you have not read it yet, my guide to Consent Mode v2 in GA4 lays the groundwork for those two signals: Feature 3 stacks on top, over an extra identifier (the IP) that those signals alone do not cover.

What to check on the CMP side, in one line: is your platform Google-certified and up to date with TCF 2.3, and does it properly declare Feature 3 in the consent string? If the answer is no or “I’m not sure,” that is your first job.

The 5-minute test: is your setup sending the IP without consent?

Enough theory. Here is how to find out whether, in your case, the IP goes to Google while the user has not granted advertising consent. The test depends on your architecture.

Client side (gtag or classic GTM). Open your browser’s developer tools, network tab, filter on google-analytics.com and googlesyndication.com. Reject the consent banner, then reload. Inspect the collection requests: look at the gcs parameter (the Consent Mode state) and above all ad_user_data and ad_personalization. If those signals are “denied” but a request still fires toward an advertising endpoint, your IP is in it by construction, since every HTTP request carries the source IP.

Server side (sGTM). This is where it gets tricky, because browser network inspection sees nothing: the transmission happens server to server, out of reach of DevTools. You have to inspect the server container itself. Put your container in preview mode, fire an event with consent denied, and look at the outgoing request to Google: the server-side GA4 tag populates the client’s real IP by default. Check for the ip_override field and the value it carries.

The key takeaway: by default, an sGTM server sees the real client IP (the one from the browser that hit your proxy) and passes it on to Google. That is not a bug, it is documented behavior. So if you have configured nothing specific, the answer to “does my setup forward the IP without consent coverage” is very likely yes.

Three architectures, three fixes

The fix depends entirely on where your data flows. Here are the three cases, from simplest to most exposed.

gtag or classic web GTM

This is the simplest case to handle, because everything happens in the browser. If your Consent Mode v2 is wired correctly and your Google tags respect the “denied” state, advertising requests do not fire until consent is granted, so the IP does not leave for that purpose either. The work boils down to auditing your Consent Mode: confirm that ad_user_data and ad_personalization default to “denied,” and that your CMP covers Feature 3. Nothing new in the plumbing, everything in the consent configuration.

Google Tag Gateway (first-party mode)

The Tag Gateway rewrites the domain name of your requests to make them first-party, but it does not change the consent logic: the Consent Mode signals stay in charge. The trap is elsewhere. As I explained in my Google Tag Gateway vs sGTM comparison, the Tag Gateway is a lightweight proxy: it forwards, it does not transform. So the client IP crosses the proxy and reaches Google as before. Coverage rests entirely on the quality of your upstream consent signals, exactly like classic gtag. Audit the Consent Mode, do not count on the proxy to filter anything.

sGTM, the most exposed case

This is where the risk concentrates, for three stacking reasons. First, ip_override: the server-side GA4 tag forwards the client’s real IP by default, and many advertising tags do the same. Second, transformations and custom variables: a heavily worked server container can reinject the IP into fields you are not watching. Third, region-specific settings: without explicit EEA configuration, your server treats a Berlin visitor exactly like a New York visitor.

The concrete fix is to not forward the client IP to Google’s advertising endpoints until advertising consent is granted, which most often means handling ip_override conditionally based on the consent signal received from the client. If you are not on server-side yet and these notions are new, my GTM Server-Side guide lays out the overall architecture before you get into these fine settings.

A word on hosts, because the question always comes up: how the IP is handled depends partly on your sGTM host and the settings it exposes. Some offer finer IP-handling options than others. I compared the main ones in Stape vs Addingwell vs Taggrs: check what yours allows on IP forwarding before concluding you are covered.

The trap: GA4 IP anonymization does not cover Google Ads

Here is the mistake I see most often, and it is a nasty one because it hands you a false sense of safety. “I turned on IP anonymization in GA4, so I’m fine.” No.

GA4 IP anonymization acts on the GA4 data path: it truncates the IP before storage and use on the Analytics side. But the GA4-to-Google-Ads flow, and above all the Google Ads tags themselves (the conversion tag, remarketing), take a separate path. Google Ads receives its own request, with its own IP, regardless of what GA4 does with its own. Anonymizing the IP on the GA4 side does not strip the IP from the request that the browser, or your server, sends to Google’s advertising servers.

In other words: two data paths, two IP treatments. Fixing one does not fix the other. It is precisely because those two paths are separate that this article is not a rehash of Consent Mode v2: there, we discussed the GA4-to-Ads flow governed by ad_storage; here, we are talking about an identifier, the IP, forwarded even outside GA4.

What you lose if you cut it off, and how to quantify it

Cutting IP transmission for non-consenting visitors has a cost, and it deserves an honest look rather than a blind decision. The IP feeds matching (tying a conversion back to a click), enhanced conversions quality, and modeling. Less deterministic signal mechanically means fewer attributed conversions and a slightly less well-fed Smart Bidding on the non-consenting EEA segment.

The reflex to avoid is grabbing a ready-made percentage off a blog. Your real loss depends on your share of EEA traffic, your consent rate, and the richness of your other first-party signals. Here is how to quantify it on your own data rather than inventing a number:

1. Isolate your non-consenting EEA segment (share of traffic, share of modeled conversions today).
2. Measure how much your matching currently relies on the IP: compare your conversion match rates before and after if you test the cut over a short window.
3. Weigh the lost attributed conversions against the total: a 30% loss on a segment worth 10% of your conversions is not the same decision as a 30% loss on a segment worth half of them.

And above all, do not reason as if the IP were your only lever. Strengthening your first-party signals offsets part of the loss: server-side enhanced conversions lift matching with data you collect under your own consent, and Google Ads Data Manager opens first-party connections that do not depend on the IP. The right question is not “am I losing signal,” it is “where do I go find that signal elsewhere, cleanly.”

Putting it in context, without mixing up the topics

This reversal does not come out of nowhere. Google had promised a future without deterministic identifiers, then backpedaled: the death of Privacy Sandbox leaves a gap, and the IP is a convenient deterministic signal to fill it. Seen that way, using the IP is less a surprise than a logical consequence of the retreat on cookieless.

Be careful, though, not to conflate two topics that pull in opposite directions. Safari hides the real IP through iCloud Private Relay, as I detail in Safari 27 and your tracking: on the Apple browser side, you see fewer usable IPs. Google, for its part, decides to use more of them. The two moves coexist and do not cancel out: on Safari, Google will have less to work with; elsewhere, it will have more. Do not draw a global conclusion from just one of them.

Exit checklist

Before you close the topic, the minimum to validate:

• Your CMP is Google-certified, up to date with TCF 2.3, and declares Feature 3.
• ad_user_data and ad_personalization default to “denied” and are driven by real consent.
• You ran the network test (web) or the server preview test (sGTM) to see what leaves without consent.
• On sGTM, ip_override forwarding to advertising endpoints is conditioned on consent, with a specific EEA setting.
• You quantified your potential loss on your own data, and identified the first-party signals to offset it.
• The final call (cut it or not, on what basis, with what documentation) is signed off by your DPO.

To go further on upstream configuration hygiene, my GA4 audit of 11 configuration mistakes sweeps the settings that, when badly set, amplify this kind of problem.

One last reminder, because it matters: nothing above is legal advice. I describe what Google does, what the technical setup allows, and how to verify it in your own stack. The decision to cut or not, and its justification under GDPR, belongs to your DPO and your counsel. My job stops at giving you a clear picture of what your setup actually transmits, so that decision gets made with your eyes open.