GDPRChecker

Home / Knowledge Base / How to Verify Consent Interaction Evidence

Website Compliance

How to Verify Consent Interaction Evidence

Verify Consent Interaction Evidence by testing each banner choice in a clean session and reviewing recorded consent state, runtime signals, and pre-consent tracking behaviour.

Author

GDPRChecker Editorial Team

Reviewed by

Privacy & Compliance Research Team

Last updated

July 2026

Reading time

2 min read

Educational guidance for compliance readiness — not legal advice. Requirements vary by jurisdiction and your specific processing activities.

Introduction

Verify that Reject all, Analytics only, Accept all, and preference changes produce the expected consent and tracking behavior on a live website.

What it means

Test from a clean private browser session so an old consent cookie does not hide the banner or invalidate the result.

Initial visit should begin with non-essential Consent Mode v2 parameters denied before Google tags act on a visitor choice.

Reject all should keep optional trackers blocked across navigation; Analytics only should release analytics but keep marketing denied; Accept all should follow the published configuration.

Evidence should identify the test state separately from a general runtime heartbeat, because a loaded banner alone does not prove visitor interaction behaviour.

Why it matters

Many consent failures appear only after a user clicks a button or navigates. Interaction evidence turns a visual banner review into a behaviour test.

Common mistakes

  • Treating a copied snippet as installed without verifying a live runtime heartbeat.
  • Placing the consent runtime after GTM, analytics, advertising pixels, or theme-injected scripts.
  • Publishing a configuration change without testing a clean browser session and the Reject all path.
  • Applying a broad blocking rule without reviewing the detected provider and category first.

Practical checklist

  1. Confirm domain ownership and open the site-specific Privacy Setup flow.
  2. Install or update the GDPRChecker runtime before non-essential tracking code.
  3. Publish the banner configuration and verify its live heartbeat.
  4. Test initial visit, Reject all, analytics-only, Accept all, and withdrawal in a private window.
  5. Run a compliance scan and keep the resulting evidence with the release record.
  6. Enable scheduled scans so later tag, plugin, theme, or campaign changes are detected.

How GDPRChecker helps

GDPRChecker’s Consent Interaction Evidence report shows the expected parameter state for initial visit, Reject all, Analytics only, and Accept all, alongside runtime readiness.

Combine it with a private-window test and a scanner report; automated third-party browser testing is intentionally labelled separately from recorded runtime evidence.

FAQ

Why is initial visit evidence important?
It proves the site begins from a denied state rather than relying on a banner that appears after optional tags already ran.
Does a green runtime heartbeat prove every button works?
No. It proves the runtime is connected. Test each visitor choice to collect interaction-specific evidence.
What should I do if a state remains pending?
Verify that the latest configuration is published, the runtime is installed on the live domain, and then run the clean-session interaction test again.

GDPRChecker guides are educational resources and do not constitute legal advice. Use them to understand technical and operational privacy requirements, and consult qualified counsel for legal interpretation.

Check Your Website in Under 60 Seconds

  • No signup required
  • GDPR-focused checks
  • Cookie banner detection
  • Privacy policy verification