Debug Analytics data collection
This article explains what to check when you debug data sent to Adobe Analytics. Find your implementation method in the following table and follow its section. If you are investigating unexpected report data, start with Compare requests with reports.
For steps and tools that apply to all Adobe data collection, such as capturing network requests, enabling debug logging, and investigating canceled requests, see Debugging and troubleshooting data collection.
AppMeasurement and the Analytics extension appmeasurement
Find the request appmeasurement-find
Capture network requests and filter for /b/ss/. Tag debuggers such as Adobe Experience Platform Debugger identify and decode these requests for you.
If no /b/ss/ request appears:
- Check the browser console for JavaScript errors.
- If you use the Analytics tag extension, confirm that the tag embed code is inside the page’s
<head>element and that your library is published to the environment that you are testing. Tag debug mode shows whether the rule that sends the hit fired. - If you host AppMeasurement yourself, open the library’s URL directly to confirm that the file loads and contains code.
- Disable browser extensions, such as ad blockers, that can prevent requests from being sent.
- Debugger does not recognize requests sent from within an iframe. Use browser developer tools instead. See Use AppMeasurement with iFrames.
Check what Analytics received appmeasurement-contents
- Report suites: The path segment after
/b/ss/lists the report suite IDs that receive the hit. Confirm that they are the report suites that you expect, such as a development report suite on development pages. - Variables: Raw requests use query parameter names rather than variable names; for example, eVar1 appears as
v1and prop1 appears asc1. See the variable reference. When a request is too long, AppMeasurement sends it with HTTPPOST, so variables appear in the request body instead of the URL. - Hit type: Requests sent by
tl()include thepeparameter and do not increment page views. Requests sent byt()do not includepe.
If values are present but wrong, see Troubleshoot JavaScript implementation for common causes, such as quoting, capitalization, and whitespace.
Check the response appmeasurement-response
A 2xx response confirms only that the data collection server received the request, not that the hit was recorded. With the default response type, a request can return success even when the hit is dropped. A 302 response on a new visitor’s first request is expected. See HTTP response codes.
AppMeasurement sends exit link requests, and all requests when useBeacon is enabled, with navigator.sendBeacon(). Developer tools can label these requests as canceled even when the browser sent them. See Aborted requests.
Web SDK web-sdk
Find the request web-sdk-find
With Web SDK, the browser sends events to the Edge Network instead of directly to Analytics, so you do not see a /b/ss/ request. Inspect the Edge Network request and confirm the following:
- The
configIdparameter matches a datastream that has the Adobe Analytics service enabled with the report suites that you expect. - The payload qualifies as a page view or a link event. Analytics ignores payloads that contain neither page details nor a web interaction type. See Edge Network event types in Adobe Analytics.
Check what Analytics received web-sdk-contents
Start an Edge Trace and reproduce the action. Locate the row that starts with Analytics Automatic Mapping, then expand mappedQueryParams and the report suite ID beneath it.
- Variables: Mapped values use the same query parameter names as AppMeasurement requests, sometimes in shorthand form, such as
gnfor page name andplfor products. See XDM object field mapping and Data object field mapping. - Context data: XDM fields that do not map to an Analytics variable appear as context data with the
c.a.x.prefix. Use processing rules to assign them to variables. - Report suites: If you use report suite overrides, the datastream configuration row in Edge Trace shows the report suites that the Edge Network used.
Check processing web-sdk-processing
In the Assurance session that Edge Trace opens, search events for hitdebugger. These events use the vendor com.adobe.analytics.hitdebugger, and their payloads show values after Analytics processing, such as the Experience Cloud ID (mcvisId) and pageName.
For a guided walkthrough, see Set up Adobe Analytics with Adobe Experience Platform Web SDK.
Compare requests with reports reports
A hit that reaches Analytics does not appear in reports immediately, and reported values can differ from the values in the request:
- Latency: Complete data typically appears in reports about two hours after collection. Some data, such as timestamped hits, can take longer. See Data availability and latency.
- Processing: Processing rules, VISTA rules, bot rules, and other processing steps can change or exclude values after collection. See Processing order for data in Adobe Analytics. Assurance post-processed data shows the result of processing for an individual hit.
- Report suite: Confirm that you are viewing the same report suite that the request or datastream targeted.
- Unexpected values: If a dimension shows unexpected spikes or values, see Hash collisions.
For broader traffic changes, see Troubleshoot spikes and drops in data.