Data Layer and Integration Architecture
The data layer is a versioned contract between the application and analytics. Candidates should understand its purpose: decoupling tracking from UI implementation, providing a stable schema for tag rules, and enabling validation before data leaves the browser. Know the anatomy: a global object populated on page render and updated on interaction, with documented field names, types, and allowed values, plus an event/push mechanism for single-page applications.
Integration architecture covers how Adobe Analytics receives and shares data: classifications and SAINT imports, data feeds and Data Warehouse exports, Customer Journey Analytics and Experience Platform dataset ingestion, and API-based integrations. Understand the tradeoffs: data feeds give raw hit-level export but require downstream processing; classifications enrich dimensions but lag and need governance; Experience Platform ingestion enables cross-channel joins but demands identity and schema discipline.
Also understand single-page application tracking: virtual page views, route-change listeners, and clearing or resetting variables between views to avoid leakage.
Traps: treating the data layer as a dumping ground with undocumented fields; assuming the data layer is populated before the tag fires; forgetting to reset conversion variables on SPA route changes, causing carryover attribution; and designing classifications without a source-of-truth owner. Questions may present an integration that works technically but creates two competing definitions of the same metric.
Rule of thumb: the data layer is an API - version it, document it, and validate it. Any field consumed by analytics must have a defined type, allowed values, and a named owner before tagging begins.
Worked example: an SPA shows inflated campaign attribution because the campaign eVar persists across virtual page views. The fix is a route-change rule that clears campaign fields unless the data layer explicitly repopulates them.