Until 15 June, two control layers governed what got collected on a site. First, the user’s cookie banner choice, expressed through Consent Mode’s ad_storage and analytics_storage signals. Second, sitting on top of linked GA4 and Google Ads accounts, the Google Signals data collection toggle within GA4 Admin’s Data Collection tab.

From 15 June, only the first layer matters for ad data. Google Signals no longer governs what flows from GA4 into Google Ads. It will only affect what shows up in GA4 reports: cross-device user counts, signed-in audience features, that kind of thing.

That’s the entire change. One admin lever narrowed.

This list is longer, and it’s the more important list, because it’s the bit most coverage will skip past.

The Consent Mode v2 specification stays as it is. The four signal names (ad_storage, ad_user_data, ad_personalization, analytics_storage) and their meanings: unchanged. The gtag(‘consent’, …) API: unchanged.

The semantics of analytics_storage: unchanged, which means GA4, Hotjar, Microsoft Clarity, Matomo, and Plausible all behave exactly as they do today.

The user-facing cookie banner: unchanged. Nobody sees a different banner on 16 June. Regional defaults: unchanged. EU stays opt-in. US and AU stay opt-out.

Compatibility with non-Google tags: unchanged. Meta Pixel, LinkedIn Insight Tag, TikTok Pixel, all the rest, behave as today. IAB TCF v2.2 and v2.3 implementations: unchanged. Server-side GTM flows: unchanged.

If you find yourself reading vendor copy that suggests a re-implementation, a banner update, or a customer-facing communication, the vendor is selling you the change as bigger than it is.

Five categories, ordered from least to most affected.

Sites with a certified CMP and EU opt-in defaults. Zero change. ad_storage was already denied by default. The user’s choice already governed everything from page load.
Sites with a CMP and US or AU opt-out defaults. Zero change. Cookies fired by default in those jurisdictions; the cookie banner correctly governed the user-overridden case. Same on 16 June.
Sites with GA4 only, no Google Ads link. Outside the announced scope. Behavior governed by Signals and the GA4 APIs, same as today.
Sites with Google Ads but no GA4. Outside the announced scope. There was never a Signals lever to begin with.
Sites with no CMP, GA4, and Ads linked, Google Signals turned OFF as a backend privacy gesture. Material change. The Signals-off lever stops blocking Ads-bound data. From 15 June, these sites emit ad cookies they previously did not. If they sit in EU/EEA jurisdictions, that’s a regulatory exposure they didn’t have before.

That last category is the only one materially affected. It’s not nothing. There is a real population of sites that used Google Signals OFF as a CMP substitute, and those sites have a problem on 15 June. But it’s a narrower population than the announcement framing suggests.

Every certified CMP on the market already routes the user’s Marketing choice to ad_storage, ad_user_data, and ad_personalization, and the user’s Statistics choice to analytics_storage. Cookiebot, OneTrust, Iubenda, Usercentrics, Termly, Klaro: all of them.

They’ve done this since Consent Mode v2 became mandatory on 6 March 2024.

Which means the 15 June change is industry table stakes. Any CMP that wasn’t doing destination-specific signal routing wasn’t certified. Any vendor about to send their customer base a “we’re ready for the June 15 change” email is pitching a feature every certified competitor also has, and the savvy buyer reads that as trying to spin baseline functionality as differentiation.

The change is real for end-state behavior on un-CMP’d sites. It is not real as a CMP differentiator.

The change in isolation is small. The sequence it sits in is not.

Looking at Google’s last four years:

• 2023/24: Consent Mode v2 launched, splitting ad_user_data and ad_personalization from ad_storage. Mandatory from 6 March 2024. The legal substrate for sending hashed personally-identifying information to Google.
• 2024: Heavy push on Enhanced Conversions. Behavioural conditioning of advertisers to transmit hashed email and phone alongside conversion events.
• 2024/25: Expanded reliance on _gcl_aw and first-party storage for click-ID persistence under ITP and Chrome cookie restrictions. A bridge that buys time but doesn’t solve the underlying problem; cookies are dying.
• 2025/26: Enhanced Conversions for Leads. Hashed name, email, and phone surfaced as primary conversion identifier alongside GCLID, not yet replacing it.
• 15 June 2026: Consent Mode becomes the sole authority for Google Ads data on linked GA4-GAds accounts.

Every step is consistent with one trajectory: away from cookie-and-click-ID-based ad measurement, toward measurement keyed to hashed personally-identifying information.

The hypothesis worth holding is that the 15 June change is infrastructure preparation for a 2027 to 2029 shift in which the consent-banner conversation moves from “block cookies” to “control hashed-PII transmission.” That’s not announced. It’s not in any public Google document. It’s a trajectory-consistent inference.

It’s also not certain. The Court of Justice of the European Union ruled in EDPS v. SRB on 4 September 2025, introducing a recipient-perspective test for pseudonymized data. If hashed identifiers Google cannot reverse aren’t treated as personal data in Google’s hands, a piece of the legal scaffolding under the hypothesis weakens. The trajectory still makes operational sense, but the regulatory force pushing it forward isn’t as strong as it looked in early 2025.

So: plausible hypothesis, worth tracking, not yet evidenced strongly enough to bet a roadmap on.

The next weeks will produce a lot of CMP vendor copy framing 15 June as a major event their product handles correctly. Most of it will be technically true and strategically empty. The hard question is not whether your CMP routes Marketing to ad_storage.

Every certified CMP does that. The hard question is what your stack does in 2027 or 2028, when the regulatory conversation moves to hashed-PII granularity. That question doesn’t get answered by a 15 June readiness email.