
The GA4 consent change that quietly broke Ads data
Since 15 June 2026 one parameter decides whether GA4 shares data with Google Ads, and both failure modes are silent.
On 15 June 2026 Google split GA4 consent handling, and ad_storage became the only control over whether GA4 shares cookies and identifiers with your linked Google Ads accounts. The Google Signals toggle no longer does that job. It now controls signed-in behavioural reporting only: demographics, interests and cross-device.
Nothing in the interface tells you this happened to your account. Both ways it can go wrong are silent.
The two failure modes
Over-collection. If your Google Signals toggle is off and your consent setup grants ad_storage, you are now sharing more with Ads than you were before, because Signals was acting as a backstop and that backstop is gone. Teams who switched Signals off for privacy reasons believe they are still restricted. They are not.
Under-collection. If your consent setup denies ad_storage by default and you relied on Signals being on to keep Ads data flowing, that flow stopped in June. Conversions in Ads drop, remarketing lists shrink, Smart Bidding gets fed less, and the change looks like performance decay rather than a plumbing fault. This is the expensive one, because bidding responds to it. Two months of quiet decline gets blamed on the market.
How to check in ten minutes
Do not use GA4 Tag Diagnostics for this. It reports on a 48 to 72 hour lag and will happily show you a clean picture that is three days old.
Use the browser instead.
- 1.Open your site in a private window with developer tools open, on the Network tab.
- 2.Filter requests for google-analytics.com.
- 3.Reject consent on your banner. Load a page. Click any request and read the query string.
- 4.Find the gcs parameter. It is four characters, formatted as G1 followed by two digits. The first digit is ad_storage, the second is analytics_storage. Zero is denied, one is granted. So G100 means both denied, G111 means both granted, G110 means ad_storage granted and analytics_storage denied.
- 5.Now find gcd. That describes your default consent state and how it was set, which tells you whether defaults are firing before the banner or after.
- 6.Repeat the whole thing accepting consent, and compare.
What you are looking for is simple. Does gcs change when the user changes their choice, and does it show what you intended in each state? If gcs reads G111 on a rejected load, your banner is decorative. If it reads G100 on an accepted load, you are throwing away consented data.
Do this on a real page in production, not on your staging environment, and do it on a page reached from a paid ad with parameters attached, because consent defaults sometimes behave differently on the first landing.
The Australian wrinkle nobody raises
Australian privacy law does not require the same blocking consent banner that European law does. A lot of Australian sites run one anyway, because it was in a template or a global brand rolled it out.
If that is you, you have voluntarily denied yourself ad_storage on a meaningful share of your traffic to comply with a law that does not apply to you. That is worth an actual conversation with your legal counsel rather than an assumption in either direction. The right answer might still be to keep the banner, for a global brand or for genuinely sensitive categories. But it should be a decision, not an inheritance.
And if you do keep it, banner design is now a measurement lever. Consent rate directly determines how much of your conversion data exists.
Server-side is unaffected, and that is the point
This change does not touch server-side Google Tag Manager flows. Events flowing through your own server container behave as they did.
That gap is instructive. Every consent and browser change of the last three years has landed on the browser layer and left the server layer alone. If your measurement lives entirely in the browser, you will keep absorbing these changes on Google's schedule rather than your own.
What to do after you have checked
Write down your intended consent state for each combination and store it with your tagging documentation. Not in someone's head. A four-row table: consent granted, consent denied, no interaction yet, and returning visitor with a stored choice. For each, what gcs should read.
Then set a monthly recheck. Fifteen minutes. The reason is that consent behaviour breaks whenever anyone touches the banner, the tag manager, the cookie library or the site template, and none of those changes come with a warning that they altered your Ads data.
Finally, if you find the June change did hit you, look at your Ads conversion volume from mid-June forward before you accept any explanation about seasonality or market conditions. The break will be sharp and dated, and it will line up with a Monday.
Measurement does not usually fail loudly. It fails on a specific date, in one parameter, while every dashboard keeps drawing a line.
Written by David Eid. Published .
Read next.
Contact the Ignis Team
Send through your details and we will audit your business before we reply.




