Debug Adobe Analytics Tracking Issues | OpsBlu Docs

Debug Adobe Analytics Tracking Issues

Troubleshoot Adobe Analytics with Experience Platform Debugger, Charles Proxy, and server call inspection. Fix eVar, prop, and processing rule problems.

Adobe Analytics debugging requires different tools and techniques than Google Analytics. The data collection mechanism (image requests to /b/ss/), the variable system (eVars, props, events), and the tag management layer (Adobe Experience Platform Launch) all have their own failure modes. This guide covers systematic approaches to diagnose and fix each one.

Essential Debugging Tools

Adobe Experience Platform Debugger

The AEP Debugger browser extension (Chrome and Firefox) is the primary tool for inspecting Adobe Analytics calls in real time.

  1. Install the Adobe Experience Platform Debugger extension
  2. Navigate to your site and open the extension
  3. Go to the Analytics tab to see every server call
  4. Each call shows the full list of variables sent: pageName, events, eVars, props, and products

The debugger decodes the raw /b/ss/ image request into a readable table. This is far easier than reading the raw query string.

Charles Proxy for Deep Inspection

For mobile apps or environments where browser extensions are unavailable, Charles Proxy intercepts all HTTP traffic and lets you inspect Adobe Analytics image requests.

  1. Install Charles Proxy and configure SSL proxying for *.omtrdc.net and *.2o7.net
  2. Filter requests by host to isolate Adobe Analytics calls
  3. Inspect the query string parameters on each /b/ss/ request
  4. Compare the values against your solution design reference (SDR)

Charles is especially useful for debugging mobile SDK implementations where the AEP Debugger is not available.

The s.debugTracking Flag

Adobe's AppMeasurement library has a built-in debug mode that logs every server call to the browser console:

// Enable debug logging (add before s.t() call or in Launch rule)
s.debugTracking = true;

// This outputs the full image request URL to the console
// along with all variable values at the time of the call

When debugTracking is enabled, every s.t() (page view) and s.tl() (link tracking) call is logged with the complete variable payload. Look for the line starting with Image request: in the console output.

ObservePoint and Tag Inspector

For automated validation across hundreds of pages, ObservePoint and Tag Inspector crawl your site and validate that Adobe Analytics tags fire correctly on each page. These tools are valuable for:

  • Verifying that pageName values follow your naming convention across all templates
  • Catching pages where the tag fails to load entirely
  • Detecting variable values that deviate from your SDR

Reading the /b/ss/ Image Request

Every Adobe Analytics server call is an image request to a URL like:

https://metrics.example.com/b/ss/rsid/1/JS-2.22.0/s12345678?...

The path contains: /b/ss/{report-suite-id}/{version}/{library-version}/{visitor-id}.

Key Query Parameters

Parameter Description Example
pageName Page name variable Home Page
g Current page URL https://example.com/
r Referrer URL https://google.com/
c1-c75 Props (traffic variables) c1=navigation:header
v1-v250 eVars (conversion variables) v1=logged-in
events Events list event1,event5,purchase
products Products string ;SKU123;1;49.99;event5=2
pe Link type (lnk_o, lnk_d, lnk_e) lnk_o (custom link)
pev2 Link name (for s.tl calls) Header:Login Button

Common Issues and Fixes

s.t() vs s.tl() Confusion

s.t() sends a page view server call. s.tl() sends a link tracking call. Using the wrong one causes data to land in the wrong places:

  • s.t() increments the Page Views metric and populates the Pages report
  • s.tl() increments Custom Links, Download Links, or Exit Links depending on the link type argument
  • Calling s.t() on a button click inflates your page view count
  • Calling s.tl() for a virtual page view means the page will not appear in the Pages report
// Page view call (use for actual page loads or virtual page views)
s.pageName = "Product Detail: Widget";
s.t();

// Link tracking call (use for interactions that are NOT page loads)
// Arguments: linkObject, linkType, linkName
s.tl(this, 'o', 'Add to Cart Button');
// 'o' = custom link, 'd' = download, 'e' = exit link

