Adobe Analytics Developer Expert cheat sheet

A KPI must map to a measurable variable or event; any KPI without a defined metric source is a requirements gap, not an implementation task.

Business requirements convert to solution design via a traceability matrix: requirement ID, KPI, variable/event, report, owner, acceptance test.

Report suite strategy decision rule: split suites when data retention, currency, traffic volume, or legal jurisdiction differ; otherwise use one global suite plus virtual report suites.

Success metrics are classified as count (event), value (currency event), ratio (calculated metric), or dimension breakdown; each class imposes different variable needs.

Naming conventions for variables, events, and props/eVars are fixed in the design document before implementation so that downstream segments and classifications remain stable.

S.M.A.R.T. acceptance criteria per requirement enable QA sign-off; a requirement without a testable acceptance criterion cannot be validated in UAT.

Stakeholder sign-off gates: requirements freeze, solution design approval, pre-production QA, and post-launch validation; each gate has a named approver.

Data layer and tag requirements (page type, user state, content metadata) are derived from reporting needs, not from what is technically available on the page.

Adobe Experience Platform Tags execution order: library loads, then rules fire by event type; Data Layer (or custom code) actions typically precede Analytics beacon actions within a rule.

Rule ordering is not guaranteed across rules; use sequencing (rule chaining via custom events) when one rule must complete before another.

Data layer contract: use a versioned, documented object (e.g., digitalData or a custom object) with stable keys; page views clear page-scoped keys and merge persistent keys.

Event-driven data layer (push-based) fires a custom event after each state change; tag rules listen to that event and read the current data layer snapshot.

Environments (Development, Staging, Production) map to separate embed codes; library publishing promotes a build between environments, not individual rules.

Data elements support types: JavaScript variable, CSS selector, cookie, query string, and custom code; a data element with no default value returns undefined and can break beacon construction.

Extensions are versioned; upgrading an extension can change action behavior, so pin the extension version in the design record before production publish.

Consent and opt-in gating is enforced at the rule/action level (condition or custom code) so that no beacon fires before consent state resolves.

Web SDK sends data to the Adobe Experience Edge Network; the datastream maps to a report suite (or multiple) and to Adobe solutions such as Analytics.

Web SDK command surface: configure (datastream ID, org ID), sendEvent (with xdm and data), and optional commands for identity and consent; the legacy AppMeasurement library is replaced by alloy.js.

XDM schema fields (web.webPageDetails.pageViews.value, eventType, identityMap) are required for page views; context data is passed in the data object and mapped via processing rules or context data mappings.

The identityMap replaces legacy visitor ID settings; ECID is generated by the SDK and stored in the kndctr cookies (or local storage) under the org-specific key.

Mobile SDK (Edge) uses Mobile Core plus the Edge/Analytics extensions; lifecycle events (launch, upgrade, crash) are tracked automatically when lifecycle extension is registered.

Track action vs track state: track state implies a page/screen view (page view event), track action is a non-page interaction; mapping to Analytics eVars/props is done via the Analytics extension or Edge mapping.

Consent in Web SDK is set via the setConsent command with categories (collect, marketing, personalize); beacons are held or dropped depending on the configured consent policy.

Debugging: Adobe Experience Platform Debugger and the Edge Network debugger (assurance / edge trace) show the raw XDM payload and the mapped Analytics hit.

Variable allocation rule: eVars are conversion (persist beyond the hit), props are traffic (hit-scoped); s.events are counters or currency values.

Allocation on an eVar decides which value receives credit: most recent (last), original value (first), linear, or participation; allocation is set per eVar and cannot be changed retroactively without data loss.

Expiration on an eVar sets persistence: visit, page view, event, or a fixed period (day, week, month, quarter, year); expiration interacts with allocation to determine attribution.

Merchandising eVars bind a value to a product within the same hit; syntax is eVarX = product syntax (eVarX = 'value') and requires product syntax enabled.

Processing rules run in order at data collection time; they can set, copy, or delete values but cannot create new variables or change variable type.

Marketing Channel rules are evaluated in order; the first matching rule wins, and the last-touch channel is stored in the tracking code unless overridden.

