Synthetic test-event matrix: eleven named actions and what GA4 DebugView should show

This is an invented shop

Everything here is synthetic: the shop, the products SKU-A and SKU-B, the prices and the order numbers TEST-1001 and TEST-1002 are made up to show the shape of an acceptance test. It is not a record of any client work or any real property. The point is the method: each row is an action you can perform, an event you can see, and a condition that is either met or not.

The prices are chosen so the arithmetic can be checked by hand. One SKU-A at 20.00 plus two SKU-B at 15.00 each gives 50.00, which is the sum of price times quantity that Google's purchase sample describes for the value field.

• Use obviously fake order numbers so test orders can be recognised later.
• Write the expected value before you run the test.

The matrix

Run the rows in order on the live site or a staging copy, with DebugView open on your debug device. Rows 4 and 6 check that nothing from an earlier step is carried forward. Rows 7 to 9 check that each order produces one purchase with its own ID and that a reload adds nothing. Rows 10 and 11 apply the same discipline to a form.

If the matrix is wider than the box, scroll horizontally to read every column. Keyboard: focus the matrix and use Left/Right.

step | test action (synthetic shop)         | expected event  | what to see in DebugView                              | pass condition
 1  | open the home page                    | page_view       | page_location is the home page                       | one event
 2  | view product SKU-A (price 20.00 GBP)  | view_item       | items: SKU-A only; currency GBP; value 20.00         | one event
 3  | add 1 of SKU-A to the cart            | add_to_cart     | items: SKU-A, quantity 1                             | one event
 4  | view product SKU-B (price 15.00 GBP)  | view_item       | items: SKU-B only (no SKU-A left over)               | one event
 5  | add 2 of SKU-B to the cart            | add_to_cart     | items: SKU-B, quantity 2; value 30.00                | one event
 6  | begin checkout                        | begin_checkout  | items: SKU-A x1 and SKU-B x2; value 50.00            | one event
 7  | place test order TEST-1001            | purchase        | transaction_id TEST-1001; value 50.00; currency GBP  | exactly one event
 8  | reload the confirmation page          | (none)          | no second purchase for TEST-1001                     | zero new events
 9  | place test order TEST-1002            | purchase        | transaction_id TEST-1002 (a different ID)           | one new event
10  | send the contact form with a bad email| (none)          | no form event                                        | zero events
11  | send the contact form correctly       | enquiry_sent    | form_name only; no field values                      | one event

How to read a failure

No event on a row points to a trigger or data layer fault. Two events on a row point to two senders or a trigger that fires twice. The right event with the wrong items points to a stale ecommerce object. A purchase with an empty or repeated transaction ID points to the ID generation. A form event with field values in its parameters is a privacy fault whatever the count shows.

Each failure type has its own guide and, where it is a bounded job, its own priced outcome with this kind of table as its acceptance test.

• Keep a screenshot of DebugView for every row.
• Mark which rows were run on the accept path if consent mode is active.

What this does not prove, and where it leads

Passing every row proves that these actions produced these events once, at the time of the test. It does not prove every visitor, browser or consent state is measured, that GA4 revenue equals your accounts, or that any report will rise. The next-day report check confirms processing; it does not extend the claim.

To have a table like this written and run for your own shop, see the duplicate-purchase repair at £295, the shop funnel events from £795 and the form tracking at £245, all untested proposals with payment only after sign-off. Send invented or de-identified details, not logins or order data.