PrivacyForgeSign In
Back to Blog

Google IP Address Ad Targeting: Your Consent Checklist

Google uses IP addresses for ad targeting in the EEA and UK from 3 August 2026. Check what your consent banner actually sends before assuming you are covered.

PFMariyan ValevAug 10, 2026 · 14 min read
GuideGuide

Key Takeaways

  • Google told AdSense publishers on 17 June 2026 that from on or shortly after 3 August 2026 it would begin using IP addresses to power ad measurement and personalisation across the EEA, the UK and Switzerland.
  • The IP addresses were already flowing to Google for routing and coarse location. What changed is the purpose — the same data is now used to identify devices, which is the use that engages consent duties.
  • In the IAB Europe Global Vendor List version 171, dated 6 August 2026, vendor 755 "Google Advertising Products" declares Feature 3, "Identify devices based on information transmitted automatically".
  • Feature 3 is not a new toggle. Under the TCF Policies a Feature is one "for which the user is not given choice separately", and the TCF v2 string format has no consent field for Features at all — only for Special Features.
  • Google declares Purposes 1, 3 and 4 on a consent basis but Purpose 7, "Measure advertising performance", on legitimate interest — so a visitor pressing "Reject all" may not stop the measurement half of this change.

Introduction

Your banner has not changed. Your tags have not changed. Nobody sent you an email, because you are a merchant rather than an AdSense publisher — and from 3 August 2026 the data your store already sends Google quietly acquired a new job.

Google told publishers it would begin using IP addresses received through site tags to identify devices for ad measurement and personalisation across the EEA, the UK and Switzerland, on or shortly after that date. The addresses themselves are not new; Google has always needed them to route a request. The legal question is what they are used for, and that is what Google said would change.

Most coverage so far has been written for publishers running AdSense. This is the merchant version: what actually changed, what your consent platform genuinely needs to do about it, and the one widely repeated instruction that is technically impossible to follow.

What Google Changed on 3 August 2026

Google notified AdSense publishers by mandatory service email on 17 June 2026 that, beginning on or shortly after 3 August 2026, it would "begin using IP addresses to power ad measurement and personalization" in the European Economic Area, the United Kingdom and Switzerland. The notice reminded publishers they "remain bound by our EU User Consent Policy, which requires that you display accurate disclosures…"

The data was already there — the purpose is what moved

Before this change, Google received IP addresses through customer tags, SDKs, HTTP calls and uploads, and used them to route traffic, deliver ads and derive coarse location. From 3 August, the same addresses are used to identify devices for measurement and personalisation.

That distinction is the whole story. An IP address arriving at Google's servers so a response can be sent back is unavoidable plumbing. The same address used to recognise a device across sessions is a different processing operation with a different purpose, and purpose is what consent attaches to. A new purpose needs its own legal basis established and documented against it rather than quietly inheriting the routing one, which is the per-activity discipline set out in our complete guide to GDPR compliance.

Google frames the change around three privacy-enhancing technologies: on-device processing, Trusted Execution Environments and secure multi-party computation. Those constrain how the data is handled, not what it is used for — and it is the use your consent notice has to describe.

Which products this covers

The platform programme policies named in Google's announcement cover Authorized Buyers, Campaign Manager 360, Google Ad Manager, Google Ad Manager 360, Search Ads 360 and Display & Video 360.

If you are a Shopify or WooCommerce merchant, you are unlikely to be running most of that list. You are, however, almost certainly running Google tags that feed Google Ads and Analytics — and Google's own advertiser guidance is unambiguous about what that requires: "Advertisers must adhere to the EU UCP to use ad personalization and for measurement when using: Tags that send data to Google (websites) [and] SDKs that send data to Google (apps)."

One clarification worth making, because the two changes are circulating together: Google Analytics has a separate update covering IP addresses collected by the Google tag being encrypted and flowed to a linked Google Ads account. That page explicitly scopes itself to "users not located in the European Economic Area (EEA), the UK, or Switzerland" and says exact dates "will be shared later this year." It is not this change. Do not brief your team on one and implement the other.

Does Your Cookie Banner Need Updating?

Probably not the banner itself — but your vendor disclosure almost certainly needs a refresh, and your consent signals need testing. The change alters what Google does with data it already receives, so the fix is in what your consent platform discloses and transmits, not in redesigning the interface your visitors see.

Concretely, there are two jobs. The first is disclosure: your consent platform's record of what Google does needs to reflect Google's current declaration, which as of Global Vendor List version 171, dated 6 August 2026, now includes Feature 3. The second, and the more consequential one, is verification: confirming that the consent signal your platform generates actually reaches Google in a form Google will act on.

The second job is where merchants lose. A banner can look immaculate and still transmit nothing useful, and no amount of visual polish surfaces that — which is why our cookie consent best practices put signal testing ahead of banner copy.

TCF Feature 3: What It Is, and What It Is Not

Feature 3 is a disclosure item, not a consent toggle. In the IAB Europe Global Vendor List version 171, last updated 6 August 2026, vendor 755 "Google Advertising Products" declares Features 1, 2 and 3 — Feature 3 being "Identify devices based on information transmitted automatically". Users are never asked to opt in to it separately, and the framework does not provide a way to.

