Which Google Consent Mode is your site running?

Two modes, one real difference

Google Consent Mode v2 has two implementation patterns. The difference is not what your consent banner looks like. It is whether Google's tag is on the page before the visitor decides.

Advanced

The Google tag loads on page load. Before consent it sets all four v2 parameters to denied and sends cookieless pings: no identifiers, no cookies, just a signal that a page was viewed. When the visitor consents, a second call flips the relevant parameters to granted and normal measurement begins. Those pre-consent pings are what Google uses to model the conversions it could not observe directly.

Basic

The Google tag never loads until the visitor consents. Nothing is sent beforehand, cookieless or otherwise. When consent arrives the tag loads and fires normally. There are no pre-consent pings, so there is nothing to model from.

Both are legitimate implementations. They trade differently, and the trade is the whole decision.

Which one you have is an install property, not a setting

This is the part that surprises people. You do not choose Basic or Advanced in a dashboard. You choose it by how the Google tag is written into the page.

If your GA4 tag looks like this, the browser fetches it immediately and you are running Advanced at best:

<script async src="https://www.googletagmanager.com/gtag/js?id=G-XXXXXXX"></script>

If it looks like this, the browser will not fetch it at all until a consent manager rewrites it, and you are running Basic:

<script type="text/plain"
        data-consential-category="analytics"
        data-consential-src="https://www.googletagmanager.com/gtag/js?id=G-XXXXXXX">
</script>

The second pattern works because a browser will never execute a script whose type is not a recognized JavaScript MIME type. The consent manager finds those placeholders and converts them into real script tags once the matching category is granted. It is the standard client-side blocking technique and it is what makes blocking independent of load order.

Which also means a single site can be running both at once. A GA4 tag converted to the placeholder convention is blocked. A Meta pixel that a plugin injects directly, that nobody converted, is not blocked at all, and no consent manager can intercept it. Mixed installs are the norm rather than the exception, and usually nobody involved knows it.

A consent banner is not evidence of blocking. A banner can be present, correctly worded, and fully functional while the tags behind it fire on page load regardless of what the visitor clicks.

Consential defaults to Basic, and here is why

Consential sets all four parameters to denied in every US jurisdiction, including the states where a granted default would be permitted, and holds Google's tag until the visitor acts.

The reason is context. A cookieless ping carries no identifiers, but it does carry the page it fired on. On a retail site that is a product page. On a practice website it can be a treatment page, a procedure page, or a consultation request form, and the URL by itself can imply why someone is there. We are not willing to send that before a visitor has said yes, even in a form that carries no cookie.

This is a deliberate product stance and it is stricter than the legal minimum. It is not a determination about your obligations, and it does not replace your counsel's reading of them.

What Basic costs, stated plainly

Basic has a real measurement cost. You should price it in rather than discover it.

Under Advanced, visitors who decline still generate a pre-consent ping, and Google can model conversions from that population once your volume clears its modeling thresholds. Under Basic, visitors who decline generate nothing at all. They are absent, not estimated.

Your consent rate becomes a direct multiplier on browser-side conversion data. A practice where 60 percent of visitors accept will see roughly 40 percent fewer conversions in Google Ads than it actually produced. Smart Bidding optimizes against what it can see, so the effect compounds past reporting and into delivery.

This also used to be softer than it is now. Google Signals previously filled part of that gap for linked Ads accounts. It no longer does, so a missing consent signal is not degraded data anymore. It is no data.

The cost is much smaller if your conversions are not browser-side

Browser consent mode governs what the browser sends. It does not govern what your server sends.

If a click identifier is captured into a hidden form field when the visitor arrives, stored against the lead record, and uploaded from your CRM once that lead becomes a booked consultation or a completed procedure, the conversion reaches Google through a path that never depended on the Google tag firing in the first place. Basic mode does not touch it.

Practices measuring on form fills alone feel Basic mode immediately. Practices measuring on booked consultations through a server-side upload barely feel it. Which of those you are determines what this decision actually costs you, and it is worth knowing before you pick a mode.

One question worth raising with your counsel rather than settling in code: whether a conversion should be uploaded server-side for a visitor who explicitly declined marketing consent. It is technically possible. Whether it is appropriate is a policy question, not a technical one.

How to check your own site in about two minutes

Or have us check it for you

We load your site in a real browser and never touch the consent banner, so everything we observe is genuinely pre-consent. You get the implementation in force and a list of which tags fired anyway.

ImplementationBasic, Advanced, or no gating at all

All four v2 paramsv2 added two that many installs still omit

Mixed installSome tags held, others firing regardless

Prefer to do it by hand? Open your site in a private window with DevTools on the Network tab, and do not touch the banner yet.

Filter for gtag/js. If a request fires before you interact with the banner, that tag is not being blocked.
Filter for /g/collect. A request here before consent is a measurement hit leaving the page.
Now accept, and confirm the requests appear. If they never appear, your release path is broken and you are losing all measurement, not just the pre-consent portion.
Repeat for every tracker, not just GA4. Meta, Google Ads, and chat widgets are usually installed by different people at different times.

Then check the signal itself

This is where implementations fail quietly, because all three of these can be wrong on a site that looks correct.

All four parameters present. ad_storage, analytics_storage, ad_user_data, ad_personalization. v2 added the last two and a lot of installs still send only the original pair.
Default queued before tags. The consent default call has to land before any Google tag initializes. If the default arrives after the tag has started, the tag spent its first moments in an undefined state and no banner interaction fixes that retroactively.
A consent surface that actually works. A correct signal with no way for a visitor to change their mind later is not consent management.

Most scanners check that a consent signal exists somewhere on the page. That is a presence check, and presence is not correctness. A site can pass a presence check while failing all three of the above.

What we do with this

Every Consential scan cycle runs these checks and reports the result, including which of your tags are actually being held and which are firing regardless of the banner. When a site changes, when a plugin is added, when a new pixel appears, the gap shows up in the next cycle's report with a timestamp on it.

Compliance isn't a promise. It's a paper trail.

Which Google Consent Mode is your site actually running?