Adobe Analytics implementation QA checklist

What this is

Adobe Analytics implementation QA is the practice of confirming that every beacon carries the right variables to the right report suite, both before release and after. This reference decodes the /b/ss/ image request and the Web SDK /ee interact call, lists the query parameters, expected response codes, and validation tools, and flags the configuration settings that silently drop hits.

Image request URL anatomy (the /b/ss/ beacon)

Path structure: https://[trackingServer]/b/ss/[reportSuiteID]/[hitSource]/s[randomNumber]?[query]

The tracking-server host varies by implementation: *.data.adobedc.net, the legacy *.sc.omtrdc.net, or a first-party CNAME. Only the adobedc.net example is confirmed on the source page, so QA should verify the configured tracking server per environment rather than assume a fixed host.

Query-string boundary markers

A hit showing AQB but no AQE was truncated and dropped variables.

Core query parameters

ts format: dd/mm/yyyy hh:mm:ss w o — month is zero-based, w is the day of week (0 = Sunday), o is the negative GMT offset in minutes.

Variable ranges

Link-tracking parameters

A page view carries no pe parameter; its presence marks a link-tracking hit.

Page hit vs link hit

s.t() takes all Analytics variables defined on the page, compiles them into an image request, and sends it to Adobe data-collection servers. For s.tl(): the linkObject value this waits up to 500ms for the image request, true navigates with no delay; linkType is a single character o / d / e. When trackDownloadLinks or trackExternalLinks are enabled, AppMeasurement automatically invokes s.tl() for those links.

Expected response codes

Validation tooling

The Auditor overview documents the weighting scheme and general categories only; it does not enumerate which individual tests apply to Adobe Analytics versus Web SDK, so specific per-check pass/fail criteria are unverified.

Assurance processing statuses

The status column reports one of: Queued, Processed, Delayed, Error, Unauthorized, Unavailable, No Debug Flag, Expired. Processed means the hit was accepted downstream; Error, Unauthorized, and No Debug Flag indicate it was not cleanly accepted. The source lists the statuses but does not define each individually.

Web SDK / Edge Network validation

Interact request body: { xdm{…}, data{…} } — xdm carries identityMap, eventType, web details, and timestamp; data carries custom properties. Query: datastreamId required, requestId optional (external tracing ID). Use the collect endpoint to batch multiple events.

Web SDK Analytics is configured to look for any properties in the data.__adobe.analytics object and use them for eVars, props, and events; processing-rule / XDM-schema mapping is no longer recommended (as of May 2024). In the AEP Debugger, view mapped variables by expanding the events row: events → 0 → data → __adobe → analytics.

XDM fields that auto-map to Analytics

Report-suite timestamp configuration

Pre-publish QA flow

Install the Experience Platform (CX Enterprise) Debugger → open the dev site → confirm Adobe Analytics data, Tags information, and Experience Cloud Visitor ID (ECID) all appear → then publish the tag library Dev → Staging → Production. Read the report suite ID from the /b/ss/[rsid]/ path (or the datastream’s Analytics service) to confirm data is going to the correct dev vs prod suite.

Gotchas

1. Beacon fires with ts but never appears in reports → the target suite is Timestamps not allowed (or Timestamps required drops any hit missing ts) → match the suite’s Timestamps setting to the implementation; use Timestamps optional when mixing offline/mobile and standard hits, and verify it in Admin before QA sign-off.
2. Out-of-order data, broken time-on-page / visit counts / pathing after enabling timestamped hits → s.visitorID is set on already-timestamped hits under Timestamps optional → do not set s.visitorID on timestamped data; let ECID and the timestamp handle identity and ordering.
3. Debugger shows the request but reports show no data → ad blockers or privacy extensions block the /b/ss/ request, or JS errors stop the library loading → disable ad blockers during QA, clear console JS errors, confirm the AppMeasurement file contains real code and is referenced in <head>, then re-check the request returns 200.
4. s.tl hits intermittently missing on exit/download links → the browser advanced to the next page before the beacon completed (NS_BINDING_ABORTED); passing true skips the delay → pass this (not true) so AppMeasurement waits up to 500ms, and treat NS_BINDING_ABORTED as expected-but-risky, confirming the hit server-side.
5. First hit of a session returns 302 and QA flags a failure → 302 FOUND is normal for first-time visitors and comScore integrations → only 404 is a true failure; accept 200 and 302 as healthy.
6. After Web SDK migration QA cannot find the s.gif / b/ss request → Web SDK POSTs to the Edge Network interact endpoint, and variables live under data.__adobe.analytics, not query-string params → filter for /ee, inspect the xdm and data.__adobe.analytics payload, and validate in the AEP Debugger (events → 0 → data → __adobe → analytics) or the Assurance Analytics view.
7. ECID appears missing in the Web SDK request payload → the ECID is returned in the response, not carried in the outgoing identityMap → verify the ECID in the response Preview (or the Identity view), not the request identityMap.
8. AEP Debugger shows tags/property data but no solution details, or non-public data is blank → you are not authenticated into Experience Cloud in an active browser tab → sign into Experience Cloud with your Adobe ID in the debugger.
9. Page URL truncated around 255 characters → g caps the page URL at 255 bytes; longer URLs overflow into -g → confirm the beacon carries -g for long URLs and validate the full Page URL dimension, not only the g value.

