Should you block Google's own tags until someone consents
For an Advanced Consent Mode implementation, no. In Basic mode, yes: Basic means Google tags stay blocked until the visitor consents. In Advanced, Google's own tags stay unblocked and enforce the visitor's choice themselves through built in consent checks. An Additional Consent check on top blocks them outright, which quietly turns Advanced into Basic and removes the denied signal Google models from. The test: a declined visit should still send gcs=G100.
Start with a scan.
The free scan reads your homepage HTML and public Tag Manager container, and lists the tracking tags it finds.
Free · No signup · HTML and public GTM checks
The advice is right. It is just not about Google's tags.
Almost everything written about consent in Google Tag Manager arrives at the same instruction: gate the tag. Open Advanced Settings, then Consent Settings, require additional consent, name the types. For a vendor script that writes its own cookie the moment it loads that is correct, and our own guide to moving a script into Google Tag Manager to gate it says exactly that.
One caveat first, because it is about jurisdiction rather than mechanics. Some operators, German ones especially, block the whole container until consent on legal advice. That is a deliberate choice of Basic behaviour with the measurement cost accepted, and a different thing from a stray consent check left on a GA4 tag. This post is about the second one.
Google's own tag types are the exception, and it is not a matter of taste. Google states it plainly in its guide to unblocking Google tags. Its tags have built in consent checks and change behaviour on their own, so they do not need additional ones, and implementing both at once stops them working properly. A GA4 configuration tag or a Google Ads conversion tag already knows what ad_storage and analytics_storage are set to. An Additional Consent check sits in front of that machinery and never lets it run.
We learned this over five container versions of one consent remediation. The banner was fine. The container had a consent check on everything, evenly applied, which was why the account had stopped modelling anything.
What the extra check actually costs
An unblocked Google tag on a page where the visitor declined still sends a request. It goes to /g/collect with no cookies and no client identifier, carrying gcs=G100: Consent Mode is on, both storage types denied. That is a recorded refusal, and it is the input Google's modelling uses to estimate the conversions it is not allowed to observe.
A blocked Google tag sends nothing at all. Nothing is not a refusal. It is absence, and a model cannot learn from absence. You have also not made the visit more private, because the unblocked request was already cookieless on that path. You have only deleted your own evidence that the visitor was there.
So this one setting decides, in effect, whether the site runs Advanced or Basic Consent Mode, whatever the banner's screen says. It is the same question as basic vs advanced Consent Mode, read from the tag side. That denied ping is the input Google models from, and modelling only runs once your site meets the data thresholds in Google's consent mode documentation. What it produces is an estimate, not conversions anyone observed.
Same banner, same refusal. The tag setting decides.
Additional check on
- Visitor declines
- Container blocks the tag
- Its consent handling never runs
- No request leaves
No additional check
- Visitor declines
- Tag fires, enforces consent itself
- No cookies, no client identifier
- Cookieless ping,
gcs=G100
Read from the live page, not the container preview.
How to check what you actually shipped
Five steps, in order.
-
List every tag carrying an Additional Consent check
Go through the container tag by tag rather than trusting whatever integration guide set it up. In each tag, under Advanced Settings and then Consent Settings, the setting reads either no additional consent required or a named list of consent types. Write down every tag on the named list, which in a container that has been through two CMP migrations is reliably longer than anyone expects.
-
Take the check off every Google tag type
GA4 configuration and event tags, Google Ads conversion and remarketing tags, Floodlight, and the Google tag itself all go back to no additional consent required. Leave the checks on genuine third party tags. The line is ownership, not sensitivity: a Google tag enforces consent inside itself, a Meta or Hotjar tag does not.
-
Switch the firing option from once per page to once per event
A tag set to fire once per page counts a blocked attempt as its one firing. The trigger fires before the visitor decides, the consent check stops the tag, and the counter still records its turn as used. When consent arrives and the trigger fires again, the container skips it. The tag looks correct in every screen and produces nothing. Once per event is the right setting on anything that can be attempted before a decision.
-
Let the consent update land before you judge a trigger
The container evaluates a tag's consent state at the instant its trigger fires, and a CMP applies a stored decision asynchronously, typically a few hundred milliseconds into the page. So a page load tag can be judged while consent still reads denied, on a visit from someone who accepted weeks ago. The symptom is a tag that fires on a click but never on a page view. Google's built in checks handle this timing themselves, which is the second reason not to wrap them.
-
Verify on the live page, never in Preview
Preview mode runs with the container's debug wiring and, very often, a consent state you clicked yourself. Load the production page in a clean browser, decline, and read what leaves. Tag Assistant will tell you the tag fired. Only the network panel tells you what Google received.
The diagnostic, in one line
Open the network panel on the live page, filter for collect, and decline. A request that leaves carrying gcs=G100 means your Google tags are unblocked and the refusal is being reported. An empty panel means something is blocking them, and there are only two realistic candidates: an Additional Consent check on the tag, or a banner that blocks the whole container before the tag exists.
Then accept and run it again: gcs=G111 is both signals granted. Getting the update to the container in the first place is the wiring in the Google Tag Manager install guide, worth re reading with this exception in mind.
Velo works this way round by default: it updates Consent Mode, leaves Google's tags to enforce the outcome themselves, and gates only the scripts that cannot. What no banner can do for you is step one, because the checks already in your container were put there by whatever set it up before.
Common questions
What people ask about this topic.
Should I block Google tags until consent is granted?
For an Advanced Consent Mode implementation, no. In Basic mode, Google tags are blocked until the visitor consents, which is how Basic works. In Advanced, Google's own tags carry built in consent checks and enforce the visitor's decision themselves, so they should stay unblocked and fire on every page load. When consent is denied they send a cookieless request with no identifiers, carrying gcs=G100, which is how Google records a refusal and the input its conversion modelling uses. An Additional Consent check on top blocks the tag before any of that runs, so nothing leaves at all.
Why does an Additional Consent check break Consent Mode?
Because it stops the tag rather than shaping it. Consent Mode works by letting the Google tag run in a restricted cookieless state and report the denied signal. An Additional Consent check is evaluated before the tag executes, so the tag never runs and never reports anything, and the site is on Basic behaviour in effect whatever the banner's settings screen says. Google's documentation says the two mechanisms do not work correctly together.
Why did my tag stop firing after the visitor accepted consent?
Usually the tag is set to fire once per page. A blocked attempt still counts as that one firing, so when consent arrives and the trigger fires again the container skips the tag. Change the firing option to once per event. A second cause is timing: the container evaluates consent when the trigger fires, while a CMP applies a stored decision a few hundred milliseconds into the page, so a page load tag can be judged while consent still reads denied.
How do I tell whether my Google tags are blocked before consent?
Load the live page in a clean browser, open the network panel, filter for collect, and decline. If a request leaves carrying gcs=G100 your Google tags are unblocked and the refusal is being reported. An empty panel means they are blocked, and the two realistic causes are an Additional Consent check on the tag or a banner that blocks the whole container. Preview mode runs with its own consent state, so it cannot answer this.
Website privacy, in one place.
Scan your site →