Features and Special Features are not the same thing

The IAB Europe TCF Policies, document version 2026-05-29.5.0.b, draw the line explicitly. A Feature is one "used in pursuit of one or several Purposes for which the user is not given choice separately". A Special Feature is one "for which the user is given the choice to opt-in separately".

The technical specification says the same thing at the string level. The TCF v2 Core string carries a SpecialFeatureOptIns field — "One bit for each Special Feature: 1 Opted in 0 Not opted in" — and there is no corresponding field for ordinary Features.

This matters for a practical reason. Trade coverage of the August change instructs publishers to verify that "the TC string their CMP generates includes Feature 3 in Google's entry." On our reading of the spec, that instruction cannot be carried out, because a TC string does not encode Features at all. If your agency or CMP support ticket sends you looking for a Feature 3 consent bit, you will spend a week failing to find something that was never there.

There is a real task hiding underneath the bad instruction, and it splits in two:

  1. Refresh your Global Vendor List version so Google's Feature 3 declaration appears in your disclosure UI and vendor documentation. A CMP pinned to an older GVL will describe Google's processing inaccurately.
  2. Verify consent for Purposes 1, 3 and 4 is genuinely being captured and transmitted, because those are what actually gate personalisation in the string.

What actually gates personalisation

Google (vendor 755) declares Purposes 1, 3 and 4 on the consent basis: "Store and/or access information on a device", "Create profiles for personalised advertising", and "Use profiles to select personalised advertising". Those three are the gate. If your visitors are not consenting to them, or the consent is not reaching Google, personalisation should not proceed regardless of what your banner displays.

The registry also settles a question worth asking directly: Google does not declare Special Feature 2, "Identify devices based on information actively requested" — the entry corresponding to actively-solicited fingerprinting. So no new opt-in prompt appears in your banner as a result of this change. If your CMP has started showing one, something else caused it.

Feature 3 is also not exotic. Of the 1,202 vendors on GVL v171, 684 declare Feature 3, and 503 of those also declare Purpose 4 under consent. Only 190 declare Special Feature 2. Google is joining a majority practice, not inventing one — which is an argument for auditing your whole vendor list rather than treating Google as a special case. Our recent breakdown of why your cookie banner has too many vendors works through that list-pruning exercise in detail.

The measurement half is declared under legitimate interest

Here is the part we would look at hardest. Google's announcement covers "measurement and personalization", but those two halves sit on different legal bases in Google's own TCF declaration. Personalisation runs on consent through Purposes 3 and 4. Measurement runs on legitimate interest: Google declares Purposes 2, 7, 9 and 10 — including Purpose 7, "Measure advertising performance" — on a legitimate-interest basis, all of them flexible.

The practical consequence is that a visitor who rejects everything has not necessarily stopped the measurement side. Under the TCF, legitimate-interest purposes are objected to separately, usually on a second screen most visitors never open. Whether that arrangement holds up for a purpose newly powered by device identification is not something any regulator has ruled on. Until one does, the conservative read is to treat IP-based measurement as consent-gated in your own configuration where your platform lets you, and to document that you made that choice deliberately.

The Consent Checklist for EU and UK Stores

Work through these in order. The first two are the ones that fail most often.

  1. Confirm your CMP's Global Vendor List version. You want a version at or after 171 (6 August 2026), so Google's Feature 3 declaration is present. Most platforms display the GVL version in the consent-configuration screen; if yours does not, the support team can tell you.
  2. Test what your TC string actually contains. Load your storefront in a clean browser profile, reject everything, then accept everything, and inspect the consent signal both times. You are checking that Purposes 1, 3 and 4 flip as expected and that Google (vendor 755) is present in the vendor consent section.
  3. Check your legitimate-interest configuration for Purpose 7. Decide deliberately whether advertising measurement runs on legitimate interest on your store, and record who decided.
  4. Do not assume Google's own tooling handles this. In PPC Land's analysis of the rollout, Google's consent-optimisation auto-enrollment selects message formats to maximise consent rates from existing configurations, but does not update the underlying vendor list or Feature declarations. Auto-enrollment optimises how the question is asked, not what is disclosed.
  5. Update your privacy notice's description of Google's processing. Your notice probably says Google receives IP addresses to deliver ads and estimate location. That description is now incomplete.
  6. Record the review. Date it, name the reviewer, and keep the before-and-after of your vendor configuration. Google's EU User Consent Policy requires you to "retain records of consent given by end users" — and a dated configuration review is what turns that from a claim into evidence.

Common Mistakes

Chasing a Feature 3 consent bit. Covered above, and worth repeating because it is the single most likely way to waste this week. Features are disclosed, not consented to. Verify the GVL version and the Purpose 1/3/4 signals instead.

Assuming this only affects publishers. The coverage says "publishers" because Google's email went to AdSense accounts. The obligation in Google's advertiser guidance attaches to anyone running tags or SDKs that send data to Google, which includes essentially every EU or UK store running Google Ads or Analytics.

