Google Signals is Dead: Why Your Remarketing Audiences Will Hit Zero After June 15, 2026 (Unless You Act Now)

There's a change coming that most performance marketers haven't heard about yet. And if they have heard about it, most of them are drastically underestimating what it actually breaks.

Starting June 15, 2026, Google is killing the admin-panel toggles inside GA4 — specifically the "Google Signals" setting and the "Ads Personalization" control — as the governing mechanism for cross-device advertising data and remarketing audiences.

Control is transferring entirely to Google Consent Mode. No CMP. No `gtag` consent signals. No audiences. No cross-device attribution. It's that simple, and it's that serious.

This isn't a minor UX update to the GA4 interface. This is a foundational architectural shift in how Google governs the flow of advertising data from your website to Google Ads. If your tracking stack isn't ready, your Smart Bidding campaigns will fly blind, and your remarketing lists will quietly bleed out to zero.

Let's break down exactly what's changing, why it matters, and what you need to do about it — right now.

What Exactly is Changing? The Technical Shift You Need to Understand

The Old World (How It Worked Until Now)

For years, the model was straightforward, if a bit convoluted. You linked your GA4 property to your Google Ads account, and then you managed data permissions for advertising through two backend toggles in the GA4 Admin panel:

• Google Signals — This toggle controlled whether the Google Analytics tag collected Google Ads cookies and cross-device identifiers (like GAID and IDFA). Enabling it is what allowed GA4 to stitch together user journeys across devices and power cross-device conversion reporting and Smart Bidding.
• Ads Personalization — This setting (configurable at the account, property, Ads link, and even event level inside GA4) controlled whether your GA4 data could be used to build and populate remarketing audiences in Google Ads.

The implicit assumption baked into this model was: if the admin toggles are ON, the data flows. Consent Mode was a separate, optional compliance layer on top — important for EEA/GDPR compliance, but not the core engine.

That assumption is now obsolete.

The New World (Effective June 15, 2026)

Google has officially announced a consolidation of data controls, separating them based on where the data is actually used. Here's how the new architecture works:

• Google Ads settings will exclusively control Google Ads data (including data sourced from GA4 via the property link).
• GA4 settings will exclusively control data used for behavioral reporting within GA4 — nothing more.

In practice, this means two critical things:

Change #1 — Google Signals (Effective June 15, 2026):

Starting June 15, 2026, Google Analytics will transition to using Consent Mode (within Google Ads) as the single control for data collection of Google Ads cookies and IDs. The Google Signals setting in the GA4 admin panel and the Google Signals API will be demoted — they will only control the association of GA4 data with signed-in user information for behavioral (demographic) reporting inside GA4.

In other words: `ad_storage` via Consent Mode is now the exclusive on/off switch for cross-device advertising identifiers.

Change #2 — Ads Personalization (Later in 2026):

Later in 2026, ads personalization controls — currently managed across multiple layers within GA4 — will also be simplified. The `ad_personalization` Consent Mode parameter will become the exclusive control governing whether GA4 data is used for audience personalization in Google Ads.

The multi-layered GA4 admin controls (account level, property level, Ads link level, event level) will cease to be the governing authority for remarketing.

The bottom line:

Your GA4 admin panel is being stripped of its authority over ad data. Front-end Consent Mode signals now rule everything.

The "No CMP" Danger: The Silent Killer Most Brands Are Walking Into

While everyone is talking about the shifting of the toggles, this is the part that almost nobody in the industry is talking about clearly enough.

The Dangerous Assumption

A huge number of websites — particularly those outside the EEA, or those that simply "haven't gotten around to it" — operate without any Consent Management Platform (CMP). No cookie banner. No consent dialog. Just tags that fire on page load because nobody ever set up the consent architecture.

The assumption these brands are making is: "We don't have a CMP, so our tags just fire normally by default. We're not blocking anything."

This assumption is dangerously wrong in the new consent architecture.

What "No Signal" Actually Means to Google

Consent Mode doesn't just have two states — `granted` and `denied`. It has a third, critical state that most people don't think about: `null` / "Not Set" — the state where no consent signal is passed at all.

Historically, Google's tags were relatively permissive in this null state, especially outside of GDPR-regulated regions. But the entire thrust of this architectural change is that Google is moving toward treating the absence of an explicit `granted` signal as a privacy restriction.

