Migration › Knowledge Base › The consent model
The consent model
Old consent was a blocked pipe: no permission, no beacon, no data. New consent is a valve on a queue, events wait safely behind it until the visitor says go.
Three parts work together. defaultConsent sets the posture before the visitor chooses[10], pending queues events locally and sends nothing (the GDPR-friendly default), in collects, out discards. setConsent records the actual choice and flushes or drops the queue[11]. The kndctr_..._consent cookie persists the preference, written either way.
You wire the choice with a Set Consent rule action[13], fired on Window Loaded for Adobe-standard consent, or from a __tcfapi useractioncomplete listener for IAB TCF[12]. Consent doesn't persist across page loads by itself, so you re-assert it each load.
For your migration: with pending, a mis-wired Set Consent leaves every event queued forever, which looks exactly like "Analytics is down" when nothing is actually broken. It's the most misdiagnosed failure in the whole migration.
Default to pending in regulated regions. Treat a queued-but-not-sending state as a consent-wiring bug to fix, not an outage to panic over.
From blocking the beacon to gating a queue
AppMeasurement consent worked by suppression: no consent, no script, no hit, and any data in that window was simply gone. The Web SDK instead queues. With consent pending, events accumulate locally and nothing is sent, but nothing is lost either, and the moment consent arrives, the queue flushes. Same goal, completely different mechanism, and the difference is the source of most consent confusion.
The three moving parts
| defaultConsent | Posture before the visitor chooses[10]: pending (queue, the GDPR-friendly default), in (collect), out (discard). |
| setConsent | Records the actual choice and flushes or drops the queue[11], wired as a Set Consent rule action. |
| kndctr_…_consent | The cookie that persists the preference, written regardless of the choice (it must record opt-out too). |
Adobe standard vs IAB TCF
For Adobe standard consent, fire Set Consent on Window Loaded and again on any consent change. For IAB TCF 2.0, listen with __tcfapi('addEventListener', …) and fire on useractioncomplete, passing the TC string, with standard set to IAB TCF[12].
1. Consent doesn't persist across page loads by itself, re-assert it each load, because the extension can't read current consent on its own. 2. With pending, events queue and never process until opt-in, a mis-wired Set Consent looks exactly like "Analytics is down." 3. For IAB TCF, the consent signal is not auto-attached to events, add the consent field group and include it in the XDM.