Consent Management

Signal provides comprehensive consent management that integrates with your Consent Management Platform (CMP), enforces consent rules per-integration before delivery, and passes the correct consent signals to each vendor API.

How Consent Works in Signal

1. Capture — Datafly.js reads consent state from your CMP’s cookie or storage location.
2. Attach — Two views of the consent state are attached to every event payload:
   • context.consent.categories — the customer’s CMP-specific codes (e.g. statistics, C0002).
   • context.consent.canonical — Signal’s fixed vocabulary, mapped from those codes.
3. Enforce — The pipeline engine filters integrations based on consent before delivery.
4. Translate — Vendor blueprints reference consent through context.consent.canonical.<purpose>, so the same blueprint works for any CMP.
5. Audit — Every filtering decision is logged.

The two views: categories vs canonical

Signal emits both views on every event so blueprints stay portable across CMPs:

{
  "context": {
    "consent": {
      "categories": {
        "necessary": true,
        "preferences": true,
        "statistics": false,
        "marketing": false
      },
      "canonical": {
        "essential": true,
        "functional": true,
        "analytics": false,
        "marketing": false
      }
    }
  }
}

See Canonical Categories for the full vocabulary, classification guidance, and migration notes.

Supported CMPs

Signal supports reading consent from any CMP, with first-class auto-seeding for the most common ones:

When you select a known CMP in Settings → Consent, Signal pre-populates the standard categories and their canonical classifications. You can override these or add custom categories at any time.

Cookie format support

Signal’s parser handles five formats so you rarely need transformation logic in your CMP integration:

1. JSON object — {"necessary":true,"marketing":false}
2. JS object literal (Cookiebot’s native shape) — {stamp:'abc==',necessary:true,...}
3. Colon-delimited, comma-separated — essential:1,functional:1,analytics:0,marketing:0
4. URL query string (OneTrust) — groups=C0001:1,C0002:1,C0003:0,C0004:0
5. Semicolon-delimited key=value — analytics=1;marketing=0;functional=1

URL-encoding and double-encoding are handled transparently.

Per-Vendor Consent Enforcement

Consent enforcement happens at two stages:

1. At ingestion — before any vendor-side identifier sync runs, Signal checks the visitor’s recorded consent against each sync’s required category (default marketing). Denied vendors are silently omitted so the browser never fires the corresponding match-pixel redirect. See Identity.
2. At delivery — before events reach each vendor’s API. Each integration can have a consent category gate; events without the required consent are filtered and never delivered.

Both stages honour the pipeline’s consent_mode: explicit (GDPR, absent → denied) or implicit (CCPA, absent → granted).

How blueprints reference consent

Vendor blueprints reference consent through the canonical view:

# GA4 blueprint — works for Cookiebot, OneTrust, Didomi, anything
- target: "@root.consent.ad_user_data"
  source: "context.consent.canonical.marketing"
  transform:
    type: value_map
    map:
      "true": GRANTED
      "false": DENIED

The customer chooses how their CMP’s categories map to Signal’s canonical vocabulary in Settings → Consent. Once that mapping is set, every blueprint that references canonical.marketing (Meta CAPI, Google Ads, TikTok, GA4 …) reads the right value automatically.

Vendor-Specific Rules

In addition to the pipeline-level consent gate, each delivery layer applies vendor-specific consent enforcement. The blueprint determines the exact behaviour; the table below shows the typical defaults shipped with Signal:

Consent Audit Logging

Every consent filtering decision is recorded in the consent_filtered_events table:

This provides a complete audit trail for compliance reviews without storing PII.

Configuration

1. Add a consent provider

1. Go to Settings → Consent.
2. Click Add Provider and pick your CMP (or Custom).
3. Cookie name, storage type, and standard categories are pre-populated for known CMPs.
4. Each category has a Canonical Category dropdown — set it to one of essential, functional, analytics, marketing, personalization. Leave blank for unclassified categories (they still appear under categories but not under canonical).

2. Pipeline-Level Consent Gate

Each integration attached to a pipeline can have a consent category:

1. Go to Pipelines → [Your Pipeline] → Integrations.
2. Click an integration.
3. Set the Consent Category (typically marketing, analytics, or functional — these refer to the canonical vocabulary).
4. Set the Consent Mode (“Explicit” for GDPR, “Implicit” for CCPA).

Events without the required consent for that category will be filtered before delivery.

3. Notify the SDK on consent change

Whenever the user updates consent (CMP banner, preferences page), call:

datafly.refreshConsent();

This is cheap and idempotent — modules diff internally. The next event the SDK sends carries the new state.