Inspect data collection requests
Inspecting requests shows what your implementation sent, whether a server responded, and, for Web SDK, how the Edge Network processed the event. This article covers the outgoing request, server receipt, and Edge processing stages of the diagnostic workflow.
To choose an inspection tool, see Debugging tools. To see what your implementation did before it sent a request, see Enable debug logging. For endpoints, request formats, and validation steps that belong to a specific Adobe application, see Product-specific debugging.
Inspect web requests web
Use browser developer tools or a tag debugger to capture requests from a web page:
- Open developer tools: press F12 or Ctrl+Shift+I (Windows and Linux) or Cmd+Option+I (macOS). In Safari, first enable developer features in Safari’s Advanced settings.
- Select the Network tab.
- Enable Preserve log (Chrome and Edge) or Persist Logs (Firefox) so that navigation does not clear the request list.
- Filter the request list for
/ee/(Web SDK). If your implementation sends data directly to an Adobe application, filter for that application’s endpoint as described in its debugging guidance. - Reproduce the action. Requests sent before you opened the tools are not captured.
- Select a collection request and inspect its URL, payload, response, and timing.
Browser tools show traffic originating in the browser. They do not expose outgoing calls from your application server or from event-forwarding rules.
Read Edge Network requests edge-network-requests
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 the Edge Network. This filter matches the default Web SDK base path; if your implementation changes edgeBasePath, filter for the configured path or collection host instead.
Web SDK request URLs use the format https://{edgeDomain}/ee/[{locationHint}/]v1/{action}?configId={datastreamId}&requestId={requestId}. The default edgeDomain is edge.adobedc.net; first-party implementations use their own CNAME. The following parts of the URL are useful evidence:
interactaction: The default. The Edge Network returns response content, such as identity, personalization, warnings, and errors, that you can inspect in the request’s response.collectaction: Used when Web SDK sends an event withsendBeacon, whichdocumentUnloadingselects after identity is established. These requests do not return response content to the page.configIdparameter: The datastream ID that the request used. If the event uses a datastream ID override, this parameter contains the override. Compare it with the datastream that you expect.
The Edge Network can forward data to the services configured in your datastream. Inspecting the client request shows what the client attempted to send; it does not by itself confirm server receipt or downstream processing.
Inspect mobile and server requests mobile-server
For Mobile SDK implementations, add the Assurance extension to your app and connect it to an Assurance session to inspect SDK events and supported validation views. Use an HTTP debugging proxy when you need HTTP-level evidence, subject to your app’s certificate and network configuration. To inspect messages in native development tools, see Mobile SDK logging.
For Server SDK, direct Edge Network API, or other server-side implementations, inspect the server’s outgoing request, HTTP status, response body, and errors. Use your runtime’s HTTP instrumentation or a proxy configured for that server. A browser request to your application does not show the separate request from your server to Adobe. See Server SDK logging for SDK diagnostic output.
An SDK log or a successful HTTP response is evidence about a particular stage of collection, not proof that all configured destinations processed the event.
Trace Edge Network processing edge-processing
For Web SDK implementations, use Edge Trace in Adobe Experience Platform Debugger to see the request that the Edge Network received, the datastream configuration that it applied, and the requests that it sent to the services in your datastream. Edge Trace also opens the same data in an Assurance session. For Mobile SDK implementations, connect the app to Assurance directly; see Inspect mobile and server requests.
Do not treat an incoming event or response handle as confirmation that every downstream service processed it. Continue with the relevant application’s debugging guidance.
For event forwarding, Monitor activities provides usage, outgoing error, and compute-time reports. Its aggregate reports can help identify failing destinations, but are not a per-event delivery trace.
Aborted requests 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. Requests using navigator.sendBeacon() or fetch with keepalive can continue sending after navigation even when developer tools display a canceled status. Preserving the log keeps the entry visible; it does not confirm delivery.
To investigate, open Debugger or a proxy before reproducing navigation and inspect the captured request and any server response. A captured server response provides evidence that the endpoint handled the request; an outgoing request alone does not. For Web SDK, an incoming request in Edge Trace provides server-side evidence. None of these observations alone establishes availability in downstream reports.
Browsers do not expose the HTTP response from sendBeacon to the calling JavaScript. A debug message reporting that the SDK used sendBeacon therefore cannot confirm receipt.
Web SDK’s documentUnloading selects an unload-capable transport subject to identity and payload constraints. This option cannot send events that are still queued when the page unloads; see When events can be lost. Libraries that send data directly to an Adobe application can provide similar options; see that application’s debugging guidance.