Google IP-Based Ad Personalisation Update

How Google uses IP addresses for advertising

Since August 2026, Google has been rolling out IP-based ad measurement and personalisation across the European Economic Area (EEA), the UK and Switzerland.

This is confirmed directly by Google, not just reported by specialist media. IP addresses already reached Google through its tags, SDKs, HTTP requests and data uploads, this isn’t a new data source. What changes is the purpose: from now on, those addresses will be used to identify devices for measurement and personalisation, which triggers consent obligations under the GDPR and the UK GDPR.

Google notified advertisers directly through a mandatory service email on 17 June 2026 (with a subject line referring to IP-based measurement and personalisation solutions), explicitly stating that “as a user of Google’s ads products, you remain bound by our EU User Consent Policy.” This confirms the notice covers advertisers generally, not only publishers monetising with AdSense, Ad Manager or AdMob.

What’s happening: Google started using IP addresses to measure and personalise ads from August 2026.
Who it affects: advertisers with traffic in the EEA, the UK and Switzerland.
What you need to do: make sure your cookie banner (Consent Mode) is working properly and update your Privacy Policy.

Official source

The FAQ section of Google’s EU User Consent Policy includes a direct, specific confirmation:

Does Google use IP Addresses for ads measurement and ads personalization in the EEA, the UK, and Switzerland?

Yes. Beginning in August 2026, Google will begin launching its IP-based ads measurement and ads personalization solutions in these regions. To support these solutions, Google will use the IP Addresses it receives via customer tags, SDKs, HTTP calls, uploads, or similar means for ads measurement and ads personalization. Google will also update its registration in the Global Vendor list of the TCF to register for Feature 3, to “Identify devices based on information transmitted automatically.” See this page of Google’s Privacy Policy for additional information on how Google uses IP Addresses.

Already used elsewhere

This isn’t a new practice globally, it’s only new for the EEA, the UK and Switzerland, because of local consent legislation. Google’s own advertising policy page confirms it has already been using IP signals in advertising, for measurement and personalisation, in other regions for some time. The change in the EEA, UK and Switzerland is the addition of a mandatory legal basis (consent), not the introduction of a new technical capability.

The mechanism

Google is updating its registration in the TCF’s Global Vendor List (GVL) for Feature 3: “identify devices based on information transmitted automatically.”
Feature 3 isn’t itself a consent toggle, it’s tied to core advertising purposes (creating a personalised ads profile, ad selection). Valid, active user consent is required where it applies; legitimate interest isn’t a valid basis.
Google bases this change on privacy-enhancing technologies (PETs): on-device processing, trusted execution environments (TEEs) and secure multi-party computation.
An end-user opt-out on Google’s own properties is not available since launch. Google says it will arrive “later this year or early next,” leaving a gap period with no dedicated opt-out for IP-based personalisation.

Important nuance: consent signal requirement differs by region

This is a distinction missing from earlier drafts of this brief, confirmed directly by Google’s FAQ:

EEA traffic: advertisers are expected to send a verified consent signal to Google (via Consent Mode or TCF).
UK and Swiss traffic: Google explicitly states it doesn’t require a verified consent signal for this traffic. Direct quote: “No, we do not have an expectation for advertisers to send a verified consent signal to Google for UK or Swiss traffic (either via consent mode, or TCF).” That said, at the legal level, local regulations (such as the UK GDPR) still require user consent for tracking and advertising.
The disclosure obligation, however, applies across all three regions (EEA, UK, Switzerland), regardless of the consent-signal distinction above.

In practice: if your traffic is from the EEA, you need the full Consent Mode or TCF signal chain working correctly. If your traffic is UK or Swiss only, the technical effort is lighter, but you still need to update your Privacy Policy.

What this means

Mandatory disclosure requirement

Google’s FAQ specifies this precisely:

What transparency obligations apply to this change?

As a reminder, you are required to display a prominent link in your disclosures to make it clear how Google processes end user data […]

