On June 15, 2026, Google restructured how advertising data flows between Google Analytics 4 and Google Ads. The change was quiet -- no flashy blog post, no developer summit keynote -- but its implications for anyone running a consent management platform are substantial. Google Signals, the setting that for years acted as a secondary gate on ad-data collection, lost its authority over that flow. Control consolidated into a single Consent Mode parameter: ad_storage.

If you manage a website with linked GA4 and Google Ads accounts, this is not a cosmetic UI change. It rewrites the trust model between your analytics configuration and your consent implementation. Here's what happened, why it matters, and what you need to do.

What Google Signals Used to Do

Google Signals was introduced as a GA4 property-level setting that enabled three things when activated:

Cross-device reporting -- associating sessions from the same signed-in Google user across phones, tablets, and desktops
Demographics and interest data -- surfacing age, gender, and affinity categories from users signed into their Google accounts
Remarketing audience building -- feeding user data from GA4 into Google Ads for audience targeting and Smart Bidding

Crucially, Signals also acted as a gate. If you turned it off, Google Ads would not receive advertising identifiers or cross-device data from your GA4 property, regardless of what your Consent Mode configuration allowed. It was a redundant safety layer: even if your CMP misconfigured ad_storage to default to granted, the Signals toggle being off would still block that data from reaching Ads.

That redundancy is gone.

What Changed on June 15, 2026

Google split the responsibilities that Signals used to carry into two separate control planes:

GA4-internal behavioral reporting -- the Signals toggle and allow_google_signals gtag parameter still control whether GA4 associates sessions with signed-in user data for its own reports. This includes demographics and cross-device session stitching within GA4 itself.
GA4-to-Google Ads data flow -- now governed exclusively by Consent Mode parameters, specifically ad_storage and ad_personalization. The Signals toggle has zero authority over what reaches your Ads account.

The practical consequence: if your CMP sets ad_storage to granted (because the user consented to advertising cookies), Google Ads will receive and link advertising data to signed-in users -- whether or not Google Signals is toggled on in your GA4 admin. The multi-layered admin controls in GA4 (account level, property level, Ads link level) are no longer the governing authority for remarketing data.

This Is Not the 2024 Reporting Identity Change

In February 2024, Google separately removed Signals from GA4's reporting identity -- the mechanism GA4 uses to count unique users across sessions. That change addressed thresholding issues (where small sample sizes caused GA4 to suppress report data). The June 2026 change is architecturally different: it removes Signals from the advertising data control pipeline. Both events are often conflated in industry discussion, but they affect different systems.

Why This Shifts Responsibility to Your CMP

Before June 15, the consent architecture for Google's advertising stack had built-in redundancy. Two independent controls had to align for ad data to flow: the GA4 admin setting (Signals) and the browser-side consent signal (ad_storage). An error in either one would still block data.

Now there's one control: ad_storage. And ad_storage is set by your CMP -- your cookie consent banner, your tag management configuration, your Consent Mode implementation. If your CMP defaults ad_storage to granted (a common misconfiguration), or fails to fire the consent update call correctly, advertising data flows to Google Ads with no secondary check.

As Simo Ahava noted, the change "places more stress on your consent mode implementation, so make sure the update calls are done appropriately and contain the correct signals." He described the new model as a binary choice: either grant ad_storage and Google uses all available ads signals including signed-in user linking, or deny it and Google receives no identifiers beyond what's in the URL (like gclid).

Others in the analytics community have been blunter. Writing on PPC Land, a former Google analyst argued the change primarily benefits Google by simplifying its own data pipeline rather than giving advertisers more control -- a consolidation that removes a manual override advertisers could previously use to restrict data sharing independently of consent.

The Four Consent Signals That Now Carry the Load

With Signals removed from the advertising equation, the four Consent Mode v2 parameters become the exclusive controls for Google's entire measurement and advertising stack. Understanding what each one gates is no longer optional:

ad_storage -- controls whether advertising cookies (like the Google Ads click ID cookie) can be read and written. After June 15, this is the single gate for all ad-data collection from GA4 to Google Ads.
ad_personalization -- controls whether collected data can be used for ad personalization, including remarketing audiences built from GA4. This is now the exclusive control for whether GA4 audience data feeds into Google Ads targeting.
ad_user_data -- controls whether user-provided data (like email addresses in Enhanced Conversions) can be sent to Google for advertising purposes.
analytics_storage -- controls whether analytics cookies (GA4's _ga and _gid) can be read and written. This is unchanged by the June 15 update but remains essential for measurement.

If your CMP does not explicitly set and update all four of these signals on every page load, your consent implementation has gaps. And after June 15, those gaps have no backstop. For a deeper look at how these signals interact with GA4 reporting, see our guide on how Consent Mode v2 affects GA4 reporting.

Impact on GA4 Reporting and Google Ads

Remarketing Audiences Will Shrink

This is the most immediate, visible consequence. Before June 15, remarketing audiences in GA4 included users identified via Google Signals' cross-device graph regardless of granular consent signaling. After June 15, those audiences include only users who explicitly granted ad_storage and ad_personalization through a properly configured CMP.

For sites with European traffic and consent rates between 40-75%, this means remarketing audiences built from GA4 could shrink significantly. Smart Bidding strategies that relied on large, Signals-enriched audiences will see reduced signal volume, potentially degrading campaign performance.

Demographics and Interest Reports

Within GA4 itself, demographics data still requires the Signals toggle to be on. But since Signals' role is now limited to GA4-internal reporting, this data no longer flows to Google Ads for targeting. If you relied on GA4 demographics to inform ad targeting, that pipeline is severed unless users grant ad_storage.

Cross-Device Reporting

GA4's cross-device session stitching (associating visits from the same user on different devices) still works for GA4's own reports when Signals is enabled. But the cross-device data that enriched Google Ads audiences is now gated by ad_storage consent, not by the Signals setting.

Conversion Modeling

If you're running Advanced Consent Mode, Google's behavioral modeling continues to work as before. The modeling engine uses cookieless pings from non-consenting users to estimate conversions. The June 15 change doesn't affect this pipeline directly, but it does make getting your consent signals right even more critical: a misconfigured ad_storage default can now either over-share data (if defaulting to granted) or starve your models (if update calls aren't firing).

