How to Check Whether Consent-Mode Tags Are Blocked

If Google tags appear in Tag Assistant, receive an early consent default, update after the visitor makes a banner choice, and are not listed as blocked, denied consent is not by itself evidence that the implementation is failing. If the tags are absent, late, or blocked, inspect the page installation, Google Tag Manager rules, consent-management platform (CMP), and event timing before changing Google Ads bidding.

This guide is for U.S. small-business search marketers and developers managing lead-generation accounts. The goal is to answer one practical question: are you seeing legitimate signal loss from a visitor’s consent choice, or are your tags being prevented from working at all?

Why the distinction matters

Consent mode does not mean that every visitor must produce the same request. Google documents two broad implementation patterns in its Consent Mode overview:

Basic consent mode: Google tags are blocked until the visitor interacts with the consent banner. No pre-interaction tag data is sent.
Advanced consent mode: Google tags load with default consent settings. When storage is denied, tags can send limited, cookieless measurements rather than storing or reading the disallowed data.

Google says in its guidance on unblocking Google tags with consent mode that active tags with denied consent can send limited non-identifying signals, such as consent state and country, while blocked tags cannot send information. Delayed or blocked tags therefore reduce the inputs available for reporting and conversion modeling. Google also describes more advertiser-specific modeling with advanced consent mode than with basic consent mode, but that distinction is not a promise of more conversions, lower cost per lead, or better return on ad spend.

Do not treat a denied value as an error, and do not treat a tag shown under Tags Fired as proof that the complete conversion, conversion-linker, or enhanced-conversions flow is correct.

Before testing: preserve the current state

Record the implementation and campaign state before making changes. This gives you a reference point when a later reporting change could otherwise be blamed on the wrong cause.

Google Ads conversion volume and the reporting period used
Consent rate, if your CMP or analytics reporting provides it
Current consent-mode impact or modeled-conversion status
Which Google tags fire, do not fire, or fire late
Current campaign bidding settings and recent campaign changes
The test region, browser, device, landing page, and consent choice

Do not remove consent controls or mark denied users as consented to make the test look healthier. Any repair must still match the site’s privacy requirements and CMP design.

Step 1: Start a clean Tag Assistant session

Open a fresh session in Tag Assistant and connect it to the page you want to test. Use a first-visit state where practical: clear the site’s consent state or use a suitable private browsing session, while remembering that browser extensions, regional settings, and existing storage can affect the result.

Document these conditions before interacting with the page:

Whether the consent banner appears
The test region and any regional consent rules that apply
Whether this is a first visit or a returning visit
The initial banner state and the choice you plan to make
The page URL and the time the test began

Run separate tests for the relevant choices, such as accepting, rejecting, or customizing consent. A single accepted-consent test cannot show how the implementation behaves when storage remains denied.

Expected result: Tag Assistant connects to the page and records the consent state and tag activity from the start of the session. According to Google’s consent-mode troubleshooting guidance, if the Consent tab is blank, consent mode may not be implemented on the page, or the Google tag may have been blocked before Tag Assistant could detect it.

Step 2: Compare Tags Fired with Tags Not Fired

Inspect both lists rather than looking only for a successful tag. Tag Assistant’s consent-mode troubleshooting documentation identifies these views as useful for finding missing tags and late or missing consent signals.

Check Tags Fired

Identify the Google tag, Conversion Linker, Google Ads conversion tags, and relevant Google Analytics events. Note when each one fires in relation to the consent default, banner interaction, form submission, and page navigation.

A Google tag that loads while consent is denied may be behaving as intended under an advanced consent-mode setup. The important question is not simply whether it fired, but whether it received the correct consent state and whether the later conversion event was handled correctly.

Check Tags Not Fired

Look for explanations such as:

An exception trigger
Required Additional Consent not being satisfied
A missing trigger or conversion event
A tag blocked by the CMP or another script
A consent default that was not available when the tag evaluated

Google identifies GTM exception triggers and additional consent checks as common reasons that Google Analytics, Google Ads, Floodlight, and Conversion Linker tags remain blocked. Google tags also have built-in consent checks, so adding a second blocking mechanism can prevent a tag from firing even when the intended consent logic is already present.

Expected result: Relevant tags appear at the expected stage. A conversion or Conversion Linker tag should not be blocked solely by a redundant GTM exception or additional-consent rule that duplicates the intended consent control.

Step 3: Inspect consent values and event timing

Open the Consent tab and review these four parameters. Google lists them in its consent-mode troubleshooting guidance as important values to check in a CMP implementation:

Parameter	What to verify
`ad_storage`	A default exists before relevant Google Ads activity, and the update matches the visitor’s advertising-storage choice.
`analytics_storage`	The initial state and later update match the visitor’s analytics-storage choice.
`ad_user_data`	The default, user update, and regional behavior are recorded as intended for advertising-related user data.
`ad_personalization`	The default and update reflect the visitor’s personalization choice and regional rules.

For each parameter, check four points:

Default: Was a value set before the first relevant Google tag or measurement command?
Update: Did the value change promptly after the visitor interacted with the banner?
Region: Does the initial value change appropriately for the test region?
Persistence: Does the choice remain consistent when navigating to another page, subject to the CMP’s designed expiration and preference behavior?

