AD0-E213 — Adobe Analytics Developer Professional Exam

Adobe Experience Cloud Services

• Adobe Analytics integrates with ECID (Experience Cloud ID Service) for cross-solution visitor identification
• The Identity Service sets a demdex cookie and an AMCV cookie to persist visitor IDs across domains
• Adobe Audience Manager can receive Analytics segments via server-side forwarding
• Adobe Target and Analytics integration (A4T) uses a supplemental data ID (SDID) to stitch hits
• Experience Cloud Organizations link report suites to an IMS Org for solution integrations

Report Suite Architecture

• Each report suite has a unique Report Suite ID (rsid) that must be referenced in the implementation
• Global report suites collect data from multiple properties; rollup report suites aggregate data but do not deduplicate
• Virtual report suites apply segment filters on top of a parent report suite without separate data collection
• Data collected into the wrong report suite cannot be retroactively moved; correct rsid assignment is critical
• Multi-suite tagging sends a hit to multiple report suites simultaneously by comma-separating rsids in s.account

Solution Design Reference (SDR)

• An SDR (or Business Requirements Document) maps business requirements to specific Analytics variables
• SDR documents which eVars, props, and events are used, their purpose, expiration, and allocation settings
• SDR serves as the source of truth for developers and analysts to ensure consistent data collection
• Variable naming conventions and value formatting should be defined in the SDR before implementation begins
• SDR should be versioned and updated whenever implementation changes are made

Variable Planning

• Distinguish between traffic variables (props) for pathing and conversion variables (eVars) for attribution
• Events (success events) must be planned as counter, numeric, or currency types before enablement
• Determine correct eVar expiration (hit, visit, time period, or event-based) during planning phase
• Plan for data layer availability to ensure variables are populated before the Analytics beacon fires
• Identify which data points require classification and plan SAINT or Classification Set workflows accordingly

AppMeasurement Implementation

• AppMeasurement.js is the core JavaScript library; s_code.js is the legacy equivalent
• The s.t() method sends a page view beacon; s.tl() sends a custom link tracking beacon
• s.tl() accepts three arguments: link object (or true), link type ('o', 'd', or 'e'), and link name
• Setting s.linkTrackVars restricts which variables are sent on link tracking calls
• s.pageName must be set for page view tracking; if empty, the URL is used as the page name
• Character encoding for variable values should use UTF-8; special characters must be handled carefully

Adobe Experience Platform Tags (Launch) Implementation

• Tags replaces the legacy DTM and is the recommended tag management system for Analytics deployments
• The Adobe Analytics extension in Tags handles library loading, report suite configuration, and variable mapping
• Rules in Tags consist of Events, Conditions, and Actions; Analytics variables are typically set via Set Variables action
• Data Elements abstract data layer values and can be referenced with %dataElementName% syntax in rules
• Publishing workflow: Development → Staging → Production libraries must be approved and published
• Custom code boxes in the Analytics extension support direct AppMeasurement API calls using the 's' object

Web SDK (alloy.js) Implementation

• The AEP Web SDK uses the alloy() function with sendEvent command to send data to the Edge Network
• XDM (Experience Data Model) schema must be configured and mapped to Analytics variables via a datastream
• A datastream must have Adobe Analytics enabled with the correct report suite ID(s) mapped
• The data object (non-XDM) in alloy sendEvent can pass Analytics-specific variables directly
• Web SDK replaces both AppMeasurement and the Visitor ID Service; ECID is handled natively by alloy
• Page views are tracked by setting xdm.web.webPageDetails.pageViews.value = 1 or using the Web SDK extension in Tags

Variable Types and Configuration

• eVars have configurable expiration (hit, visit, custom time, event) and allocation (most recent, original value, linear)
• Props are traffic variables limited to 100 characters; eVars are limited to 255 characters
• List vars (s.list1–s.list3) accept delimited lists of values and can attribute to multiple items per hit
• Hierarchy variables (s.hier1–s.hier5) track page hierarchy with a delimiter (default '|')
• s.products syntax: 'Category;Product;Quantity;Price;Events;Merchandising eVars'
• Merchandising eVars use product syntax or conversion variable syntax with specific binding events

Cookies and Visitor Identification

