Adobe Analytics Architect Master cheat sheet

Discovery outputs: business objectives, KPI definitions, report consumers, data sources, system owners, and success criteria - each mapped to a measurable requirement.

Solution Design Reference (SDR) is the single source of truth: variables, dimensions, events, classifications, segments, and owners documented before build.

Report suite strategy decision rule: split report suites only for divergent data (different traffic, different KPI sets, legal separation); otherwise use virtual report suites.

Variable selection rule: use eVars for persistence and allocation, props for hit-scoped traffic dimensions, events for counters/currency/numeric values.

Conversion variable allocation: most recent (last touch) vs original value (first touch) vs linear - allocation choice must match the business question.

Expiration rule: set eVar expiration to session, visit, or event-based (success event) to control persistence; never leave defaults unexamined.

Multi-suite tagging rule: send data to a global/base suite plus child suites for rollup; keep variable mappings identical to preserve comparability.

Architect sign-off gate: SDR reviewed, tracking spec approved, and QA plan agreed before tag deployment begins.

Naming convention rule: prefix custom variables by type (e.g., eVar, prop, event) and use lowercase, no spaces, documented in the SDR.

Event serialization: use always-record for counting events, first-time-only for unique actions, and disable for numeric/currency events where serialization is irrelevant.

Merchandising eVars require a product syntax binding (eVar set at product level) and correct allocation to avoid attribution errors.

List variable (list1/list2) delimiters must be single characters not appearing in values; list props capture all delimited values per hit.

Context data variables (c.*) are the recommended transport layer; map them to eVars/props/events in processing rules or Analytics settings.

Do not use getQueryParam for values also available in the data layer - it increases fragility and misses non-URL interactions.

Success events drive conversion reporting; tie each to an eVar with event-based expiration when the event defines the conversion moment.

Tag governance: one rule per interaction type, version-controlled container, and a documented data element-to-variable map.

Adobe Experience Platform Tags (Launch): data elements resolve values, rules define event conditions and actions, extensions provide the Analytics beacon and identity.

Rule order matters: Analytics beacon fires as an action; ensure dependent data elements resolve before the Send Beacon action executes.

trackState (s.t / tl) for page views, trackAction (s.tl) for non-page events; s.tl requires linkType (o, d, or e) and does not increment page views.

AppMeasurement sends an image request to the tracking server; parameters include v0 (report suite), g (URL), and c.* context data.

Visitor identification: Experience Cloud ID (ECID) service sets the mid; Analytics visitor ID (s_vi cookie) is derived when ID service is deployed.

First-party cookie rule: set trackingServer to a first-party CNAME to reduce third-party cookie blocking and improve data persistence.

Cross-domain tracking uses the adobe_mc / s_ecid parameter appended to destination links to pass visitor identity across domains.

Beacon size: GET requests are limited (~2KB practical); move oversized payloads to POST or reduce concatenated values.

Data layer contract: a versioned, documented JSON object (e.g., digitalData or custom) populated before the tag manager fires; tags read, never write business data.

Push-then-fire pattern: event-driven pushes (dataLayer.push / digitalData events) trigger rules; page-load pushes cover initial state.

Adobe Client Data Layer extension provides event-driven state and computed state; use it to avoid DOM scraping.

Adobe Analytics / Experience Platform Web SDK maps XDM fields to Analytics variables via the Analytics mapping in the datastream or event schema.

Context data (c.*) is the integration bridge to processing rules, classifications, and Adobe Experience Platform destinations.

Integration rule: server-side sources (CRM, offline) enter Analytics via Data Sources or the bulk/streaming ingestion APIs, keyed to an identifier present in Analytics.

Customer Journey Analytics uses the same XDM data but schemas differ from report suite variables; plan the schema for both consumers.

Identity stitching requires a consistent person identifier across web, app, and offline; document which ID (ECID, CRM ID, hashed email) governs each join.

Processing rules execute in order at collection time and cannot be undone; they do not apply retroactively and are not applied to already-collected data.

Processing rules limits: 150 rules per report suite, 30 conditions per rule, 30 actions per rule; context data conditions match exact strings unless wildcard logic is used.

