Consent Enforcement

Datafly Signal enforces user consent at two stages in the event pipeline: once at ingestion and again at delivery. This two-stage approach ensures that consent is respected even when a user’s consent state changes between the time an event is collected and when it is delivered to a vendor.

Two-Stage Enforcement

Browser → Datafly.js (reads consent state)
  → Ingestion Gateway (Stage 1: consent check)
  → Kafka → Event Processor → Kafka
  → Delivery Workers (Stage 2: consent re-check)
  → Vendor API

Stage 1: Ingestion

When the Ingestion Gateway receives an event, it reads the consent state from the event’s context.consent object. If consent is not granted for any required category, the event is tagged but still ingested — it enters Kafka and can be processed for analytics purposes.

Stage 2: Delivery

When a Delivery Worker is about to send an event to a vendor, it re-checks the user’s consent state. This second check queries the most current consent state from Redis (updated in real time by Datafly.js when consent changes).

If consent has been revoked between ingestion and delivery, the event is dropped and not sent to the vendor. The drop is recorded in the delivery logs.

Consent Categories

Datafly Signal supports four standard consent categories:

Categories are configurable per integration. When you create an integration, you specify which consent categories are required:

{
  "type": "meta_capi",
  "name": "Meta CAPI",
  "consent_categories": ["advertising", "marketing"],
  "config": { ... }
}

This means events will only be delivered to Meta if the user has granted consent for both advertising and marketing.

Consent State in Events

Datafly.js reads consent state from the user’s consent management platform (CMP) and includes it in every event:

{
  "type": "track",
  "event": "Product Viewed",
  "properties": { ... },
  "context": {
    "consent": {
      "analytics": true,
      "marketing": false,
      "functional": true,
      "advertising": false
    }
  }
}

Consent Management Platform Integration

Datafly.js integrates with popular consent management platforms to automatically read consent state:

OneTrust

<script src="https://data.example.com/d.js"
  data-pipeline-key="dk_live_abc123"
  data-consent-provider="onetrust">
</script>

Datafly.js listens for OneTrust’s OptanonWrapper callback and maps OneTrust group IDs to Datafly consent categories.

Cookiebot

<script src="https://data.example.com/d.js"
  data-pipeline-key="dk_live_abc123"
  data-consent-provider="cookiebot">
</script>

Datafly.js listens for Cookiebot’s CookiebotOnConsentReady event and reads consent state from Cookiebot.consent.

Custom Consent Manager

For custom or unsupported CMPs, provide consent state directly via the SDK:

_df.setConsent({
  analytics: true,
  marketing: false,
  functional: true,
  advertising: false
});

Call _df.setConsent() whenever consent state changes (e.g., when the user updates their preferences). The new state is included in all subsequent events and pushed to Redis for the delivery-time re-check.

Per-Integration Consent Mapping

Each integration specifies which consent categories are required. The Delivery Worker evaluates the event’s consent state against the integration’s required categories:

The rule is: all required categories must be true for the event to be delivered.

Consent Revocation

When a user revokes consent:

1. Datafly.js detects the change (via CMP callback or _df.setConsent() call).
2. The updated consent state is sent to the Ingestion Gateway.
3. The gateway updates the consent state in Redis, keyed by anonymous ID.
4. Any Delivery Workers processing events for this user will read the updated consent state from Redis at delivery time.
5. Events that no longer meet the consent requirements are dropped.

User revokes advertising consent
  → _df.setConsent({ advertising: false })
  → POST /v1/consent → Ingestion Gateway → Redis update
  → Delivery Worker reads Redis → advertising: false
  → Meta CAPI event → DROPPED
  → GA4 event (analytics only) → DELIVERED

Consent Audit Trail

Consent state is included in every event payload, creating a built-in audit trail. For each event delivered to a vendor, you can verify:

• What consent the user had granted at the time of the event.
• What consent categories the integration required.
• Whether the event was delivered or dropped.

This information is visible in the Management UI under Sources > Live Events and in the Audit Logs.