Processing Rules Not Applying

Processing rules run server-side after data collection. If you set up a rule to copy a context data variable into an eVar and it is not working:

  1. Verify the context data variable is actually being sent. In the AEP Debugger, look for c. prefixed parameters (e.g., c.loginStatus)
  2. Check that the processing rule targets the correct report suite (rules are suite-specific)
  3. Processing rules are order-dependent. A rule that depends on a value set by a previous rule may fail if the order changes
  4. Rules only apply to new data. They do not retroactively modify historical hits
// Setting context data variables in AppMeasurement
s.contextData['loginStatus'] = 'authenticated';
s.contextData['pageCategory'] = 'product';

// These appear in the image request as:
// c.loginStatus=authenticated&c.pageCategory=product

eVar Expiration Settings

eVars persist across hits based on their expiration setting (visit, day, week, custom, purchase, etc.). A common mistake is setting an eVar on every page view when it should only be set once per visit, or using "visit" expiration for a value that needs to persist across visits.

Check your eVar expiration in: Admin > Report Suite > Conversion Variables. If an eVar keeps its value longer than expected, the expiration is too long. If it resets too soon, the expiration is too short.

Classification Import Failures

Classification (SAINT) imports fail silently in many cases. Common causes:

  • Encoding issues: Files must be UTF-8. Excel exports often use Windows-1252
  • Key column mismatch: The classification key must exactly match the values collected in the variable
  • Tab-delimited format: Despite accepting CSV, tab-delimited files are more reliable
  • Processing delay: Classifications can take 24-72 hours to apply to new data

Debugging in Adobe Experience Platform Launch

Launch (the replacement for DTM) manages your Adobe Analytics deployment. Debug Launch-specific issues with these techniques:

Enable Launch Logging

// In the browser console, enable verbose Launch logging
_satellite.setDebug(true);

// This logs every rule evaluation, condition check, and action execution
// Look for "Rule fired" and "Rule condition not met" messages

Common Launch Problems

Rule order conflicts: If two rules target the same event and modify the same variables, the execution order matters. Set explicit rule ordering in Launch if you have dependencies.

Extension version mismatch: The Adobe Analytics extension in Launch must match your AppMeasurement library version. After updating the extension, republish the library.

Data element timing: If a data element reads from the DOM before the page is fully rendered, it returns undefined. Use the "DOM Ready" or "Window Loaded" event type instead of "Library Loaded" for DOM-dependent values.

Validating with the Data Debugger

In Launch, the Adobe Analytics extension includes a "Data Debugger" panel accessible through the AEP Debugger. This panel shows:

  • Every variable set at the time of the s.t() or s.tl() call
  • Which Launch rules contributed each variable value
  • The final merged state of the s object before the server call fires

This is invaluable for tracing which rule set a particular eVar when multiple rules run on the same page.

Products String Debugging

The products string is notoriously difficult to format correctly. The structure is:

category;product;quantity;price;incrementor;merchandising

Fields are separated by semicolons and multiple products are separated by commas:

// Single product
s.products = ";SKU123;1;49.99";

// Multiple products
s.products = ";SKU123;1;49.99,;SKU456;2;29.99";

// With events
s.products = ";SKU123;1;49.99;event5=1";

// With merchandising eVars
s.products = ";SKU123;1;49.99;event5=1;eVar10=blue";

If your products string is malformed, the entire hit may be discarded or product data will not populate correctly in reports. Always validate the string format in the AEP Debugger before moving to production.

Debugging Checklist

  • AEP Debugger shows server calls firing on each page
  • Report suite ID in the /b/ss/ URL matches your target suite
  • pageName is populated and follows your naming convention
  • s.t() fires for page views, s.tl() fires for interactions
  • Context data variables appear with the c. prefix
  • Processing rules are active and in the correct order
  • eVar expiration settings match your analysis requirements
  • Products string format is valid (semicolon-delimited fields)
  • No JavaScript errors before AppMeasurement loads
  • Launch library is published to the correct environment
Back to top