Google restructured how GA4 and Google Ads share user data on June 15, 2026. Before that date, two separate controls jointly governed whether GA4 forwarded advertising identifiers and cookies to Google Ads: the Google Signals toggle in GA4 Admin and the Consent Mode ad_storage parameter. After June 15, only ad_storage controls the Google Ads data path. Teams that assumed the Signals toggle was a kill switch for advertising data need to audit their setups now.
What changed with GA4 Consent Mode on June 15?
Before June 15, 2026, disabling Google Signals in GA4 Admin would block GA4 from sending advertising identifiers and cookies to Google Ads, regardless of ad_storage state. After June 15, that gate is gone. The ad_storage Consent Mode parameter is now the sole control for Google Ads data transmission: when ad_storage='granted', GA4 sends advertising data to Google Ads even if the Signals toggle is turned off.
Google Signals is not removed. It still associates sessions with signed-in users for Analytics-internal purposes — cross-device journey stitching, demographics reporting, and interests data inside GA4. The change is a decoupling, not a deprecation. Signals now governs Analytics behavioral reporting exclusively. It no longer gates anything on the advertising side.
Who is affected and how
The practical blast radius depends on why a team turned Google Signals off.
If Signals was disabled to satisfy a DPO review that treated it as an advertising-data control, that configuration no longer does what the review assumed. Advertising identifiers, remarketing audience membership, and conversion signals will flow to Google Ads whenever ad_storage='granted', regardless of the Signals state. For properties running Basic Consent Mode — where ad_storage defaults to granted and modeling fills in the rest — this means the Signals toggle was already providing only cosmetic protection after June 15.
The affected features are specific. With ad_storage='granted', Google Ads receives:
- Cross-device recognition — signed-in user identifiers used to stitch sessions across devices for remarketing
- Remarketing audience membership — segment qualification signals exported from GA4 to Google Ads
- Conversion import — GA4 goal completions imported into Google Ads for Smart Bidding
None of those require the Signals toggle to be on after June 15. They require only a granted ad_storage.
The before / after in one table
| Scenario | Before June 15 | After June 15 |
|---|---|---|
Signals ON + ad_storage='granted' | Ads data flows | Ads data flows |
Signals OFF + ad_storage='granted' | Ads data blocked | Ads data flows |
Signals ON + ad_storage='denied' | Ads data blocked | Ads data blocked |
Signals OFF + ad_storage='denied' | Ads data blocked | Ads data blocked |
The only configuration that reliably blocks Google Ads data after June 15 is ad_storage='denied'. The Signals toggle is irrelevant to that outcome.
What to check today
Three concrete checks apply to most GA4 implementations.
1. Verify your ad_storage default state. Open Google Tag Manager and find the Consent Initialization trigger firing your consent configuration tag. Check whether the default consent state sets ad_storage to denied before the user interacts with your CMP. Properties that run Basic Consent Mode — where defaults are granted — should treat this as urgent. The European Digital Omnibus proposal, which would move cookie consent governance into GDPR Articles 88a and 88b and require single-click refusal, makes this even less negotiable for EU-facing properties.
2. Audit your CMP’s consent update call. Confirm that when a user declines advertising consent, your CMP fires gtag('consent', 'update', { ad_storage: 'denied' }) before any Google tag fires. The old assumption — that Signals-off provided a backstop — is no longer valid.
3. Update any privacy-policy or DPA-documentation language that implied Google Signals governed advertising data. Statements such as “we have disabled Google Signals to prevent data sharing with Google Ads” are now factually incorrect. The controlling mechanism is Consent Mode ad_storage, and your policy should say so.
What this means for GA4 measurement going forward
Google is consolidating advertising controls into Consent Mode and pulling them out of product-level toggles. The same pattern appeared earlier this year when GA4 added the AI Assistant acquisition channel as a server-side default — Google applying a single, property-wide change without requiring per-account configuration. The June 15 Consent Mode change is the inverse: removing a dual-control system where two settings could both block the same data pathway, consolidating authority into the dedicated consent signal.
For teams running Advanced Consent Mode with proper ad_storage='denied' defaults, the practical impact is zero — their Signals toggle was never load-bearing on the ads side. For teams relying on the Signals OFF state as a compliance measure, the gap opened on June 15. Consent Mode configuration is now the only document your legal and data teams need to review when auditing Google Ads data flows.
Secondary reporting from Piwik PRO and UniConsent corroborates the change timeline and underscores the compliance gap for properties still using the Signals toggle as their primary advertising-data control. Google documented the change through its Google Analytics consent and Google Signals settings.