How to check Consent Mode v2 in GA4 and GTM

Identify basic or advanced consent mode first

Basic mode blocks Google tags until consent; advanced mode loads tags with consent defaults and can send cookieless measurements while consent is denied. A denied state therefore does not mean zero network traffic in advanced mode. Decide which behaviour your implementation is meant to have before interpreting a request as a defect. Consent mode communicates choices to Google tags; it is not itself a consent banner or legal certification.

Record the four relevant consent states

Inspect analytics_storage, ad_storage, ad_user_data and ad_personalization. The first two govern analytics and advertising storage; the latter two cover sending advertising user data and personalised advertising. Review the defaults that apply to the test visitor and the later update separately. Do not assume all four should become granted when someone accepts only analytics.

// Illustrative denied defaults for a direct gtag implementation.
// GTM templates should use the dedicated consent APIs.
gtag("consent", "default", {
  analytics_storage: "denied",
  ad_storage: "denied",
  ad_user_data: "denied",
  ad_personalization: "denied"
});

Check the event order in Tag Assistant

Connect Tag Assistant to the page and inspect its consent information. Record the earliest consent event and the states before measurement tags act. In a direct gtag integration, defaults belong before measurement commands; for a GTM consent template, use its consent APIs and Consent Initialization trigger. A later denied update cannot undo data already sent under an earlier granted state.

1. Use a clean session with no saved consent choice.
2. Open the page through Tag Assistant and record the initial consent information.
3. Compare the consent event order with tag firing and network requests.
4. Repeat on another important entry page, not only the homepage.

Test rejection, acceptance and partial choices

Make one choice per clean session and keep a short record of what you selected, which state changed and which tags ran. Start with Reject, then test Accept and any available category-specific choice. If the banner offers an analytics-only choice, compare that with its advertising states. Inspect unrelated third-party tags too: a correct Google consent update does not automatically control every script on the page.

1. Reject: compare the resulting states and requests with the intended basic or advanced behaviour.
2. Accept: confirm an update reflects the categories the visitor selected.
3. Partial choice: confirm a restricted category remains restricted.
4. Navigate to a second page and confirm the stored choice is respected.

Test withdrawal and returning visitors

Use the site’s preference control to change a previous choice. Confirm that the update reaches the tags and that later behaviour follows the new choice. Then reopen the site with the saved preference and check the initial state. Write down any difference between first-time and returning sessions. A test that covers only a new visitor accepting everything leaves the most useful failure cases unexamined.

Keep the evidence specific

A useful handover names the tested URL, implementation type, browser session, consent events and observed requests. Report a source-code observation as a source-code observation; report runtime behaviour only when it was exercised. AuditHQ can surface public consent signals to prioritise the review. It cannot turn the presence of a script into proof that every journey, region or legal requirement is satisfied.

Frequently asked questions

See where your website stands

Start with a public-signal screening report in about 60 seconds. No signup or card. Quick Scan samples the website; it does not test every topic in this guide.