Debugging and troubleshooting data collection
Debugging data collection involves checking both how your implementation behaves and what happens to the data it sends. Start with the symptom, then follow the event through each stage of collection until you find where it stops behaving as expected.
Debug logging exposes SDK commands, tag execution, warnings, and errors in the browser or application runtime. Request inspection exposes payloads, responses, and, for supported workflows, server-side processing. These approaches often complement each other: a log can explain why an event was delayed, while a network capture can show whether a request was sent.
Follow the event through collection diagnostic-workflow
Investigate the following stages in order. Evidence that one stage succeeded does not establish that later stages also succeeded.
- Implementation execution: Did the SDK command or tag rule run? Check diagnostic messages and errors. If consent or identity handling delays an event, investigate that state before looking for a network request. See Enable debug logging.
- Outgoing request: Was the request sent, and did it contain the expected data? Inspect the payload and compare it with your command inputs or data elements. See Inspect web requests or Inspect mobile and server requests.
- Server receipt: Did the collection endpoint receive the request? Inspect the response where available or use a supported server-side trace. A client log that says a request was sent is not confirmation of receipt.
- Edge processing and routing: Did the event use the intended datastream and configured services? For Web SDK, the request’s
configIdparameter shows which datastream it used, and Edge Trace shows how the Edge Network processed the event. - Downstream processing: Did the destination accept and process the event as expected? Use the destination’s product-specific debugging guidance. A successful response from the Edge Network is not proof that data is available in every downstream report or store.
Choose a starting point choose-a-starting-point
The following table identifies useful evidence for common tasks. When both approaches apply, they answer different parts of the investigation. Available messages and tools depend on your SDK, runtime, and configured services.
documentUnloading.Product-specific debugging product-specific
The articles in this section apply to all Experience Platform data collection. Adobe applications that receive your data can use their own endpoints, request formats, validation views, and processing. After you confirm that the Edge Network received and routed an event, or when your implementation sends data directly to an application, continue with that application’s debugging guidance:
- Adobe Analytics: Debug Analytics data collection
- Adobe Analytics for Streaming Media: Adobe Analytics for Streaming Media view in Assurance
- Adobe Audience Manager: DCS error codes, messages, and examples
- Adobe Experience Platform datasets and Real-Time Customer Profile: Streaming ingestion troubleshooting guide
- Adobe Journey Optimizer: Test code-based experiences, Validate in-app messages using Assurance, and Decisioning validation view
- Adobe Target: Debug Target with Web SDK and Test an at.js implementation with Debugger
- Customer Journey Analytics: View, troubleshoot, and modify connection settings
Continue your investigation next-steps
- Enable debug logging: Enable, inspect, and disable diagnostic output for Web SDK, tags, Server SDK, and Mobile SDK.
- Inspect data collection requests: Capture requests, interpret Edge Network request evidence, trace Edge processing, and investigate canceled requests.
- Debugging tools: Compare Adobe tools, tag debuggers, browser developer tools, and HTTP proxies.
- Subject-specific guidance: Keep detailed investigations close to their configuration or API reference, such as consent and identity, document unloading, and event duplication.
Before sharing logs, traces, or network captures, remove credentials, visitor identifiers, and other sensitive information according to your organization’s policies.