Guide 12 · Debugging · GA4 + Tag Manager
Check the consent state: Tag Assistant shows what the visitor actually allowed
Tag Assistant has a Consent tab that shows the consent state for each event — granted or denied, per type. Read it before you decide the tag is broken.
After the steps below, the Consent tab shows the consent state at each step of the visit, and the state that blocked the event is named: which type, and when it was set.
Download the check: the debugging check (JSON) (MD5 51a85886a80218c21eb085c655b29ef6, 439 bytes). It lists the checkpoints from this guide and the worked check, with the figures recomputed. The file was built for this guide and validated structurally — it was not exported from a live container or a live property.
What you need
- Tag Assistant Preview, connected to your site. The Consent tab lives in the Tag Assistant debug view, so start Preview from the workspace first.
- The cookie banner, working as visitors see it. The banner is part of the test: accept it, decline it, and watch the consent state change each time.
- The consent types that matter. For Analytics the one that matters is analytics_storage; ad_storage governs advertising, not GA4.
- A test visit done twice. Once with consent accepted and once with it declined, so you can compare what each state does to the same event.
The trace
The worked check: the figures below were recomputed before publication, and the note under the table shows the working.
| Check | Figure |
|---|---|
| Consent types shown in the Consent tab | 4 |
| Types set to granted after accepting | 4 |
| Types set to denied after declining | 4 |
| Events sent with consent accepted | 6 |
| Events sent with consent declined | 0 |
The Consent tab showed 4 consent types. After accepting, 4 of 4 were granted, and 6 events were sent. After declining, 4 of 4 were denied, and 0 events were sent — 6 minus 0 is 6 events that consent, not the tag, decided. The tag was fine in both visits; the state changed.
- Start Preview and open the Consent tab. In Tag Manager, click Preview, enter the site URL, and click Connect. In the Tag Assistant debug view, open the Consent tab. It lists each consent type and its state — granted or denied — for the current event. Read it before you do anything on the site.
- Note the state before the banner is answered. Most sites start with analytics_storage denied until the visitor answers. If the tab shows denied before any choice, that is the default, not a fault. Note it, then answer the banner.
- Accept, then do the action. Accept the banner and watch the Consent tab: analytics_storage should change to granted. Then do the test action. The event should fire and reach GA4. If it does not, consent is not the cause — the state is granted and the event is still missing.
- Decline, then do the same action. Start a fresh session, decline the banner, and do the same action. The Consent tab should show analytics_storage denied, and the event should not reach GA4. That is the design working, not a break: the visitor said no, so nothing is collected.
- Compare the two visits, then fix the real cause. If the event arrives when consent is granted and not when it is denied, the setup is correct and the missing data is consent, not a tag fault. If the event does not arrive even with consent granted, the break is elsewhere — the trigger, the ID, or the tag.
Dead ends
DEAD END — THE BANNER WAS NEVER ANSWERED IN THE TEST. A test visit that never touches the banner stays in the default state, which is usually denied. The event never arrives, and the tester blames the tag. Answer the banner in every test visit, and note which answer you gave.
DEAD END — READING ad_storage WHEN THE QUESTION IS ANALYTICS. The Consent tab shows several types. ad_storage governs advertising; analytics_storage governs GA4. A granted ad_storage with a denied analytics_storage still sends nothing to GA4. Read the type that matches the tool you are debugging.
DEAD END — CONSENT GRANTED ON ONE PAGE, DENIED ON THE NEXT. A banner that only fires on the home page can leave later pages in the default denied state. If consent works on the home page and fails on the checkout, check whether the banner and the consent update run on every page or only on the first.
End state
The consent state read at each step of two test visits, one accepted and one declined, with the state that blocked the event named by type. Consent is now a checked fact, not a suspicion — either the visitor said no and the data is rightly absent, or consent was granted and the hunt moves on.
Sources
- Analytics Help — Monitor events in DebugView — Events not visible in debug mode when consent mode is implemented and users have not consented to Analytics cookies
- Tag Manager Help — Preview and debug containers — The Tag Assistant debug view as the place that shows how tags fired and what data they pass
Checked 11 November 2026. The click paths above are the ones in Google's help pages, opened 11 November 2026. What was run: the consent counts, recomputed — 4 of 4 types granted after accepting with 6 events sent, and 4 of 4 denied after declining with 0 events sent, a difference of 6 events. No step in this guide was run inside a live Analytics property or a live Tag Manager container, because both need a Google sign-in and this site does not sign in as anyone. Google moves menu items without warning; if a path on this page no longer matches, the linked help page is the current map.