Since June 15, 2026, the Google Consent Mode ad_storage parameter is the sole control over whether advertising data collected by your Google Analytics tags reaches your Google Ads account. The Google Signals toggle in the Analytics admin no longer restricts that flow. If your team set its Consent Mode defaults once during the v2 rollout and has not revisited them since, an ad_storage default of granted is now sending Google Ads the data that the Signals setting used to hold back, and nobody on your side had to change anything for that to start.
Key Takeaways
- Google's own documentation states that from June 15, 2026, "your users' privacy selections, managed via Ads Consent Mode settings, will exclusively govern how data is collected and used," and that the Google Signals setting and API "will only control the association of your Google Analytics sourced data with signed in user information for behavioral reporting." Turning Signals off is no longer a brake on Google Ads data collection; it only narrows signed-in-user reporting inside GA4.
- Privado AI's June 25, 2026 scan of the top 250 US and European sites by traffic found 28% of European sites defaulting Consent Mode to granted before the visitor selects anything, and 19% failing to switch to denied after a reject-all. Both misconfigurations previously carried a partial backstop and now carry none.
- Privacy notices and processing records written to describe the old two-control flow now describe a data flow that no longer exists, which is a transparency problem independent of the tagging problem.
- Regulators are not the only enforcement route. Google has run periodic audits under its EU user consent policy since introducing the policy in 2015, and its reviewers check whether cookies are placed before consent is obtained. Google states that a partner who does not engage or show a good-faith effort toward compliance may face action on the accounts in scope, including suspension of ad personalization and remarketing.
- Google says the ad_personalization parameter will similarly become the exclusive control over personalization in your Ads account later in 2026, but has not published a date.
What changed in Google Consent Mode on June 15, 2026
Before that date, two independent switches sat between your site and Google Ads. The Google Signals setting inside the Analytics admin governed whether Analytics-sourced advertising data could be used for ads purposes, and the Consent Mode ad_storage parameter governed whether the tag was permitted to read or write advertising cookies and identifiers in the first place. Both had to permit the flow for the full signal to arrive.
Google collapsed that into one. Its Analytics Help notice on updates to data controls confirms Consent Mode now governs collection and use exclusively, and reassigns Google Signals to a narrower job: linking Analytics data to signed-in user information for behavioral reporting within GA4. The mechanism is a deliberate consolidation of authority. Google has moved the decision out of a product setting buried in an admin panel and into the consent signal your site sends on every page load. Simo Ahava, who documented the change as it landed, described the intent as moving "towards a single source of truth for Ads consent rather than have obscure (and often hidden) GA settings affect the data flow."
The practical consequence is that your Google Consent Mode configuration is now load-bearing in a way it was not in May. Anyone who had Signals switched off as a precaution (a common posture at organizations whose legal team was uneasy about cross-device identification) has lost that precaution without being asked.
| Control | Before June 15, 2026 | Since June 15, 2026 |
|---|---|---|
| Consent Mode ad_storage | One of two controls gating advertising data to Google Ads | Sole control gating advertising data to Google Ads |
| Google Signals setting (Analytics admin) | Gated whether Analytics-sourced advertising data could be used for ads | Controls only the association of Analytics data with signed-in user information for GA4 behavioral reporting |
| Effect of ad_storage defaulting to granted | Advertising data flow partly limited if Signals was off | Advertising data flows; nothing else limits it |
| Effect of switching Google Signals off | Reduced advertising data reaching Google Ads | No effect on advertising data reaching Google Ads |
| Consent Mode ad_personalization | Governs personalization signaling | Google states it will become the exclusive control over Ads personalization later in 2026; no date published |
Read the right-hand column as your current configuration, not as a forecast. If you do not yet know which state your own tags are in, the Tag Assistant procedure further down settles it in about five minutes, without a developer.
Why a granted ad_storage default is a bigger exposure than it was
A default of granted has never been defensible in the EEA or the UK. Article 5(3) of the ePrivacy Directive requires consent before storing or accessing information on a user's device unless it is strictly necessary, and advertising cookies are not strictly necessary. Google's own advertising and measurement cookie reference lists _gcl_au, one of the cookies its ads products rely on, with a maximum lifetime of 90 days, so a single pre-consent page load can leave an advertising identifier on the device for a quarter. What changed on June 15 is not the legality — it is the size of what a single wrong default now releases.
The mechanism is straightforward. A misconfigured default used to produce a partial leak: the tag would write an advertising cookie, but if Signals was off, the downstream ads use of Analytics-sourced data was constrained. Now the same misconfiguration produces the full flow, including the cross-device linkage Signals used to gate. As Ahava put it, there is no middle setting left: grant ad_storage and Google uses the ads signals available to it, deny it and Google works from what is in the URL and nothing else.
Privado AI's report, published June 25, 2026 and based on a scan of the 250 highest-traffic sites in the US and Europe, found 48% carrying at least one Google Consent Mode misconfiguration: 28% of European sites defaulting to granted before any user selection, 19% failing to flip to denied after a reject-all, and 40% of Californian implementations staying granted after a Global Privacy Control opt-out. Vaibhav Antil, Privado AI's co-founder and CEO, framed the gap plainly: "Collecting consent and enforcing it are two different things."
Regulators have already shown what they do with pre-consent advertising cookies. The CNIL's €325 million decision against Google of September 1, 2025 (split €200 million against Google LLC and €125 million against Google Ireland) turned in part on consent for personalized advertising cookies that the authority found was "neither free nor informed." Enforcement has consistently targeted the gap between what a banner records and what the tags actually do, which is precisely the gap the June 2026 change widens.
If your organization runs Google tags in Europe and cannot currently demonstrate the denied-by-default state, the cookie blocking and consent logging in Secure Privacy's Cookie & Consent Solution is designed for exactly this: trackers do not load until the visitor agrees, and every consent event, accepted or declined, is logged and exportable as the evidence trail.
Google audits this itself, separately from any regulator
A regulator is not the first party likely to look at your banner. Google is. Its EU user consent policy is a contractual condition of using its advertising products for end users in the European Economic Area, the UK and Switzerland, and it requires legally valid consent for the use of cookies or other local storage where legally required, and for the collection, sharing and use of personal data for ads personalization. For EEA traffic, Google's own guidance is explicit that you need to pass end-user consent choices through to Google, giving consent mode or the IAB TCF as the ways to do it.
That policy is enforced through inspection, not self-declaration. Google says it has conducted periodic audits of websites and apps using its advertising services since introducing the policy in 2015, with reviewers visiting sites as an ordinary user would. The published audit criteria include whether a consent mechanism is present, whether disclosures name ads personalization, whether the user can take an affirmative action, whether third-party data sharing is disclosed, whether consent signals are implemented properly, and whether cookies are placed before consent is obtained. Google allows a reasonable timeframe for remediation, and states that a partner who fails to engage or to demonstrate a good-faith effort toward compliance may see action on the accounts in scope, including suspension of audience functionality such as ad personalization and remarketing, and restrictions on conversion measurement.
The two enforcement routes now examine the same object. A granted default that a regulator would treat as consent obtained unlawfully is the same defect a Google reviewer records as cookies placed before consent, and since June 15 there is no Signals setting sitting behind it to limit what that defect releases.
One scoping detail follows from the policy's territory list: it covers Switzerland alongside the EEA and the UK. A region array that names only EEA and GB leaves Swiss visitors on whatever your global default is, which is a gap worth closing in the same edit rather than a separate project.
The four Google Consent Mode parameters, and which one this change touches
Consent Mode v2 carries four signals, and conflating them is a common source of misconfiguration:
- ad_storage: permits reading and writing cookies and identifiers for advertising purposes. This is the parameter the June 2026 change elevates to sole gatekeeper for Google Ads.
- ad_user_data: permits sending advertising-related user data to Google. Covered in more depth in our breakdown of what ad_user_data actually does.
- ad_personalization: permits personalized advertising. Google has said this becomes the exclusive control over personalization in your Ads account, later in 2026.
- analytics_storage: permits analytics cookies and identifiers.
For visitors in the EEA, the UK and Switzerland, the correct configuration sets all four of those parameters to denied before any tag reads consent, and updates them to granted only on an affirmative acceptance. Google's tag documentation is explicit that defaults must be scoped to the regions where you surface a banner, and that consent updates must be captured on the page where the interaction happens, before any navigation. A minimal default looks like this:
gtag('consent', 'default', {
ad_storage: 'denied',
ad_user_data: 'denied',
ad_personalization: 'denied',
analytics_storage: 'denied',
region: ['EEA', 'GB', 'CH']
});Two further consolidations are announced without dates, and both move control to the Ads side. Google's notice says the ad_personalization parameter will exclusively control whether data is used for personalization in your Ads account, and that IP addresses automatically collected by the Google tag and SDK will be encrypted and flow to your linked Google Ads account, where they are then controlled by Google Ads and used in accordance with your Google Ads settings. Google has committed only to sharing exact dates later in the year. The planning consequence is that the governing layer moves into Google Ads settings, which at most organizations sit outside the privacy team's review scope, so an inventory of who holds edit access there is worth doing before the dates land rather than after.
Basic versus advanced consent mode changes what "denied" means
The two implementation modes behave differently in the denied state, and the difference matters for how you describe your processing. In basic consent mode, Google's Ads documentation states tags are blocked until the user interacts with the banner, and nothing is transmitted before that point, not even the consent status. In advanced mode, tags load with defaults set to denied, and when consent is denied, consent state and cookieless pings are still sent. Advanced mode also uses an advertiser-specific conversion model rather than a general one.
Advanced mode's cookieless pings are what feed conversion modeling, and modeling is where teams expect the measurement loss to be recovered. It is not automatic. Google's documentation on consent mode modeling sets two quality checks before an account enters the training period that produces modeled conversions: consent mode or the IAB TCF v2.0 has to be correctly implemented, and the account needs a threshold of 700 ad clicks over a seven-day period, per country and domain grouping. Below that volume, Google Ads can report consent mode as implemented while no modeling is active, which is the state a small or single-market account is most likely to be in. Read the per-country wording carefully: an account clearing 700 clicks in aggregate across six European markets may clear it in none of them individually.
Neither mode is wrong. But an organization running advanced mode and telling users that no data leaves the site before consent has a disclosure inaccuracy, regardless of how correctly the parameters are set. If you have not confirmed which mode your Google Tag Manager setup is actually running, that is the first thing to establish.
How to verify your own state without a developer
Google's Tag Assistant exposes the consent state directly, and the check is a UI procedure a compliance owner can run alone.
- Open Tag Assistant and connect to your site. Load a page as a first-time visitor, with no prior consent stored: a fresh incognito window with any existing consent cookie cleared.
- In the Summary, select the earliest consent event. In the tag's Output section, open the Consent tab.
- Read the On-page Default column. All four advertising and analytics parameters should show denied for a visitor in the EEA, the UK or Switzerland. If ad_storage shows granted, or shows nothing at all because no default was ever set, you have found the problem.
- Accept on the banner, then select the most recent consent event and read the On-page Update column. The values should now reflect what the visitor chose, not a blanket grant regardless of which button they pressed.
- Check the tags list in the Summary and confirm which tags fired and which were blocked. A Google Ads tag that fired in the denied state is a defect, not a reporting quirk.
- Watch for Tag Assistant's timing error, which appears when an ad tag read or wrote a cookie before the default consent was set. Google's own guidance is to move the default consent command above every tag snippet and to fire consent-setting tags on Consent Initialization.
Step 3 is the one that has changed value. Before June 15, a granted default with Signals off produced a constrained leak. Now it produces the whole flow, so the same screen tells you something more serious than it used to.
A common shortcut is to skip Tag Assistant and read the outgoing network request instead. The underlying fact is real: Google's consent mode overview confirms that consent mode parameters are translated into HTTP request parameters including dma, gcd and gcs, and that gcs is the one carrying ad_storage and analytics_storage. The catch is that the same documentation notes these fields can change over time, and points to Tag Assistant for debugging. A decoding table for gcs values copied from a third-party post is therefore a weak foundation for a recurring compliance check, even when it is accurate today. Use the network view to confirm a suspicion; use Tag Assistant for the record.
Common issues and fixes
| What Tag Assistant shows | Likely cause | Fix |
|---|---|---|
| No default consent state at all | No gtag('consent', 'default', ...) command runs before the tags, or the CMP template is not publishing one | Set the four parameters to denied with a region array covering the markets where you show a banner; needs edit access in Google Tag Manager |
| A timing error against an ad tag | An ad tag read or wrote a cookie before the default was set | Move the default consent command above every tag snippet and fire consent-setting tags on Consent Initialization; if the snippet sits in a hard-coded template, this is the point to hand off to a developer |
| ad_storage granted in the On-page Default column | Defaults were set to granted, or the region scoping does not cover the visitor's market | Change the default to denied and verify from an EEA, UK or Swiss vantage point, not only your own location |
| On-page Update shows all parameters granted after a reject-all | The banner records the choice but sends the same update either way | Trace the reject path in the CMP configuration; a recorded refusal that transmits a grant is the exact failure Privado AI measured on 19% of sites |
| Google Ads tag fired while consent was denied | The tag is not consent-gated, or advanced mode is being read as permission to fire normally | Confirm which mode you run, then check the tag's own consent settings rather than assuming the page-level default covers it |
Continuous verification matters more than a one-time pass, because tag inventories drift. Secure Privacy's compliance scanner crawls domains monthly and updates categorization automatically as it detects changes, covering plugins, cookies, TLS and data locations rather than cookies alone. The practical value is that a marketing team adding a tag next quarter does not silently reintroduce the exposure you just closed. Our guide to running a cookie audit covers the manual equivalent.
Your privacy notice now describes a data flow that does not exist
If your privacy notice or cookie policy explains that advertising data reaching Google Ads is governed by both your Analytics configuration and the visitor's consent choice, that statement became inaccurate on June 15, 2026. GDPR Article 13 requires that data subjects be informed about the purposes of processing and the recipients of their data; a notice describing a two-control arrangement that Google has retired is not accurate information about how the processing works.
The same applies to internal documentation. A record of processing activities that lists the Google Signals setting as a control or safeguard for advertising data transfers now lists a control that does not perform that function. Both are correctable in an afternoon, and both are the kind of thing a supervisory authority asks about early. Proving GDPR consent rests on the individual consent event records, but the surrounding disclosures are what a regulator reads first to decide whether your account of the processing is credible.
Automated policy generation helps here mainly because it removes the excuse of effort: Secure Privacy's Cookie & Consent Solution builds cookie declarations and privacy policies through a guided setup and localizes them across 70+ languages, so a change in the underlying data flow becomes an editing task rather than a translation project across every market you operate in.
What to check if your audience sizes moved
Remarketing audiences in GA4 that depended on Google Signals for cross-device reach now reflect only users who granted ad_storage. If your list sizes shifted after mid-June, that is the expected mechanical result of the change rather than a tracking fault — and it is diagnostic. A list that grew is worth investigating, because on a correctly configured banner it should not have.
Do not treat a drop as a reason to loosen the configuration. The reachable audience under a compliant denied-by-default setup is the audience you were always entitled to address; the previous number included reach you were not. If measurement loss is the pressure point, Google's URL passthrough and data redaction features are the sanctioned mitigations: passthrough carries ad click, client and session identifiers in the URL when ad_storage is denied, and redaction routes network requests through a domain without third-party cookies.
Consent rates are the legitimate lever, and they are a design problem rather than a configuration one. Our guidance on implementing cookie consent covers banner design that raises acceptance without crossing into the dark-pattern territory the CNIL penalized. If your properties include apps or connected TV, the same ad_storage logic applies through the mobile SDKs, which we cover separately for Consent Mode on mobile.
Where a CMP fits
The change moves the entire burden onto the consent signal, which means it moves the burden onto whatever sends that signal. A consent platform's job here is narrow and testable: set the correct regional defaults before any tag reads them, block advertising trackers until the visitor agrees, transmit the update accurately on interaction, and keep a retrievable record of each event.
Secure Privacy is a certified Google partner supporting Consent Mode v2, and integrates with Google Analytics, Google Ads, Google Tag Manager and Floodlight. The certified CMP partner detail matters less than whether the integration demonstrably holds tags until consent, which is what the Tag Assistant check above will tell you about any vendor. On scope, Secure Privacy covers 55+ privacy laws, 70+ languages, automated monthly domain scanning, exportable consent logs, DSAR forms with email validation, and a visitor preference center for withdrawal: a consent-and-cookie remit rather than a full privacy governance suite, which is the relevant trade-off if you are comparing against broader platforms. For the specific problem the June 2026 change created, the consent-and-cookie remit is the part that does the work.
If your ad_storage default is wrong today, it is releasing more data than it was in May. The Cookie & Consent Solution sets denied-by-default regional consent, blocks trackers until the visitor accepts, and produces the exportable consent log you would need to show a regulator that the banner and the tags agree.
FAQ
What changed in Google Consent Mode on June 15, 2026?
The Consent Mode ad_storage parameter became the only control over whether advertising data from your Google Analytics tags flows into your Google Ads account. The Google Signals setting in the Analytics admin was narrowed to controlling only the association of Analytics data with signed-in user information for behavioral reporting inside GA4.
Does turning off Google Signals still limit data going to Google Ads?
No. Since June 15, 2026, switching Google Signals off has no effect on advertising data reaching Google Ads. If ad_storage is granted, that flow proceeds, including cross-device user recognition, regardless of the Signals toggle.
What should ad_storage default to for EEA and UK visitors?
It should default to denied, along with analytics_storage, ad_user_data and ad_personalization, and update to granted only after the visitor affirmatively accepts. Article 5(3) of the ePrivacy Directive requires consent before non-essential cookies are stored or read, so a granted default places advertising cookies without a lawful basis.
How do I check whether my ad_storage default is set correctly?
Open Google's Tag Assistant, load your site as a first-time visitor with no stored consent, and read the On-page Default column in the Consent tab of the earliest consent event. All advertising and analytics parameters should read denied; if ad_storage reads granted or is missing entirely, the default is wrong.
Do I need to update my privacy notice because of this change?
Yes, if your notice describes advertising data sharing with Google Ads as governed by both your Analytics settings and the visitor's consent. That two-control description no longer matches how Google operates, and GDPR Article 13 requires accurate information about processing purposes and recipients.
Why did my GA4 remarketing audience sizes change after June 15, 2026?
Audiences that relied on Google Signals for cross-device reach now include only users who granted ad_storage, so sizes reflect actual consent rates rather than Signals-supplemented reach. A decrease is the expected result of the change; an increase suggests your consent signal may be granting more than visitors chose.
Will Google Ads still report conversions if ad_storage is denied?
Partly, through modeled conversions, but only if the account qualifies for modeling. Google requires a correct consent mode or IAB TCF v2.0 implementation plus 700 ad clicks over a seven-day period per country and domain grouping, so accounts below that volume in a given market see the raw reporting loss with no modeling to offset it.
Can Google itself penalize a broken consent setup?
Yes. Google has audited sites using its advertising services under its EU user consent policy since 2015, and states that an account whose owner does not engage or demonstrate a good-faith effort toward compliance may face action, including suspension of ad personalization and remarketing and restrictions on conversion measurement.
Is the ad_personalization change happening too?
Google has stated that the Consent Mode ad_personalization setting will become the exclusive control over whether data is used for personalization in your Ads account, but has not published a date beyond "later in 2026." Google has separately said that IP addresses collected by its tag and SDK will be encrypted and flow to the linked Google Ads account, governed by your Google Ads settings, also without a date.
