Google Consent Mode v2 After the Signals Sunset

If you read the coverage in the run-up to 15 June 2026, you probably came away thinking Google Signals was being switched off. A lot of it was written that way — "Google Signals removal," "the end of Google Signals," and similar.

That framing is wrong, and the difference matters if you are auditing your setup now. Google Signals still exists. What ended was its authority over advertising data. Those are different changes with different consequences, and the version circulating in most summaries will send you looking for a toggle that is still there and still doing something.

Here is the precise picture, and what is worth checking in your own account.

What changed

Before 15 June, two independent controls governed whether a linked Google Ads account received advertising data derived from Google Analytics. Consent Mode's ad_storage signal was one. The Google Signals toggle inside your Analytics property was the other. Either could withhold data. In practice the Signals toggle functioned as a backstop: if your consent implementation was wrong, the Signals setting might still catch it.

That dual-control arrangement ended. As UniConsent describes the change, ad_storage "becomes the sole authority for all advertising data collected for linked Ads accounts."

CookieHub's summary puts the consequence more bluntly: Google Ads stops referencing Google Analytics settings entirely, and if your consent signals "are misconfigured, misaligned, or outdated, there is nothing downstream to catch the error."

The practical effect is a removed safety net. Your CMP is now the only thing standing between a misconfiguration and either a compliance problem or a silent data loss, depending on which direction the misconfiguration runs.

Google Signals is still there, doing less

This is the part most summaries got wrong, and it is worth being exact about because it determines what you will find when you go looking.

Google Signals continues to exist as an Analytics feature. Its remaining job, per UniConsent, is "specifically associating sessions with signed-in users for behavioral reporting inside GA4." It still enriches your Analytics reporting. What it no longer does is influence what reaches Google Ads.

Google's own Analytics documentation on Google Signals is consistent with this. As of writing it describes Signals as an active feature with standard activation instructions, and carries no deprecation notice or removal date — exactly what you would expect if the feature was narrowed rather than retired.

The consequence that catches people: the Signals toggle no longer protects you. If ad_storage is granted in your CMP, Ads will link advertising data to signed-in users regardless of how that toggle is set. A team that turned Signals off years ago for privacy reasons, and has assumed ever since that it constrains what Google Ads receives, is now operating on an assumption that stopped being true in June.

The four signals

Consent Mode v2 transmits four parameters, and it is worth knowing which one does what now that one of them carries so much weight:

• ad_storage — governs storage and use of advertising identifiers. This is the one that became the sole control for linked Ads accounts.
• analytics_storage — governs analytics storage, and therefore GA4 measurement.
• ad_user_data — governs whether user data may be sent to Google for advertising purposes.
• ad_personalization — governs whether data may be used for personalized advertising and remarketing.

The two ad_user_data and ad_personalization parameters were the v2 additions, and they are frequently the ones implemented carelessly, because a v1 implementation that predates them will keep working without obvious errors while simply never sending them.

The EEA requirement

Separately from the June change, and often conflated with it: since March 2024, Google has required EEA advertisers to implement Consent Mode v2 through a Google-certified CMP. This is documented in both the CookieHub and Stape writeups.

"Certified" is a specific status, not a general claim of compliance. A CMP that is standards- compliant, well-regarded, and correctly configured but not on Google's certified list does not satisfy the requirement. If you inherited your consent stack, this is worth verifying rather than assuming.

When ad_storage is denied

Understanding the denied path matters, because it is where teams accidentally destroy their own measurement.

When ad_storage is denied, Google does not collect advertising identifiers for that user. Per UniConsent, in the denied state "Google won't access any identifiers apart from what's available in the url (e.g. gclid)." You lose direct measurement and remarketing eligibility for that user.

What you do not lose, if you have implemented this correctly, is everything. Google's conversion modeling statistically estimates conversions from non-consenting traffic — but it can only do so when it receives the denial signal. The mechanism needs to know a user existed and declined.

This produces a genuinely counterintuitive failure mode. A pipeline that simply drops events from non-consenting users — sending nothing at all rather than sending a denial signal — performs worse than one that transmits the denied state properly. In the first case Google has no idea those users existed and cannot model them. In the second it can. Silence and denial are not the same message, and only one of them preserves your modeled conversions.

A consent implementation that sends nothing when consent is denied is not more private. It is the same privacy outcome with worse measurement.

The server-side consequence

Most Consent Mode guidance stops at the browser: install a certified CMP, wire the four signals, done. If you run a server-side pipeline, that is where the interesting part starts.

Once your backend is the thing dispatching conversions to ad platforms, consent state has to travel with the event and be evaluated at dispatch time. The requirements this creates:

Consent must be captured on the event. The consent state at the moment the user acted has to be recorded alongside the event, not looked up later. A conversion processed an hour after the fact needs to know what the user consented to when it happened, not what their current cookie says.

Evaluation happens per destination, not globally. This is the requirement most systems fail. A user may consent to analytics but not advertising, or to some vendors and not others. "Tracking on / tracking off" cannot express that. Your dispatch layer needs to ask, for each destination independently, whether this specific event may be sent there.

The denial path must be implemented deliberately. For each destination, decide what a denied state means: suppress entirely, or send with the platform's reduced-processing flag set. These are different, and the right answer differs per platform.

Google's is not the only consent mechanism

A multi-destination pipeline cannot treat Consent Mode as the consent system. It is Google's consent system.

Meta has Limited Data Use, a separate flag with its own semantics that restricts how Meta processes data for a given user. TikTok has its own consent parameters. Each platform expects its own signal, in its own format, and none of them reads Google's gcs parameter.

So the correct architecture is one internal consent state — captured once, attached to the event — mapped onto each platform's distinct mechanism at dispatch. Teams that implement Consent Mode thoroughly and then send unrestricted events to Meta and TikTok have solved a quarter of the problem and may believe they have solved all of it.

What to audit now

If you have not reviewed your setup since June, this is the short list:

1. Confirm your CMP is Google-certified, not merely functional, if you serve EEA traffic.
2. Verify all four signals fire, including ad_user_data and ad_personalization. A v1 implementation will pass a casual look while never sending the v2 additions.
3. Test the denied path specifically. Set consent to denied and confirm the denial is transmitted rather than the event silently dropped. This is the single most valuable test here and the one least likely to have been run.
4. Stop relying on the Google Signals toggle as a control over what Ads receives. If it was part of your privacy posture, that role is gone and something else has to cover it.
5. Check consent propagates into server-side dispatch, per event and per destination. Consent captured client-side but not carried through the pipeline means your backend is sending events for users who declined.
6. Map consent to Meta and TikTok, not just Google.
7. Review your privacy policy against what you now actually do.

A note on sourcing

The two detailed accounts of this change cited above were published on 27 April and 21 May 2026 — both before the 15 June date they describe. Google's Analytics documentation remains consistent with the change as described, in that Signals persists as a reporting feature with no removal notice, but we did not find a post-15-June source explicitly confirming the rollout landed exactly on schedule and unmodified.

So verify against your own account rather than against this article. Check whether your linked Ads account is receiving data you expect it not to, or missing data you expect it to have. That test costs ten minutes and is authoritative for your setup in a way no blog post can be — including this one.