I85PREP
⌘ K
Adobe Analytics Developer Expert study materials
Adobe Analytics Developer Expert study resources

The Data Layer That Lies About Consent

Adobe Analytics Developer Expert · Put your knowledge to work in context.

All case studies

The Data Layer That Lies About Consent

A healthcare-adjacent client (HIPAA-adjacent, though the marketing site itself is public) has a global digitalData data layer pushed on every page. A recent audit found that digitalData.user.authenticated is set to true by default in the base template and only flipped to false by a tag rule after login state resolves - meaning for ~400ms on every page, authenticated is true. The Adobe Experience Platform Web SDK is configured with defaultConsent: { analytics: 'pending' } and a setConsent call fires from a OneTrust callback. Analytics events are being sent before consent resolves for roughly 2% of sessions. The client's legal team wants a guarantee that no analytics beacon leaves the browser before consent. The tag manager is Adobe Experience Platform Tags (Launch).

1. Identify the two independent failure modes in this setup and explain why fixing only the data layer default would not satisfy the legal requirement.

Read the worked answer

Failure mode 1 - data layer default is wrong. authenticated: true by default means any tag rule that reads the data layer before the login state resolves will misclassify anonymous users as authenticated. This is a data quality problem: it inflates authenticated-user segments and could route PII-adjacent context incorrectly. The fix is to default to false (or an explicit unknown sentinel) and only promote to true on positive confirmation.

Failure mode 2 - consent gating is event-driven, not enforcement-driven. defaultConsent: { analytics: 'pending' } means the SDK holds events in a queue until setConsent resolves. But 'pending' is a queue, not a drop. If setConsent never fires (OneTrust blocked, callback error, slow CSP load), queued events may flush on a timeout or on the next page depending on configuration. More importantly, if any rule calls alloy with consent overridden, or if a separate AppMeasurement instance still exists, beacons leave regardless of the Web SDK consent state.

Fixing the data layer default does nothing for failure mode 2. The legal requirement is 'no beacon before consent' - that is an enforcement property, not a data accuracy property. They are orthogonal.

2. Propose a tag manager configuration that enforces the no-beacon-before-consent guarantee, and describe how you would validate it.

Read the worked answer

Enforcement configuration:

  1. Set defaultConsent to { analytics: 'out' } - not pending - so events are dropped, not queued, until consent is explicitly granted. If the client wants to preserve pre-consent events for later, that is a separate legal decision and must be documented; the safe default for a healthcare-adjacent client is out.
  2. Gate every analytics-bound rule with a consent check that reads a single source of truth (the OneTrust category state), not a data layer flag that can drift.
  3. Remove or disable any legacy AppMeasurement library still loaded on the page. Two SDKs means two consent states.
  4. Add a rule on the OneTrust OnConsentChanged event that calls alloy('setConsent', ...) with the mapped categories.
  5. Ensure no rule fires sendEvent on Library Loaded or DOM Ready for analytics events - those must be user- or state-driven and consent-gated.

Validation:

  • Use the Adobe Experience Platform Debugger and browser dev tools to confirm zero requests to edge.adobedc.net before the consent callback fires, across a sample of pages including error pages.
  • Test the 'OneTrust blocked' scenario (block the script via dev tools) and confirm no beacons fire at all - the failure mode should be 'no analytics', not 'analytics without consent'.
  • Run a synthetic crawl that loads 50 pages and asserts no edge requests in the first 2 seconds.
  • Confirm the consent state persists correctly across sessions per the client's consent expiry policy.