Since 15 June 2026, the Google Signals toggle no longer controls whether GA4 shares data with Google Ads - a single Consent Mode parameter, ad_storage, does. If your consent banner isn't reliably setting ad_storage to granted when a user accepts, GA4 stops passing the identifiers Google Ads needs and your conversions can drop without any obvious error. This is a quiet break worth checking now.
Most tracking failures are loud - a tag stops firing, a number goes to zero, someone notices. This one is quiet, which is what makes it dangerous. On 15 June 2026, Google changed how GA4 decides whether to share data with Google Ads, and if your consent setup was already a little shaky, the effect is a slow leak rather than an alarm.
Auditing exactly this - whether consent is flowing correctly and where signal is leaking - is day-to-day work for our analytics team.
What actually changed
Before 15 June, two separate controls jointly governed whether GA4 could send Google Ads cookies and identifiers: the Google Signals toggle in GA4 Admin, and the ad_storage Consent Mode parameter. After 15 June, Google Signals no longer plays that role. A single parameter - ad_storage - now decides.
When ad_storage is granted, full ad measurement works. When it's denied, tags stop setting advertising cookies like _gcl_au, stop forwarding device identifiers, and stop passing visitor-level data to Google Ads. That's by design and it's the right thing for privacy - the risk is when ad_storage is accidentally denied because your banner never sets it to granted properly.
Who's exposed
- Broken or partial Consent Mode v2 - the banner loads but never updates ad_storage on acceptance.
- Region-config gaps - defaults set for the EEA and UK that never get overridden when a user consents.
- Custom banners that fire analytics_storage but forget ad_storage.
- Anyone who set it up once and never re-checked - which is most accounts.
A small config gap that used to be masked by Google Signals is now fully exposed.
Source: Google Analytics announcements, 2026; compiled by The Digital Lighthouse.How to check, this week
- Open Tag Assistant and confirm ad_storage moves to granted the moment a user accepts - not just analytics_storage.
- Check that _gcl_au is being set on consent.
- Compare Google Ads conversions week-over-week around mid-June. A step down that lines up with the 15th is your smoking gun.
- Confirm your region defaults are actually being overridden on consent, not left denied.
Server-side Consent Mode enforces consent more reliably and loses less data to browser blocking. It doesn't remove your obligations, but it does make a change like this far less likely to quietly break you - one of the genuine reasons server-side is now closer to a baseline than an upgrade.
If you'd like us to check whether this change has quietly cost you conversions - and fix it if it has - that's a fast, high-value strand of a strategic review.
Frequently asked questions
What changed in GA4 on 15 June 2026?
Google removed Google Signals as a control over whether GA4 shares data with Google Ads. A single Consent Mode parameter, ad_storage, now governs it - when denied, GA4 stops passing the cookies and identifiers Google Ads relies on.
Will this reduce my conversions?
It can, if your consent banner doesn't reliably set ad_storage to granted when users accept. In that case GA4 stops passing ad identifiers and Google Ads conversion tracking degrades, often without an obvious error.
How do I check my setup?
Use Tag Assistant to confirm ad_storage moves to granted on acceptance, check the _gcl_au cookie is set, and compare Google Ads conversions week-over-week around 15 June for a step change.
Does server-side tracking help with this?
Yes. Server-side Consent Mode enforces consent more reliably and loses less data to browser blocking, making this kind of quiet break far less likely - though it doesn't remove your consent obligations.