Start with the documented event model
Google’s ecommerce implementation guide describes events for shopping actions, an items array and event-level currency when value is sent. It recommends debug mode for troubleshooting. This guide uses that documentation as a reference and proposes an independent acceptance process; AMZ12 has not tested your implementation or certified a particular plugin.
Begin with a written map from customer action to expected event. Include the page or application state, required item information and the person responsible for the implementation. A tag being present on a page does not establish that a business action is recorded correctly.
Choose a revealing product sample
Create a small test set with a simple item, a variant, a discounted item and a basket containing more than one product. Include the store’s actual currency and a shipping destination suitable for its test environment. Keep personal data out of event labels and test notes.
Write the expected identifiers before running the flow. The analytics item reference should be understandable alongside the catalog reference used by the reporting team. If the mapping changes between a product view and purchase, document the reason or correct the inconsistency before judging funnel performance.
Check actions at their boundaries
Perform each intended action once and record the time, expected event and observed payload. Inspect adding an item, changing quantity, removing an item and entering checkout separately. A basket update and a new addition are different user actions; the implementation should follow its agreed measurement design.
Repeat the journey with a page refresh and browser back navigation. Look for events emitted merely because a component rendered again. Record evidence of the action and its resulting payload together, rather than reporting that an event name appeared somewhere during the session.
Reconcile values with the order
For a permitted test order, compare quantity, item amounts, discounts and the event total against the store’s order record using your documented calculation. Write down how shipping and tax are treated. A difference should lead to an explanation grounded in the design, not an assumption that one dashboard must be correct.
Keep the order reference in the private test record and use a non-sensitive reference in shared engineering notes. Check rounding with a basket that makes it visible. Review currency separately from numeric value; a plausible amount paired with the wrong currency can survive a casual visual check.
Test repeated completion and failure
Check what happens when the confirmation page is refreshed or revisited. Then inspect an abandoned attempt and an unsuccessful payment path in the available test environment. The purpose is to establish which business state triggers the purchase record and whether repeated navigation can distort it.
Agree on handling for delayed or retried order updates with the developer. Do not patch a symptom by hiding a visible event before understanding its source. Keep server-side and browser-side responsibilities in the implementation notes if both participate in measurement.
Make acceptance a release habit
Save a short evidence sheet with expected actions, observed results, unresolved issues and the implementation version. Ask the business owner to confirm that the numbers answer the intended questions. A technically valid payload can still represent the wrong operational concept.
Rerun the relevant checks after checkout, theme or tracking changes. Use the same sample where practical so differences are easier to explain. Treat analytics as maintained instrumentation: it needs a defined owner and a reviewable history, especially when teams use its output to prioritize expensive work.
Official reference: Google Analytics: measure ecommerce. Source checked on 29 October 2026. AMZ12 analysis and suggested checks are independent editorial guidance.