Skip to content
Lightning CMP

How it works

Everything the CMP does rests on one idea: four consent categories drive every tag on your page, and the CMP forwards the visitor’s decision to your vendors live. This page is that idea, unpacked.

The four categories

Section titled “The four categories”
Category What it governs Default under GDPR
necessary Strictly required functionality. Always granted, can’t be switched off. granted
preferences Remembering choices (language, region, UI state). denied
statistics Analytics and measurement. denied
marketing Advertising, retargeting, conversion tracking. denied

A visitor’s decision is a set of booleans over these four categories. Every mechanism below is just a way of acting on those booleans.

Bridge, then block

Section titled “Bridge, then block”

Most CMPs do one thing: block a tag until the visitor consents. That’s correct, but blunt — a blocked analytics tag sends nothing, so you lose the data even for measurement the visitor never objected to.

Lightning does something better first. Where a vendor supports a consent-aware mode, it bridges consent — loads the tag and forwards the decision, so the vendor self-throttles to privacy-safe, cookieless signals under denial instead of going dark. It falls back to hard blocking only for vendors with no such mode.

Prefer this

Bridge it

The vendor has a consent-aware mode (Google, HubSpot, Adobe, Pardot…).

The CMP loads the tag and forwards the decision. Under denied consent it keeps sending cookieless, privacy-safe signals instead of going dark — so your measurement survives.

Fallback

Block it

The vendor has no consent-aware mode (Meta Pixel, TikTok, LinkedIn, Hotjar…).

The CMP refuses to execute the <script> until its category is granted. Nothing fires, nothing is set, until the visitor says yes.

Section titled “1. Consent bridges”

The CMP loads a supported vendor and forwards the decision, live. The vendor self-throttles: full tracking when granted, cookieless/anonymous signals when denied.

  • Google Consent Mode v2 is the first bridge — gtag('consent', …) lets GA4, Google Ads and Floodlight degrade gracefully, and Google’s modelling recovers much of the denied data.
  • HubSpot, Adobe and Pardot follow, each a single config flag.

This is what keeps your measurement alive without hard-blocking — and it’s the part most sites get wrong when wiring vendors by hand. See Built-in bridges.

2. Hard script blocking

Section titled “2. Hard script blocking”

For vendors with no consent-aware mode (Meta Pixel, TikTok, LinkedIn, Hotjar…), the CMP refuses to execute any <script> you mark with a placeholder type until its category is granted. It’s Cookiebot-compatible, so existing markup migrates as-is. See the Script blocker.

How categories map to Google’s signals

Section titled “How categories map to Google’s signals”

Bridges translate the four categories into each vendor’s own consent flags. For Google Consent Mode:

CMP category Google Consent Mode signal(s)
necessary security_storage (always granted)
preferences functionality_storage, personalization_storage
statistics analytics_storage
marketing ad_storage, ad_user_data, ad_personalization

More on this in Google Consent Mode v2.

Regulation is resolved at the edge

Section titled “Regulation is resolved at the edge”

You install one snippet. Which rules apply to a given visitor is decided server-side from their region, so you never ship per-market logic:

  • GDPR (EU/EEA/UK) → opt-in: optional categories default denied, the banner is shown.
  • US state laws (CCPA/CPRA…) → opt-out: optional categories default granted, Global Privacy Control is honoured, and a “Do Not Sell or Share” path is offered.
  • Elsewhere → no banner, by design.

You can override this with the geo option to force one model everywhere.

Section titled “The consent lifecycle”
  1. First visit. The CMP reads the region-resolved default. Under GDPR nothing optional is granted and the banner appears; under US law optional categories start granted (subject to GPC) and the banner is informational.
  2. The visitor decides — Accept all, Reject all, or per-category in the preferences modal.
  3. The decision is stored and every bridge is updated live; blocked scripts whose category is now granted are executed.
  4. They change their mind. A persistent floating button reopens preferences; LightningCMP.openPreferences() does the same from your own UI.
  5. Re-prompting. With consentExpiryDays set, a stored decision expires after N days and the banner returns.

Every explicit decision can produce a downloadable consent receipt and a server-side audit record — see Consent state & receipts.

Where to go next

Section titled “Where to go next”