Consent-Gated Tracking and the Missing Conversion Spike
A European retailer runs Adobe Analytics with the Web SDK. After a May consent-banner rollout, the analytics team notices that purchase events dropped 22% month over month while the order management system (OMS) shows revenue flat. Implementation review shows the Web SDK is configured so that non-essential calls are held until ecid and consent are resolved; the banner's default state is 'reject all' and only 31% of visitors interact with it. The purchase event fires on the order-confirmation page via sendEvent with documentUnloading: true. The privacy team requires that no analytics beacon containing identifiers leave the browser before explicit opt-in. The business wants the 22% gap explained and a path to trustworthy conversion reporting.
1. Diagnose the most likely cause of the purchase gap and separate it from a tagging defect. What evidence would you request before concluding?
Read the worked answer
The gap is most consistent with consent-driven suppression, not a broken tag. With a default 'reject all' banner and only 31% interaction, a large share of sessions never reach an opted-in state, so purchase beacons are not sent even though the transaction completed in the OMS.
Before concluding, request:
- Hit-volume trend by consent state (opted-in vs. pending vs. rejected) from the Web SDK debug/Experience Platform debugger or edge network logs, not just the report suite.
- A same-period comparison of
purchasecount vs. OMS order count, segmented by day, to confirm the drop is uniform and not concentrated on a release date. - Release timeline - did the consent change and the drop share a date? A tagging defect usually produces a sharp step change tied to a deploy; consent suppression produces a gradual shift tied to banner behavior.
- A test order through the funnel with the debugger open, confirming
sendEventfires and whether the edge call is deferred or dropped.
Key discriminator: if the edge request is made but not sent pending consent, that is a consent-gating behavior. If the sendEvent never executes, that is a tagging defect.
2. The business asks you to 'recover' the missing conversions by sending a delayed beacon after consent resolves. Evaluate this against the stated privacy requirement and recommend an approach.
Read the worked answer
A delayed beacon that replays a past purchase after consent resolves conflicts with the stated requirement that no identifier-bearing analytics beacon leaves the browser before explicit opt-in. Replaying a queued event after the fact is defensible only if the queued payload contains no identifiers and is genuinely non-identifying until consent - which is hard to guarantee for a purchase event tied to an ECID and order ID.
Recommended approach:
- Do not queue-and-replay identified purchase events. Keep the hard gate.
- Model the gap, don't fabricate the data. Use OMS revenue as the source of truth for totals and use analytics for behavioral ratios among consented users, clearly labeling analytics conversion as 'consented-visitor conversion.'
- Improve consent rate through banner UX (timing, clarity, granular purpose toggles) so the observed population grows - this is a business lever, not a tagging workaround.
- If leadership needs full-population estimates, produce a documented, reviewed model (e.g., consented-sample extrapolation) with an explicit confidence caveat, owned by analytics and approved by privacy - never silently blended into the report suite.
The architect's job is to make the tradeoff visible, not to engineer around the privacy control.