Consent Mode v2: Basic vs Advanced, and what your pre-consent network tab should look like

Correction 2026-09-27: an earlier version of this piece said the free scan checks a page across three consent states and 25 pages. The free scan runs one page through all three consent states; the 25-page, multi-state crawl is the paid full audit, and it walks pages beyond the start page only under a live reject-all and accept-all.

Google Consent Mode is one of the most implemented and least verified pieces of marketing infrastructure on the web. Every CMP claims a one-click integration; every agency has a checkbox for it. When someone finally opens the network tab, the signals being sent frequently do not match what the banner says.

Privado's June 2026 scan of the top 250 sites by traffic found that 48% had at least one Consent Mode misconfiguration. In Europe, 28% defaulted to a granted state before anyone had clicked, and 19% failed to switch to denied after "reject all". These are sites with CMPs, tag governance and legal review. The gap is between configuration and behaviour, and the only way to close it is to observe the behaviour.

This article explains what the two implementations actually do, shows what a correct pre-consent network tab looks like for each, and lists the misconfigurations to hunt for.

What Consent Mode is, and what changed in v2

Consent Mode is a signalling layer. Your CMP tells Google's tags what the visitor has consented to, and the tags change their behaviour accordingly. It does not, by itself, block anything; it modifies how Google's own tags (GA4, Google Ads, Floodlight) behave. Non-Google tags are unaffected unless your tag manager gates them separately.

The original version carried two signals: ad_storage (may advertising cookies be set?) and analytics_storage (may analytics cookies be set?). Version 2, which Google rolled out ahead of the Digital Markets Act, added two more: ad_user_data, which "sets consent for sending user data related to advertising to Google", and ad_personalization, which "sets consent for personalized advertising". Google's own help documentation is explicit about the consequence for EEA advertisers: since March 2024, both ad_user_data and ad_personalization must be GRANTED for Customer Match lists to be used in the EEA, and data from unconsented EEA users is not processed for ad personalisation. The same logic applies to remarketing audiences and enhanced conversions: no v2 signals, no EEA audiences.

Three further signal types exist (functionality_storage, personalization_storage, security_storage) but they are not what enforcement and measurement conversations are about.

The mechanism is two gtag commands. A default command sets the starting state and must run before any measurement command on every page. An update command changes the state when the visitor interacts with the banner. The optional wait_for_update parameter tells tags how many milliseconds to wait for the CMP before firing, which prevents the race where GA4 fires before the CMP has loaded a stored choice.

Basic vs Advanced: the actual difference

Google describes the two implementations in its Analytics help and Ads help. Stripped of vendor marketing:

Basic Consent Mode. Google tags are blocked until the visitor grants consent. Nothing is sent to Google before the click; if the visitor rejects, nothing is ever sent. Google still offers conversion modelling for Basic, but Ads modelling uses a general model rather than an advertiser-specific one. Basic is what a strict reading of ePrivacy and most DPA guidance points to: no tag loads, no data leaves, until consent.

Advanced Consent Mode. Google tags load before the consent dialog appears and "send cookieless pings when cookie consent is declined". Those pings carry no cookies and no client ID; they contain coarse information such as timestamp, user agent, referrer and the consent state itself. In exchange you get an advertiser-specific model and GA4 behavioural modelling. You also get a legal question: is a cookieless ping to Google, sent for a visitor who has not consented, "accessing information on the terminal equipment"? Google says no cookies are read or written; DPAs have not answered directly, and the CNIL's cookie decisions turn on what is stored and read. Most compliance teams treat Advanced as defensible only after a documented legal review and a clean pre-consent state elsewhere.

The practical rule: Basic is a blocking implementation; Advanced is a signalling implementation. Under Basic, an unconsented visitor's network tab shows no Google measurement requests at all. Under Advanced, it shows requests whose consent parameters say "denied" and whose payloads carry no identifiers. Both are legitimate. What is not legitimate is a site that believes it is running one while its network tab shows the other.

What the pre-consent network tab should look like

Open an incognito window, open DevTools before loading the page, tick Preserve log in the Network tab, and load the site. Do not click the banner. Then filter.

If you run Basic

Filter on collect, doubleclick, googleads, googlesyndication. You should see:

• googletagmanager.com/gtm.js?id=GTM-... (loading the container is not measurement).
• No /g/collect request to google-analytics.com, analytics.google.com or any regional collector.
• No pagead/viewthroughconversion, pagead/1p-user-list, td.doubleclick.net or googleads.g.doubleclick.net requests.
• In Application → Cookies: no _ga, _ga_*, _gid, _gcl_au, _gcl_aw, IDE (on doubleclick.net) or test_cookie.

If you see a /g/collect hit under Basic, the implementation is not Basic, whatever the CMP dashboard says. Either the GA4 tag has no consent requirement in GTM, or the default state was never set to denied, or the tag fires before the CMP's default command runs.

If you run Advanced