VISTA rules are server-side, sequential, and apply before data is written; use for complex logic beyond processing-rule capability (requires Adobe provisioning).

Classifications map report values to metadata via SAINT (file upload, rule-based) or the Classification API; classifications are not retroactive to unclassified values.

Rule-based classifications use regular expressions to match keys and assign attributes; test regex against sample keys before publishing.

SAINT file format: key, then attribute columns; the key must match the collected value exactly (case-sensitive).

Marketing Channel processing order: first matching channel rule wins; channel expiration (visit vs. visitor) determines attribution window.

Governance rule: any change to processing rules, VISTA, or classifications requires change control, versioning, and a documented rollback plan.

Segment containers: hit (page view), visit (session), and visitor (person); container choice determines what qualifies and how metrics are attributed.

Sequential segments require defined before/after/within logic and use hit or visit containers with sequence constraints.

Segment stacking (AND) narrows data; OR within a container broadens; each additional container adds processing cost.

Calculated metrics are formulas over existing metrics (sum, divide, subtract, multiply); they cannot reference dimensions directly except via segment-scoped metrics.

Participation vs. instance: a metric's participation counts the hit where a segment qualified; instance counts occurrences - choose per question.

Virtual report suites apply a parent suite plus a segment and optional custom calendar/time zone; they do not duplicate data.

VRS data is not retroactive to segment changes for historical periods in the same way as the parent - verify time-zone and calendar effects on reporting.

Segment and calculated metric governance: name, description, owner, and sharing scope must be documented to prevent duplication and drift.

Adobe Experience Platform Privacy Service handles data subject access/deletion requests; Analytics supports delete via Privacy Service with identity (ECID, CRM ID) mapping.

Data retention: report suite setting controls how long hit-level data is retained; aggregated data persists beyond raw retention.

Consent: collect only after consent where required; Adobe Experience Platform consent and the Analytics opt-in service (s.optIn) gate beacon firing.

Do not place PII (names, emails, SSNs) in props/eVars or URLs; hashed identifiers are preferred and must be documented as such.

IP obfuscation: Analytics can obfuscate last octet or full IP at collection; document the setting per report suite.

Data governance framework: classify variables by sensitivity, define ownership, retention, and access, and audit quarterly.

GDPR/CCPA scope: identify lawful basis, data subject rights, and cross-border transfer; tag manager and Analytics settings must reflect consent state.

Audit trail: maintain a change log for variables, processing rules, and privacy settings to demonstrate compliance.

Use Adobe Experience Platform Debugger to inspect the Analytics beacon, report suite ID, and context data before and after deployment.

Validation sequence: data element resolution → rule firing → beacon payload → processing rules → reported values; fix the first failing step.

Common causes of missing data: report suite mismatch, tracking server misconfiguration, consent blocking, or rule order preventing beacon fire.

Metric discrepancy rule: compare page views (s.t) vs. events (s.tl) and check for duplicate beacons caused by multiple rules firing.

Data quality checks: compare Analytics against source logs, verify unique visitors vs. ECID counts, and reconcile revenue against backend.

Use the Analytics API / Data Warehouse for reconciliation and to confirm processing-rule output on historical and new data.

Regression QA: after any tag change, re-run a smoke test across key templates, devices, and consent states.

Document known issues with reproduction steps, expected vs. actual, and resolution to build an internal knowledge base.

Translate technical constraints into business impact: e.g., 'cookie blocking reduces visitor accuracy' rather than 'third-party cookies are deprecated'.

Define KPI glossary with formula, source, owner, and refresh cadence; share it with every report consumer.

Design review artifacts: SDR, data layer spec, tracking plan, and QA checklist - each versioned and accessible to stakeholders.

Enablement plan: role-based training (marketer, analyst, developer) with hands-on exercises in the actual report suite.

Change communication: announce variable/segment/processing changes with effective date, impact, and rollback plan.

Adoption metric: track report/segment usage and data quality incidents to measure enablement success.

Escalation path: document who approves schema changes, who owns privacy requests, and who triages data incidents.

Feedback loop: quarterly review with stakeholders to retire unused variables and align reporting with business goals.