Picture a reasonably common support ticket: a remarketing audience that has quietly shrunk over the summer, spend that hasn't moved, and nobody on the team who can point to a single thing they changed. If that sounds familiar for your own account, the likely answer is a setting nobody actually touched at all. Google's Consent Mode v2 change on June 15, 2026, quietly took over a control a lot of accounts used to rely on.
That is the pattern worth knowing about if you run an ecommerce store and have not specifically checked this since June. The change did not send an email that most marketing teams would have read as urgent. It did not throw an error in GA4 or Google Ads. It just changed which signal decides whether Google Ads gets the data it needs, and a store whose consent setup was slightly off before the change is probably more off now.
- Before June 15, 2026, the Google Signals setting in GA4 and the ad_storage consent parameter jointly controlled what reached Google Ads.
- After that date, Google's own Analytics Help documentation confirms ad_storage alone governs Google Ads data, including data shared by Google Analytics, and Google Signals lost its backstop role.
- A denied ad_storage signal still blocks advertising cookies and identifiers, which pushes Google Ads onto statistical conversion modeling instead of counted conversions.
- The failure is silent: no error, no warning, just a quieter conversion count and a smaller remarketing audience that nobody notices until revenue conversations start asking why paid performance looks worse.
What Google Consent Mode v2 actually controls
Consent Mode v2 is built around four signals that tell Google's tags what a visitor has agreed to: ad_storage, analytics_storage, ad_user_data, and ad_personalization. Google's Consent Mode documentation is specific about what each one does. ad_storage governs whether advertising cookies can be written or read and whether advertising identifiers get collected at all. analytics_storage governs the equivalent for GA4's own behavioral data. When either is denied, Google's tags do not simply stop firing, they switch to sending a cookieless ping carrying only coarse signals like browser type and time of day, which feeds conversion modeling instead of a direct count.
That modeling layer is the whole reason Consent Mode exists instead of a hard on/off switch. It lets Google estimate the conversions it cannot directly observe, so a denied-consent visitor who converts still contributes something to reported numbers. But modeled numbers are not counted numbers, and the gap between the two grows exactly in proportion to how much traffic is sending a denied signal.
Why June 15, 2026 changed the math
For two years, Google Ads data collection inside GA4 had two gatekeepers: the Google Signals toggle in GA4's admin settings, and the ad_storage consent parameter. Both had to allow the signal through for the full advertising data to reach a linked Google Ads account. A store that turned Google Signals off, deliberately or by inheriting a default from an agency setup years ago, had a second layer of protection even if its consent banner was misconfigured.
Google's Analytics Help page on the change describes the new arrangement plainly: "Google Ads settings will exclusively control Google Ads data (including data shared by Google Analytics)," while Google Analytics settings control only what GA4 uses for its own behavioral reporting. Google Signals' remaining job is narrower, associating GA4 data with signed-in user information for reporting inside Analytics itself. It no longer limits what Google Ads receives.
The practical result is that ad_storage is now the only thing deciding whether Google Ads gets advertising cookies and identifiers. A store with a consent banner that was already firing ad_storage=granted correctly for consenting visitors saw essentially no change. A store whose consent setup had a quiet gap, a banner that never actually fired the update call, a default that leaned the wrong way, a region check that caught the wrong visitors, inherited that gap at full strength the moment Google Signals stopped covering for it.
The failure mode that shows up in real audits
This kind of gap rarely announces itself. In a tracking audit we delivered, a consent banner had been configured to display only to visitors whose browser timezone matched the EU, as a shortcut for regional compliance. The logic worked in the sense that it never crashed. It also meant every visitor outside that timezone check was left in a permanent consent-denied state by default, because the banner that would have let them grant consent never appeared for them at all. Ad and analytics tags were blocked globally for a large share of traffic, and nobody had noticed, because a blocked tag does not throw an error. It just quietly stops counting.
That is the exact shape of failure the June 2026 change makes more consequential. Before, a gap like that one was already undercounting conversions and shrinking remarketing audiences. After, there is no Google Signals setting left to partially offset it. The gap is the whole story now.
How to check your own setup this week
Run this in an incognito browser window, not your own logged-in session, since your browser may already carry stored consent that masks the problem.
- Load the site and reject consent explicitly. Trigger the banner and choose the option that denies advertising and analytics cookies, not the default "accept all" path most of us click out of habit.
- Open the Network tab and filter for Google requests. Look for calls to
google-analytics.comorgoogleads.g.doubleclick.netand inspect thegcsandgcdparameters on those requests. They encode what consent state Google's tags actually received, not what your banner's UI claims to be sending. - Confirm the signal fires before any measurement tag, not after. If GTM loads the GA4 or Google Ads tag before the consent default is set, the first several events on every visit fire with no consent signal attached at all, which Google treats conservatively.
- Compare two weeks of Google Ads data: June 8 to 14 against June 15 to 21, 2026. A sudden drop in conversions or remarketing audience size with flat spend and flat traffic is the specific signature of a consent gap that the old dual-control system had been partially masking.
- Re-check regional logic for literal correctness, not intent. A timezone check, an IP-based guess, or a hardcoded country list are all common shortcuts that quietly deny consent to traffic nobody meant to deny it to.
If step four shows a drop and step two shows ad_storage denied for visitors who clearly accepted your banner, the fix lives in how your consent management platform's decision gets passed into GTM, not in Google Ads itself. That is GTM configuration work: confirming the consent initialization tag fires first, confirming the CMP's update call actually reaches gtag('consent', 'update', ...), and testing both the first-visit and return-visit paths separately, since many setups only tested one of the two. Our GTM container audit walks through the broader checklist this sits inside, including the trigger and tag hygiene issues that tend to travel alongside a consent gap. It is also worth checking the same signal path on Safari and other browsers with their own default tracking restrictions, which is a related but separate failure mode we cover in Safari GA4 tracking.
What this is actually costing, and what to do about it
A store running real ad spend on a consent gap is not losing data in the abstract. It is making bidding decisions off conversion counts that undercount reality, and sizing remarketing audiences off a pool that is smaller than its real addressable traffic. Smart Bidding optimizes toward whatever it is told converts, so a consent gap does not just hide performance, it actively steers budget away from the segments the gap happens to suppress.
A fixed-scope tracking audit is built for exactly this: checking what your consent signal actually sends under a realistic denied and granted state, not what the banner vendor's dashboard claims, and tracing any gap back to the specific GTM trigger or tag order causing it. If the audit confirms the wiring itself needs rebuilding rather than a single fix, that is tracking setup work, standing up the consent initialization and update calls correctly so the signal is accurate the first time a visitor loads the page, not patched after the fact.
The checklist above takes under an hour to run once. Google will not send a second notice about this one. The accounts that find out are the ones that went looking.