You should see Google requests, but each one should be marked denied. Open any /g/collect request and look at the query string:

• gcs=G100. The gcs parameter encodes ad_storage and analytics_storage as G1xy: G100 is both denied, G110 ads granted only, G101 analytics granted only, G111 both granted. Pre-consent, in the EEA and UK, the only acceptable value is G100.
• gcd=.... This is the v2 parameter and it appears in every hit. Its format is a string like 13l3l3l3l1 or 13p3p3p3p1 encoding all four consent signals plus their history; letters l and p denote denied or not set, and letters such as t, r, v denote granted. Before consent you should see only l or p in the four signal positions. If you see t or v, a signal was granted by default.
• npa=1 (non-personalised ads) on Ads requests when ad_personalization is denied.
• No _ga cookie in Application → Cookies, and no cid parameter with a stable value across pages. A cookieless ping has no client ID to carry.

The simplest cross-check is Google's Tag Assistant (tagassistant.google.com): connect, do not touch the banner, and open the Consent tab for the first events. If it shows analytics_storage: granted on the first page view while your CMP says the default is denied, the default command is not reaching the tag.

Either way: the ordering check

In the waterfall, the CMP script and the consent default should complete before the first Google measurement request. GTM's "Consent Initialization – All Pages" trigger fires before all other triggers including Initialization for exactly this reason. A CMP tag on "All Pages" instead is racing GA4 and will sometimes lose.

The misconfigurations that show up in scans

1. Default set to granted. Some CMP templates and hand-written gtag('consent','default', ...) snippets set everything to granted and rely on the update command to switch to denied. Under Advanced, the first hits of every session then carry gcs=G111. Privado found 28% of European sites defaulting to granted. Fix: default to denied for every signal wherever consent is required, and set wait_for_update to 500 ms or more.

2. Region-scoped defaults that miss the visitor. The default command accepts a region array, and country lists drift: the EEA is not the EU, the UK is neither, Switzerland is its own case. Fix: a global denied default with granted exceptions only where you have legal cover, not the reverse.

3. Update never fires on reject. The CMP sends update on accept but not on reject, or only for the two v1 signals. The stored preference says "rejected"; the tag still sees the default. This is the 19% of European sites that fail to move to denied after "reject all". Fix: verify in Tag Assistant that all four signals transition to denied on reject.

4. Consent Mode on, gating off. Consent Mode only governs Google's tags. A perfect gcs=G100 on GA4 pings while the Meta pixel, LinkedIn Insight Tag and Microsoft Clarity fire freely has decorated the Google slice of the problem. Use GTM's additional consent checks on every non-Google tag, or the CMP's script-blocker for hard-coded ones.

5. Server-side tagging that re-identifies. A server-side GTM endpoint receives a cookieless ping and, because a first-party cookie is available server-side, attaches a client ID before forwarding to Google. The browser looks clean; the server log does not. Check the request to your server container endpoint (often sgtm. or metrics. on your own domain) for cookie headers and any cid or _ga value in the forwarded payload.

6. Believing the dashboard. CMPs record a choice but "were not built to verify if it is enforced across the tags and third parties that fire on a page". A green tick in the CMP admin is a statement of intent.

Why the stakes rose in 2026

Two things changed this year. On 15 June 2026, Google removed the Google Analytics setting that limited personal data sent to Google Ads for cross-device remarketing, so a granted-by-default misconfiguration now flows further into advertising systems. And enforcement decisions are naming the behaviours a network tab reveals: the CNIL's SHEIN decision cites cookies placed before banner interaction, a "Refuse all" button that did not work, and continued reading of cookies after withdrawal. Consent Mode does not create those problems, but a misconfigured one creates the evidence of them, hit by hit, in query strings any investigator can read.

A nine-line checklist

1. Default command sets all four v2 signals to denied for every region where consent is required.
2. Default runs on the Consent Initialization trigger, before any measurement tag.
3. wait_for_update is set (500 ms is Google's example) so stored choices are read before tags fire.
4. Under Basic: no Google measurement requests pre-consent, no _ga/_gcl cookies.
5. Under Advanced: every pre-consent Google request shows gcs=G100 and a gcd string with no granted markers.
6. Reject all transitions all four signals to denied; verify in Tag Assistant's Consent tab.
7. Accept all transitions all four to granted, and _ga/_gcl_au appear only then.
8. Every non-Google tag has an explicit consent requirement or is blocked by the CMP.
9. Server-side endpoints do not re-attach identifiers to denied pings.

If you can tick all nine by looking at the browser rather than a dashboard, your implementation is verified. If you would rather have it checked automatically, the full audit loads your page in all three consent states and then walks up to 25 pages under a live reject-all and accept-all, with gcs/gcd decoded per request. The free scan at tagpatrol.app runs one page through all three consent states and shows the five most serious findings. That is usually enough to know whether the rest is worth a look.

Written by TagPatrol's AI content team and reviewed under human direction.