ConsentCheck

Case Studies (Anonymized)

These short examples are anonymized and simplified, but they reflect real patterns seen in ConsentCheck scans. They show how technical consent issues can translate into lost conversions or misleading Google Ads data.

1. Ecommerce: Conversions Dropped After a Theme Update

An ecommerce site saw Google Ads conversions fall sharply after a visual theme update. Campaigns were still spending, but reported conversions were down and CPA was up.

What the scan found

  • GA4 and Google Ads tags started firing before the consent banner appeared.
  • The theme update moved the consent banner lower in the DOM and delayed its script, so tags loaded with default consent "granted".
  • No gtag('consent', 'default') call with denied states was present.

Impact

  • Google Ads received inconsistent signals; some sessions had full tracking, others had none.
  • Modeled conversions were suppressed because Consent Mode v2 was effectively off.

Fix

  • Re‑introduced Consent Mode v2 with default denied states before any tags.
  • Ensured the banner script and consent logic run before GTM/gtag load.

2. B2B SaaS: sGTM Setup Passing Client‑Side but Failing Server‑Side

A B2B SaaS company moved conversions to server‑side GTM (sGTM). Browser‑side tags looked clean at first glance, but reported conversions in Google Ads were lower than expected.

What the scan found

  • No browser‑side conversion events were observed (as expected with sGTM), but some legacy GA/Ads scripts still loaded before consent.
  • Consent Mode v2 was configured, but there was no clear mapping of consent state from the browser to the server.

Impact

  • Google Ads received a mix of partial client‑side and server‑side signals.
  • Some conversions were dropped due to missing or inconsistent consent state server‑side.

Fix

  • Removed legacy client‑side conversion tags to avoid double counting.
  • Implemented explicit consent propagation from the client to the server (e.g. via TTLC or custom headers) and verified it in sGTM.

3. Publisher: Reject Button That Didn't Block Tracking

A content publisher added a new CMP with "Accept" and "Reject" buttons. On paper, the CMP vendor promised full consent enforcement.

What the scan found

  • Tracking scripts continued to fire after clicking "Reject".
  • No meaningful change was observed in network requests between Accept and Reject.
  • TCF signals were present but did not affect actual tracking behavior.

Impact

  • Users were tracked regardless of their choice, creating both privacy and trust issues.
  • Google Ads measurement appeared "fine" in the UI, masking the underlying problem.

Fix

  • Updated tag manager logic so that tracking tags were gated by consent state.
  • Validated behavior again with a follow‑up scan and manual checks.