The Compliance Dimension

The removal of Signals as a data-control backstop is, in the view of several privacy analysts, a material change to how consent functions across the GA4/Google Ads infrastructure. For businesses with EU users, this could trigger GDPR notification obligations -- you may need to update your privacy policy and cookie policy to reflect that advertising data collection is now governed solely by your CMP's consent signals rather than by a combination of GA4 admin settings and consent.

The practical risk: if your CMP was configured correctly but your GA4 Signals setting was off, you may have been inadvertently compliant -- Signals was blocking ad data even without explicit ad_storage handling. After June 15, that safety net is gone. Any CMP misconfiguration now directly translates to a compliance exposure.

This applies globally, not just to EU businesses. The change affects all GA4 properties linked to Google Ads accounts worldwide.

Action Items: What to Do Right Now

Whether you manage one site or dozens, these steps should be on your immediate to-do list:

1. Audit Your Consent Mode v2 Implementation

Open your tag manager's preview mode and load your site in an incognito window. Before interacting with the cookie banner, verify that ad_storage, ad_personalization, ad_user_data, and analytics_storage are all set to denied by default. Then accept cookies and confirm all four update to granted. Then reject and confirm they remain denied. If any signal defaults to granted before consent, you have a compliance problem that Signals used to mask.

2. Verify Consent Mode Update Calls Fire Correctly

The most common failure mode is a CMP that sets the default state correctly but never fires the gtag('consent', 'update', ...) call when the user makes a choice. Use your browser's developer tools or a tag debugging extension to confirm the update call fires on every consent interaction -- accept, reject, and granular category toggles. Every signal must be present in the update payload.

3. Check Your Remarketing Audience Sizes

Log into Google Ads and compare your GA4-sourced remarketing audience sizes from before and after June 15. A significant drop is expected and normal -- it reflects the removal of Signals-sourced users who hadn't explicitly consented. But a drop to near-zero may indicate your CMP is not passing ad_personalization: granted when users consent to marketing cookies.

4. Review Your Privacy Policy and Cookie Disclosures

If your privacy documentation references Google Signals as a data-sharing control, update it. Your disclosures should now reflect that advertising data collection and sharing with Google Ads is governed by user consent (via your cookie banner), not by a platform-side admin setting. Check our GDPR cookie compliance checklist for a full review framework.

5. Re-evaluate Advanced vs Basic Consent Mode

With ad_storage as the sole advertising gate, the choice between Advanced and Basic Consent Mode carries more weight. Advanced Mode's cookieless pings give Google's modeling engine training data even from non-consenting users, partially compensating for the audience shrinkage. Basic Mode blocks everything until consent, which is cleaner but leaves Google Ads with less data to work with. If you haven't revisited this decision recently, now is the time.

6. Test Across Your Full Tag Stack

Don't stop at Google tags. If you use GA4 audiences to feed other platforms (DV360, SA360, Campaign Manager), verify those integrations still receive the data they expect. The Signals change affects the GA4 side of the pipeline, and downstream systems may need their own consent signal configuration reviewed.

7. Monitor Conversion Modeling Thresholds

Google's behavioral modeling requires minimum traffic thresholds to activate. If your consented audience shrinks below those thresholds after the Signals change, modeled conversions may stop appearing. Monitor the "Modeled" badge in your GA4 conversion reports over the next 2-4 weeks. If modeling drops off, it may indicate your consent rates are too low for Google's models to work, and you should focus on consent rate optimization.

How CookieBeam Handles This

CookieBeam's Consent Mode v2 integration was built around the four-signal model from the start. When a visitor interacts with a CookieBeam banner, all four consent parameters -- ad_storage, ad_personalization, ad_user_data, and analytics_storage -- are set as denied by default on page load, then updated to the user's actual choice the moment they make one.

This means the June 15 change requires no configuration changes for CookieBeam users. The consent signals that now exclusively govern ad-data flow were already the signals CookieBeam emits. There is no dependency on the GA4 Signals toggle for compliance.

CookieBeam also supports both Advanced and Basic Consent Mode, letting you choose the implementation style that fits your privacy posture. And with regional consent rules, you can apply different consent behaviors per visitor location -- GDPR-strict defaults for EEA visitors, CCPA opt-out for California, and lighter-touch consent elsewhere -- all from a single banner configuration.

The Bigger Picture

June 15 is one step in a broader consolidation that Google has been executing across 2024-2026: collapsing redundant settings into Consent Mode as the single source of truth for privacy-relevant data controls. The February 2024 removal of Signals from GA4's reporting identity was an earlier move in the same direction. The pattern is clear -- platform-side toggles are being deprecated in favor of browser-side consent signals that your CMP controls.

For website owners, this trajectory has one consistent implication: your consent management platform is no longer just a compliance checkbox. It is the mechanism that determines what data Google collects, what your analytics measure, what your ad campaigns can target, and whether your behavioral models have enough training data to function. Getting it right was always important. After June 15, 2026, it's structural.

Google Signals Removal (June 2026): What It Means for Your Consent Architecture