Adobe — Certification Cheat Sheet

AD0-E209 — Adobe Analytics Developer Expert

The AD0-E209 Adobe Analytics Developer Expert exam validates advanced technical skills in implementing and configuring Adobe Analytics using AppMeasurement, the Adobe Experience Platform Web SDK, and related tools. Candidates are tested on their ability to design, deploy, troubleshoot, and optimize data collection solutions across web and mobile environments. The exam targets developers with at least 2 years of hands-on Adobe Analytics implementation experience.

▶ Take Practice Exam 📖 Study Guide Updated:

⚡ Key Facts to Know

  • eVars: up to eVar250 available; Props: up to prop75; Custom Events: event1–event1000 (1000 total)
  • Processing Rules limit is 150 rules per report suite; rules execute in listed order top-to-bottom
  • s.tl() link tracking calls do NOT increment page view count; s.t() page view calls DO increment page views
  • Visitor ID resolution order: custom s.visitorID > ECID (AMCV cookie) > s_vi cookie > s_fid fallback cookie
  • Analytics standard latency is 30–90 minutes for most reports; Data Warehouse and Data Feeds may take hours
  • Transaction ID data (s.transactionID) expires after 90 days by default if not matched with offline Data Sources upload
  • Multi-suite tagging via comma-separated RSIDs (s.account='rs1,rs2') sends identical hits to all listed report suites
  • The Data Repair API permanently and irreversibly deletes or modifies collected Analytics data at the hit level

🎯 Exam Tips

  • Memorize the image request query string parameter mappings: v0=pageName, v1-v75=props (c1-c75 for eVars), pe=link type, pev2=link URL — these appear in troubleshooting scenario questions
  • Know the complete Visitor ID hierarchy cold — questions on cross-device, authenticated users, and migration scenarios test this heavily
  • For Web SDK questions, understand that XDM schema is required and that alloy('sendEvent') with eventType 'web.webpagedetails.pageViews' replaces s.t() — focus on how datastreams bridge Web SDK to Analytics
  • Scenario-based questions dominate: practice reading implementation code snippets and identifying bugs related to variable scope, SPA tracking, and link tracking syntax
  • Study Processing Rules logic thoroughly including condition operators and variable copy/overwrite/delete actions — know what happens when rules conflict and the order of operations
  • Review the Analytics 2.0 API JSON request body structure for /reports endpoint — understand globalFilters, metricContainer with metricFilters, and how breakdowns are chained with parent itemIds

⚠ Common Mistakes

  • Confusing s.t() and s.tl(): candidates forget that s.tl() does not increment page view count and requires linkType ('o','d','e') and linkName parameters
  • Misunderstanding eVar allocation vs. expiration: allocation (Most Recent vs. Original) determines credit when values change within the expiration window, not how long the value persists
  • Forgetting that Processing Rules operate on context data AFTER VISTA rules and before final storage — VISTA rules actually run AFTER processing rules, not before
  • Incorrectly applying props vs. eVars: props are for pathing and real-time reports (no persistence), eVars persist and are used for conversion attribution
  • Overlooking the linkTrackVars and linkTrackEvents restrictions on s.tl() calls — variables not listed in linkTrackVars are NOT sent with link tracking hits
  • Assuming Web SDK XDM data maps automatically to Analytics variables — datastream and field mappings must be explicitly configured, or __adobe.analytics context data must be used

AD0-E209 Exam Domains & Study Topics

1

Analytics Configuration in Adobe Experience Platform Tags (Launch)

18% of exam

Tag Property Setup and Configuration

  • Create and configure a tag property with correct settings for web or mobile
  • Configure environments (Development, Staging, Production) and generate embed codes
  • Manage extensions — Adobe Analytics extension requires Report Suite ID, tracking server, and cookie settings
  • Use the Adobe Analytics extension vs. AppMeasurement library directly — extension wraps AppMeasurement
  • Set up character set (UTF-8 default) and currency code at the extension level

Rules, Data Elements, and Extensions

  • Rules consist of Events, Conditions, and Actions — control when code fires
  • Data Elements map to JavaScript variables, CSS selectors, cookies, local storage, or custom code
  • Data Element types: JavaScript Variable, DOM Attribute, Cookie, Local Storage, Custom Code
  • Core extension provides generic event listeners; Adobe Analytics extension provides Set Variables and Send Beacon actions
  • Rule order/sequencing matters when multiple rules fire on the same event — use rule ordering (0-100+)

Publishing Workflow and Governance

  • Libraries must be built and published through Dev → Staging → Production workflow
  • Use Satellite object (window._satellite) for debugging and calling direct call rules
  • Approval workflows and user roles (Admin, Approver, Publisher, Developer, Extension Developer) control publishing rights
  • Embed code must be placed in <head> as high as possible before other scripts
  • Asynchronous vs. synchronous loading: async loading recommended but requires pre-hiding snippet to avoid content flash
2

Analytics Implementation Strategy

