Skip to content
Home Guides Compliance
Compliance Intermediate

Consent Mode Basic vs Advanced: What Actually Changes

The technical difference between basic and advanced consent mode, what each one sends before consent, which modelling thresholds Google documents and how to decide which one belongs in your setup.

Fabian Weiss, founder of FW Delta Fabian Weiss
10 min 1 to 2 hours to assess, longer to implement
The Problem

Teams switch on advanced consent mode because it sounds better, without understanding what it sends before consent or whether their volume is enough for modelling at all

The Fix

Understand the four consent signals, what each mode does before and after the decision, know the documented thresholds and decide deliberately

Google Tag ManagerGoogle Analytics 4Google Ads

The choice is not technical, it is a policy decision with a technical implementation

Consent Mode v2 is often reduced to a toggle in a consent management platform. That framing hides the actual question. The two modes differ in one thing: what happens before the visitor has decided anything.

Everything else, the four signals, the update mechanism, the testing, applies to both. Google describes both variants in its consent mode overview.


The four signals

Consent Mode v2 separates at least four states and they are independent of each other:

SignalGoverns
analytics_storageStorage used for analytics, for example the GA4 client ID
ad_storageStorage used for advertising, for example conversion cookies
ad_user_dataWhether user data may be sent to Google for advertising purposes
ad_personalizationWhether the data may be used for personalised advertising

Google also defines functionality_storage, personalization_storage and security_storage. They do not govern Google advertising or analytics tags, but they are useful for consent checks on your own tags in Tag Manager.

The two ad_ signals introduced with v2 are the ones most setups get wrong, because a banner that only offers “analytics” and “marketing” has to map two categories onto four signals. That mapping needs to be a written decision, not an accident of the CMP defaults. For users in the EEA Google requires the two ad_ signals, otherwise personalisation and remarketing are lost (Obtain user consent).


Basic mode

In basic mode, the Google tags do not load until the relevant consent has been granted.

Before the decision:

  • no measurement events are sent, according to Google not even the default consent state (About consent mode in Google Ads)
  • no Google tag executes
  • nothing is stored on the device by these tags

After acceptance:

  • the tags load and measurement starts from that point
  • there is no retroactive replay of what happened before the decision
  • a visitor who accepts on the entry page is measured there as soon as the tag fires; everything before that, earlier pages and everyone who left before deciding, stays invisible

On rejection:

  • the tags never fire and nothing reaches Google
  • Google Ads falls back to a general model for conversion modelling, not one that works with your account’s own data
  • GA4 does not model the behaviour of users who rejected, because behavioural modelling requires the advanced implementation (Behavioral modeling)

Consequence: basic mode produces a clean, easily explainable data set with a visible hole. The hole is the size of your rejection rate plus everyone who left before deciding.


Advanced mode

In advanced mode, the Google tags load immediately, but they respect the denied state by sending cookieless signals instead of storing identifiers.

Before the decision:

  • the tags are present and send the default state plus signals without device storage
  • the signal carries no identifier that persists beyond the page load

On rejection:

  • the tags keep sending cookieless signals rather than nothing
  • Google documents three kinds: consent state pings, key event pings and analytics pings on page load and on events
  • according to Google these pings contain a timestamp, user agent, referrer, an indicator of ad clicks in the URL, the consent state as yes/no values, a random number per page load and the identifier of the consent platform (About consent mode in Google Ads)
  • Google can use those signals as an input to conversion modelling, in that case with an advertiser-specific model

Consequence: advanced mode produces more complete reporting, at the cost of transmitting something in a state where basic mode transmits nothing at all. That is exactly why the decision is not purely technical.


What neither mode does

Both modes are frequently oversold. To be precise:

  • Neither mode replaces a consent banner. Accessing or storing information on a device still requires consent. Google itself lists a banner as a prerequisite.
  • Neither mode makes a setup compliant on its own. Compliance depends on the banner, the privacy policy, the legal bases and the processing agreements.
  • Neither mode recovers the data of users who rejected. Advanced mode enables modelling; modelling is an estimate, not the raw event.
  • Modelling is not guaranteed. It has documented thresholds. Google Ads requires 700 ad clicks over 7 days per country and domain grouping (consent mode modeling). Behavioural modelling in GA4 requires at least 1,000 events per day with analytics_storage denied for at least 7 days and at least 1,000 daily users with analytics_storage granted on at least 7 of the previous 28 days. Even then Google does not guarantee activation (Behavioral modeling). A small site may see no modelled conversions at all, which makes advanced mode a lot less attractive than the marketing suggests.

What changed in 2026

Three changes affect the decision directly.

Since 15 June 2026 the consent signal alone controls which ads data flows from Google Analytics to Google Ads. Before that, collection of Google Ads cookies depended on both the Google Signals toggle in GA4 and consent mode. Now consent mode is the single control for it. The Google Signals toggle only governs whether GA4 data is associated with signed-in users for behavioural reporting. Google has also announced two further steps: Later in 2026 ad_personalization alone decides whether data is used for personalisation in the Ads account. IP addresses collected by the Google tag flow encrypted to the linked Ads account (Updates to Google Analytics data controls). For you this means: the mapping of ad_user_data and ad_personalization in your banner is no longer a formality, it decides what reaches Ads. The old escape hatch “switch off Google Signals and be done” no longer exists.