Classification rules map a key (eVar/prop value) to a hierarchy of attributes; classifications are applied to the raw value and can be uploaded or rule-based.

Virtual report suites inherit data from a parent suite with a segment applied; they cannot add variables or change processing rules.

s.events syntax: event1 is a counter, event2 is numeric/currency (value set with s.events = 'event2=10.00'); serialized events (event ID) prevent duplicate counting.

Products syntax: s.products = 'Category;Product;Quantity;Price;Merchandising eVars;Currency'; the semicolon delimiter is positional and must be preserved.

s.t() fires a page view (increments page views); s.tl() fires a link/action hit and requires a link type (o, d, or e) as the third argument.

Context data variables (c.) are prefixed with c. and mapped to props/eVars via processing rules; unmapped context data is not reportable.

Processing rule conditions support string, numeric, and date comparisons; rule actions include set value, copy value, and delete value, evaluated top-down with the first matching rule applying.

List vars (list1, list2, list3) hold delimited values (default comma) and support up to 250 characters; they are hit-scoped and useful for multi-value dimensions.

Events can be counted as instances, and a numeric event can also drive a calculated metric (e.g., revenue / orders) without additional variables.

Hit-level deduplication: setting a purchase ID (s.purchaseID) or event ID prevents duplicate orders from being counted more than once.

Data Sources (legacy) upload types: generic (full or incremental), standard, and full; incremental uploads append, full uploads replace the date range.

Data Sources require a transaction ID for deduplication; without a unique key, re-uploads double-count metrics.

Classification imports use a key column (the variable value) plus attribute columns; the file must match the classification schema or the import fails validation.

Bulk data insertion (BDI) via the Data Insertion API ingests hits server-side; it uses the same hit schema as AppMeasurement and respects processing rules.

Data Warehouse exports and feeds (daily/hourly) deliver raw hit data; feed files are gzipped and contain a header row describing each column.

Adobe Analytics integrations: Audience Manager/Experience Platform share segments and audiences; the Analytics source connector in AEP mirrors report data into a dataset.

Customer Journey Analytics uses the Experience Platform dataset, not the report suite; data passes through the Edge Network and the Analytics source connector.

Data Sources and imports do not trigger processing rules on imported rows; only real-time hit collection applies processing rules.

Adobe Experience Platform Debugger shows the Analytics beacon (s.t/s.tl) and the decoded variables; the Edge trace shows the XDM payload and the mapped hit.

Beacon validation checklist: pageName set, eVar/prop values populated, events counted once, products syntax valid, no undefined or 'null' strings.

Real-time report and the Analytics debugger (Experience Cloud debugger) confirm a hit within seconds; data warehouse/feeds lag behind real-time.

Regression QA: compare pre- and post-release hit payloads for a fixed set of pages; a diff in variable values signals a broken data layer or rule.

Automated QA uses a tag rule in the staging environment that logs the payload to the console; assert on the expected variable map before publish.

Common failure: data element resolves before the data layer is populated; fix by firing the rule on a custom event pushed after the data layer update.

Duplicate hits are diagnosed by counting beacons per page load and comparing to the expected s.t() calls; extra hits often come from double-firing rules.

Server-side validation uses the Analytics API (reports) or the Data Insertion API response to confirm the hit was accepted rather than rejected.

PII rule: never send email, name, phone, or free-text fields into props/eVars; hashing does not make a direct identifier safe to collect.

Consent enforcement: the SDK holds or drops beacons based on consent categories; the data layer must expose consent state before any tag rule fires.

Data retention is configured per report suite (or per component); retention changes affect future data and may not retroactively delete historical data.

IP obfuscation and geolocation settings are report-suite level; enabling obfuscation removes the last octet of the IP before storage.

Governance reviews gate new variables: each new eVar/prop requires a documented owner, purpose, retention, and classification before it is enabled.

Data quality monitoring compares expected vs. actual hit volume per day; a drop in volume usually indicates a broken tag rule or consent gate.

Access control: product profiles and permission groups restrict who can edit processing rules, classifications, and data sources.

Audit trail: tag library publishes and report suite admin changes are logged; retain the log for the period required by the organization's data policy.