Google’s consent setup guidance says the consent default must precede measurement commands or Google tags. For an asynchronous CMP, a wait period such as wait_for_update may be needed to give the CMP time to provide the visitor’s consent state before data is sent. The correct implementation depends on how the site’s CMP and tag setup work together; do not copy a timing value without testing it.

Expected result: The first relevant event sees a consent default, and the consent update appears immediately after the banner choice and before navigation or conversion activity. Tag Assistant should not report that a tag read consent before a default was set.

Step 4: Review GTM, CMP blocking, and network evidence

If the consent state looks correct but tags are missing, trace the blocking path.

Inspect Google Tag Manager

Open the affected tag and check:

Exception triggers attached to the tag
Required Additional Consent settings
The tag’s trigger and event timing
Consent Initialization or other early initialization logic
Whether a separate Custom HTML or script tag writes consent too late

Do not automatically delete an exception or additional consent check. First determine whether it is required by the intended privacy design or whether it redundantly blocks a Google tag that already evaluates consent.

Identify how the CMP blocks scripts

Google describes automatic, manual, and tag-management-system-based CMP blocking approaches in its Google tag troubleshooting guidance. The repair depends on which approach is installed. Automatic blocking may prevent a script from loading before GTM can inspect it. Manual blocking may use modified script attributes or custom code. TMS-based blocking may occur through GTM triggers or consent settings.

Review the CMP configuration, page source, browser console, and GTM preview together. The aim is to find whether the Google tag never loaded, loaded but did not receive consent, or loaded and was stopped by a separate GTM rule.

Use network requests as supporting evidence

In the browser’s developer tools, inspect requests around the initial page load, banner interaction, and test conversion. Compare requests across consent choices rather than looking for one universal request pattern. The exact details vary by Google product, browser, tag implementation, and consent state.

Network evidence can confirm that a script or event request is absent, delayed, or sent after an update. It cannot, by itself, prove that every conversion parameter, consent value, conversion-linker action, or enhanced-conversion signal is correct. Use it alongside Tag Assistant and the GTM configuration.

Expected result: Google tags load according to the selected consent-mode design, consent updates occur before the relevant later events, and no unintentional CMP or GTM rule prevents the intended measurement flow.

Hypothetical example: two lead-generation sites

Site A uses an advanced consent-mode design. On a first visit, Google tags load with denied defaults. Before consent is granted, the tags can send limited signals permitted by that state. When the visitor accepts or rejects categories, the CMP sends an update before the visitor submits a form or navigates away.

Site B uses a basic consent-mode design or an equivalent blocking configuration. Google tags do not load until the visitor interacts with the banner. A visitor who leaves without making a choice produces no pre-interaction tag signal.

These sites provide Google with different reporting and modeling inputs. That difference does not establish that Site A will produce more leads or that Site B’s campaigns will perform worse. It does mean that an analyst should not compare the two implementations as though they collect signals in the same way.

Decision aid: what to do with each observation

Observation	Likely area to inspect	Next action
Tags Not Fired cites an exception trigger	GTM configuration	Review the exception’s purpose, scope, and timing. Remove only an unintended or redundant block after documenting the privacy behavior.
Tags Not Fired cites Required Additional Consent	GTM consent settings	Compare the additional check with the intended CMP and built-in Google tag consent checks.
Google tags never appear	CMP blocking or page installation	Check whether the Google tag is present, whether the CMP prevents it from loading, and whether the correct GTM container or page tag is installed.
Consent appears only after the first tag event	Initialization timing	Move the default and CMP update into the appropriate early sequence. Test asynchronous CMP behavior and navigation timing.
Consent and tag behavior pass, but Google Ads impact is absent	Reporting eligibility and data volume	Check consent rates, traffic mix, regional settings, the seven-full-day requirement, and Google’s data thresholds before changing bidding.

Final verification checklist

Before treating the implementation as ready for campaign analysis, confirm each item:

A clean Tag Assistant session records the page’s consent state.
The Google tag, Conversion Linker, relevant conversion tags, and expected analytics events appear at the correct stages.
Tags Not Fired does not show an unexplained exception or Required Additional Consent block.
ad_storage, analytics_storage, ad_user_data, and ad_personalization each have an intentional default.
The defaults occur before the first relevant measurement event.
Banner choices generate matching consent updates before navigation or conversion activity.
Regional defaults behave as designed in the test region.
Consent persistence behaves consistently on the next page and does not silently override a new choice.
CMP blocking, GTM exceptions, and additional consent checks do not duplicate or conflict with the intended controls.
Network requests support the Tag Assistant findings for the tested consent choices.
The pre-change record is saved before any implementation or bidding change.

Only after the implementation passes this review should you interpret a change in conversion reporting as a campaign or bidding issue. Google says in its consent-mode troubleshooting documentation that impact results require at least seven full days of implementation and sufficient data. A missing uplift result before those conditions are met, or a low result afterward, is not proof that tags are blocked. It may reflect consent rates, regional behavior, traffic mix, thresholds, or ordinary model variation.

If you manage a lead-generation site, the most useful next question is specific: which Tag Assistant observation has been hardest to reconcile with your CMP or GTM setup?

Sources

Editorial note: AI assists with research, drafting and automated checks. Sources are linked so you can verify the guidance. Platform requirements can change; confirm the details that apply to your setup.