If your Google Ads conversions fell off a cliff in the second half of June and nobody touched the account, start with consent mode. On June 15, 2026, Google retired the Google Signals setting as a control over GA4-to-Google-Ads data flow. From that date, the ad_storage consent parameter is the only gate. If your banner defaults it to denied and never updates it properly, ads data silently stops flowing — conversions, audiences, and Smart Bidding signals all at once. There is no error message, because from Google's side everything is working exactly as instructed.
What actually changed on June 15, 2026
Before the change, Google Signals functioned as a second path. Even when consent signals were incomplete or a banner was half-wired, Signals could still carry advertising data from GA4 into Google Ads. It was an accidental safety net, and a lot of accounts were quietly relying on it without knowing.
That net is gone. Google Signals now only controls behavioral reporting features inside GA4 — demographics, interests, cross-device metrics. It no longer has any say over whether Google Ads receives your data. ad_storage does, and nothing else does.
The practical consequence: your consent management platform is now a paid-media system. Whoever installed your cookie banner two years ago, probably a web developer working from a compliance checklist and not a media brief, now controls whether your Smart Bidding gets fed.
Two opposite failures are showing up in audits right now, and they are worth naming because they look nothing alike:
| Failure | What it looks like | Who it hits |
|---|---|---|
| Under-collection | Conversions, audience sizes, and remarketing lists drop sharply after mid-June. Smart Bidding gets erratic. | Accounts that leaned on Google Signals while ad_storage defaulted to denied |
| Over-collection | Nothing visibly breaks, but ads data is now flowing where the privacy policy says it shouldn't | Accounts with Signals disabled whose banner still sends ad_storage=granted |
The second one is more dangerous, because nothing in your dashboard flags it. You only find it by looking.
Why the drop is invisible until you look for it
We audit tracking for a living, and the pattern here is the same one we wrote about in why your Google Ads and GA4 numbers don't match: the platform reports confidently on the data it received, and says nothing at all about the data it never got.
A misconfigured consent banner does not produce an error. It produces a smaller, cleaner-looking number. Campaigns look like they got worse. Someone pauses the "underperformers." Budget shifts to a channel whose tracking happens to still be intact. Two months later the account has been restructured around a measurement artifact.
One organization that hit a consent mode misconfiguration around the cutover reported conversions dropping roughly 90% overnight, with only about 40% of the lost attribution recoverable through modeling. That is the extreme case, but the shape is right: the loss is instant, and the recovery is partial at best.
The 10-minute audit: read the gcs parameter yourself
Skip Tag Diagnostics for this. It reports on a 48 to 72 hour lag, which is useless when you are trying to confirm a fix you shipped ten minutes ago. Read the network request directly.
- Open Chrome DevTools, Network tab, filter for the Google collect requests.
- Reject all consent on the banner. Reload. Find the
gcsparameter on the outgoing request and write down its value. - Clear cookies, accept all consent, reload, and read
gcsagain.
The gcs value encodes the granted/denied state of storage consent — G111 for granted, G100 for denied, with G1-- meaning no consent state has been set at all. You don't need to memorize the encoding. You need the two values to be different. If accepting and rejecting produce the identical string, your CMP is not updating your tags, and one of those two states is silently wrong.
While you're in there, check two more things:
- The default call fires first. The consent default must execute before any measurement tag loads. If a tag beats it, that tag ran with no consent state.
- All four parameters are present. Consent mode v2 requires
ad_storage,ad_user_data,ad_personalization, andanalytics_storage. The last two were added in November 2023, and banners installed before that often still flip only the original two. This is the single most common miss we find — a banner that reads as compliant and is quietly withholding half the signal.
"But all my traffic is in the US" — does this still apply?
Usually, yes. This is the objection we hear most from local and regional advertisers, and it comes from a fair assumption: consent mode was built for the EEA and the UK, so a Dallas HVAC company with zero European traffic shouldn't care.
The problem is that consent mode isn't scoped to a region by default — your setup is. Most consent management platforms ship with a region setting, and plenty of installs either apply the banner globally or were configured for the strictest case and never revisited. If your CMP is sending ad_storage=denied by default to every visitor regardless of geography, and there's no geographic override, then a Texas visitor is being treated exactly like a German one. Before June 15 that was survivable. Now it's the whole gate.
There's also a second, quieter path: US state privacy laws. If your CMP was updated for California, Colorado, or Texas opt-out requirements at some point, it may already be flipping consent parameters on domestic traffic without anyone framing it as a "consent mode" change. Check the actual parameter values on a domestic page load rather than reasoning about which regulations apply to you. The network tab settles it in ten seconds; the legal argument takes a week and still doesn't tell you what your tags are doing.
Basic vs. advanced mode decides how much you get back
This is the part most teams never made a real decision about, and it's the one with money attached.
Basic consent mode blocks Google tags from loading until the user consents. A rejection produces nothing — no ping, no signal, no trace. Advanced consent mode loads the tags immediately and sends cookieless pings carrying no identifiers when consent is denied.
That difference is the whole ballgame for modeling. Google can only estimate the conversions you lost if it received something. On basic mode, rejected users are invisible, so there is nothing to model from and your reported conversions are simply lower than reality by whatever your rejection rate happens to be.
And modeling is not automatic even on advanced mode. Google applies minimum daily volume thresholds across a trailing window before it will model anything at all. Plenty of local and mid-market advertisers — exactly the profile of most businesses we work with around Dallas — never hit them. Check whether modeled conversions actually appear in your reporting before assuming the platform is covering for you. A lot of people are quoting recovery percentages from case studies for accounts ten times their size.
Stop making the browser your system of record
Here's the strategic read, and it's the same conclusion we reached after iOS 26 started stripping click IDs: every one of these changes points the same direction. Browser-side measurement keeps getting narrower, and each fix buys you less time than the last one.
Fixing consent mode is necessary. It is not a strategy. The accounts that shrugged through June are the ones already sending conversions server-side from their CRM, where the event is a real qualified lead or a closed deal — not a cookie that survived a banner.
That means, in rough order of payoff:
- Server-side conversions. Route qualified events from your CRM through the Conversions API and server-side GTM instead of relying on the pixel firing in a browser you don't control.
- Offline conversion import. Push closed-deal revenue back into Google Ads so bidding optimizes toward money rather than form fills.
- An independent source of truth. We use Hyros for attribution precisely so that when a platform changes how it counts, we can tell the difference between a reporting change and a business change — within a day, not a quarter.
Do that and consent mode goes back to being a compliance concern instead of a revenue one. Which is where it should have been all along.
The bottom line
Google didn't break your tracking on June 15. It removed a fallback most people didn't know they were using, and left one switch in charge. If your conversions dropped and the account didn't change, the odds strongly favor consent mode over anything you did.
Go read the gcs parameter. Ten minutes, two page loads, one comparison. Either the values differ and you can move on, or they don't and you just found the reason your Q3 numbers look wrong.
Not sure whether your drop is real or a tracking artifact? We'll audit your consent mode setup end to end, confirm ad_storage is gating correctly, quantify how much of the drop is reporting versus reality, and wire qualified conversions server-side so this stops being fragile. Get a free automation audit and we'll show you exactly where the signal is leaking.