Since 15 June, a Single Signal Decides What Google Ads Receives From Your Analytics.

What Google changed on 15 June 2026

Google consolidated its data controls in Analytics. The announcement in the Analytics help centre describes the change in two sentences whose consequences are easy to skim past.

Previously, the collection of Google Ads cookies and IDs by the Analytics tag and SDK was controlled by two settings together: the Google Signals toggle in Analytics admin and the consent settings for ads. Two switches, both had to be open.

Since 15 June 2026, Google states that the Signals toggle in admin and its API only control whether Analytics-sourced data is associated with signed-in user information, and specifically for behavioural reporting inside Analytics. It no longer decides anything about the data flow to Google Ads.

This is not the removal of Google Signals. The toggle still exists and still does something. It simply does something different than before, and the thing it stopped doing is the thing many setups were quietly relying on.

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 block the same flow. In practice, that redundancy is exactly why many implementations worked despite being imprecise.

A common case from audit work: a consent banner sets analytics_storage to denied on rejection but leaves ad_storage on granted, because the categories in the banner are cut differently from the signals in the tag. That is a configuration error, but as long as the Google Signals toggle was off, it had no visible consequence for the flow to Ads. The error was there. The effect was not.

The inverse case is just as common: a team deliberately turns Google Signals off because a privacy review decided so, and considers the matter closed. The consent signal was never examined in detail, because the switch was off anyway.

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

What actually changes in measurement

The honest answer is that it depends on your starting state, which is precisely why this is worth testing rather than predicting.

Case A, clean consent and 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 reporting inside Analytics on signed-in users, since the toggle still governs that.

Case B, clean consent and Signals was off. The switch was blocking additionally what the consent signal already blocked. That additional block is gone. If the consent signal really was clean, the flow is unchanged. The test for that is a measurement, not an assumption.

Case C, imprecise consent and Signals was off. This is the case that deserves attention. Previously the switch absorbed the imprecision in the consent signal. Now that imprecision takes effect directly. Depending on which direction it runs, either more data flows than intended or less than campaign management needs.

Case C is awkward because it appears as an error in no interface. Google Ads reports no configuration fault, Analytics shows no warning, the banner reports success. It only surfaces in a metric 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 “do we have consent mode?” but “what values are actually in the four consent parameters at the moment the tag fires, separated by acceptance, rejection and first visit?”. 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 granular banners, add every combination your banner can actually produce.
2. Record the actual consent 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 actually leave the browser and with which parameters. A tag that fires is not the same as a tag that transmits.
4. Compare the state before and after 15 June, as far as historical data allows. A break in a metric around that date is a signal, not proof, but a good starting point.

Step two is the one most teams skip, and the only one that makes Case C visible. The banner configuration describes intent. The values in the dataLayer describe what happens.

Why the pattern matters more than the case

This particular change is manageable on its own. It is interesting as an example of a risk category that measurement systems systematically 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 worked out that way, because two controls blocked the same thing and you therefore only had to maintain one of them without noticing. Dependencies like that do not survive vendor changes, and they break without an error message, because from the system’s point of view nothing is broken.

Our research report on measurement reliability classifies exactly this case: it separates events that were observed, events that can be corrected afterwards, and events a platform merely models. A silent change to a consent control shifts volume between those classes 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 documented where it takes effect. Relying on a second control that happens to do the same thing is not a setup. It is a coincidence with an expiry date.

What to do now

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

• Record the four consent parameters per state and compare them with what the banner configures. The discrepancies are the actual finding.
• Check whether anyone documented that Google Signals was deliberately switched off, and why. If the reason was the flow to Ads, that reason has not been addressed since 15 June.
• Check metrics around 15 June for breaks, especially conversion counts in Google Ads against the source in your shop or CRM.
• Write down the audit path, not just the result. The next vendor change is coming, and a documented path is the difference between an hour of work and a week of reconstruction.

If you never set up a clean reconciliation between measured and actual purchases, the tracking coverage calculator is a sober entry point. It shows a measurement gap, not a proven revenue loss, and that distinction is the whole point.

The actual argument

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

It is about the fact that your measurement system just changed its behaviour without you doing anything, and that the change is invisible anywhere 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 holding the events your decisions rest on somewhere the rules only change when you change them. What such a server-side architecture looks like, and what it realistically delivers, we have costed out elsewhere with the assumptions on the table.