• Analytics sets s_vi cookie (third-party) or s_fid (fallback) for visitor identification without Identity Service
• With ECID/Identity Service, the AMCV cookie stores the Experience Cloud ID (MID)
• Visitor ID can be overridden using s.visitorID for custom ID implementations (e.g., authenticated users)
• Cross-domain tracking uses s.appendVisitorIDsTo() or the appendVisitorIDsTo destination setting
• ITP (Intelligent Tracking Prevention) impacts third-party cookie duration; CNAME implementations mitigate this
• First-party data collection via CNAME requires a custom tracking server configured in the Analytics implementation

Processing Rules and VISTA Rules

• Processing rules run at collection time on the server and can copy, set, or delete variable values
• Processing rules can read context data variables (s.contextData['key']) and map them to Analytics variables
• VISTA (Visitor Identification Segment Technology Architecture) rules run before processing rules
• Processing rules cannot modify eVar, prop, or event data after it has already been processed and stored
• Rules are applied in order; changes made by one rule are visible to subsequent rules
• Bot rules filter known bots; IAB list integration and custom bot rules can be configured in Admin

Debugging Tools

• Adobe Experience Cloud Debugger (browser extension) inspects Analytics, Target, and other solution beacons
• Charles Proxy or Fiddler capture raw HTTP requests to validate beacon parameters at the network level
• The Analytics Debugger (legacy _satellite.setDebug or DigitalPulse Debugger) shows variable values in the console
• Omnibug browser extension decodes and displays beacon parameters in a human-readable format
• Adobe Assurance (formerly Project Griffon) debugs mobile SDK and Web SDK implementations in real time
• Network tab in browser DevTools can inspect /b/ss/ requests (AppMeasurement) or interact.adobedatastream.net requests (Web SDK)

Beacon Validation

• AppMeasurement beacons are sent to /b/ss/{rsid}/1/ endpoint; parameters are URL-encoded query strings
• Key beacon parameters: v1–v250 (eVars), c1–c75 (props), events, pe (page event type), pev2 (link name)
• pe=lnk_o for custom links, pe=lnk_d for download links, pe=lnk_e for exit links
• t= parameter contains timestamp; ts= contains the visitor timestamp offset
• Web SDK sends data as JSON POST to the Edge Network; inspect request payload for xdm and data objects
• Look for duplicate page view beacons caused by misconfigured rules firing multiple times

Common Implementation Issues

• Variables not persisting across pages due to incorrect scope (setting in wrong rule or wrong event timing)
• s.t() firing before DOM is ready or before data layer is populated causing empty variable values
• Incorrect link tracking type causing download or exit links to be miscategorized
• Context data not mapped via processing rules, resulting in data appearing in context data report but not in eVar/prop
• Multiple instances of the Analytics library loaded causing duplicate beacons
• Timestamp mismatch between Analytics report suite settings (timestamp enabled vs. disabled) and implementation

Data Validation in Reports

• Use Real-Time reports in Analytics for near-immediate validation of newly deployed code
• Livestream API provides a real-time feed of server calls for validation before data is processed
• Compare expected variable values in debug tools against what appears in Analytics Workspace after 24–48 hours
• Latency for standard reports is typically 30–90 minutes; Data Warehouse and Data Feed latency may be longer
• Use the 'None' line item in reports to identify hits where a variable was not set, indicating a potential implementation gap

Admin Console and User Management

• Adobe Admin Console manages product profiles, user permissions, and access to Analytics features
• Product profiles control access to report suites, tools (e.g., Data Warehouse, Report Builder), and metrics/dimensions
• Analytics Admin must have access to the Admin Console at the IMS Org level to manage users
• Custom permission groups can restrict or grant access to specific report suites or Admin functions

Data Governance and Privacy

• GDPR and CCPA compliance requires labeling variables in the Data Governance UI with I1, I2, DEL, ACC labels
• Privacy labels determine how data is handled during access and delete requests submitted via Privacy Service API
• s.visitorID and ECID fields must be labeled appropriately for identity resolution during privacy requests
• Data Retention settings define how long raw hit-level data is stored (default 25 months); required for privacy requests
• Opt-out links can be implemented using s.doNotTrack or the Privacy Service opt-out mechanism

Report Suite Configuration

• Conversion variables (eVars) and success events must be enabled in Admin > Report Suite Manager before data appears
• Timestamp configuration (timestamps optional, enabled, or disabled) must match the implementation method
• Channel Manager configures Marketing Channels rules which run on every hit server-side
• Internal URL filters define which referrers are considered internal to prevent incorrect referral attribution
• Paid search detection and unique visitor configuration are set at the report suite level in Admin