An agency's consent QA handoff should state which pages, visitor countries, and consent paths were tested, what the browser showed, and who will resolve and retest each finding. A screenshot of the banner leaves most of that work unspecified.
Use the checklist below for a client release. Keep untested locations and incomplete runs visible so the next team can continue from the evidence you captured.
Review a regional consent handoff
The example has a resolved German finding and an incomplete UK retest. Add the missing evidence and an owner to see when the packet is ready for client review. Download a blank checklist for your own project.
Same URL and path retested, country verified, state and capture complete, owner recorded.
UK retest inconclusive. Keep the evidence gaps in the handoff.
Still needed: Readable rejection state; Retest cookie and request capture; Named follow-up owner.
Read the blank checklist
INTERNATIONAL COOKIE CONSENT QA HANDOFF Client / site: Release or published container version: Policy owner: Implementation owner: Verification owner: SCOPE (one entry per URL and visitor location) Public URL: Requested location: Observed country and verification evidence: Expected regional behavior: Observation window and date: Planned paths: first load, accept all, reject all (separate fresh sessions) Completed paths and coverage gaps: Unmeasured pages, endpoints, and server-side behavior: FINDING (repeat for each finding) Specific measured observation: Affected URL, location, and consent path: Baseline audit / evidence link: Proposed cause (unconfirmed): Confirmed cause and source / tag configuration: Fix owner and due date: Deployed change and release: Matching regional retest / evidence link: Result: resolved / still observed / inconclusive Remaining work and owner: CLIENT REVIEW Completed coverage: Open findings and owners: Missing evidence: Next check and responsible person: Requests alone don't establish a consent violation. Missing evidence stays inconclusive. This packet documents measured browser behavior; it isn't legal certification.
The UK fixture assumes the measured cookie mismatch is absent when complete evidence is supplied. These controls change invented evidence, not a live client report. Review readiness applies only to these two example rejection findings.
Agree the scope with the client
List the exact public URLs, visitor countries, and expected consent behavior. Include campaign pages when their scripts differ. Ask the client who owns the consent policy and who can change the consent management platform (CMP), the banner and choice-storage system, or the tag container.
Record the observation window and exclusions. A browser check covers its measured page and activity; server-side tracking, first-party proxies, or unrecognized endpoints may require separate work. CookieTrail's US East and US West routes don't establish a specific state's location.
Capture three fresh paths per location
- First load: no prior cookies or saved choice; record defaults and early activity.
- Accept all: a separate fresh session; confirm the choice and resulting behavior.
- Reject all: another fresh session; confirm the choice and compare cookies and relevant requests with the intended setup.
- For every path: keep the requested and verified country, time, duration, evidence link, and coverage limitations.
Count planned coverage separately from completed coverage. Three locations with three paths mean nine planned observations. If one rejection control can't be reached, report the eight observations and the gap rather than claiming all nine were checked. For a scoped plan and blank CSV, use the regional test-plan builder.
Assign findings to the people who can act
Give each finding a specific observation, affected URL and country, evidence, and named owner. A developer may own a hardcoded script; the client's marketing team may own Google Tag Manager. Confirm who can publish the change and who will verify it.
Keep a proposed cause separate from a confirmed one. For a request after rejection, inspect consent and cookie evidence before deciding it is a failure: advanced Google Consent Mode can send cookieless measurements under denied consent.
- Google: Consent Mode behavior Interpret Google requests before assigning a fix.
Include the matching release retest
Retest after the change is public using the original URL, location, and path. Record the release or container version and link the baseline and new evidence. Label each finding resolved, still observed, or inconclusive at that scope.
You can assemble the handoff from browser captures and a spreadsheet. Keeping it current means repeating the regional checks and linking every retest. CookieTrail keeps audit evidence and finding history together; use the worksheet for scope, completed coverage, findings and owners, deployed changes, verification, and remaining work.