Think about what that means for a website with no CMP:

• No CMP installed = no consent signal fired via `gtag('consent', 'update', {...})` or the Data Layer
• No consent signal = Google receives a `null` / "Not Set" state for `ad_storage` and `ad_personalization`
• "Not Set" state = Google will increasingly treat this as a restriction on data collection and use

You are not "defaulting to granted." You are defaulting to ambiguity — and Google is resolving that ambiguity in favor of privacy restriction.

The Consequence of Doing Nothing

The danger for sites with no CMP isn't that Google will proactively penalize them. It's more structural than that. By removing the GA4 admin toggle as an alternative control, Google has ensured that Consent Mode is now the only authoritative signal governing ad data collection. For sites with no CMP and no Consent Mode implementation, there is simply no signal — and no signal means the new architecture has nothing to act on.

To substantiate further, Google's own developer documentation states that when Consent Mode is implemented, the system defaults to denied unless you explicitly configure otherwise.

The Google Ads Help Center states directly: "By default, consent will be denied, unless you set your own defaults."

The Google Developers Consent Mode overview similarly states: "By default, consent may be denied, unless you set your own defaults. While consent is denied, the Google tags send cookieless pings."

For sites with no Consent Mode at all, there is no default call, no update call, and no consent state communicated — meaning Google receives no explicit granted signal for ad_storage or ad_personalization. And as of June 15, 2026, the GA4 admin toggle that previously provided that implicit "permission" is gone.

The result is the same as a denied state in practical effect: no advertising cookies written, no cross-device IDs collected, no audience population. Not because Google called it denied — but because the infrastructure that used to substitute for an explicit granted signal has been decommissioned.

If your website does not explicitly pass `ad_storage: 'granted'` and `ad_personalization: 'granted'` signals through Consent Mode v2 by the relevant 2026 deadlines, here is what breaks:

Your Google Ads campaigns won't throw an error. They'll just quietly get dumber, smaller, and more expensive — and you might not even notice for weeks.

The Action Plan: What Agencies and Brands Must Do Right Now

This is a six-to-eight week project for most organizations. Don't wait until the end of May 2026.

Here's your execution roadmap:

Step 1: Audit Your Current Consent Mode Implementation

Before you build anything, you need to know where you stand. Run this audit across every property you manage:

In GTM:

• Is there a `gtag('consent', 'default', {...})` call firing before any Google tags?
• What are the default values? Are `ad_storage` and `ad_personalization` set to `'denied'` by default (EEA best practice) or `'granted'` (non-EEA approach)?
• Is there a `gtag('consent', 'update', {...})` call wired up to your CMP's consent callback?

In GA4 DebugView / Browser Console:

• Open DevTools → Network tab. Filter for `collect` requests to `google-analytics.com`.
• Look for the `gcs` parameter in the GA4 hit payload. This tells you the current consent state:
  • `G100` = `ad_storage: denied, analytics_storage: denied`
  • `G110` = `ad_storage: denied, analytics_storage: granted`
  • `G101` = `ad_storage: granted, analytics_storage: denied`
  • `G111` = `ad_storage: granted, analytics_storage: granted` ← This is what you want for advertising

In Google Tag Assistant / Consent Mode debugger:

• Use the Google Tag Assistant Chrome extension to inspect consent state visually.

