Since 15 June, only your cookie banner decides what Google Ads receives from Google Analytics.

What Google changed on 15 June 2026

Google merged two settings that previously decided the same data flow together. The announcement in the Analytics help centre describes it in a few sentences. The consequences are not in there.

Previously it worked like this: whether the Analytics tag collected cookies and identifiers for Google Ads depended on two things. First, the Google Signals toggle in Analytics admin. Second, the consent signal your cookie banner passes to the tag. Both had to be open.

Since 15 June 2026, only the consent signal decides. According to Google, the Google Signals toggle now only controls whether Analytics uses data from signed-in Google users for reports inside Analytics. It says nothing about the flow to Google Ads any more.

Google Signals has not been removed. The toggle still exists and still does something. It just does something different than before. And the effect it lost is exactly the one many setups were quietly relying on.

Google calls the consent signal Consent Mode. It consists of four values your cookie banner sets when the page loads. For advertising, the one that matters most is ad_storage. When it is granted, Google Ads may set cookies and store identifiers. When it is denied, it may not.

Why two brakes are not the same as one

In theory the two settings were redundant. If you set the consent signal correctly, you do not need a second switch to stop the same flow. In practice, that redundancy is exactly why many setups worked despite being imprecise.

A common case from audits: a cookie banner sets analytics_storage to denied on rejection but leaves ad_storage on granted. That happens when the categories in the banner are cut differently from the four values in the tag. It is a configuration error. As long as Google Signals was off, it had no visible effect on the flow to Google Ads. The error was there. The effect was not.

The reverse case is just as common. A team deliberately turns Google Signals off because the privacy review decided so. After that, the matter counts as closed. The consent signal was never examined in detail, because the switch was off anyway.

Both setups have behaved differently since 15 June. Not because anyone did something wrong, but because the second brake is gone.

What changes in the numbers

The honest answer: it depends on your starting state. That is exactly why you should test it rather than predict it.

Case A, clean consent signal and Google Signals was on. Little changes in the data flow here. The consent signal used to co-decide and now decides alone. What does change is the reporting on signed-in users inside Analytics. The toggle still governs that.

Case B, clean consent signal and Google Signals was off. The toggle was additionally blocking what the consent signal already blocked. That extra block is gone. If the consent signal really was clean, the flow stays the same. Whether it was clean is shown by a measurement, not by an assumption.

Case C, imprecise consent signal and Google Signals was off. This is the case that deserves attention. Previously the toggle absorbed the imprecision. Now it takes effect directly. Depending on the direction, either more data flows than intended or less than your campaigns need for bidding.

Case C is awkward because it shows up as an error nowhere. Google Ads reports no configuration fault. Analytics shows no warning. The banner reports success. It only becomes visible in a number that has behaved differently since mid-June. Usually with a delay and with no obvious connection.

An audit path that holds up

The question is not whether you have Consent Mode. The question is which values are actually in the four parameters at the moment the tag fires. Separated by acceptance, rejection and first visit without a decision. That is a measurement, not a judgement call.

One approach that works in practice:

1. Define three states. First visit with no decision, full acceptance, full rejection. With banners that offer individual categories, add every combination your banner can produce.
2. Record the actual values per state. Not the ones configured in the banner. The gap between the two is exactly what produces Case C.
3. Check per state which requests leave the browser and with which parameters. A tag that fires is not the same as a tag that transmits.
4. Compare the numbers before and after 15 June, as far as your data goes back. A break around that date is a hint, not proof. But a good starting point.

Most teams skip step two. It is the only step that makes Case C visible. The setting in the banner describes intent. The values in the dataLayer describe what happens. The dataLayer is the list in the browser that the banner writes its values into and the tag reads them from.

Why the pattern matters more than the case

This particular change is manageable on its own. It is interesting as an example of a kind of risk that measurement systems regularly underrate: the silent dependency on a setting nobody planned as load-bearing.

Nobody ever decided to use the Google Signals toggle as a safety net for an imprecise consent signal. It just happened, because two settings blocked the same thing. So only one of them had to be maintained, without anyone noticing. Dependencies like that do not survive vendor changes. They break without an error message, because from the system’s point of view nothing is broken.

Our report on measurement reliability classifies exactly this case. It separates three kinds of orders: observed, correctable afterwards and merely estimated. A silent change to a consent setting shifts volume between those three kinds without turning a single number in a report red.

The practical consequence is uncomfortable but simple. If a setting matters to you, it has to be tested and written down where it takes effect. Relying on a second setting that happens to do the same thing is not a setup. It is a coincidence with an expiry date.

What you can check now

For most setups this is a few hours of work, not weeks.

• Record the four values per state and compare them with what is configured in the banner. The discrepancies are the actual finding.
• Check whether anyone wrote down that Google Signals was deliberately switched off and why. If the reason was the flow to Google Ads, that reason has not been covered since 15 June.
• Check numbers around 15 June for breaks. Above all the orders your ad account counts against the orders in your shop or CRM.
• Write down the audit path, not just the result. The next vendor change is coming. Then a written-down path is the difference between an hour of work and a week of reconstruction.

If you have never cleanly reconciled measured and actual orders, the tracking coverage calculator is a sober entry point. It shows a measurement gap, not a proven revenue loss. That distinction is the whole point. If you would rather not run the audit yourself, that is what our tracking check is for.

The actual argument

This is not about whether Google made a good or bad decision. Merging the controls is reasonable. One place for one decision is cleaner in the end than two.

It is about the fact that your measurement system changed its behaviour without you doing anything. And that the change is visible nowhere unless you go looking for it. Every system you do not own and whose rules someone else writes has that property.

That is not an argument against Google Analytics. It is an argument for also keeping the orders your decisions rest on in a place where the rules only change when you change them. What that looks like with your own server for tracking and what it realistically delivers is described there with the assumptions in the open.