Consent integration

Prism enforces visitor consent server-side, before any event is shared with an ad platform. You don't have to remove or gate the snippet to be consent-correct (though you can) — tell Prism the visitor's consent state and the platform fan-out respects it automatically.

How the gate works

Every event the snippet sends can carry a consent object. On the server:

• An explicit denial always suppresses Meta/Google delivery — regardless of configuration. The event is still recorded first-party (your own analytics keep working); it is never shared.
• A Global Privacy Control signal (Sec-GPC: 1 header or navigator.globalPrivacyControl) is treated as a denial. The server checks the header itself, so it holds regardless of what the payload says.
• On Shopify storefronts, window.Shopify.customerPrivacy (marketingAllowed() / saleOfDataAllowed()) can deny, and a later grant restores delivery.
• A grant allows delivery.
• No signal: behavior depends on your per-client configuration (below).
• Meta Limited Data Use is sent on every Meta event (data_processing_options: ['LDU'], with country and state set to 0), so Meta geo-detects the visitor and applies restricted processing in covered US states and leaves everyone else unaffected. It doesn't depend on the consent signal: a denial still blocks delivery entirely.
• Google Consent Mode parameters (adUserData / adPersonalization) follow the visitor's own signal. A visitor who granted data-sharing but denied personalization is delivered with personalization off.

The resolved status is stored on every event (granted / denied / unknown), so your records show what was honored.

Telling Prism the consent state

Option 1 — window.prismConsent (recommended)

Set a Google-consent-mode-shaped object before or after the snippet loads (values are 'granted' or 'denied'). The snippet reads it at page load and re-reads it every time it sends an event; only keys that changed since the last read are merged, so an unchanged stale value never overrides a later signal:

<script>
  window.prismConsent = {
    ad_storage: 'granted',
    ad_user_data: 'granted',
    ad_personalization: 'denied',
    analytics_storage: 'granted',
  };
</script>

Wire your CMP's callback to set this object from the visitor's choice. If you already run Google Consent Mode, mirror the same values. The same signal can also be sent with a command or a DOM event, below.

Option 1b — prism('consent', …) command and prismConsent event

Once prism.js has loaded, update consent at any time (for example from a banner button). Partial objects merge into the current state:

prism('consent', {
  ad_storage: 'denied',
  ad_user_data: 'denied',
  ad_personalization: 'denied',
  analytics_storage: 'granted',
});

Before prism.js has loaded the command doesn't exist yet; use window.prismConsent instead. If you'd rather not call into Prism directly, dispatch a DOM event with the same shape as detail. The snippet listens on window, and also sees it when dispatched on document:

window.dispatchEvent(new CustomEvent('prismConsent', {
  detail: { ad_storage: 'granted', ad_user_data: 'granted', ad_personalization: 'granted' },
}));

Option 2 — IAB TCF auto-detect

If your site runs an IAB TCF v2 CMP (OneTrust, Cookiebot, Didomi, …), Prism detects window.__tcfapi automatically and derives consent from the standard purposes — no configuration needed. It subscribes with __tcfapi('addEventListener', 2, …) and updates on the CMP's tcloaded and useractioncomplete events, so a choice made after page load is picked up. CMPs without addEventListener get a single getTCData read. TCData with gdprApplies === false is treated as "no signal", never as a denial. The latest signal from any of these sources wins.

Signals that always win

Whichever route you use, two signals can only deny, never grant, and override all of the above: Global Privacy Control (navigator.globalPrivacyControl or the Sec-GPC header) and a Shopify customerPrivacy denial (marketingAllowed() or saleOfDataAllowed() returning false). A site-supplied granted can't undo them.

The _fbp cookie

While ad consent is denied, Prism doesn't create the _fbp Meta browser-ID cookie and doesn't send it. If consent flips to denied part-way through a page view, _fbp stops being sent from that point; an _fbp cookie that already exists isn't deleted (Meta's own pixel may own it too).

Option 3 — gate the script entirely

The strictest posture: only inject the snippet after consent, exactly as you would a pixel. Note this also disables first-party analytics for non-consenting visitors, which the server-side gate would have preserved.

Per-client configuration

Ask your agency (or set in the Adsidian dashboard) two per-site options:

Setting	Effect
consent_required	When on, events without any consent signal are gated by consent_default instead of being delivered. Turn this on for sites serving EU/UK visitors.
consent_default	granted (default) or denied — what happens to no-signal traffic when consent_required is on. denied = strict opt-in posture.

A site with a CMP needs no configuration at all: explicit signals always win.

Cookies and consent

The adsidian_id identifier cookie is set by Prism's /id endpoint when the snippet initializes. If your jurisdiction requires consent before any non-essential cookie, use Option 3 (gate the script) so no cookie is set pre-consent.

What to put in your privacy notice

See Required disclosures and Suggested privacy-policy wording for template language you can adapt for your own privacy policy.