To troubleshoot Google Consent Mode v2, compare the visitor's choice with the consent state at the moment each measurement event runs. Inspect defaults, updates and tag behaviour in Tag Assistant, then verify the actual requests and storage in browser developer tools. A working banner alone does not prove that the signals reach Google correctly.
This guide covers website debugging with Google Tag Manager (GTM) or direct gtag.js. Start with the symptom you can reproduce. If you are still deciding what should run before consent, read basic vs advanced Google Consent Mode first.
Start with a repeatable test
Write down the page, published container version, CMP configuration, intended region and visitor choice. Use a clean browser profile for the first-visit case, then keep a separate returning-visitor test. Otherwise, an old preference can make two identical deployments appear to behave differently.
Open Tag Assistant and connect the site. In its event timeline, inspect the earliest Consent event and the later update after a banner choice. The Consent tab shows the on-page default and update; the API Call view exposes parameters. Inspect the relevant measurement event as well, rather than only the final state. Google's verification instructions.
Keep the browser Network panel open with its log preserved during navigation. Record cookie and local-storage changes separately. Do not share raw request exports containing customer identifiers, authentication tokens or form contents.
Find the likely cause by symptom
The following table is a triage plan. A likely cause becomes a finding only when you reproduce it and inspect the evidence.
| Symptom | Evidence to inspect | Next action and retest |
|---|---|---|
| No consent information | Connection status, loaded container and CMP integration | Confirm the correct environment, then test before and after a choice |
| Default missing or late | First consent event relative to measurement | Correct initialisation order; reload with fresh storage |
| Banner accepts, state stays denied | CMP callback and purpose mapping | Follow one choice through to its update; repeat with partial consent |
| Choice changes after navigation | Saved preference, restored state and duplicate writers | Identify which integration overwrites the choice; test the next page |
| Tags run after rejection | Requests, storage and intended basic/advanced mode | Compare actual data with approved behaviour; retest rejection |
| Tags remain blocked after acceptance | Triggers, exceptions and consent checks | Identify the unmet condition; test its intended purpose separately |
| Conversions change after release | Release timing, event counts and duplicates | Separate collection faults from reporting differences |
Consent tab empty or Tag Assistant cannot connect
These are different starting points. A blocked Google tag or container can prevent Tag Assistant from connecting before consent. That can be intentional in basic mode. Accept the relevant purpose in your test and reconnect before concluding that the installation is absent.
For a connected page with no consent information, confirm that the CMP's Google integration is enabled and deployed. Check the actual container ID and published version. A banner installed on the page is not evidence that Consent Mode is configured. Google's connection and empty-tab guidance.
As a practical isolation step, compare the affected page with another page using the same template. Check for a missing CMP script, an old cached template, a JavaScript error or a blocked resource. Record which condition changes the result instead of enabling additional tags at random.
Default consent not set or set too late
Consent defaults must precede the measurement commands that depend on them. In a direct gtag.js setup, place the default before config and event commands. Set the four v2 parameters explicitly: analytics_storage, ad_storage, ad_user_data and ad_personalization. Google's website setup guide.
For GTM, use the CMP's supported consent template on Consent Initialization - All Pages. Templates should call setDefaultConsentState and updateConsentState. Google advises against using queued gtag('consent', ...) commands inside custom templates because they may be processed after the next event. GTM consent template guidance.
Inspect the sequence under a slow connection as well as a normal reload. An asynchronous banner download must not be the only thing preventing an unintended initial state.
Worked example: a late default
This is an illustrative event trace, not a customer result or a screenshot of a live installation. The test specification requires denied defaults before Google measurement runs.
| Observed order | Interpretation |
|---|---|
| 1. Page starts loading | No established consent state yet |
| 2. Measurement event runs | The event may use a state other than the intended default |
| 3. CMP sets denied defaults | The default arrived after the event that needed it |
| 4. Visitor accepts analytics | A later grant cannot validate the earlier sequence |
The repair is to establish the required defaults before measurement can execute. Repeat the same clean-visit test and capture the new order. Then inspect the first request and storage operations: a corrected final state does not establish what happened earlier.
Consent stays denied after the visitor accepts
Follow the change across three boundaries: the banner saves a choice, the CMP maps it to Google purposes, and the integration applies an update. Identify the first boundary where the expected value disappears.
For example, an analytics-only choice might produce this state:
{
"analytics_storage": "granted",
"ad_storage": "denied",
"ad_user_data": "denied",
"ad_personalization": "denied"
}
This is an illustrative expected result, not installation code. The advertising denials are deliberate. Do not make every signal granted just to clear a diagnostic warning. The four parameters represent different storage and advertising purposes. Google's consent type reference.
Check that the update happens on the page where the choice occurs, before navigation. A wait_for_update value gives an asynchronous CMP a limited response window; it does not wait indefinitely for a visitor to decide. Consent Mode does not store preferences across pages itself, so the consent solution must save and restore the choice. Consent updates and asynchronous CMPs.
If an update appears and then reverses, inspect other integrations that write consent. A CMS plugin, hard-coded snippet and GTM template can compete. Establish one intended owner for each update path, then repeat acceptance, partial consent and withdrawal.
Tags fire after rejection or stay blocked after acceptance
First compare the observation with the intended mode. Basic mode blocks the relevant Google measurement tags until consent. Advanced mode can send cookieless pings with storage consent denied. A request after rejection is therefore not, by itself, proof of a broken consent update. Google's basic and advanced comparison.
Inspect the request payload as well as the cookie list. Denied analytics storage does not guarantee that configured identifiers or custom dimensions are absent from transmitted data. Review fields, URLs and destinations against the processing approved for that state. Google's tag-behaviour reference.
When a tag stays blocked after acceptance, inspect its trigger, exceptions, built-in consent checks and additional consent requirements. A granted analytics purpose does not satisfy an advertising requirement. Do not remove a blocking rule until its purpose and intended replacement are clear.
Keep non-Google pixels in the investigation. A correct Google consent state only controls another integration if that integration actually reads and enforces it. See the consent signal integration guide for mapping choices to separate destinations.
For server-side GTM, inspect the browser event and the server processing together. Google's supported setup carries consent information from web tags to the server container; checking the browser alone does not verify the final outgoing request. Google's server-side Consent Mode guide.
Results differ by region or returning visit
Build a small test matrix: one fresh visit and one saved-choice visit for each configured regional rule. Include the global fallback. Record which region the CMP actually applied rather than inferring it from the banner text.
Google supports region-specific defaults, with more specific settings taking precedence. Test the resulting state as well as the regional configuration. Regional consent defaults.
The location test must exercise your actual implementation. Changing browser geolocation is not sufficient evidence for a CMP that selects rules using IP location. Use the CMP's documented regional testing mechanism, and verify its limits before treating the result as representative.
For a returning visitor, inspect storage scope, expiry, domain and restoration timing. Then follow the visitor into checkout, another subdomain or a single-page route. Note exactly where the saved choice stops matching the active state. Treat cross-domain preference sharing as a deliberate design decision, not an automatic consequence of using the same banner vendor.
GA4 or Google Ads numbers changed after the fix
Separate three questions: did the event occur, did the intended request leave, and how did the destination report it? Use a controlled test journey and compare event identifiers, destinations and duplicate counts. A drop in reported conversions alone does not identify a consent fault.
GA4 behavioural modelling depends on eligibility and the reporting identity. Meeting volume thresholds does not guarantee model availability, and modelled data is not included in every output, including BigQuery export. Verify the property's status before promising that a configuration change will restore reporting totals. GA4 behavioural modelling requirements.
Record the deployment time and compare like-for-like periods and journeys. Investigate unrelated changes to event names, conversion configuration, traffic sources and checkout releases. Keep reporting analysis separate from the decision about what processing is permitted.
Retest before closing the issue
For every case below, capture the choice, event sequence, resulting state, requests and storage. Record the container and CMP versions alongside the result so another person can reproduce it.
| Test journey | What a useful result establishes |
|---|---|
| Fresh visit without interaction | Initial behaviour matches the documented mode and regional rule |
| Reject all, then navigate | Denials remain effective on the next page |
| Analytics only | Advertising remains denied while the analytics choice is honoured |
| Accept all | Intended events occur without duplicate measurement |
| Accept, then withdraw | Subsequent processing follows the changed choice |
| Return with saved preferences | Restoration does not introduce an unintended temporary grant |
| Slow or unavailable CMP | The failure path follows the agreed default behaviour |
| Checkout or single-page navigation | State and event ordering remain consistent across the journey |
Repeat affected journeys outside preview against the published test environment. Preview success alone does not prove the deployed configuration matches it. Technical checks also do not establish the legal validity of the consent collection or every downstream use of data.
FAQ
How do I check whether Consent Mode v2 is working?
Compare the four consent parameters with the visitor's choice at the relevant event, then inspect network requests and storage. Test rejection, partial consent and withdrawal as well as acceptance.
Does denied mean Consent Mode is broken?
No. It may be the correct state before a choice or after rejection. Investigate when the observed state differs from the visitor's choice or your documented default.
Should I add another consent snippet to fix missing signals?
First identify the integration responsible for the existing defaults and updates. A second writer can obscure the original fault or overwrite a valid choice. Repair the identified path and retest it.
Can I use a successful Tag Assistant check as proof of compliance?
No. It helps verify supported consent signals and tag behaviour. It does not validate your notices, legal basis, every third-party integration or all subsequent data processing.
Related guides and implementation support
- Basic vs advanced Google Consent Mode explains the expected behaviour of each approach.
- Google Consent Mode, GPC and GPP integration covers coordinating different signals.
- Microsoft UET Consent Mode covers Microsoft Advertising diagnostics.
For help tracing an implementation fault, explore Google Consent Mode and GTM services or request a free consent audit.
