By Anurag Anant Mishra — MarTech Architect
Google Consent Mode v2 comes in two flavours: Basic and Advanced. The names make them sound like tiers of the same thing, but the difference is fundamental, and it changes what data you actually get. I recently implemented Advanced Consent Mode on this very site, so most of what follows comes from doing it rather than reading about it.
The one-line difference: in Basic mode, if someone declines consent, you get nothing from them. In Advanced mode, you still get an anonymous, modelled picture of their visit. That gap is bigger than it sounds.
Consent Mode is the bridge between your cookie banner and your Google tags. When a visitor accepts or declines, Consent Mode translates that choice into signals your tags understand - mainly analytics_storage and ad_storage - and the tags then behave accordingly.
Before Consent Mode, the choice was binary and blunt: either a tag fired or it did not. Consent Mode makes the tag consent-aware, so it can adjust its behaviour instead of simply being switched on or off.
In Basic Consent Mode, Google tags are blocked entirely until the visitor gives consent. Nothing loads, nothing fires, no signal is sent. If the user accepts, the tags load and run normally. If they decline, you get complete silence from that visitor.
It is simple and easy to reason about. The cost is that everyone who declines becomes invisible - and in privacy-conscious regions, that can be a large share of your audience.
In Advanced Consent Mode, the tags load immediately, but in a restricted state. Until consent is given, they run without cookies and without any identifier, and they send anonymous, cookieless pings to Google. These pings carry no way to recognise a person across pages, sessions or sites.
If the user then accepts, the tags upgrade to full behaviour. If they decline, the cookieless pings are all Google receives - and Google uses them to model the behaviour of declined users, filling the gap with aggregate estimates rather than leaving it empty.
This was my own moment of it clicking. I had assumed that declined consent meant zero data - that those visitors were simply gone from reporting. With Advanced Consent Mode, that is not the case. Even after someone declines, you still get a high-level, anonymous signal that a visit happened.
In practice that is close to a win-win. You respect the person's choice - no cookies, no identifier, nothing that tracks them - and you still get an aggregate sense of your traffic instead of a blind spot. For understanding roughly how many people are coming to your site and how that trends over time, that anonymous baseline is genuinely useful. It is not the same as full analytics, and it should not be sold as such, but it beats reporting on only the half of your audience that accepted.
I will be honest - two things took a while to sit right in my head. The first was the idea of collecting data without cookies at all. We are so used to analytics meaning "a cookie with an ID" that a cookieless, identifier-free ping feels almost contradictory at first. It clicks once you accept that the ping is aggregate by design - it is a signal that something happened, not a record of who did it.
The second was reading the gcs parameter while debugging. When you inspect the outgoing GA4 request, you see a value like gcs=G100 or gcs=G101, and it is not obvious what it means. It is simply a status code for the consent state: the two digits after G1 represent ad_storage and analytics_storage, where 0 is denied and 1 is granted. So G100 means both denied, G101 means analytics granted but ads denied, and G111 means both granted. Once you can read that at a glance, verifying your setup becomes much easier - you can literally see the consent state on every hit.
Set the default denied consent state by hardcoding it directly in the site's head, above the Google Tag Manager container. This is the best practice, and there is a concrete reason for it.
You can push the defaults from within GTM instead, and it can work - but it sometimes introduces a race condition. If the default state is set from inside the container, there is a window where a tag can fire before the default has been registered, which defeats the whole point. Hardcoding the default in the head, before GTM loads, guarantees the denied state is in place first. I ran into exactly this timing behaviour during setup, and moving the defaults to the head resolved it cleanly.
This is the part I want to be loudest about, because it is technical writing's blind spot. Consent is a legal matter, and it sits on a thin line. Advanced Consent Mode sends signals even when a user has declined - and whether that is acceptable depends on your jurisdiction and how consent law is interpreted there.
Google gives you the option to run Advanced mode. That does not mean it is automatically the right choice for your organisation. Before implementing it, get a discussion and a sign-off from your legal or privacy team. Being technically correct is not the same as being compliant, and on privacy the compliance bar is the one that matters. Implement the technology and the legal position together, not one before the other.
If your legal team is comfortable with it, Advanced Consent Mode generally gives you more - you keep an anonymous baseline instead of losing declined users entirely. Basic mode is the more conservative choice when you want tags to stay completely dormant until consent, with no pings at all.
My honest summary: Advanced is usually the better default for understanding your traffic, but it is a decision you make with legal, not a switch you flip because a tutorial said so.
I write about MarTech architecture, analytics governance, and privacy-first measurement. If you are working through consent setups, you may also find my piece on tag governance across Adobe and GA4 useful. More of my work is on the home page.