Trace one test from the browser to the report
Follow one synthetic purchase or demo identifier from browser action to receiver and report. Compare expected event count, identity, value and final state, then include invalid submissions and refresh behavior. A visible confirmation is only one part of the evidence needed to accept the measurement change.
Worked example — illustrative data.
| Synthetic action | Expected record | Failure to look for |
|---|---|---|
| Complete test purchase T501 | One purchase with intended ID/value/currency | Duplicate event after refresh |
| Send valid demo D501 | One request and CRM routing record | Missing or duplicated receiver record |
| Submit invalid form | Visible recovery; no valid-request conversion | Error counted as successful request |
| Repeat internal QA | Clearly identified test data | Tests mixed into buyer totals |
Use a staging or otherwise approved test path and record the timestamp and time zone. Follow one synthetic identifier through browser diagnostics, collection and destination records. Check the selected variant and amount for purchase events. For demo forms, keep personal data out of analytics and use an approved join method for the CRM. Inspect consent states and the documented collection behavior without bypassing the user’s choice. Record waiting periods before calling a report event missing.
Distinguish a valid request from the visible success state
For test order T501, compare the browser action with the stored order, the emitted purchase event and the report record using the same non-sensitive test identifier. Repeat the confirmation reload as a separate case. For demo D501, require a receiver record before counting success; an error message or timed-out response cannot settle whether the request was stored.
Refreshing confirmation can send a duplicate purchase event
Refreshing a success page can send another purchase event even when only one order exists. Compare transaction IDs and receiver behavior instead of accepting matching aggregate totals by coincidence.
Accept the change when the intended action produces the intended records once, invalid actions do not count as success and test traffic can be distinguished in reporting.
Can I use real customer details for this test?
Use clearly marked synthetic details in an approved test environment. Keep payment secrets and personal customer data out of screenshots and event logs. A local success state does not verify actual delivery to the intended receiver.
Continue with Guides for stores, software teams and local businesses, Conversion tracking for orders and qualified leads and Measure revenue from organic store landing pages.
For purchase and refund event fields, see Google Analytics ecommerce event documentation (checked November 2026).