Debugging tools for Analytics implementations
Debugging tools, sometimes called packet analyzers or packet sniffers, let you inspect the data that your implementation sends to Adobe. They can help you confirm that requests fire successfully, inspect the variables and payloads included in those requests, and troubleshoot unexpected implementation behavior.
Choose a debugging tool
The following categories can help you select a tool based on what you want to inspect.
Analytics and tag debuggers
Analytics and tag debuggers recognize analytics technologies and interpret their requests. These tools can make it easier to identify Adobe Analytics variables, Experience Platform Web SDK payloads, tags, and related implementation information without manually decoding network requests.
Browser developer tools
Every modern browser includes developer tools that can inspect network requests, so you often do not need a separate tool to debug a web implementation. Press F12 or Ctrl+Shift+I (Windows and Linux) or Cmd+Option+I (macOS), then select the Network tab. In Safari, first enable developer features in Safari’s Advanced settings.
HTTP(S) debugging proxies
HTTP debugging proxies intercept HTTP and HTTPS traffic between a client and a server. They are useful when browser developer tools do not provide enough visibility or when the implementation runs outside of a traditional web browser.
HTTPS inspection generally requires configuring the client to trust a certificate supplied by the debugging proxy. Follow your organization’s security policies when installing certificates or intercepting encrypted traffic.
Locate Adobe Analytics requests
For implementations that send data directly to Adobe Analytics, such as AppMeasurement, filter network requests for:
/ss/
Adobe Analytics collection requests contain Analytics variables in the request URL or payload. Raw requests use query parameter names rather than variable names; for example, eVar1 appears as v1 and prop1 appears as c1. Analytics debuggers decode these names for you. To decode them yourself, see the variable reference in the Data Insertion API documentation.
For the HTTP status codes that Analytics data collection servers return, see HTTP response codes in the Data Insertion API documentation.
For implementations that use Adobe Experience Platform Web SDK, filter network requests for:
/ee/
Select the request and inspect its payload to view the data sent to Adobe Experience Platform Edge Network. The Web SDK sends data to the Edge Network, which can then forward data to Adobe Analytics and other configured services. Inspecting the client request verifies what the browser sent to the Edge Network; it does not by itself confirm that the data was successfully processed by every downstream service. To see how Edge Network processed an event, use Adobe Experience Platform Assurance.
Aborted requests
When a page navigates away, the browser can cancel requests that are still in progress. Firefox labels these requests NS_BINDING_ABORTED; Chrome and Edge label them (canceled). To keep requests visible after navigation, enable Preserve log (Chrome and Edge) or Persist Logs (Firefox).
A canceled request does not necessarily mean that data was lost. The browser might have sent the full request and stopped waiting only for the response. Browser developer tools usually cannot show the difference, but an HTTP debugging proxy can.
Requests sent with navigator.sendBeacon() are not canceled on navigation. AppMeasurement uses sendBeacon for exit links and whenever useBeacon is enabled. The Web SDK uses it for events sent with documentUnloading. If link tracking requests are frequently canceled, use these options.