10% of exam

Solution Design Reference (SDR)

  • SDR (Solution Design Document) maps business requirements to Analytics variables (props, eVars, events)
  • Document variable purpose, syntax, expiration, allocation, and owner for each variable
  • Align SDR with stakeholders before implementation to prevent data quality issues
  • Distinguish between traffic variables (props) and conversion variables (eVars) based on reporting needs
  • Review and version-control SDR as implementation evolves

Implementation Methods Comparison

  • AppMeasurement.js: traditional JavaScript library, direct variable assignment (s.pageName, s.eVar1)
  • Adobe Experience Platform Web SDK (alloy.js): uses XDM schema, sends data to AEP Edge Network
  • Web SDK advantage: single tag for multiple Adobe solutions, future-proof architecture
  • Mobile SDKs: AEP Mobile SDK replaces legacy Mobile Services SDK — use MobileCore + Analytics extension
  • Server-side (Data Insertion API / Bulk Data Insertion API): for environments where JavaScript cannot run

Variable Planning and Governance

  • Props (Traffic Variables): s.prop1–s.prop75, used for pathing and real-time reporting, not persistent
  • eVars (Conversion Variables): s.eVar1–s.eVar250, persist across hits based on expiration setting
  • Events: s.events, up to 1000 custom events (event1–event1000) plus standard events
  • List props (s.prop with list enabled) and list eVars support multi-value capture
  • Context Data variables (s.contextData['key']) used with processing rules to populate props/eVars
3

Analytics Implementation

36% of exam

