Google's IP Ad Measurement Switch: What SaaS Must Do

On August 3, 2026, Google began using IP addresses to identify devices for ad measurement and personalization for users in the EEA, UK and Switzerland. This is a genuinely new use of data Google already collects, and it is distinct from the consent-mode change earlier in the year. For SaaS teams that run Google Ads against a European audience, it quietly rewires how conversions get measured — and it makes one piece of your consent stack, the TCF Feature 3 signal, load-bearing for attribution accuracy. Here is what changed, why it is separate from June, and the specific checks to run now.

What actually changed on August 3

The change is a change of purpose, not of collection. Google has always received your visitors' IP addresses because an IP is required to route a request across the internet. From August 3, Google can use those same addresses to identify devices for advertising measurement and personalization in the EEA, UK and Switzerland. As SC Media summarized it, Google will use IP addresses for ad measurement and personalization in the EEA, UK, and Switzerland, applying a new advertising purpose to a signal it previously used only for delivery. Because IP addresses are classified as personal data under GDPR and UK law, that new purpose is exactly the kind of use that requires consent.

Mechanically, IP addresses collected by the Google tag and SDKs are encrypted and processed in privacy-enhancing environments, then made available to linked Google Ads accounts where they are controlled by Google Ads settings and terms. To slot this into the industry's existing consent machinery, Google is registering under the IAB Europe Transparency and Consent Framework for Feature 3 — the feature that covers identifying devices based on automatically transmitted information such as an IP address. Coverage in BleepingComputer notes the persistent nature of the signal: unlike a cookie, an IP address is a household-level identifier a user cannot simply clear.

Why this is not the June 15 consent change

It is easy to file this alongside the June 15, 2026 consent-mode overhaul and move on. Do not — they operate on different layers. The June change made the ad_storage signal the single control over whether GA4-sourced data reaches a linked Google Ads account; it consolidated where the control lives, as we covered in the GA4 and Google Ads consent split. Nothing about June introduced a new data signal — it re-routed authority over an existing one.

August 3 does the opposite. It introduces a new advertising use for IP data and makes that use available to measurement and personalization across properties, gated on a consent feature — TCF Feature 3 — that many SaaS consent banners were never explicitly configured to capture. So the two changes compound: June determined the pathway from Analytics to Ads, and August adds a fresh, persistent identifier flowing along adjacent rails. A team that audited only the June change and assumed it was covered for the year has missed a materially different exposure that went live in August.

What it means for SaaS attribution

For measurement, the practical rule is simple: if your consent management platform does not emit a valid TCF signal covering Feature 3, your European users are effectively excluded from Google's expanded IP-based measurement. PPC Land put the trade-off bluntly for publishers — those who do not update their consent flows effectively exclude their users from the expanded targeting and forgo the associated revenue upside. The same logic applies to advertisers measuring conversions: no Feature 3 consent means Google has less signal to attribute those users' conversions to your campaigns.

This creates a subtle reporting risk. If measured conversions move after August 3, the cause could be your consent configuration rather than any change in real demand or campaign performance. A team that reads a consent-driven measurement shift as a campaign problem may "fix" it by loosening consent — trading a reporting artifact for genuine compliance exposure. This is the same failure mode we flag for cookieless attribution accuracy: when the measurement layer changes underneath you, the first job is to separate signal changes from behavior changes before touching anything.

The consent and liability angle

Because an IP address is regulated personal data in the EU and UK, using it for device identification requires a lawful basis — in practice, consent. That puts a compliance obligation squarely on advertisers and publishers, not just on Google. Regulators noticed quickly: reporting on the rollout describes the UK's ICO warning publishers on consent as Google activated the capability, underscoring that consent for this specific purpose is expected to be explicit and demonstrable, not inferred from a generic cookie banner.

The liability trap is a stale consent banner that visually offers choices but does not actually map user decisions to the TCF Feature 3 signal. In that state you get the worst of both worlds: you may be transmitting IP for advertising use without properly recorded consent, and your measurement is simultaneously unreliable because the signal is malformed. This is the through-line of 2026's privacy shifts we track in the US state privacy law roundup — consent strings are becoming the operational contract, and a broken string is now both a compliance and a data-quality defect.

The checklist to run this week

First, confirm your CMP is IAB TCF v2.2 compliant and configured to capture consent covering Feature 3, then verify the consent string is actually passed to the Google tag rather than stored and forgotten. Load your site in the target region, accept, and inspect the emitted TCF string to confirm Feature 3 is represented. Second, test the reject path in a staging environment: click reject and confirm the signal genuinely withholds the advertising purpose instead of merely dismissing the banner — a surprising share of setups fail here.

Third, make participation a deliberate decision. For a privacy-forward SaaS brand, choosing not to opt users into IP-based measurement is a legitimate, defensible position — but it should be a choice you make with eyes open about the measurement trade-off, not an accident of misconfiguration. If you decide to stay out, plan to fill the resulting attribution gap with first-party, consented measurement rather than pretending the conversions did not happen. That is the same architectural argument behind moving toward cookieless, first-party acquisition data.

The bigger pattern: identifiers move to signals you do not control

Step back and the direction is unmistakable. As third-party cookies decayed, the industry did not stop identifying users — it shifted to signals that are harder to clear, and IP is the clearest example. Google leaning on an address it already holds, gated behind a consent feature most banners under-specified, is a preview of how measurement will keep evolving: not through new trackers you can see and block, but through new uses of data already in flight, formalized inside consent frameworks.

For SaaS teams the strategic read is the same as it was in June, only sharper. Coupling your core measurement tightly to Google's advertising pipeline means inheriting every one of these changes on Google's timeline, and each one lands as an unannounced shift in your reported numbers unless you are watching closely. Analytics that runs first-party and in aggregate — the reasoning we lay out for GA4 privacy and server-side tracking as an architecture question — is insulated from this specific change because it never depended on Google's IP signal in the first place. Whatever you choose long term, the immediate task is concrete: audit your TCF Feature 3 consent this week, and decide on purpose whether you are in or out.