Step 2: Implement a CMP (If You Don't Have One)

If your site has no cookie banner and no CMP, this is your most important infrastructure decision. Your CMP needs to:

1. Surface a consent UI to users (cookie banner/dialog)
2. Integrate natively with Consent Mode v2 — meaning it must be able to write consent decisions to the Google-recognized consent state, not just set its own internal cookies
3. Support the full Consent Mode v2 parameter set, including `ad_storage`, `ad_personalization`, `analytics_storage`, `functionality_storage`, and `personalization_storage`
4. Fire consent updates before Google tags initialize — this is non-negotiable. A CMP that loads after your GA4 or Google Ads tags is architecturally broken.

Recommended CMPs with verified Consent Mode v2 integration:

• Cookiebot (Usercentrics) — robust GTM template, widely used
• OneTrust — enterprise-grade, solid CM v2 support
• Axeptio — strong in French market, good v2 support
• CookieYes — solid for SMB, has GTM integration
• Complianz (WordPress) — strong for WP environments

A note on geography: Even if you operate primarily outside the EEA, implement Consent Mode now. Google's architecture change is global. Treat it as infrastructure, not just a compliance checkbox.

Step 3: Configure Consent Mode v2 Correctly in GTM

This is where most implementations break. Here's the correct GTM structure:

3a. Set up a default consent state

For non-EEA sites where you operate on a legitimate interest / implied consent basis and are not under GDPR:

js
gtag('consent', 'default', {
'ad_storage': 'granted',
'ad_personalization': 'granted',
'analytics_storage': 'granted',
'functionality_storage': 'granted',
'personalization_storage': 'granted'
});

For EEA/GDPR-compliant sites (correct approach):

js
gtag('consent', 'default', {
'ad_storage': 'denied',
'ad_personalization': 'denied',
'analytics_storage': 'denied',
'wait_for_update': 500
});

3b. Wire Up the Consent Update

Your CMP must call the update function after the user makes a choice:

js
gtag('consent', 'update', {
'ad_storage': userGrantedAds ? 'granted' : 'denied',
'ad_personalization': userGrantedPersonalization ? 'granted' : 'denied',
'analytics_storage': userGrantedAnalytics ? 'granted' : 'denied'
});

3c. Enable "Consent Overview" in GTM

In GTM, go to Admin → Container Settings and enable the "Enable consent overview" feature. This gives you a consent status dashboard across all your tags, and lets you configure per-tag consent requirements — ensuring tags only fire when appropriate consent is granted.

3d. Update Your Google Tag / GA4 Configuration Tag

Make sure your GA4 configuration tag is wired up to use the consent state. For advertising-purpose tags (Google Ads Conversion Tracking, Remarketing), these should require `ad_storage`.

Step 4: Verify Your Signals Are Firing Correctly

Method 1: GTM Preview Mode + Consent Debugger

• Enter GTM Preview mode
• Walk through the consent flow on your site
• Confirm the `gtag('consent', 'default')` fires on the Consent Initialization event, before any other tags
• Confirm `gtag('consent', 'update')` fires after user interaction with the CMP

Method 2: Google Tag Assistant

• - Open Tag Assistant → connect to your site
• In the "Consent" tab, verify the consent state transitions from default → updated values correctly

Method 3: Network Tab GCS Parameter Check

• Open DevTools → Network → filter for `google-analytics.com/g/collect`
• Inspect the `gcs` parameter value (as described in Step 1)
• For a user who has granted advertising consent, this must be `G111` or similar `granted` state

Method 4: GA4 DebugView

• Enable `debug_mode: true` in your GA4 config
• Navigate through your consent flow
• In GA4 → Admin → DebugView, confirm events are being received with correct consent state metadata

Step 5: Monitor Audience Health and Conversion Signal Quality Post-Launch

Once your Consent Mode v2 implementation is live, set up monitoring:

• Watch remarketing audience sizes in Google Ads. If you've implemented correctly, audience membership should remain stable or even recover if previous consent signals were broken.
• Monitor "Tag Coverage" in Google Ads. Under Tools → Tag → Tag Coverage, Google shows you the percentage of conversions covered by your tag. This number should be high.
• Check "Consent Mode Status" in Google Ads. Tools → Tag → Consent Mode — this now shows per-tag consent signal health.
• Set up a Smart Bidding performance baseline. Changes in consent signal quality will manifest in CPA volatility within 2–3 weeks of any change.

The Timeline Summary

Final Word: This is Infrastructure, Not a Feature

The marketers and agencies who treat this as a compliance box-ticking exercise will wake up to degraded campaigns, shrinking audiences, and confused clients. The ones who treat this as a core tracking infrastructure project — with proper audit, implementation, verification, and monitoring — will maintain the data quality advantage that makes their campaigns actually work.

Consent Mode v2 is no longer a nice-to-have for GDPR markets. As of June 15, 2026, it is the engine that runs your Google advertising data pipeline, globally.

Audit your properties. Get a CMP deployed. Configure the signals correctly. Verify everything with real data.

The clock is running.

Have questions about your specific GTM setup or Consent Mode v2 implementation? Drop them in the comments below.