Measurement / framework / Free to use

Consent Choice QA Review Framework

Plan and review consent-choice tests across routes, devices and tags without mistaking coverage for compliance.

Growthcraft Editorial · 2026-11-04. AI-assisted research and implementation. Examples are synthetic; Akshay's personal review is not claimed.

Copyable template

Select and copy the complete template below. With JavaScript enabled, you can edit, copy and download it in the interactive workspace.

CONSENT CHOICE QA REVIEW — WORKSHEET
Decision and release: [what is changing and who approves?]
Owner / reviewer / next review date: [roles and date]
Environment and version: [staging or permitted production, build, CMP and tag container versions]
Markets and rules to review with privacy counsel: [list, or unknown]
Routes, browsers, devices and tag inventory: [list]
Agreed expected behaviour by purpose and state: [link to approved specification]
Evidence policy: [how to avoid capturing personal data, identifiers or secrets]

FREEZE A TEST MATRIX
One row is one unique combination of route, browser/device, region, existing choice and action. Assign a unique synthetic case ID; do not use a visitor identifier. Include initial visit before choice, reject, accept, mixed purpose choices where offered, preference changes, reload and a second route. Include any critical tags not built into the Google tag. Test only states available in the actual product.
Case ID | setup | action | expected behaviour | observed behaviour | evidence reference | current outcome | owner | retest date
Outcome is exactly one of PASS, FAIL, BLOCKED, NOT_TESTED. A retest replaces the prior outcome for the current snapshot; keep the history separately. Mark a case blocked if the expected result or safe test environment is unavailable. Never infer a pass from a green banner.

COUNT AND HAND OFF
Planned = passed + failed + blocked + not tested.
Executed = passed + failed. Coverage = executed / planned; unavailable if planned is zero.
Pass share = passed / executed; unavailable if executed is zero. Keep failures and untested cases visible.
Release decision: [hold / investigate / approved by named owner]. A percentage is not permission to ignore a critical failure.
Critical unresolved case and next owner: [fill in]; retest date: [fill in].

SYNTHETIC EXAMPLE
12 planned: 7 pass, 2 fail, 1 blocked, 2 not tested. Executed coverage is 9/12 = 75%; pass share is 7/9 = 77.8%. Three cases remain blocked or untested. A failure involving a tag firing contrary to an approved reject expectation is a release blocker for the responsible team to review, even if the arithmetic looks high.

LIMITS
This measures coverage of the selected cases, not consent rates, population behaviour, legal compliance, conversion loss or the safety of untested tags. Reviewers must interpret the evidence and obtain appropriate legal and technical advice.

What this review is for

Before releasing a banner or tag change, a marketer and an implementation owner need evidence that the intended choices were tested. This original worksheet turns the agreed expectations into a small, reviewable test plan. It is not a legal opinion or a certification.

Prepare the test plan

Record the release, CMP and container versions, routes, browsers, devices and markets. Get an approved expectation for each relevant purpose and tag. Include non-Google tags where applicable. Ask the privacy owner what is appropriate for the organisation and jurisdiction; do not assume a platform setting supplies permission.

Run and record cases

Freeze one case per combination of route, device, region, existing choice and action. Include first visit, accept, reject, purpose-specific choices if offered, a change of mind and navigation or reload.
Use synthetic sessions and an approved environment. Record expected and observed behaviour without collecting personal information, cookies or credentials in the evidence.
Assign one current outcome: passed, failed, blocked or not tested. A failed retest remains failed until evidence supports a pass; retain history separately.
Review failures by consequence and owner. A high overall percentage cannot resolve an unsafe or critical case.

Worked example

Of 12 synthetic cases, seven pass, two fail, one is blocked and two are untested. Nine of 12 were executed (75%); seven of nine executed cases passed (77.8%). Three remain blocked or untested. The coverage calculator checks the arithmetic. A failed reject case requires investigation against the approved expectation, regardless of the pass share.

Make the next decision

Record unresolved cases, evidence, the responsible person and retest date. The optional prompt drafts a note from anonymised counts. Without AI, use the worksheet. Do not treat the result as a consent rate, compliance finding or conversion-loss estimate.

Sources and limits

Checked 4 November 2026: Google's consent mode overview explains consent states and basic and advanced implementations. Its verification guide describes inspecting default states, updates and tag behaviour. The UK ICO's consent-management guidance discusses user choices and their presentation. This original QA method does not decide which legal rules apply or certify a site.