Since 15 June 2026, the Google Signals toggle no longer controls whether GA4 shares data with Google Ads - the Ads Consent Mode settings (ad_storage, ad_user_data and ad_personalization) do. Note the direction of travel: this change removes a restraint rather than adding one. If you had Signals switched off believing it held data back from Google Ads, it no longer does. The job now is making sure consent is doing that work properly, and lawfully.
Most tracking changes are loud - a tag stops firing, a number goes to zero, someone notices. This one is quiet, and it has been widely misread. On 15 June 2026, Google changed how GA4 decides whether to share data with Google Ads. A lot of coverage framed it as something that breaks conversion tracking. It isn't. It takes a control away, which is a different problem and, for UK and EEA advertisers, a more interesting one.
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 things jointly governed whether GA4 could send Google Ads cookies and identifiers: the Google Signals toggle in GA4 Admin, and Consent Mode. After 15 June, Google Signals no longer plays that role - it now only controls whether your GA4 data is associated with signed-in user information for behavioural reporting. The Ads Consent Mode settings decide the rest: ad_storage (whether ad cookies and IDs can be stored), ad_user_data (whether that data can be used for ads measurement) and ad_personalization (whether it can be used for personalisation and remarketing).
The important consequence is the one most coverage missed: turning Google Signals off no longer stops data flowing into Google Ads. If that toggle was part of how you limited data sharing, you are now relying entirely on consent to do that job.
Under PECR and UK GDPR, storing or accessing non-essential advertising cookies needs prior consent that is freely given, specific and informed - the ICO is explicit on this. Until June, some teams treated the Google Signals toggle as a backstop limiting what reached Google Ads. That backstop has gone. So the question isn't just “is our tracking working” but “is everything now reaching Google Ads properly consented?” If your banner is shaky, the failure mode after 15 June is over-collection, not under-measurement - and that is the more expensive kind of mistake.
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 behaviour hasn't changed on 15 June - Consent Mode has always gated those cookies. So if your banner has never set ad_storage correctly, you were already losing that data before June; this change didn't cause it. It's still worth fixing, but be clear about which problem you're solving.
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 using the Signals toggle as a data-sharing control - that lever has stopped working, and this is the group genuinely affected by the June change.
- Anyone who set it up once and never re-checked - which is most accounts.
A control some teams relied on has gone. Consent is now doing that work on its own.
Source: Google Analytics Help, “Changes to Google Signals” (support.google.com/analytics/answer/17016975).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.
- If you had Google Signals switched off, check whether Ads-attributed data increased around 15 June - that's the expected signature of the control being removed, not a drop.
- Confirm your region defaults are actually being overridden on consent, not left denied.
A server container gives you one place to enforce what leaves your environment, and it loses less data to browser blocking. Be clear on what it doesn't do: consent is still captured in the browser, so a server container cannot make a broken banner valid, and it doesn't remove any of your obligations. It's a control point, not a compliance fix. Whether it's worth the engineering depends on your stack - we've written honestly about that.
If you'd like us to check what your consent setup is actually doing - and whether the data reaching Google Ads is properly consented - 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. The Ads Consent Mode settings - ad_storage, ad_user_data and ad_personalization - now govern it. Google Signals still controls whether your data is associated with signed-in users for behavioural reporting.
Will this reduce my conversions?
Not by itself - this is the most common misreading. The change removes a restraint rather than adding one, so if anything more data reaches Google Ads, not less. A banner that never sets ad_storage to granted will suppress ad cookies, but that was true before 15 June too. Worth auditing, but don't attribute a June drop to this change.
How do I check my setup?
Use Tag Assistant to confirm ad_storage, ad_user_data and ad_personalization update correctly on acceptance, check the _gcl_au cookie behaves as expected, and confirm your EEA and UK region defaults are actually overridden on consent rather than left denied.
Does server-side tracking help with this?
It helps with control and with data loss to browser blocking, but it is not a consent fix. Consent is still captured client-side, so a server container cannot make a broken banner valid and does not reduce your obligations under UK GDPR or PECR.