On June 15, 2026 — seven days from this post — Google is severing the link between two settings that have shared one job for years. GA4's Google Signals toggle and Google Ads' ad-identifier collection. Until that date, flipping Google Signals OFF in your GA4 property was an effective override: even if your on-site Consent Mode v2 implementation was leaky, the GA4 setting blocked Google Ads from associating site visitors with signed-in user data. From June 15, that override disappears. Google Ads stops reading the GA4 setting and listens exclusively to ad_storage signals sent from your site.
For B2B SaaS teams, this matters more than the size of the change suggests. Most SaaS sites set Google Signals OFF once in 2022 or 2023, documented it in a compliance log, and never thought about it again. Many also bolted Consent Mode v2 on hastily in early 2024 with default signals that contradict the GA4 setting. The two have been in tension for two years, and the GA4 setting was winning. On June 15, the Consent Mode v2 signal starts winning instead — which means whatever your CMP is actually sending becomes the source of truth, whether it's correct or not.
What's actually changing on June 15
The mechanic is narrow and worth stating precisely. Google Ads currently consults two pieces of information when deciding whether to collect a Google-account-linked identifier for a site visitor: the page-level ad_storage consent signal sent via gtag, and the property-level Google Signals toggle inside GA4. If either one says no, Google Ads does not collect. After June 15, the GA4 toggle stops being consulted for that decision. As Launch Online put it, "From June 15, Google Ads will stop looking at your GA4 dashboard and start listening exclusively to the code on your website."
The GA4 Google Signals toggle still exists — it just no longer governs Google Ads. After June 15 it controls whether GA4 itself associates analytics data with signed-in user information for behavioral reporting inside Analytics, which is a much narrower job. Cross-device reporting in GA4, demographic insights from Google accounts, and the signed-in user reporting in Analytics still depend on it. Google Ads conversion tracking, audience building, and Smart Bidding identifier collection do not. The two products had a shared switch for years; now they each get their own. That sounds tidy on paper. In practice, the shared switch was load-bearing on more SaaS sites than anyone has admitted.
Why the GA4 backstop existed in the first place
Consent Mode v2 launched in March 2024 with an aggressive rollout timeline and an even more aggressive default-deny behavior in regions covered by Google's DMA enforcement. Many SaaS teams hit the deadline by shipping a minimal CMP integration, accepted the defaults, and moved on. That left a real risk: the page-level signals from a hastily configured CMP could be wrong — too permissive in some sessions, too restrictive in others — and the team had no quick way to tell. So most teams kept the Google Signals toggle OFF in GA4 as a second line of defense. If Consent Mode v2 was misfiring on the page, GA4 would still refuse to let Google Ads associate the visit with a signed-in user. It was crude but effective.
The crudeness was the point. A property-level toggle is hard to get wrong. There is one place to set it, one auditor to check it, one compliance log to reference. Page-level ad_storage signals, by contrast, depend on the CMP firing the right call at the right time on every page of the site, which depends on consent banner UX, on geo-detection, on per-session cookie state, and on whether the engineer who wired it understood the difference between default and update calls. Any one of those can break silently. The GA4 toggle absorbed the breakage. From June 15, it stops absorbing it. As Piwik PRO notes, the backstop that organizations used as a "privacy insurance policy" disappears, and the page-level implementation has to carry the full weight on its own.
The four ways B2B SaaS sites are silently affected
The change creates four distinct failure modes depending on how each site configured the two controls. Most B2B SaaS accounts fall into one of them. The first is the over-collection failure: GA4 Google Signals was OFF, Consent Mode v2 defaults to ad_storage=granted, and there is no real consent banner on the relevant pages. Until June 15, the GA4 setting was suppressing collection. From June 15, the page-level granted signal wins. The site silently starts associating visitors with signed-in user identifiers when it shouldn't. This is a compliance gap, not an attribution gain — the data was being suppressed for a reason.
The second is the under-collection failure: GA4 Google Signals was ON, but Consent Mode v2 defaults to ad_storage=denied and the CMP never sends an update call when consent is granted. Until June 15, the GA4 setting effectively turned this on across the property. From June 15, the page-level denied signal wins and Smart Bidding loses identifier collection that it had been getting for two years. Conversion volume drops not because of GA4 but because the page-level signal has been wrong all along and the GA4 setting was masking it. The third is the mid-cycle attribution loss: an Enhanced Conversions for Leads setup that depends on consistent identifier collection across a 60-90 day B2B sales cycle now sees a regime change mid-cycle. The fourth, and most common: nobody on the team remembers what Google Signals is set to, the answer matters for the next 7 days, and the documentation is stale.
Your 7-day audit: Consent Mode v2 + ad_storage signals
The audit has three checks. Each takes 10-15 minutes. Start with the GA4 toggle: open your GA4 property → Admin → Data Collection and Modification → Data Collection. Note whether Google Signals is currently ON or OFF. Write it down with the date. This is the setting that is about to stop controlling Google Ads — knowing what state it's in lets you predict the direction of any silent change on June 15. If it's been OFF for years and your CMP is permissive by default, expect identifier collection to increase next week.
Second, audit what your CMP actually sends. Open the site in an incognito window, open DevTools → Network, filter to google-analytics.com and googleadservices.com, and load a page. Look for the gtag('consent', 'default', …) call and the value of ad_storage. If it shows granted on a page where users haven't interacted with a consent banner, that's your over-collection risk. If it shows denied and never updates after you click "Accept" on the banner, that's your under-collection risk. Either is fixable in a day if you find it now. Both turn into compounding noise if you find it after June 15. Third, cross-check the implications against your conversion tracking setup and whether any of your primary conversion events depend on Enhanced Conversions match rates — those are the events most sensitive to identifier-collection regime changes.
Smart Bidding fallout: what happens if you do nothing
Doing nothing is a valid choice if your CMP implementation has been correct all along. The risk is that you don't know whether it has been. Smart Bidding strategies — Target CPA, Maximize Conversion Value, Target ROAS — depend on a stable signal of which clicks convert. If the identifier-collection regime shifts on June 15 and you didn't anticipate it, the strategy doesn't know whether the shift means "real conversion behavior changed" or "the signal got cleaner / noisier." It assumes the former, adjusts bids accordingly, and you spend a learning period (often 7-14 days for established campaigns) recalibrating.
For B2B SaaS specifically, the highest-risk campaigns are the ones running Enhanced Conversions for Leads with offline imports of MQL / SQL / Closed-Won events. Those depend on consistent GCLID-to-identifier stitching across the sales cycle — a regime change on June 15 puts every deal currently in pipeline at risk of attribution drift. If you have a $500K+ deal closing in late Q3 2026, the click that started it might re-attribute. The fix is not panic; it's pre-flighting the audit above so you know what changes and what doesn't. We covered the broader pattern of how attribution gets quietly wrong in our piece on Google Ads attribution models — the same dynamics apply here, just compressed into a one-week window with a hard external deadline.
After June 15: the new control loop for B2B SaaS ad data
Once the transition is done, the long-term picture is actually cleaner. There is one control: Consent Mode v2 ad_storage, set from the page, surfaced from your CMP, auditable in DevTools. You can stop maintaining two independent compliance logs (one for GA4, one for the CMP) and consolidate to one. Cross-product behavior becomes predictable because both Google Ads and GA4 derive their consent state from the same page-level source. That predictability is worth the one-week scramble — many SaaS teams have been carrying a slow compliance bug for two years because the dual-control system made it easy to hide.
The behavior change to internalize: from June 15, every meaningful decision about ad-identifier collection lives in your CMP configuration. That means engineering owns the consent stack the way analytics or growth used to. Get the CMP audit on the same rotation as conversion-tracking audits and the broader Google Ads mistake list for B2B SaaS — the next change like this one will come faster than the dual-control system trained anyone to expect. If you want a second pair of eyes on your specific implementation before June 15, the audit covers Consent Mode v2 signal verification as part of the tracking pass.