Testing, Validation, and Troubleshooting
Read the beacon, not the report
Troubleshooting is mostly about confirming what actually left the browser. Use the Adobe Experience Platform Debugger for AppMeasurement and Assurance for Web SDK and Edge traffic, and read the beacon parameters: rsid, tracking server, pageName, channel, the page event parameter (empty for s.t(), a link value for s.tl), the link URL and link name parameters, the mid for Experience Cloud ID, and the numbered parameters where props appear as c1 through c75 and eVars as v1 through v250. Events arrive in the events parameter as a comma-separated list.
Confirm the response too: a successful hit returns a small image with HTTP 200 and no visible content. A blank response, a redirect, or a different report suite in the payload explains most missing-data tickets. Remember data latency: traffic variables often appear quickly while conversion data and some dimensions take hours to fully process, and real-time reports will never match a processed report exactly.
Traps: assuming a hit did not fire when it fired to the wrong rsid; forgetting linkTrackVars on custom links so variables vanish; testing with an ad blocker or privacy extension enabled; blaming the tag manager for an AppMeasurement load-order error; and comparing a filtered debug session against unfiltered production numbers.
Rule of thumb: work one change at a time through a fixed checklist - report suite, hit type, page name, variables, events, then latency.
Worked example: a download report is empty. The debugger shows the link event fired and the link type was correct, but the link name parameter is blank and prop12 is missing from the payload. Two fixes: pass a real link name in the s.tl call so the download dimension populates, and add prop12 to linkTrackVars so the variable is transmitted.