Since 20 August 2026 Google tag and Tag Manager are merged. Google tags are now fully capable Tag Manager containers with an interface, debugging and version control. Existing pages do not change automatically. New deployment snippets omit the gtag('config') call, initialisation behaviour is configured through the gtm init trigger (Google tag and Tag Manager merged). For the consent default this means the same tool for both paths: the “Consent Initialization” trigger (according to Google it always fires before all other tags) and the consent overview under Admin, Container Settings (Consent mode in Tag Manager).

The Google tag gateway for advertisers exists. With it the Google tag loads through your own domain and measurement events go to your domain first, which forwards them to Google, via Cloudflare, a CDN or a load balancer, with no change to the tag code on the page (Google tag gateway for advertisers). That changes the transport path, not the consent logic: the same tag with the same consent checks runs, just through your host. The basic or advanced question arises with the gateway exactly as without it and the consent requirement remains.


How to decide

Work through these questions in order. The first “no” usually settles it.

1. What does your legal assessment say? This is the gate. If your counsel or your data protection officer has taken a position on cookieless pings before consent, that position decides the question. Everything below only matters if advanced mode is on the table at all.

2. Do you have the volume for modelling to do anything? Modelled conversions need enough traffic and enough conversions to be produced at all. Use the thresholds above: 700 ad clicks in 7 days per country and domain grouping for Google Ads, 1,000 denied events per day and 1,000 consenting users per day for GA4. Below that, advanced mode adds transmission without adding reporting.

3. What is your actual rejection rate? If most visitors accept, the gap that advanced mode addresses is small. Measure it before you optimise it.

4. Does the ad spend justify it? The commercial argument for advanced mode is better bidding signals. With little or no ad spend, that argument does not exist.

5. Is the rest of your measurement correct? This is the one people skip. Advanced mode on top of a broken purchase event produces more complete transmission of the wrong number. Fix the web tracking foundation first.


Implementation checklist

Whichever mode you land on, these have to hold:

  1. The default state is set before any Google tag executes, not after. In Tag Manager it belongs on the “Consent Initialization” trigger. In a custom deployment the call sits before the tag loads (Set up consent mode):
gtag('consent', 'default', {
  'ad_storage': 'denied',
  'ad_user_data': 'denied',
  'ad_personalization': 'denied',
  'analytics_storage': 'denied',
  'wait_for_update': 500
});
  1. wait_for_update is set if your consent platform loads asynchronously. The value in milliseconds gives the banner time to deliver the stored state via update before the tags send data. Without it a returning visitor who accepted long ago can be treated as a rejecting visitor on the first hit.
  2. The update state is sent after the decision and you have verified it in the network request rather than in the banner UI. In Tag Assistant Google shows the columns “On-page Default” and “On-page Update” per consent event. Before the decision it must read “Denied”, afterwards the actual state.
  3. All four signals are mapped from your banner categories, with the mapping written down.
  4. Rejection is tested and produces the expected behaviour.
  5. Partial consent is tested. Analytics-only is the case most setups fail.
  6. Withdrawal is tested. A visitor who revokes mid-session must stop being measured.
  7. Later acceptance is tested. A visitor who accepts on page three must be measured from page three.
  8. Non-Google tags have an additional consent check in Tag Manager. According to Google only the Google tag, Google Analytics, Google Ads, Floodlight and Conversion Linker have built-in checks (About consent mode in Google Ads).
  9. No first-party customer data is sent for enhanced conversions without the required consent. ad_user_data is the signal that governs sending user data to Google for advertising purposes.
  10. The behaviour is documented, including known limits, so the next person does not have to reverse-engineer it.

The Shopify and WordPress case

If you run a WordPress main site and a Shopify shop, you almost certainly have two consent systems. Shopify has its own Customer Privacy API; WordPress typically has Borlabs, Cookiebot, Usercentrics or similar.

The Shopify side has three particularities you need to know:

  • Shopify has four purposes: Analytics, Marketing, Preferences and Sale of Data. These have to be mapped onto the four Google signals. For the Google channel this happens through the customer privacy settings, a third-party banner has to be integrated with those settings according to Shopify and a custom pixel needs its own consent mode call (Understanding customer privacy settings).
  • In regions that require consent such as the EEA and the UK, web pixels according to Shopify only run once the permissions required in the pixel configuration have been granted (Configuring customer privacy settings). An advanced mode in the classic sense, where the tag loads before the decision, therefore requires a deliberately configured pixel permission there.
  • Checkout must share the same root domain as the storefront, otherwise it cannot read the consent decision.

Two systems mean two decisions to reconcile. Either you unify them or you document why a visitor who accepted on one surface may be treated differently on the other. Leaving it undocumented is how audits get uncomfortable.

The Shopify tracking checklist covers the shop side of this in detail.


Where this fits

Consent handling is one block of a measurement setup, not the whole of it. It belongs alongside a correct event model, working conversion actions and reliable transaction IDs. The GA4 and Consent Mode v2 service covers the consent layer in depth; the web tracking service covers the full measurement foundation around it.

FW Delta implements the technical consent handling. The legal assessment of the texts and legal bases stays with the client and their advisers. This guide is a technical explanation, not legal advice.

Newsletter

Research for technical decisions

New reports, benchmarks and technical analyses on SaaS economics, AI engineering and owned infrastructure.

Original research Public sources No sales mail

By subscribing you receive new analyses and updates from FW Delta by email. You can withdraw your consent at any time. Further information is available in the privacy policy.