ConsentCheck

Methodology: How ConsentCheck Measures Consent & Conversion

This page documents, in plain technical terms, how the scan works, what it detects, and what it intentionally does not measure. It is written for people who need to trust the method (engineers, analysts, reviewers, and search engines), not as sales copy.

1. High‑Level Overview

ConsentCheck runs a headless browser that behaves like a new visitor with no prior cookies. It loads your page, observes what actually happens in the browser, and records evidence about cookies, scripts, network requests, and consent signals. The verdict is based on observed behavior - not on what dashboards or CMP settings claim should happen.

2. Scan Flow (Step by Step)

  1. Start a fresh browser session with no existing cookies or storage.
  2. Load the URL and wait a short period so CMPs can initialize.
  3. Record all cookies set before any consent interaction.
  4. Record all network requests that match known tracking patterns (Google Analytics, Google Ads, Meta Pixel, etc.).
  5. Inspect the page for Google Consent Mode v2 configuration and default states (e.g. ad_storage, analytics_storage). See our Consent Mode validation guide for how to check if it's working.
  6. Simulate consent interactions (accept / sometimes reject) where possible and observe how cookies, scripts, and requests change.
  7. Optionally read IAB TCF signals when the TCF API is present, to compare declared consent with actual browser behavior.
  8. Assign a verdict (PASS / PARTIAL / FAIL) based on the combined evidence.

A more narrative version of this flow is available on the How the Consent & Conversion Scan Works page. This page is the concise reference.

3. What the Scanner Detects

The scanner focuses on technical signals that directly affect Google Ads conversion measurement and consent enforcement in the browser:

  • Cookies before consent: non‑essential cookies (e.g. GA, _gcl_au, _fbp) set before any consent action.
  • Tracking scripts before consent: network requests to tracking endpoints fired before consent (Google Analytics, Google Ads, Meta Pixel, etc.).
  • Google Consent Mode v2: presence of gtag('consent', 'default'), default denied states, and whether gtag('consent', 'update') is called after consent.
  • Conversion behavior: whether conversion events are observed before consent and after accept, and whether they appear blocked by consent.
  • Banner structure: existence of a visible consent banner, accept/reject parity, and obvious structural issues.
  • TCF context (when present): basic TCF values and whether declared consent appears aligned with observed behavior.
  • Server‑side tracking hints: presence of server‑side GTM / measurement endpoints (used to adjust how we interpret missing browser‑side events).

4. What the Scanner Intentionally Does Not Detect

Some things are outside the scope of this tool by design. Calling these out explicitly is important for correct interpretation:

  • No legal compliance verdict: we do not judge whether your setup is legally compliant with GDPR, CCPA, or any other regulation. We only report technical behavior.
  • No Google Ads account inspection: we do not read your Google Ads or GA4 account. We cannot see bids, conversion columns, or attribution windows.
  • No business performance verdict: we do not estimate ROI, ROAS, or revenue impact. We highlight technical patterns that are likely to affect measurement.
  • No full site crawl: the scan focuses on the URL you provide and the flows it can reach from there. It does not automatically crawl your entire site.
  • No deep server‑side audit: we surface server‑side tracking hints, but do not audit your server‑side pipelines or cloud configuration.

5. Client‑Side vs Server‑Side Behavior

The scanner observes the browser. This is well‑suited for detecting issues where tags fire too early, cookies are set before consent, or Consent Mode v2 is absent or misconfigured. It is less suited to diagnosing problems that exist only in server‑side infrastructure.

When server‑side tracking endpoints are detected, the verdict logic changes:

  • We do not automatically fail because we do not see a browser‑side conversion; conversions may legitimately be sent from the server.
  • We continue to verify browser‑side consent behavior and Consent Mode v2 configuration.
  • We label certain checks as requiring manual verification for server‑side setups.

In short: we verify browser consent behavior directly and treat server‑side conversions as a context signal, not something we can fully validate.

6. Known Limitations

No automated scan can cover every edge case. These are some of the most important limitations to keep in mind:

  • Single‑page context: we analyze one URL and the flows reachable in a short session. Checkout funnels, pop‑ups, or flows hidden behind logins may not be reached automatically.
  • Bot protection and A/B tests: some sites block automated browsers or show different behavior (e.g. different consent banners) to different users. Our scan captures one path.
  • Timing‑sensitive behavior: CSPs, delayed scripts, or late‑loading banners can change behavior over time. We wait a short, fixed period before measuring, but cannot simulate every timing.
  • Framework‑specific quirks: SPAs and frameworks that hydrate client‑side can temporarily re‑order script execution. We try to distinguish these from true tracking‑before‑consent issues, but there are edge cases.
  • Interpretation still required: the report shows strong technical signals. Final interpretation (especially for legal or business decisions) should consider your full setup, not just this scan.