Debug Adobe Target in Chrome DevTools

What Adobe Target traffic looks like

Adobe Target's modern wire format is the Delivery API: one request that is both content-fetch and data-collection.

Endpoint pattern

<clientcode>.tt.omtrdc.net/rest/v1/delivery; edge clusters show as mboxedge-prefixed hosts; legacy mbox implementations use /mbox/json or /rest/v2/batchmbox

Transport

POST with client, sessionId, and version as query parameters and a JSON body; at.js typically loads with a pre-hiding snippet that hides the body until the response arrives, so a slow or blocked delivery call means a flash of default content or a page held blank until timeout

Payload

execute.pageLoad global mbox, resolved immediately for page-load experiences · execute.mboxes[] named regional mboxes with name and index · prefetch content fetched ahead (common in SPAs: nothing counts as visited until a notification fires)

Notifications

notifications[] display and click reports. Missing notifications are the classic "Target reports no traffic"

Identity

context, experienceCloud (A4T logging setup + supplemental data ID), and id: tntId, marketingCloudVisitorId, any thirdPartyId

Cookies

mbox, visible per request in the cookies section

A typical delivery call body, as Event Watcher captures it:

{
  "context": { "channel": "web", "address": { "url": "https://example.dk/" } },
  "execute": { "pageLoad": {}, "mboxes": [{ "name": "hero-banner", "index": 0 }] },
  "id": { "tntId": "8b3c21…", "marketingCloudVisitorId": "61254…" },
  "experienceCloud": { "analytics": { "supplementalDataId": "7f2d…", "logging": "server_side" } }
}

Debugging Adobe Target with Event Watcher

• The dedicated Adobe Target parser breaks each delivery request into readable sections (Execute, Prefetch, and Notifications), plus grouped parameters for Context, Experience Cloud (A4T), Identifiers, and the request itself.
• Whether a call is a page-load request, a regional mbox, or a notification is readable at a glance, without unpacking the JSON.
• The cookies section shows the mbox cookie traffic per request.
• Every call gets the consent verdict.

Adobe Target and consent

The extension checks Target against functional consent. The nuance: the delivery call is content-fetch and data-collection in one request, sending the visitor's tntId/ECID and context before any experience renders.

A full delivery request, identifiers included, while the CMP is still undecided is flagged as a pre-consent violation.

Setups that gate at.js behind the CMP instead show no Target traffic at all until the grant, which is easy to confirm in the stream.

Common debugging scenarios

• Activity not qualifying. Inspect the Execute section: is the expected mbox name present in the request, and does the response context match your audience conditions?
• Prefetch traffic without visits. SPA views prefetched but no notifications sent afterwards. Filter Target requests and check the Notifications section for the missing display events.
• Flicker hunting. The Script Tree view shows whether at.js was loaded by the page or a tag manager; tag-manager-injected Target is a common flicker cause because the pre-hiding snippet fires too late.
• A4T rows empty in Analytics. Verify the Experience Cloud group in the parsed request actually carries the Analytics logging payload and supplemental data ID.
• Comparing arms across tools. Pivot the Grouped view by Tool to line Target up against Optimizely or VWO on a site running multiple testing stacks.