Guide 25 · Debugging · GA4 + Tag Manager
Consent denied means the events are missing by design: prove it, then decide
When a visitor declines analytics cookies, GA4 collects nothing for them in basic consent mode — or only cookieless pings in advanced mode. Missing events from decliners are not a tag fault.
After the steps below, you know how many of your missing events are visitors who declined, and the tag is proven working on visitors who accepted.
Download the check: the debugging check (JSON) (MD5 5112f5af17bfe1dde3dd9b2b6264b2d4, 502 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, with the Consent tab. The consent state per event, granted or denied, is the evidence.
- Two test visits. One where you accept the banner and one where you decline it, on the same pages, doing the same actions.
- DebugView, for the accepted visit. The events must appear there when consent is granted, or consent is not the story.
- The consent mode type your site uses. Basic or advanced — the two behave differently when consent is denied, and the difference decides what is missing.
The trace
The worked check: the figures below were recomputed before publication, and the note under the table shows the working.
| Check | Figure |
|---|---|
| Test visits done | 20 |
| Visits where consent was accepted | 12 |
| Visits where consent was declined | 8 |
| Events from accepted visits | 48 |
| Events from declined visits | 0 |
| Share of visits that declined | 40.00% |
Twenty test visits were done: 12 accepted and 8 declined, so 8 divided by 20 is 40.00% who declined. Accepted visits sent 48 events and declined visits sent 0, so 48 minus 0 is 48 events that consent decided. The tag sent 4 events per accepted visit — 48 divided by 12 is 4 — and none per declined visit.
- Work out which consent mode the site uses. In basic mode, Google tags do not load until the visitor answers, and a decline sends nothing at all. In advanced mode, tags load with consent denied by default and send measurements without cookies — cookieless pings — while consent is denied. Ask whoever built the banner, or read the tag setup, before you test.
- Do the accepted visit first. Accept the banner and do the actions. The events should fire in Preview and appear in DebugView. If they do not, the break is not consent — the visitor said yes and the events are still missing.
- Do the declined visit the same way. Start a fresh session, decline the banner, and do the same actions. In basic mode, no events should reach GA4. In advanced mode, only cookieless pings go out, and the events do not appear in DebugView or Realtime as normal events. That is the design, not a fault.
- Count the share of visits that decline. If 40 in every 100 visitors decline, 40% of your expected events will never appear in basic mode — and no tag fix recovers them. The count turns a vague feeling that data is missing into a number with a cause.
- Decide what to do about it — and what not to do. Do not weaken the banner or bypass consent to recover the data; the visitor's choice is the point. What you can do is report with the gap named: this many visitors declined, so this many events are absent by design, and the rates you report are rates among consenting visitors.
Dead ends
DEAD END — TREATING DECLINERS AS A TAG FAULT. Events from visitors who declined are missing because they declined. Rebuilding the tag, the trigger, or the container cannot bring them back, and each rebuild risks breaking the events from visitors who accepted.
DEAD END — READING THE BANNER, NOT THE CONSENT STATE. A banner that looks accepted may not have updated the consent state — the banner and the consent signal are two different things. Read the Consent tab in Tag Assistant, not the banner's own message.
DEAD END — ONE TEST VISIT, ONE CONCLUSION. A single declined visit proves nothing about the share of missing data. Run both visits, count them, and report the share. One visit is an anecdote; twenty visits is a measurement.
End state
Consent proven as the cause, with numbers: the accepted visits send events, the declined visits send none, and the share of decliners is counted. The missing data is now explained, not chased — and the tag is left alone, because it was working all along.
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 the consent state and how tags fired for each event
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 — 20 visits, 12 accepted and 8 declined, so 8 of 20 is 40.00% declined, with 48 events from accepted visits and 0 from declined, 48 divided by 12 is 4 per accepted visit. 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.