GA4 E-commerce Events: Setup and How to Check Them
GA4 is installed, a purchase count appears in the reports, and you are not sure you can trust it. The reports look plausible, which is the dangerous part: a wrong number that looks reasonable is rarely questioned.
This article gives you the events to set up, what the purchase event must contain, and a test routine that ends with a comparison to your real orders.
Why "it shows data" is not a check
GA4 will happily record a purchase with no order ID, a revenue of zero, or the same order three times. Nothing turns red. The common approach is to install the tag, see events arrive, and move on.
What goes wrong afterwards is quiet. Revenue differs from the store, the same order inflates a day's totals, and product reports are empty because the items were never sent. You discover it when someone compares GA4 with the order list, usually after budget decisions were made on it.
The model: events, parameters, proof
Think in three layers.
Events
The actions you measure, named as GA4 expects
Layer 1Parameters
The data each event carries: currency, value, items
Layer 2Proof
A test order checked against the store
Layer 3
Events. GA4 documents a set of recommended e-commerce events. A store usually needs the ones that follow the shopper's path:
view_item
A product page was viewed.
add_to_cart
An item was added to the cart.
begin_checkout
The shopper started checkout.
purchase
The order was completed.
- view_item
- add_to_cart
- begin_checkout
- purchase
Add others, such as refund or view_item_list, only when you will use them in a report.
Parameters. An event name alone says little. Google's purchase-event guide describes what the purchase should carry: a transaction ID, a value, a currency and an items list, with tax, shipping and coupon as further optional details. Treat that page as the reference, since field requirements can change.
The `transaction_id` deserves special attention. It is the order's identity. Google's guide notes that a repeated purchase needs a different ID, otherwise Analytics will deduplicate it. Use your real order number, never a random value that changes on each page load.
Proof. Every event needs a test order, not an assumption.
Setup in practice
How the events reach GA4 depends on your stack. A store platform may provide a native integration. Otherwise the events are pushed to a data layer and sent by a GA4 tag in Google Tag Manager, as described in Google Tag Manager for E-commerce: Data Layer Basics. Whichever you use, keep one method. Running a native integration and a GTM tag for the same purchase is a classic cause of doubled revenue.
Also decide what the purchase means for your business. For a store with cash on delivery, an order placed is not an order delivered; the purchase event then measures intent, not revenue. Say so in your reports.
How to check, step by step
- Turn on debugging. DebugView in GA4 shows events from a debug-enabled device within seconds. Google's documentation says it will not show events if debug mode is off, and that privacy controls or an un-granted consent state can stop events from appearing.
- Walk the path. On a test device, view a product, add it to the cart, start checkout and place a test order. Watch each event arrive once.
- Open the purchase event. Confirm `transaction_id`, `value`, `currency` and the `items` are present. Check that the currency is a proper code, the value is a number and the items are not empty.
- Count once. Refresh the thank-you page. If a second purchase appears, the push fires on reload and needs a guard.
- Check the reports later. Standard reports can lag behind DebugView, so confirm again after the data has processed rather than the same minute.
188 of 200 orders is 94%. 27,900 of 30,000 SAR is 93%.
A worked example
Suppose that in a week your store shows 200 orders worth 30,000 SAR, an average order of 150 SAR. GA4 shows 188 purchases and 27,900 SAR. That is 94% of orders and 93% of revenue.
A gap of this size is not automatically an error. Consent choices, blockers and ad-hoc orders entered by hand can all explain missing events. The useful questions are about the pattern. Is the gap stable week to week? Does GA4 ever show more orders than the store? The second is the red flag, because browsers cannot invent orders, only duplicate them. Average revenue per GA4 purchase here is 27,900 / 188, about 148.4 SAR, close to the store's 150, which suggests values are being sent correctly even though some orders are missing.
Trade-offs and when the advice changes
- Low volume. With very few orders a week, percentages swing widely. Compare totals over a longer window.
- Several payment methods. If prepaid and cash-on-delivery orders reach the thank-you page differently, check each path separately.
- Server-side or app data. If you also send events from your server, you need an agreed ID so the same order is not counted twice.
- Consent. What you may collect depends on your audience and rules. Confirm with the relevant authority or adviser instead of assuming.
What GA4 cannot tell you
Even a perfect setup measures what browsers and consent allow. It will not match your store exactly, and it will not tell you which ad caused the order. Channel attribution depends on consistent campaign tags; see UTM Parameters: A Naming System That Keeps Attribution Clean. For why platform numbers rarely agree with the store, read Why Your Store Sales Don't Match Meta and Google Ads.
Next step
Place one test order today and open the purchase event in DebugView. If any of the four fields is missing, or the order appears twice, fix that before the next budget decision. If you would rather have the full event set built and tested against your real orders, the tracking setup service covers it.