ConsentCheck

Real‑World Consent & Tracking Findings

This page summarizes patterns we repeatedly see in scans run through ConsentCheck. The exact numbers will change over time, but the themes are stable: most sites with consent banners still have technical issues that break or degrade Google Ads conversion measurement.

1. Headline Patterns We See Often

Across scans, a few patterns show up again and again. Percentages below are rounded and meant to illustrate typical ranges, not a fixed benchmark.

  • Tracking before consent: A majority of scanned sites fire at least one tracking request (GA, Ads, or Meta) before the user accepts consent.
  • Consent Mode v2 missing or partial: Many sites believe Consent Mode is enabled, but the scan detects no gtag('consent', 'default') call, no default denied state, or no update after consent.
  • Conversions firing before consent: On some sites, conversion events fire on page load or before consent is granted, which can suppress measurement or modeling.
  • Reject buttons that do not block tracking: Banner UIs present a reject or "continue without cookies" option, but tracking behavior is identical to accept.

For a technical breakdown of modeled vs. observed conversions and why reporting differences between GA4 and Ads occur, see why GA4 and Google Ads show different conversion numbers.

2. Why These Issues Are So Common

The problems we detect are rarely malicious. They are usually side‑effects of how tags, CMPs, and frameworks interact in the real world:

  • Tag order and defaults: Tracking libraries are often loaded before consent logic is ready. Even if the CMP is configured correctly, tags can still fire on initial page load.
  • Partial Consent Mode rollout: Sites add Consent Mode v2 snippets but forget to set defaults to denied, or never call gtag('consent', 'update') on accept/reject.
  • Theme / plugin updates: CMS or theme updates reorder scripts, inject new tags, or move the consent banner in the DOM, changing behavior without anyone touching tracking code directly.
  • Server‑side tracking assumptions: Some setups move conversions server‑side but leave legacy tags or Consent Mode logic in place, creating confusing or inconsistent browser behavior.

3. Examples (Patterns Seen in Scans)

Example A - Tracking loads before consent banner

A site uses a consent banner that appears a second after page load. Google Tag Manager and GA4 are loaded immediately with no Consent Mode default set to denied. The scan sees GA requests before any consent action.

From the CMP's perspective, consent is respected because it controls some tags. From the browser's perspective, tracking already occurred before the user had a choice.

Example B - Consent Mode snippet present but not updating

A site includes gtag('consent', 'default') withad_storage and analytics_storage set to "denied". However, there is no gtag('consent', 'update') call when the user accepts cookies.

In practice, this means Consent Mode never switches to granted, so modeling may be suppressed and conversions may appear missing, even though the site "has Consent Mode" configured.

Example C - sGTM in place, but browser still leaks signals

A server‑side GTM setup sends conversions from the server, but legacy client‑side tags and cookies are still present. The scan detects early browser tracking before consent, even if the "canonical" conversion happens server‑side.

This creates both measurement and privacy issues: the account may receive double or inconsistent signals, and users are tracked before making a choice.

4. How to Use These Findings

These patterns are meant to give context, not to label individual sites as "good" or "bad". Every implementation has nuances. The scan shows what we observed in the browser; interpreting that in light of your business, stack, and legal requirements is still necessary.

  • Use the findings to prioritize fixes that have the biggest impact on measurement.
  • Use them to sanity‑check what your CMP, tag manager, and dashboards claim.
  • Share them with devs, agencies, and stakeholders to align on what is actually happening in the browser.

For a deeper explanation of how we collect this data, see the Methodology page.