In roughly seven weeks, on June 15th 2026, Google will quietly remove one of the most widely relied-upon privacy guardrails in the digital advertising stack — and most of the organizations that depend on that guardrail do not know it. The change is technical, the announcement is buried in a Help Center article, and the immediate framing in the trade press has been “ad-ops housekeeping.” It is not. It is a consent-architecture change with direct GDPR, UK GDPR, and ePrivacy implications, and any privacy or compliance lead whose organization has linked Google Analytics to Google Ads needs to make a decision about it before mid-June.
This is what is actually happening, why the conventional summary undersells the legal risk, the four scenarios in which your organization may be more exposed than you think, and a concrete pre-cutover playbook that should be on someone’s quarterly plan right now.
What Google Is Actually Doing
Today, when a Google Analytics property is linked to a Google Ads account, advertising data collection is governed jointly by two systems: the Google Signals setting inside Google Analytics, and the Consent Mode parameters (most importantly ad_storage) within Google Ads. If either system says “no,” advertising cookies and identifiers are not collected.
On 15 June 2026, that dual-control arrangement ends. After the cutover, Google Signals retains exactly one job: deciding whether Analytics-sourced data is associated with signed-in user information for behavioural reporting inside Analytics. It no longer governs anything in Google Ads.
The single source of truth for whether Google Ads can collect advertising cookies and identifiers, link users to their Google sign-in, and use that data for measurement and personalisation becomes ad_storage. Granted means yes — and Google has been explicit that “yes” includes the use of “all available ads signals at their disposal,” including linking the user to their Google account. Denied means no — and Google has been explicit that “no” means losing measurement, conversion tracking, and remarketing capabilities.
A second change, on a date Google has not yet announced, will collapse ad_personalization controls into the same architecture. A third change, also undated, will route IP addresses encrypted from Google Tag and SDK directly to linked Google Ads accounts. The pattern is unambiguous: privacy authority is moving out of Analytics and into Consent Mode, full stop.
Why Most Summaries Undersell This
The trade-press read is “Google is simplifying duplicate controls.” That is technically true and substantively misleading. Three things have changed in ways that matter for compliance, not just for ad operations.
First, the silent backstop is gone. A meaningful number of organisations turned Google Signals off as a deliberate privacy posture — not necessarily because they had analysed Consent Mode in detail, but because disabling Signals was a known, supported way to prevent Google Ads from linking users to their Google identity. After 15 June, that lever does nothing for advertising. If ad_storage is granted, Google will link the user to their Google sign-in regardless of whether Signals is on or off. Organisations that have been quietly relying on Signals-off as a privacy control will, on 15 June, start sending data to Google in ways their privacy notice may not describe and their DPIA may not contemplate. Nobody will tell them.
Second, the consent stack becomes binary. As Simo Ahava observed in the LinkedIn post that has driven most of the technical commentary, there is no middle ground in the new architecture: ad_storage granted means Google uses everything at its disposal; ad_storage denied means Google operates with whatever is in the URL (a gclid, essentially) and nothing else. The intermediate states that organisations have constructed through clever combinations of Signals settings, gtag flags, and per-region defaults stop existing. Any nuance you have built around a denied state has to live entirely inside Consent Mode now — and most CMP integrations were not designed to express that nuance.
Third, the entire weight of compliance moves to a system that sits closer to Marketing than to Privacy. Consent Mode is configured in Google Ads, by people whose performance metrics reward conversion tracking, audience size, and ROAS — not consent fidelity. The June 15 change effectively assigns the legal authority for whether your organisation is processing personal data for advertising purposes to the team most likely to favour the granted state. That is not necessarily a problem if the governance is right. It is absolutely a problem if it is not.
The Four Scenarios Worth Mapping
Before the cutover, every privacy lead overseeing a Google Analytics-Google Ads linkage should know which of these scenarios applies to their organisation. The required response differs in each.
Scenario 1: Signals on, Consent Mode v2 implemented correctly, EEA/UK defaults set to denied. The June 15 change is largely a non-event. Behaviour does not materially shift. Action: confirm signal accuracy, document the change in your records, and update your DPIA and notice to reflect the new architecture. Estimated effort: low.
Scenario 2: Signals on, Consent Mode v2 implemented correctly, defaults granted globally. The June 15 change is also a non-event behaviourally, but the underlying compliance posture (likely already shaky for EEA traffic) is now exposed without any Analytics-side mitigation. Action: re-examine whether the global-grant default is defensible under GDPR Art 6 / ePrivacy Art 5(3) for users in the EEA, UK, and Switzerland; almost always, the answer is no, and a region-specific default-denied configuration should have been in place already. Estimated effort: medium to high — this is fixing an existing problem the cutover merely makes more visible.
Scenario 3: Signals off, Consent Mode v2 implemented but ad_storage defaults granted in EEA/UK. This is the most common high-risk scenario in the wild. Today, advertising data collection is being prevented by Signals being off; the CMP is permissive but it does not matter, because Signals is the binding constraint. After 15 June, the CMP becomes the binding constraint, and the CMP says “yes.” Behaviour will change overnight: Google Ads will start linking users to their Google sign-ins, sending advertising cookies and identifiers, and using the data for measurement and (eventually) personalisation. The privacy notice almost certainly does not describe this. The DPIA almost certainly does not contemplate it. The lawful basis analysis is unlikely to support it. Action: this is your priority response. Either set the regional default for ad_storage to denied (and ensure the CMP only flips it to granted on affirmative consent) or accept the new state and update notices, DPIAs, and lawful-basis analysis accordingly. Estimated effort: medium, but urgent.
Scenario 4: Signals off, Consent Mode v2 implemented with regional defaults denied. The June 15 change preserves your privacy posture, because the CMP correctly defaults ad_storage to denied for EEA/UK traffic. Action: validate signal accuracy on a pre-cutover basis, then on a post-cutover basis. Watch for changes in modelled conversion volumes — if they shift dramatically on 15 June, you have a signal-correctness problem to investigate. Estimated effort: low to medium.
If you do not know which scenario applies to your organisation, the honest answer is Scenario 3 until proven otherwise. The Signals-off-by-default deployment was widespread, and the assumption that this constituted privacy compliance was widespread.
The Compliance Implications Most Coverage Skips
The trade press has covered the operational impact thoroughly. The legal exposure has been undersold. Three areas matter.
Lawful basis under GDPR and ePrivacy. Setting non-essential cookies and identifiers in the EEA, UK, and Switzerland requires consent under Article 5(3) of the ePrivacy Directive (or its UK PECR equivalent), and any subsequent processing of the resulting personal data requires a lawful basis under Article 6 of the GDPR. Today, Signals-off has been doing some of the load-bearing work for organisations whose CMPs were technically compliant but loosely configured. After 15 June, the CMP has to do all of the work. If your CMP defaults ad_storage to granted in EEA traffic, that has been a problem for a long time, but it has been a less visible problem because Signals was off. The cutover does not create the legal exposure. It removes the obfuscation that has been hiding it.
Notice and transparency. Article 13 of the GDPR requires controllers to inform data subjects of the categories of recipients and the purposes of processing at the point of collection. If your privacy notice describes Google Ads as receiving “aggregate” data, “modelled” conversions, or “non-identifying” measurement, and after 15 June Google Ads starts receiving identifier-linked data because ad_storage is granted, your notice is now inaccurate. CNIL, the Italian Garante, and the Hamburg DPA have all enforced against inaccurate notices in this exact area. The window to update the notice closes when the architecture changes, not when someone files a complaint.
DPIA refresh obligations. Article 35 of the GDPR requires a DPIA for processing likely to result in high risk to data subjects, and Article 35(11) requires the controller to “review processing operations in case of a change of risk.” A material change in how Google’s advertising stack ingests, links, and uses identifier data is a change of risk. The DPIA library entry for “Google Ads measurement” needs to be reviewed against the post-15-June architecture, with documented sign-off, before the cutover lands.
Sensitive data inferences. Recent state legislation — most notably Maryland’s HB 711, signed earlier in April 2026 — treats inferred sensitive data as sensitive personal information regardless of how it was derived. Google’s behavioral targeting infrastructure, applied to identifier-linked browsing data, can readily produce inferred sensitive attributes (health, sexual orientation, political views, immigration status). Organizations operating in jurisdictions that recognise inference-based sensitive data need to factor this into their post-cutover analysis. Granting ad_storage in those jurisdictions is doing more legal work than it used to.
Regulator posture. France’s CNIL has been the most active regulator on cookie compliance in the post-Schrems II era and has explicitly criticized opaque consent architectures and dark-pattern banners. The Italian Garante has been active on Google Analytics specifically. The Belgian DPA has been pursuing the IAB consent framework for years. None of these regulators are going to wait politely for organizations to update their CMPs. The first investigations triggered by the new architecture are likely to focus on exactly the Scenario 3 organisations — those whose CMPs were technically Consent Mode v2 compatible but were defaulting to granted in EEA traffic, with Signals-off masking the underlying issue.
A Pre-Cutover Playbook
Anything you do not finish before 14 June is something a regulator could ask about on 15 June. Here is the order of operations that actually matters.
Week 1 (now): Establish ownership. The Google Signals change is not an ad-ops issue and not a pure privacy issue — it sits across both. Designate a single accountable owner with cross-functional authority, a working group spanning privacy, marketing analytics, web/martech engineering, and legal. The most common failure mode is each function assuming another function is handling it.
Week 2: Identify which scenario applies. For each market you operate in, document the current Signals state, the CMP default state for ad_storage, the CMP default state for ad_personalization, and the per-region overrides actually in production. Distinguish what the system says it does from what the network logs show it does. Tag Diagnostics in Analytics has a 48-72 hour latency, so plan accordingly.
Week 3: Make the policy decision per market. For EEA, UK, and Switzerland traffic, the answer is almost always: regional default-denied for ad_storage, granted only on explicit user consent through a properly designed banner. For US, UK (PECR), and other markets, the answer depends on the regime and your risk appetite. Document the decision and the rationale; this is the artefact a regulator will ask for.
Week 4: Implement and test the CMP configuration. Verify that consent signals are firing correctly on each surface (web, mobile web, native apps, AMP if applicable). Test the granted and denied paths separately. Confirm that the CMP-to-Google handoff is producing the correct values for ad_storage, ad_user_data, and ad_personalization. Pay particular attention to the AMP and native-app paths, which have historically been where Consent Mode implementations break.
Week 5: Update the privacy notice, DPIA library, RoPA entry, and any customer-facing documentation that references how advertising data is handled. Update the controller-to-controller and controller-to-processor analysis for Google’s role under the new architecture (Google has been explicit that the linkage now flows under Google Ads control, which has implications for Article 26 controller-to-controller analysis where applicable).
Week 6 (week of 8 June): Final pre-cutover validation. Compare the documented intended state against the live signal state. Lock the configuration. Communicate the change internally so that anyone monitoring conversion data on 15 June is not surprised by a step change.
Cutover (15 June): Monitor signal accuracy and modelled conversion volumes for the first 72 hours. Sudden divergences in either direction usually indicate signal-firing problems rather than user-behavior changes.
Post-cutover (weeks 1-4): Set up ongoing monitoring as a standing operational task. Tag Diagnostics integration, network log sampling, regular CMP regression testing. Treat this as a load-bearing control, not a one-time project.
The Bigger Picture
The Google Signals retirement is one move in a multi-quarter consolidation. Google has spent the last eighteen months collapsing fragmented controls — first by introducing Consent Mode v2’s four core parameters in late 2023, then by hardening enforcement against non-compliant EEA/UK advertisers in mid-2025, then by adding the in-product Tag Diagnostics in mid-2025, then by introducing hidden data transmission controls in late 2025, and now by removing the redundant Signals lever in mid-2026. The ad_personalization consolidation later in 2026 and the IP address routing change after that are the next pieces of the same trajectory.
For privacy teams, the strategic implication is uncomfortable but clear. Google’s consent architecture is becoming the load-bearing privacy control for any organisation using Google Analytics and Google Ads — and that control is configured in tools your privacy team probably does not own, by people whose KPIs reward the granted state. The only way to keep this safe is to bring CMP configuration, ad-tech consent signal monitoring, and Consent Mode parameter governance into the privacy program itself. Not as something the marketing analytics team owns and reports on. As something privacy specifies, validates, and signs off on.
June 15th is the forcing function. The organizations that use the next seven weeks to formalize that ownership will land the cutover and have a stable post-cutover posture. The ones that treat it as an ad-ops update will discover, in some cases on 16 June, that their privacy posture changed without anyone deciding it should.