Quick recipes

Decode a captured beacon URL into labeled parameters and flag truncation:

// Paste an Analytics image-request URL to inspect it
const url = "https://example.data.adobedc.net/b/ss/examplersid/1/s234234238479?AQB=1&pageName=home&g=https%3A%2F%2Fexample.com&c1=nav&v0=email_promo&events=event1&AQE=1";
const u = new URL(url);
const q = u.searchParams;
console.log("report suite:", u.pathname.split("/")[3]); // examplersid
console.log("hit source:", u.pathname.split("/")[4]);   // 1
console.log("truncated?", q.has("AQB") && !q.has("AQE") ? "YES - dropped vars" : "no");
for (const [k, v] of q) console.log(k, "=", decodeURIComponent(v));

List the Analytics beacons already fired on the current page (both stacks):

// Run in the browser console after the page loads
performance.getEntriesByType("resource")
  .filter(e => e.name.includes("/b/ss/") || e.name.includes("/ee/v2/interact"))
  .forEach(e => console.log(e.name.includes("/ee/") ? "WebSDK" : "AppMeasurement", e.name));

Fix the exit/download link race — pass this, not true:

// linkType: "o" other, "d" download, "e" exit
// "this" makes AppMeasurement wait up to 500ms for the beacon
s.tl(this, "e", "Example exit link");

Smoke-test the Edge Network interact endpoint (expect 200 OK with Handle objects):

curl -s "https://edge.adobedc.net/ee/v2/interact?datastreamId=$DATASTREAM_ID" \
  -H "Content-Type: application/json" \
  -d '{
    "xdm": {
      "eventType": "web.webPageDetails.pageView",
      "web": { "webPageDetails": { "name": "home" } }
    },
    "data": {
      "__adobe": { "analytics": { "events": "event1" } }
    }
  }'

Hardcoded page-view image request (no AppMeasurement library):

<img
  src="https://example.data.adobedc.net/b/ss/examplersid/1/s1234567890?AQB=1&pageName=home&g=https%3A%2F%2Fexample.com%2F&c1=nav&events=event1&AQE=1"
  width="1" height="1" alt="" />

Related

• Hub: Adobe guides
• AppMeasurement to AEP Web SDK migration reference
• AEP Web SDK configuration reference

Sources

Adobe Experience League and Adobe Developer pages these values were read from:

• Data collection query parameters (read 2026-07-20)
• Implementing with hardcoded image requests (read 2026-07-20)
• Packet analyzers (read 2026-07-20)
• t (the s.t() method) (read 2026-07-20)
• tl (the s.tl() link tracking method) (read 2026-07-20)
• Legacy debugger (read 2026-07-20)
• Adobe Experience Platform Debugger overview (read 2026-07-20)
• Auditor overview (read 2026-07-20)
• Adobe Analytics view in Assurance (read 2026-07-20)
• Interact endpoint (interactive collection) (read 2026-07-20)
• Set up Adobe Analytics using Experience Platform Web SDK (read 2026-07-20)
• Validate Web SDK implementations with Experience Platform Debugger (read 2026-07-20)
• Debug and validate your Web SDK migration (read 2026-07-20)
• Validate a development implementation and publish to production (read 2026-07-20)
• Timestamp configuration (read 2026-07-20)

Flagged rather than guessed: the tracking-server host varies by implementation (data.adobedc.net, legacy sc.omtrdc.net, or a first-party CNAME) and must be verified per environment; the standalone validate/overview landing page returned HTTP 404 and appears to have been restructured, so individual validate sub-pages were confirmed instead; the Auditor’s per-check test list for Analytics vs Web SDK is not enumerated in the docs; and the exact byte threshold that switches g to -g and the precise 500ms s.tl delay across browsers are documented but version-sensitive.