GDPR & CCPA tracker consent basics

What GDPR and CCPA require before marketing trackers fire, what valid consent looks like technically, and how a beacon audit supports compliance.

Plain-language orientation for marketers and site owners — not legal advice. Privacy law is jurisdiction- and fact-specific; involve counsel for decisions.

The core rule

Under the EU's GDPR (and the UK GDPR), non-essential trackers — marketing pixels, advertising cookies, most analytics — generally need the visitor's prior consent before they fire. Under California's CCPA/CPRA, the model is different: businesses must honor the consumer's right to opt out of the sale or sharing of personal information (including via the Global Privacy Control signal), and provide clear notice. Both regimes punish the same failure mode: trackers firing when the law says they shouldn't.

GDPR: prior, informed, revocable consent

• Prior — consent must come before the tracker loads. A marketing pixel that fires on page load while the banner is still showing is non-compliant regardless of what the visitor clicks afterward.
• Granular — visitors must be able to accept analytics while rejecting marketing, not take-it-or-leave-it.
• Freely given and revocable — no dark patterns, and withdrawing consent must be as easy as giving it.
• Documented — you need records of what each visitor consented to, which is what consent management platforms (CMPs) like OneTrust and Cookiebot provide.

CCPA/CPRA: opt-out and notice

• Right to opt out of sale/sharing — typically a conspicuous "Do Not Sell or Share My Personal Information" link, honored without requiring an account.
• Global Privacy Control (GPC) — a browser signal businesses must treat as a valid opt-out request.
• Notice at collection — visitors must be told what is collected and why, at or before the point of collection.

What valid consent looks like technically

Consent must gate execution, not just visibility. The banner can render while tags stay blocked; what matters is that no marketing or analytics script fires, no tracking cookie is set, and no beacon request leaves the browser until the visitor's choice permits it. The critical failure mode is trackers firing before consent: a pixel hardcoded in the page template loads on every visit regardless of the banner, and tag managers whose tags aren't bound to consent state do the same.

How a beacon audit supports compliance

• Can: inventory every tracker embedded on each page; detect the presence of a CMP; show whether trackers load directly or via a tag manager; and — in browser-render mode, which executes the page as a first-time visitor with no consent given — show which trackers fire pre-consent. That's a concrete, reportable finding.
• Can't: click "accept" or "reject" and observe what changes, or certify legal compliance. The audit is evidence for your review, not a verdict.

More on consent banners and beacon audits.

Typical gaps an audit surfaces

• No CMP at all — marketing pixels firing on a site subject to consent requirements.
• CMP present, tags hardcoded outside it — the banner exists but key pixels bypass it.
• Legacy pixels outside governance — old tags installed before the CMP, never migrated into its consent rules.

Found gaps? Work the full audit method or clean up the dead pixels.