GA4 ecommerce tracking: the purchase event checklist

GA4 ecommerce tracking means reporting the moment of sale as a single purchase event, with four required parameters (value, currency, transaction_id, items) and a trigger that cannot count the same order twice. The job is not done when the event fires. It is done when DebugView shows exactly one event, when revenue in the reports lines up with back-office orders 24-48 hours later, and when the channel breakdown tells the same story as your ad platforms. This checklist tests all three.

What is GA4 ecommerce tracking, exactly?

GA4 ecommerce tracking is the practice of reporting each shopping step to GA4 using standard event names and standard parameters. Treat it as a contract rather than a tag: GA4 reports expect those exact names. If your naming deviates, the event still arrives, but revenue, product and conversion reports stay empty.

• view_item: a product detail page was viewed. This measures product interest.
• add_to_cart: an item was added to the cart. It forms the denominator of cart abandonment.
• begin_checkout: the shopper entered checkout. Drop-off inside the payment flow becomes visible here.
• purchase: a completed order. This is the single source of revenue, ROAS and channel breakdown.

All four matter, but only the last one drives ad decisions. If time is short, make purchase flawless first and fill in the rest later.

Which parameters are required on the purchase event?

Four parameters carry the whole event: value (order total), currency (ISO code), transaction_id (unique order identifier) and items (the product array). Miss one and GA4 still records the event while the matching report stays blank: no currency means no revenue calculation, no transaction_id means no deduplication, no items means no product performance at all.

• value: the order total. Decide whether tax and shipping are included, then keep that decision identical to your back office, otherwise every comparison turns into an argument.
• currency: an ISO 4217 code (USD, EUR, GBP). It belongs at event level. In multi-currency stores, every event must carry its own code.
• transaction_id: unique per order. Never randomise it. Derive it from the order number in your back office so reconciliation is possible.
• items: at minimum item_id and item_name per product. price, quantity, category and variant are recommended and give product reports their depth.

Why does the same order get counted twice?

Duplicates come from tying the purchase event to the thank-you page. A refresh, a back-button return or a shared confirmation link fires the event again. GA4 discards a second event carrying the same transaction_id inside a 24-hour window, but that protection collapses if the ID is generated randomly each time, and revenue inflates.

1. Derive transaction_id from the back-office order number. Do not use random numbers, timestamps or session IDs.
2. Fire the event only on a confirmed payment, from one place. Bind it to the order state, not to a page load.
3. Store the sent ID in browser session storage and block the second send. It is the cheapest insurance against refreshes.
4. If both browser and server send the event, switch one off or make sure both use the identical transaction_id. Otherwise two records look like two orders.

How do refunds and cancellations affect revenue?

GA4 does not net revenue for refunds on its own. When an order is refunded or cancelled you must send a separate refund event. Skip it and GA4 revenue drifts above your net back-office revenue, so every ROAS calculation built on top reads optimistic. In high-return categories such as apparel and footwear, that drift changes decisions directly.

• Full refund: same transaction_id as the original order, the refunded amount as a positive value, plus currency. Do not send negative numbers.
• Partial refund: the same transaction_id with an items array containing only the returned products and quantities. GA4 subtracts just those lines.
• Cancellation: a pre-shipment cancellation that reverses revenue should be treated like a refund. Accounting may separate them; measurement should not.
• Timing: refunds land days after the sale. Yesterday's ROAS and last month's ROAS are therefore not equally mature, so compare periods with the same lag.

How do you align the channel breakdown with ad decisions?

Counting the right number of purchases at the right value is not enough. Each purchase also has to be attributed to the right channel. When the breakdown breaks, total revenue still looks correct while the distribution is wrong, which means budget moves to the wrong channel. The most frequent cause is a payment provider splitting the session and claiming the conversion.

• Referral exclusions: add payment providers and 3-D Secure domains to the unwanted referrals list. You can define up to 50 domains per data stream.
• Cross-domain measurement: if cart, checkout and confirmation live on different domains, declare them as one journey. Otherwise every hop creates a new session and a new source.
• UTM discipline: enable auto-tagging on paid channels and, where you tag manually, pick utm_source and utm_medium from a fixed vocabulary. Improvised spelling shatters the breakdown.
• What direct really means: direct is rarely a user typing your address. It is usually missing information. An unusually large direct share is the first sign of a setup problem.

Even after the breakdown is fixed, GA4 and your ad platform will not match one to one: attribution models, conversion windows and click definitions differ. We unpack that gap in detail in GA4 vs Google Ads conversion discrepancy. For the technical side of signal loss, see server-side tracking.

What exactly do you validate once setup is done?

Validate in three layers: at event time in DebugView, after processing at 24-48 hours, and at channel level. Do not skip the order, because a setup that looks perfect in DebugView can still be wrong in the report layer through missing refunds or a broken source. Work through these six steps in sequence.

1. DebugView: place a real test order and confirm you see exactly one purchase event. Open it and check that value, currency, transaction_id and items are populated.
2. Identifier match: is the transaction_id in the event byte-for-byte the order number in your back office? Fix prefixes or formatting differences now.
3. Refresh test: reload the confirmation page and navigate back to it. No second purchase event should be sent.
4. Refund test: partially refund the test order and confirm the refund event carries the correct products.
5. Report reconciliation: wait 24-48 hours, then compare transaction count and revenue against back-office orders for the same date range. In practice a few points of difference are normal; a persistent, widening gap is an implementation problem.
6. Channel check: inspect the source and medium of purchasing sessions. If a payment provider appears as a source, your referral exclusions are incomplete.

How does clean GA4 data turn into ad decisions?

At this point you own a trustworthy revenue and channel table, yet decisions are still manual. That is where Ads Sensor comes in: it unifies GA4 traffic, conversion and channel breakdown data with Meta Ads, Google Ads, TikTok Ads and Criteo spend in one panel, reads campaigns with AI and produces prioritised actions with stated reasoning. To be straight with you: Ads Sensor does not build your GA4 setup, it reads the GA4 you already have. The checklist above is yours to finish.

• Unified table: platform spend next to GA4 revenue and channel breakdown on one screen.
• AI analysis: campaign-level risks and opportunities, each recommendation with its reasoning.
• Approve and apply: accepted recommendations are applied through platform APIs, and before/after results are tracked automatically.
• Anomaly monitoring: spend, conversion and revenue deviations watched around the clock, with adjustable thresholds.
• Report mode: a client-ready monthly report for agencies.

Once the checklist is complete, the next step is making the data produce decisions. You can join the beta, connect your accounts and see the first analysis.