Core AppMeasurement Variables and Methods

  • s.pageName: identifies page; if empty, URL is used as page name
  • s.t() sends a page view hit; s.tl(linkObj, linkType, linkName) sends a link tracking hit (no page view increment)
  • linkType values: 'o' (custom/other), 'd' (download), 'e' (exit link
  • s.clearVars() clears all variables set on the s object — use between hits to prevent variable bleed
  • s.linkTrackVars and s.linkTrackEvents control which variables are sent on link tracking calls
  • usePlugins function and doPlugins (s.doPlugins) runs before every image request

Visitor Identification and Cross-Device

  • Visitor ID hierarchy: custom visitorID (s.visitorID) > ECID (Experience Cloud ID) > Analytics cookie (s_vi) > s_fid fallback cookie
  • ECID (Experience Cloud Identity Service / AMCV cookie) enables cross-solution visitor stitching
  • s.visitorID overrides all other IDs — use for authenticated visitor tracking
  • grace period: when migrating from legacy cookies to ECID, enable grace period to avoid visitor inflation
  • Cross-Device Analytics (CDA) uses Device Graph or field-based stitching to stitch anonymous and authenticated data

Tracking Servers and Data Collection

  • Tracking server format: [namespace].sc.omtrdc.net (third-party) or [customdomain].sc.omtrdc.net
  • First-party data collection uses CNAME record pointing to Adobe collection servers — reduces ITP impact
  • trackingServerSecure must be set for HTTPS pages; mismatch causes data loss
  • Report Suite IDs: production vs. development suites — use s.sa() to dynamically switch report suites
  • Multi-suite tagging: send to multiple report suites by comma-separating RSIDs in s.account

Processing Rules and Context Data

  • Processing Rules run in order on the collection server — sequence matters, changes are immediate
  • Use s.contextData to pass flexible key-value pairs; map to Analytics variables via Processing Rules UI
  • Processing Rules can copy, set, delete variables, and run conditionally based on variable values
  • Processing Rules have a limit of 150 rules per report suite
  • VISTA rules run after Processing Rules and before data is stored — require Adobe Engineering involvement
  • Marketing Channel Processing Rules determine first and last touch channel attribution

Plugins and Utility Functions

  • Common plugins: getQueryParam, getPreviousValue, getPageName, getValOnce, getTimeParting, manageVars
  • Plugins are loaded in doPlugins function or via AppMeasurement Plugin Manager in Launch extension
  • getQueryParam(param, fallback, url): extracts query string parameter value from URL
  • getValOnce(val, cookieName, daysValid): prevents duplicate event firing within specified period
  • apl() (AppendToList) appends values to delimited lists for props/events without overwriting

AEP Web SDK Implementation

  • Web SDK uses XDM (Experience Data Model) schema for data standardization
  • sendEvent command replaces s.t() and s.tl() — use eventType 'web.webpagedetails.pageViews' for page views
  • Datastream configuration in AEP maps Web SDK data to Analytics report suites
  • XDM field group '_experience.analytics' contains props, eVars, events in Web SDK context
  • alloy('configure', {...}) must be called once; subsequent calls use alloy('sendEvent', {...})
  • Context data passed via xdm or data.__adobe.analytics objects in Web SDK calls
4

Analytics Reporting API

10% of exam

Adobe Analytics APIs Overview

  • Analytics 2.0 API (api.analyticsreporter.com) is the current REST API — OAuth 2.0 and JWT authentication
  • Analytics 1.4 API is legacy but still used for Data Sources, SAINT classifications, and Data Feeds APIs
  • API endpoints: /reports for reporting, /segments, /calculatedmetrics, /dimensions, /metrics
  • Adobe I/O (developer.adobe.com) is the gateway for creating API integrations and managing credentials
  • Service Account (JWT) authentication: generate JWT with private key, exchange for access token

Reporting API Requests

  • POST /reports: body contains rsid, globalFilters, metricContainer, dimension, and settings
  • Breakdown reports require parent dimension itemId in subsequent API calls
  • Anomaly Detection available via API using algorithmicModel parameter in metric definition
  • Pagination controlled by limit and page parameters — default limit is 50, max is 50000
  • Date ranges use ISO 8601 format; dateRanges can reference saved date range IDs

Data Feeds and Bulk Data APIs

  • Data Feeds deliver raw hit-level data as TSV files to FTP, SFTP, or S3
  • Bulk Data Insertion API (BDIA): server-side data collection via CSV file uploads — batch processing
  • Data Sources API (1.4): import offline/historical data; types include Generic, Transaction ID, Web log
  • Transaction ID (s.transactionID): links online behavior with offline conversion data via Data Sources
  • Data Repair API: delete or edit previously collected data at hit level — irreversible, requires approval
5

Defining Variables

10% of exam

eVar Configuration and Allocation

  • eVar expiration options: Hit, Visit, Time Period (days/weeks/months), Custom Event, Never
  • Allocation settings: Most Recent (Last Touch) or Original Value (First Touch) — applies when multiple values set in same expiration window
  • eVar syntax binding with merchandising eVars: Product Syntax vs. Conversion Variable Syntax
  • Merchandising eVars (Product Syntax): set in s.products string using ';eVar1=value'
  • List eVars (listN setting): accept multiple delimited values in a single variable, each value gets credit

Events Configuration

  • Event types: Counter (default, increments by 1), Numeric (custom amount), Currency (monetary values)
  • Serialization: add event ID to prevent duplicate counting — s.events='purchase:orderID123'
  • Participation metric setting on events: gives credit to all touchpoints in visit, not just last
  • Standard events: prodView, scAdd, scRemove, scOpen, scCheckout, purchase — reserved names
  • s.purchaseID: prevents duplicate purchase counting across visits (persists 1 year)

Products Variable

  • Syntax: s.products='category;product;quantity;price;events;merchandisingVars'
  • Multiple products separated by comma: s.products='cat;prod1;1;9.99,cat;prod2;2;19.99'
  • Quantity and price fields required for revenue and unit calculations on purchase event
  • Product-level events set in the products string override page-level event values for that product
  • s.products must be set on the same hit as the purchase event for revenue attribution
6

Testing, Validation, and Troubleshooting

16% of exam

Debugging Tools

  • Adobe Experience Platform Debugger (Chrome extension): inspects Analytics, Target, ECID, Web SDK hits in real time
  • Charles Proxy / Fiddler: intercept network traffic to inspect raw image request parameters
  • Browser Network tab: filter for '/b/ss/' to find Analytics collection hits; query string contains all variables
  • ObservePoint: automated tag auditing at scale across large site inventories
  • Adobe Analytics Debugger (legacy browser extension) shows formatted variable list from image requests

Validation Techniques

  • Validate image request URL format: [trackingServer]/b/ss/[rsid]/[type]/[version]/?[variables]
  • pe parameter in image request indicates link tracking type: lnk_o, lnk_d, lnk_e
  • v1–v75 = props, v0 is pageName (pev1 for link name, pev2 for link URL in link hits)
  • c1–c75 = eVar values in image request query string; events= contains custom and standard events
  • Use real-time reports in Analytics to verify hits within seconds of implementation

Common Implementation Issues

  • Variable persistence bleed: not clearing eVars between SPA page views — use s.clearVars() or reset variable to empty string
  • Duplicate page view counts in SPAs: s.t() firing on virtual page views without proper URL/pageName update
  • Bot filtering: enable bot filtering in Report Suite settings to exclude known bots via IAB list
  • Latency: standard Analytics processing is 30–90 minutes; real-time and livestream are near-instant
  • Unspecified values in reports indicate hits received where the variable was not set or expired

Single Page Application (SPA) Tracking

  • SPAs require manual triggering of s.t() on route changes since no full page reload occurs
  • Update s.pageName and relevant variables before calling s.t() on each virtual page view
  • Reset eVars and events between virtual page views to prevent data from previous view contaminating new view
  • In AEP Tags, use History Change event type in Core extension to detect SPA route changes
  • Web SDK sendEvent should be called with updated XDM payload on each SPA route transition

Ready to pass the AD0-E209 exam?

Test your knowledge with our free AD0-E209 practice exam — Adobe Analytics Developer Expert questions and answers with detailed explanations.

▶ Start Free Practice Exam 📖 Browse Study Guide