Skip to main content

Consent Guard

Consent Guard detects the worst kind of cookie-banner failure: the one where the banner disappears but your tracking keeps running. Under GDPR/TTDSG, every day of tracking without consent is compliance exposure — and because nothing visibly "goes down", these failures routinely last for weeks.

How It Works​

On each run, Pulsar loads your storefront in a fresh headless browser — no cookies, a genuine first visit — and:

  1. Records every network request the page makes
  2. Verifies the consent banner/CMP is present (a CSS selector and/or a JavaScript global you configure)
  3. Checks whether a consent decision exists (consent cookies set by your CMP)
  4. Flags tracking requests that fired without one — GA4 hits, Meta pixel, Klaviyo, and others

The result maps to three severities:

ResultSeverityMeaning
Trackers fired with no consent decisionViolation (pages instantly)Your setup fails open — tracking without consent, live compliance breach
CMP missing, but no trackers firedWarningYour setup fails closed — an analytics gap, not a breach, but consent can't be collected
Check couldn't runWarningBrowser/navigation failure; investigate

A consent-guard violation is treated like a security compromise: it pages immediately through every notification channel and is never deferred to the daily digest.

Configuration​

Open your site in Pulsar and find the Consent Guard card.

SettingDescription
Page pathThe page to load, usually /
CMP CSS selectorElement that must appear when the banner works, e.g. #usercentrics-root, #CybotCookiebotDialog
CMP JS globalwindow.<name> that must be defined when the CMP loaded, e.g. CCM, UC_UI, Cookiebot
Tracker URL patternsRequests that must not fire pre-consent. Leave empty for built-in defaults
Consent cookie patternsCookie names that indicate a consent decision. Leave empty for built-in defaults
Check intervalHourly is typical; minimum 5 minutes

Configure at least one of CMP CSS selector or CMP JS global so the banner-presence assertion runs.

Built-in defaults​

Tracker patterns cover the collection endpoints (not the script loaders) of GA4, Universal Analytics, DoubleClick, Meta pixel, Klaviyo onsite tracking, TikTok, and Pinterest. Loading gtag.js before consent is fine under consent mode — sending a hit is the violation, so only collection endpoints are matched.

Consent cookie patterns cover CCM19, Usercentrics, Cookiebot, OneTrust, CookieFirst, Borlabs, iubenda, Complianz, and Magento's built-in cookie notice.

Avoiding False Positives​

Two situations look like violations but aren't — Consent Guard handles both:

  • Google consent-mode "denied" pings. With consent mode active, GA sends cookieless pings even when analytics consent is denied (gcs=G100). These are recognised and not flagged; only hits with analytics storage granted — or with no consent-mode parameter at all — count.
  • Geo-based auto-grant. Some CMPs automatically grant consent for visitors outside the EU. If the CMP records a consent decision (a consent cookie appears), tracker requests are treated as the CMP's decision and not flagged.

When a Violation Fires​

  1. Confirm it — open your store in a private/incognito window with DevTools → Network. Filter for collect. If hits appear before you interact with the banner, the setup is failing open.
  2. Check the consent script itself — a common root cause is the CMP CDN serving an error stub (quota exhausted, expired plan) with HTTP 200. A dependency check on the CMP script URL tells you immediately.
  3. Fix the source — usually a plan upgrade or configuration fix at the CMP provider. The alert auto-resolves once a run comes back clean.
Harden your embed

Consent Guard detects fail-open, but you can also prevent it: gate your analytics embeds on the CMP actually being present, so a future CMP outage becomes an analytics gap instead of a compliance violation.