Basic vs advanced Consent Mode: which one are you running

The two modes, in one sentence each

Basic Consent Mode blocks Google's tags until the visitor grants consent: deny, and nothing is sent. Advanced Consent Mode loads the tags anyway but sends a stripped down, cookieless ping even on a denied session, carrying the consent state so Google can model the gap. That single behavioural difference, whether a request goes out while consent is denied, is what your browser can see and what tells the two apart.

The reason it matters is not academic. The two modes collect different amounts of data and are configured differently, and plenty of sites believe they are on advanced because someone ticked a box, while the live traffic is quietly running basic. The only reliable answer comes from watching what actually reaches Google, not from reading the tag setup. Here is the check.

How to tell, step by step

Six steps in a browser. The first four give you the answer in under a minute; the last two stop you drawing the wrong conclusion from it.

1. Open the site in a fresh incognito window

   Load your site in a new incognito or private window so there is no stored consent cookie. That gives you the true first visit default state, which is the only state that separates basic from advanced. A normal window with a saved choice already granted hides the difference, because both modes send data once consent is granted.

2. Filter the network panel to Google's requests

   Open developer tools, go to the Network tab, and filter for collect. GA4 sends its hit to a path ending in g/collect, and Google Ads sends to googleads or its conversion endpoint. These are the requests whose presence, and whose contents, answer the whole question. Clear the log and reload so you are watching a clean page load.

3. Deny consent, then watch what fires

   Click reject on the banner and watch the filtered requests. Advanced Consent Mode still sends a cookieless g/collect request on a denied session, so you see one go out. Basic Consent Mode sends nothing at all until consent is granted, so the panel stays empty. That one observation is your first read on which mode you are running.

4. Decode the gcs parameter to confirm the state

   Open the request that fired and read its gcs parameter. It is a three character code: the first digit is 1 when Consent Mode is active, the second is ad_storage, the third is analytics_storage, each 1 for granted or 0 for denied. So gcs=G100 is Consent Mode on with both denied, and gcs=G111 is both granted. Seeing gcs at all on a denied session is the definitive proof of advanced, not a guess from whether a ping appeared.

5. Rule out the broken tag false read

   An empty panel is not automatically basic mode. A tag that was never installed, or one that is failing to load, produces exactly the same empty result. Grant consent and confirm the request then fires. If it never fires in either state, your tag is broken, which is a different and more urgent problem than running basic. This is the step the vendor guides skip, and it is where people misdiagnose a dead tag as a working basic setup.

6. Check whether advanced is recovering anything

   Advanced only pays off above Google's modelling volume threshold, which is unpublished and applied silently with no alert. If your account sits below it, you get the denied pings of advanced mode and none of the recovered conversions. Confirm in Google Ads or GA4 that modelled conversions are actually being reported before you conclude advanced is doing its job. Running advanced is not the same as benefiting from it.

Why the honest answer has a catch

Most guides stop at step three: if a ping fires you are advanced, if not you are basic. That is right most of the time and wrong in the case that costs you the most. An empty Network panel is not proof of basic mode. It is equally consistent with a GA4 tag that was never published, one that is failing behind a script error, or one blocked by something else entirely. Diagnosing a dead tag as a healthy basic setup is the expensive mistake here, which is why grant and re confirm is a step, not a footnote.

The second catch sits on the advanced side. Advanced only turns those denied pings into recovered conversions above a modelling volume threshold Google does not publish and never warns you about. Below it, you are paying the cookieless ping cost and getting none of the recovery, which is the opposite of what the setup was chosen for. So the real question is rarely just basic or advanced. It is whether the mode you are running is actually collecting the data you think it is, and whether the tags obey the consent state once you read it.

None of this throws an error, which is what makes it expensive. On a typical site around a third of sessions sit behind the banner, so a misread here quietly distorts a large slice of your measured traffic while every dashboard still reads normal. That 34% is a measured baseline across Amplio Data client implementations, not a fixed rate for every site, but it is large enough that guessing at your consent mode is never safe. If the whole picture looks off, the plain English guide to Consent Mode v2 walks through what each signal is doing.

This is a large part of why Velo exists. It ships the Consent Mode configuration, the default denied signals, the accept and reject wiring and the audit trail as one configured layer, so the mode you are running is the mode you chose and every tag reads the same state. You get one place to see what is actually being sent, instead of reconstructing it from the Network tab every time your site changes.

Common questions