Debug Adobe Experience Platform in Chrome DevTools

What Adobe Experience Platform traffic looks like

The Web SDK, still widely called Alloy, replaces the older per-product Adobe libraries with a single call to an edge network. One request carries what used to be separate Analytics, Target, and Audience Manager traffic, which is why reading its payload is the whole job.

Endpoint pattern

The library loads as alloy.js; requests go to edge.adobedc.net or server.adobedc.net, or to a first-party CNAME pointing at them. Paths are /ee/v2/interact and /ee/v2/collect (with v1 equivalents still in use)

Transport

JSON POST carrying an XDM object. interact expects a response and is how personalization propositions come back; collect is fire-and-forget

Key parameters

The datastream id in the query determines which Platform services the event fans out to · xdm.eventType names the event · data.* carries free-form custom fields · data.__adobe.analytics and data.__adobe.target carry per-product overrides · the ECID is the visitor identity

Notes

The datastream is the routing table. Two sites sending identical XDM to different datastream ids end up in entirely different destinations, and nothing in the payload itself reveals that

Debugging Adobe Experience Platform with Event Watcher

• One of the platforms with a dedicated parser, so the XDM payload is decoded rather than shown as raw JSON.
• The Overview card surfaces the datastream id, the event type, the page name, and the ECID without opening the payload.
• A Custom Data section separates the three things that get confused in XDM review: free-form event data under data.*, Analytics overrides under data.__adobe.analytics, and Target data under data.__adobe.target.
• Commerce payloads are parsed into an E-Commerce Items section with the item count in the heading.
• Parsed Data groups the rest into Page Context, Commerce, Identity, Personalization, Configuration, and Timing, so a review can go straight to the group in question rather than scrolling one large object.
• The interact and collect split is visible per request, which is how you confirm whether a page is asking for personalization or only reporting.

Adobe Experience Platform and consent

Event Watcher checks Adobe Experience Platform against the marketing consent category.

The Web SDK's consent handling is genuinely built in, through setConsent and the datastream's configured default, so this is a case where the platform can be right and the implementation still wrong. The failure that matters is an event reaching the edge before consent resolves: the fan-out to downstream Platform services has already happened and cannot be recalled from the browser. Check the timing of the first /ee/ request against the CMP decision, not the library load.

Common debugging scenarios

• Data is not arriving in the expected sandbox. Read the datastream id from the request. This is the most common cause and the least visible one.
• A field is missing downstream. Check whether it is under data.* or inside an __adobe override. The two route differently.
• Personalization does not render. Confirm the request is interact rather than collect. A collect call never returns propositions.
• Duplicate events. Compare event types and timing. A migration that leaves both the Web SDK and a legacy AppMeasurement library running produces two sets of traffic, and the legacy one appears separately.
• Events fire before consent. Filter to the platform and read the consent verdict on the first /ee/ request.