The link must go to Google’s Business Data Responsibility Site: business.safety.google/privacy/. It can be placed directly in your privacy policy, in the consent notice itself, or as a “more info” style link inside that notice.

For more detail on how Google uses IP addresses, this page of its Privacy Policy explains it: policies.google.com/technologies/ads.

We recommend speaking with your legal team to confirm your obligations under applicable data protection law.

Note: this disclosure obligation isn’t new to this change, it already existed within Google’s EU User Consent Policy, and is now reiterated in the FAQ specifically in the context of IP-based measurement.

Related change already in effect: the GA4/Ads consent split (15 June 2026)

This isn’t part of the August update, but it affects the same consent infrastructure:

Since 15 June 2026, the ad_storage consent signal alone determines whether Google Ads can collect advertising cookies and identifiers from a linked GA4 property. The former dual-control setup (where both Google Signals and Consent Mode had to agree) no longer applies.

Google Signals in GA4 is now limited to behavioural reporting. It no longer influences what Google Ads receives.

Any client who relied on having Google Signals switched off as a safeguard against advertising data collection has lost that protection. If ad_storage is granted in their banner, Ads receives the full signal, regardless of the Signals status.

IP addresses collected by the Google tag will be encrypted before being passed to linked Ads accounts, governed by settings on the Ads account side. There’s no confirmed date for this specific piece, Google has only said “later in 2026.” GA4 already masks IP addresses by default and doesn’t log or store them for its own reporting, and this encryption applies specifically to the data bridge into Google Ads.

What you need to review

Consent mode

Google Consent Mode can be configured in two ways. If you don’t know which one you have, ask us, or ask whoever manages your Google Tag Manager or your analytics and advertising implementation.

Basic mode: the Google tag doesn’t send any information until the user actively gives consent. Before that, no signal reaches Google.
Advanced mode: the Google tag sends a signal on every visit, even without consent, but without cookies and flagged as “denied.” This lets Google model behaviour without identifying the user, but it means that consent signal must always be correctly configured, because the data already leaves the browser on every visit.

If you have basic mode: confirm that the consent banner requires an active action from the user before Google’s tags fire, and that the default value is “denied” before that interaction.

If you have advanced mode: confirm that the ad_storage, ad_user_data and ad_personalization signals correctly reflect the user’s actual consent status on every visit, not only after interaction.

Traffic origin

If your traffic is from the EEA: confirm that your consent management platform (CMP) sends a verified consent signal to Google, via Consent Mode or TCF.

If your traffic is from the UK or Switzerland: you don’t need a verified signal.

In all cases: confirm that the disclosure link to business.safety.google/privacy/ is present and visible, and confirm with your legal department that your privacy policy mentions the use of IP addresses for device identification for ad measurement and personalisation purposes.

Your traffic very likely includes EEA visits, not just the UK or Switzerland, so the safest assumption is that you need the verified consent signal, unless you know for certain your traffic is exclusively from the UK or Switzerland.

If we manage your consent setup with a consent management platform (Cookiebot, Complianz, Usercentrics or another), this is already covered: a correctly configured CMP with Consent Mode generates the verified signal Google requires for the EEA on its own, with no extra action needed from you on this point.

If you manage your consent setup another way, or you’re not sure how it’s configured, confirm that your platform sends a verified consent signal to Google, via Consent Mode or TCF. If you’d like us to review it with you, just let us know.

Google Analytics and Google Ads setup

What determines whether Ads receives and uses this data is the consent signal coming from your website or app, not a specific setting inside the Ads account itself.

Important note on Google Signals: if you used to switch off Google Signals in GA4 as a safeguard, note that it no longer acts as a barrier. Since 15 June 2026, the ad_storage signal alone decides whether Google Ads receives this data (see the “Related change already in effect” section).

There are several technical routes within your GA4 and Google Ads dashboards to diagnose whether this consent signal is arriving and being applied correctly. If you’d like to make sure everything is in order, let us know and our team will audit your setup.