Google Analytics was quietly fixing your broken consent setup. Until now.

Which Safety Net Is Disappearing?

Right now, two things decide whether your GA4 tag can collect Google Ads cookies and IDs and pass them to your linked Ads account: the Google Signals setting in GA4, and your site's Consent Mode signal. Both are in play. With Signals switched on, Google has had an independent path to collect ad data from signed-in users, and that path has quietly been compensating for consent mode setups that were weak, half-finished, or never properly wired up.

From June 15, 2026, that second gate is removed. Consent Mode's ad_storage becomes the only thing Google looks at for this data flow. If your ad_storage signal is wrong, misconfigured, or never fires, there's no longer a second mechanism papering over it.

The accounts most at risk are the ones where someone switched Google Signals on in GA4 two years ago and assumed the job was done. It was propped up. The prop is being removed.

Here's the part most people miss. The June 15 change is specifically about the advertising data your GA4 tag collects and feeds to your linked Ads account: your remarketing audiences, your cross-device signals, your imported GA4 conversions. That's what loses its second gate. If your ad_storage signal is broken, that flow degrades the moment Signals steps aside.

But the same broken ad_storage has almost certainly been undermining the rest of your setup already. Enhanced Conversions and Customer Match don't depend on Google Signals, they're gated by Consent Mode directly, and have been all along. So if June 15 exposes a faulty ad_storage signal in your GA4 flow, treat it as your cue to check everything else ad_storage touches. The deadline isn't what breaks Enhanced Conversions. It's what reveals it was never set up right.

What Are You Actually Passing?

Don't trust this dataLayer dump though, consent state isn't stored there in a way you can reliably read. Use Google Tag Assistant instead.

Go to tagassistant.google.com, connect your site, and load a page. Click into any Google tag that's fired, your Google Ads conversion tag or GA4 config, and open its Consent section. Tag Assistant shows you the actual consent state Google saw when the tag fired: the default state, and whether a user choice updated it. You're looking at ad_storage specifically.

If ad_storage shows 'denied' on default and never moves to 'granted' after you accept the banner, your CMP isn't wired to Consent Mode. If analytics_storage moves but ad_storage stays frozen, you've got the partial setup that's about to cost you on June 15.

Check what Enhanced Conversions is actually receiving. In GTM Preview mode, look for the Enhanced Conversions tag firing. If you see hashed email data passing through but no ad_storage consent signal, you're sending personal data without proper consent gates.

Most setups I audit fail this test. The consent infrastructure was bolted on after the tracking, not built from the foundation up.

Which Accounts Are Most at Risk?

Three configurations are exposed on June 15:

Google Signals on, no Consent Mode at all. Someone ticked the box in GA4 two years ago and never implemented Consent Mode on the site. Right now your GA4-sourced audiences and conversions are riding on the Signals path. After June 15 they ride on ad_storage, and you're not sending an ad_storage signal.

What happens next is the genuinely uncertain bit. Historically, no Consent Mode meant tags defaulted to granted, so data flowed. The direction of travel, though, is Google treating the absence of an explicit signal as a restriction, and Google hasn't spelled this out either way. Treat this as the scenario to test, not assume. Either way, leaving the single most important control unconfigured is not where you want to be on the 15th..

Partial consent mode with missing ad_storage signals. Your GTM fires analytics_storage correctly but never sets ad_storage. GA4 reads the Google Signals toggle and assumes consent for advertising features. After June 15, no ad_storage signal means no Google Ads data.

Enhanced Conversions running without proper consent gates. The worst configuration. You're hashing and sending email addresses, but your consent mode is incomplete. After the change, you may be sending personal data without documented consent, which regulators are watching for.

How Do You Fix Borrowed Consent Architecture?

There's no clever workaround here. The fix is to make consent the thing that decides whether a tag fires, instead of an afterthought bolted on once the tracking already worked. That's the whole job, and most setups have it backwards.

Backwards looks like this: the tags were built first, they fired, everyone moved on, and the cookie banner got wired in months later as a compliance tickbox. So the banner collects a choice and the tags fire regardless. The order is wrong, and June 15 is what makes the wrong order finally cost you.

Getting it right is an ordering problem before it's a configuration one. Consent has to be established before any measurement tag runs, your banner's choices have to actually reach the data layer as ad_storage and analytics_storage rather than just styling a cookie notice, and the advertising tags, Enhanced Conversions and Customer Match especially, have to treat a denied ad_storage as a hard stop rather than a suggestion. If an Enhanced Conversions tag can still fire when ad_storage is denied, you haven't got a consent setting to tune, you've got a broken architecture to rebuild.

The detail that catches people out is the default. Consent Mode starts from denied and waits for the user to upgrade it, which means a setup that "works" in testing because you always accept the banner can be completely broken for everyone who doesn't. Test the rejection path, not the acceptance path. The acceptance path almost always works. It's the denial that tells you whether the wiring is real.

Why Does This Matter Beyond Compliance?

Compliance is the floor, and it's the least interesting reason to fix this.

The more useful reason is that consent isn't just a gate you pass through, it's a filter on the data quality going into your bidding. When ad_storage is wired properly, the conversions reaching Google Ads come from users who actually consented, which is a cleaner signal than the half-consented mush a broken setup feeds in. Google's models train on what you send them. Send noise and the bidding learns from noise.

So the accounts that sort this before June 15 aren't just dodging a regulatory headache, they keep feeding clean signal while the borrowed-consent accounts watch their numbers drift, slowly enough that nobody links the drift back to a toggle they forgot about two years ago. That's the trap. There's no error message on the 15th. There's just a measurement system that quietly gets less reliable, and a team that spends the next quarter blaming the algorithm.