Adobe Web SDK pending consent: why page-view events disappear after navigation

A visitor lands on a campaign page, waits at the consent banner, accepts, and moves to the next page. The campaign entry view is missing in Adobe. The network panel also showed no Edge call before consent. Those observations do not, by themselves, mean Web SDK failed: under pending consent, calls wait inside the SDK.

An Experience League implementation question describes this exact confusion with OneTrust and a rule that maps a category to Adobe consent. The Adobe reply explains that pending calls are released on consent-in and discarded on consent-out. The critical extra condition is timing: Adobe documents that the queue lives only in page memory. Navigation or reload before resolution loses it.

Reconstruct the visitor sequence

Record the first page load, Web SDK configure time, CMP initialization, category update, consent callback, setConsent call, its resolved value and navigation. Do this for a new visitor and a returning visitor. A screenshot of the network panel at only one moment cannot establish which event was queued, discarded or sent.

If the integration reads a CMP global before it exists, the implementation may translate an unknown state into opt-out. In the community example, stringifying an unavailable OneTrust group can make the category check false. That is a mapping bug, not a reason to force collection before consent. Subscribe to the CMP's resolved-consent event and leave Adobe in pending state until the decision is known.

Test four paths, not just acceptance

Check accept on the first page, reject on the first page, accept after a delayed CMP response, and navigate before any choice. Record the expected Edge requests, ECID and consent cookie behavior for each. A denied choice should discard queued events; a granted choice should release them. An unresolved choice followed by a page reload should not be assumed to replay the old queue.

Where the business needs an entry interaction after late consent, define explicitly which event may be generated after consent and how duplicate page views will be prevented. Have privacy and measurement owners approve that behavior. Do not persist pre-consent behavioral payloads in custom storage merely to recover a number.

What to require from an implementation partner

Ask for a state diagram and a browser test trace that includes a fast navigation, a slow CMP, a returning visitor and a denial. The deliverable is a consent-safe measurement contract: which event is sent, dropped or deliberately recreated for each path.

Adovo’s view

Consent is a state transition, not a banner click. If measurement depends on a race between a page change and a callback, the number was never trustworthy. Resolve the state first, then make the event policy explicit. A lost event can be acceptable; an unexplained event cannot.