Handle consent

Consent works fundamentally differently now, and misunderstanding it is the fastest way to believe you've broken Analytics. AppMeasurement gated consent by blocking the beacon, no consent, no script, no hit. The Web SDK instead holds events in a queue: with consent pending, nothing is sent and nothing is lost, and the moment the visitor opts in, the queue flushes. Your job is to set the default posture and wire the rule that records the visitor's actual choice. Get the wiring wrong and every event sits in the queue forever, which looks exactly like "Analytics stopped working," even though it is behaving precisely as designed.

Why?Why consent works differently now ↗

What to do

Where (Web SDK extension config) › defaultConsent

Do Set the pre-choice posture. pending = queue events locally and send nothing until opt-in (the GDPR-friendly default)[10]; in outside GDPR; out to discard until opt-in.

Where Tags › Rules › Add Rule › Action: AEP Web SDK › Set Consent[11][14]

Do Record the choice. Adobe standard: fire on Window Loaded and on consent-change. IAB TCF: fire from a __tcfapi useractioncomplete listener, passing the TC string[12].

Old consent blocked the beacon. New consent holds events in a queue, opt-in flushes it, opt-out discards. A mis-wired valve looks exactly like an outage.

⚠ The gotcha that looks like an outage

With pending, sendEvent calls queue and do not process until consent is granted. A mis-wired Set Consent looks exactly like "Analytics is down." Re-assert consent each page load, the extension can't read current consent on its own.

⚠ Common mistake

Shipping pending without a working Set Consent, then chasing a non-existent outage for days while every event sits queued in the browser.

✓ You should see

Consent withheld → events queued, none sent. After opt-in → the queue flushes and hits appear in Assurance. The kndctr_..._consent cookie is written either way.