Consent Mode v2 and the June 2026 Google Signals Sunset
On June 15, 2026, ad_storage becomes the sole control over advertising data in Google's stack. Here is what the Google Signals sunset changes for developers — and why the whole machinery is something cookie-free analytics never had to build.
On June 15, 2026, Google removes Google Signals as an independent control over advertising data. After that date, the ad_storage consent signal your Consent Management Platform sends becomes the single gate that decides whether visitor-level data reaches Google Ads. If your CMP is misconfigured, there is no longer a server-side setting in Analytics to catch the mistake.
This is a quiet but significant change. It moves the entire burden of consent correctness onto a JavaScript layer that runs in the visitor's browser, before any data is collected. It is worth understanding exactly what that layer does, because it is the precise complexity a cookie-free design never incurs.
What Consent Mode v2 actually is
Consent Mode v2 is Google's framework for telling its tags whether they are allowed to use storage. It is not a consent banner — it is the wiring between your banner and Google's tags. Your CMP sets four signals:
gtag('consent', 'default', {
ad_storage: 'denied',
analytics_storage: 'denied',
ad_user_data: 'denied',
ad_personalization: 'denied',
});
ad_storagecontrols advertising cookies, device identifiers, and visitor-level data sent to Google Ads.analytics_storagegoverns the Analytics cookie that assigns a client ID.ad_user_datapermits hashing first-party data such as email for Enhanced Conversions.ad_personalizationdecides whether Analytics data feeds personalized ad targeting.
When the visitor accepts, your CMP fires a second call updating the relevant signals to granted. Everything downstream depends on that update arriving correctly.
Basic vs. advanced, and why advanced exists
There are two implementation modes, and the difference matters legally.
In basic mode, Google's tags do not load at all until consent is granted. Deny, and nothing is sent.
In advanced mode, the tags load immediately with all signals defaulted to denied, and they send cookieless pings to Google anyway — a request with no identifiers, no client ID, and no stored state. Google uses the volume of those pings, plus the behavior of the minority who do consent, to model the conversions it cannot directly observe.
Advanced mode exists because consent rates are low and advertisers want their numbers back. But a cookieless ping sent before consent is still a transmission of data to a third party, and the EDPB's technology-neutral reading of ePrivacy Article 5(3) does not exempt requests just because they omit a cookie. Modeled conversions also require a minimum pool of consented sessions to produce anything reliable, so small sites get noise.
What the June 15 sunset removes
Until now, Google Signals acted as a second gate. You could leave it off in Analytics to restrict ad data sharing regardless of what Consent Mode reported. That backstop is gone.
After the sunset:
- Google Ads stops reading Analytics-side settings and relies exclusively on the Consent Mode signals your CMP sends.
- Google Signals is narrowed to Analytics-only use — associating sessions with signed-in users inside GA4.
- IP addresses continue to be collected and are encrypted before being forwarded to linked Ads accounts, where the destination account's settings take over.
The practical effect: a single misfiring gtag('consent', 'update', ...) call — a race condition, a CMP that loads after the first tag, a deploy that drops the default state — now silently sends data you intended to gate. Under GDPR that is processing without a lawful basis, and the removal of the server-side safety net makes it harder to argue the exposure was contained.
This is also, per recent guidance, a material change to how advertising data is shared. For sites with EU visitors, that can trigger a notification obligation to users — a review worth doing before the deadline, not after.
The complexity that never had to exist
Step back and look at what a compliant Consent Mode v2 setup requires: a CMP, four consent signals, default states, update calls ordered correctly against tag load, an advanced-vs-basic decision with legal consequences, modeled conversions that only work above a traffic threshold, and now a single point of failure with no backstop.
All of that machinery exists to keep using identifiers — the client ID, the advertising cookie, the hashed email — while staying on the right side of consent law. Remove the identifiers and the entire apparatus collapses into nothing.
A cookie-free tracker has no ad_storage to gate because it sets no advertising storage. It has no client ID to deny because identity is a one-way SHA-256(IP | UA | SALT_SECRET | YYYY-MM-DD) hash computed in memory at the edge and never reversed. The raw IP and User-Agent are used only to compute that hash; D1 stores the hash, not the inputs. There is no consent signal to misfire because there is nothing to consent to under Article 5(3) — the access to the visitor's device is strictly necessary to deliver the page, and the under-2 KB script to /collect reads no storage at all.
The June 15 sunset is a good moment to ask a sharper question than "is my Consent Mode configured correctly." Ask why you are running a consent state machine to measure pageviews in the first place. The conversions Google models from cookieless pings are an estimate of data you were never allowed to collect. Counting what actually happened, without an identifier, was always the simpler system.
Comments
Loading comments…