Treating "IP addresses are just technical data" as a defence. Whether a technical identifier counts as personal data is genuinely contested in places — we walked through a €600,000 ruling that turned on exactly that question in our piece on whether a MAC address is personal data. But the contested cases turn on whether a controller can realistically link the identifier to a person. A change whose stated purpose is to identify devices for personalisation is not a promising place to run that argument.

Waiting for the user-facing control. Google says an option for users to choose IP-based personalisation on its own properties arrives later in the rollout, reported as later in 2026 or early 2027. There is no user-facing opt-out at launch. Your consent notice is the control that exists right now.

Forgetting that the UK regulator has already spoken about the underlying technique. In December 2024, responding to Google's decision to stop prohibiting fingerprinting, Stephen Almond, Executive Director for Regulatory Risk at the Information Commissioner's Office, said: "We think this change is irresponsible," adding that "Businesses do not have free rein to use fingerprinting as they please. Like all advertising technology, it must be lawfully and transparently deployed – and if it is not, the ICO will act." That was a different Google announcement, about a different technique. It is a reasonable indicator of how a UK regulator reads device identification for advertising.

How PrivacyForge Helps

The recurring failure in this change is not legal, it is evidential: most merchants cannot show what their consent banner transmitted on a given date, to which vendors, under which purposes.

PrivacyForge's consent management keeps a per-visitor record of what was consented to and when, so a configuration change like this one produces a visible before-and-after rather than a gap. Our data mapping keeps Google listed as a recipient with its actual purposes attached, which turns a privacy-notice update into a two-minute edit instead of an archaeology project. And because compliance scoring flags vendors whose declared purposes have drifted from what your notice says, a vendor quietly adding a Feature to its registry entry surfaces rather than sits.

None of that decides whether advertising measurement should run on legitimate interest on your store. That is a judgement call for a person, and it should be written down. The tooling's job is to make sure it is recorded and the evidence exists when someone asks.

This is informational content, not legal advice. For advice on your specific configuration, consult a qualified data protection practitioner.

Frequently Asked Questions

Does Google using IP addresses for ads mean I have to update my cookie banner?

Your banner design probably does not change, but two things do. Your consent platform needs a Global Vendor List version at or after 171 (6 August 2026) so Google's Feature 3 declaration is disclosed accurately, and you need to verify that consent for Purposes 1, 3 and 4 is genuinely reaching Google. Your privacy notice's description of Google's processing also needs updating.

What is TCF Feature 3 and do visitors opt in to it?

Feature 3 is "Identify devices based on information transmitted automatically", and visitors do not opt in to it separately. Under the IAB Europe TCF Policies, a Feature is one "for which the user is not given choice separately", unlike a Special Feature. The TCF v2 string format carries a SpecialFeatureOptIns field but no equivalent field for ordinary Features.

Does this change apply to my Shopify or WooCommerce store, or only to publishers?

It applies to your store if you run Google tags. Google's email went to AdSense publishers, which is why coverage says "publishers", but Google's advertiser guidance states that advertisers must adhere to the EU User Consent Policy to use ad personalization and measurement with tags that send data to Google from websites or SDKs from apps.

If I use Google's own consent tools, is this handled automatically?

No. In PPC Land's analysis of the rollout, Google's consent-optimisation auto-enrollment selects message formats to maximise consent rates from existing configurations but does not update the underlying vendor list or Feature declarations. It optimises how consent is requested, not what your platform discloses. Merchants on third-party consent platforms should treat the vendor-list refresh as a manual task.

Does pressing "Reject all" stop Google using IP addresses?

Not necessarily for measurement. Google declares Purposes 3 and 4, which drive personalisation, on a consent basis — so rejection should stop those. But it declares Purpose 7, "Measure advertising performance", on a legitimate-interest basis, which under the TCF is objected to separately rather than covered by a rejection. Check how your platform presents that objection.

Can visitors opt out of IP-based ad personalisation on Google's own properties?

Not at launch. Google says the option for users to choose IP-based personalisation on its own properties arrives later in the rollout, reported as later in 2026 or early 2027. Until then the consent your site collects, and the signal your consent platform transmits, is the operative control for visitors in the EEA, UK and Switzerland.

Conclusion

The instinct on reading about this change is to go and look at your banner. Resist it. The banner is the one part of the chain that almost certainly does not need to change, and the parts that do — your Global Vendor List version, the purposes your consent string actually carries, and the legal basis you allow for advertising measurement — are invisible from the front end.

Spend an hour on steps 1 and 2 of the checklist above. If your platform is running GVL 171 or later and your consent string flips Purposes 1, 3 and 4 the way you expect, you are in good shape and you have the evidence to say so. If it is not, you have found something worth more than a week of banner design.

Start by checking which Global Vendor List version your consent platform is running today.

Sources

#consent management#cookie consent#IAB TCF#Google Ads#eCommerce

Keep reading

All articles →
GuideGuide15 min readCredit Checks at Checkout: Your GDPR Duties, Not TheirsAug 30, 2026GuideGuide15 min readWhen Your Cache Leaks Personal Data: A GDPR GuideAug 28, 2026RegulationRegulation18 min readGDPR Article 22: Auto-Cancelled Orders and Banned AccountsAug 27, 2026