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 grant allows delivery.
• No signal: behavior depends on your per-client configuration (below).
• Visitors who granted data-sharing but denied personalization are delivered with restricted-processing flags: Meta Limited Data Use and Google Consent Mode (adUserData / adPersonalization).

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 (the snippet reads it at page load; values are 'granted' or 'denied'):

<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.

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. An explicit window.prismConsent takes precedence.

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 for template language you can adapt for your own privacy policy.