How to Set Up GA4 for E-commerce (Step-by-Step)

To set up GA4 for ecommerce properly, you need more than the basic page-view tag — you need GA4 to understand products, prices, and purchases as structured data, not just clicks. This guide walks through it step by step: the prerequisites, the e-commerce events that actually matter, how to fire the purchase event correctly, how item-scoped parameters work, and how to confirm the whole thing is reporting real revenue before you trust a single chart.

The reason this matters is simple. A store with default GA4 tracking can tell you how many people visited. A store with proper GA4 ecommerce tracking can tell you which products people viewed, where they abandoned the cart, what they actually bought, and how much it was worth. The second store can make decisions. The first is guessing.

Before you start: prerequisites

Three things need to be in place before any of the e-commerce setup is worth doing. Skip them and you will spend an afternoon wondering why your data looks broken.

A working GA4 property. You need a GA4 property created and its Measurement ID (the G- string) installed on every page of your store. If you are on a hosted platform such as Shopify, BigCommerce, or WooCommerce, this is usually a setting or a plugin. If your site is custom-built, the tag goes in the page head, ideally through Google Tag Manager so you can manage events without editing site code each time.

A way to push structured data. GA4 ecommerce reporting is driven by events that carry an items array — the products involved in each action. On most platforms this comes from a data layer that your store populates as the shopper moves through it. Confirm your platform or plugin actually writes product data to that layer, because that is the raw material everything downstream depends on.

A test order path. You will need to place at least one real or test transaction end to end. Many platforms offer a test-payment mode; if yours does not, a small live order you refund afterwards works. You cannot verify transactions are recording correctly without putting at least one through the system yourself.

The e-commerce events that matter

GA4 recognises a specific set of recommended e-commerce events. You do not need all of them on day one, but you should understand the funnel they describe, because the gaps between them are where you learn the most.

The core sequence, in the order a shopper experiences it, is: view_item_list (they see a category or search results), view_item (they open a product), add_to_cart, begin_checkout, add_payment_info, and finally purchase. There are a few others — remove_from_cart, view_cart, add_to_wishlist — but the six above form the spine of ecommerce tracking in GA4.

The value is in the drop-off. If 1,000 people fire view_item, 300 fire add_to_cart, and only 40 fire purchase, you know exactly where shoppers leave — and whether the problem is the product page, the cart, or the checkout. A single conversion number can never tell you that. The event sequence can.

Get these named exactly as GA4 expects, including the underscores and lowercase spelling. GA4 only attaches its built-in e-commerce reports to events with the correct reserved names. Call your purchase event completed_order and GA4 will record it — but it will sit outside the monetisation reports, useless for revenue analysis.

Setting up the purchase event

The purchase event is the one that matters most, because it carries your revenue. If it is wrong, every monetisation report in GA4 is wrong with it. Done right, purchase event setup is the difference between a store that knows its revenue and one that merely hopes the numbers line up with the bank.

A correct purchase event fires once — on the order-confirmation step, after payment succeeds — and carries a specific payload. At minimum it needs:

• transaction_id — a unique order reference. This is what GA4 uses to de-duplicate, so a repeated confirmation-page refresh does not count the same sale twice.
• value — the total order revenue as a number, not a string, and without a currency symbol.
• currency — the three-letter ISO code (for example CAD or USD). GA4 will not process value without it.
• items — the array of products in the order, each with its own details (covered in the next section).

Two failure modes account for most broken purchase tracking. The first is firing the event before payment is confirmed — on the “place order” click rather than the confirmation page — which counts abandoned and failed orders as revenue. The second is firing it on a page the shopper can reload or revisit without a fresh, unique transaction_id, which inflates sales through duplicates. Fire once, after success, with a unique ID, and most problems disappear.

The purchase event is the only number in GA4 you can check against your bank statement. If those two disagree, fix the event before you trust anything else.

Item-scoped parameters: getting product detail right

Every e-commerce event that involves products carries that items array, and each entry in it describes one product using item-scoped parameters. The name is precise: these parameters are scoped to the item, not the event. They let GA4 report at the level of the individual product rather than only the order as a whole.

This distinction is what powers the useful reports. Event-scoped data answers “how much was this order worth?” Item-scoped data answers “which products sold, how many of each, and at what price?” Without item-scoped parameters you get revenue totals and nothing about what drove them.

For each product in the array, the parameters worth populating are:

• item_id — your SKU or product code. Use the same ID consistently across view_item, add_to_cart, and purchase so GA4 stitches the journey together.
• item_name — the human-readable product name.
• price — the per-unit price as a number.
• quantity — how many of that item are in this action.
• item_category — the product category, which lets you analyse performance by range rather than only SKU by SKU.
• item_brand, item_variant, and similar — optional, but valuable if you carry multiple brands or variants like size and colour.

Keep item_id and item_name identical wherever the same product appears. A product that is SKU-204 on the product page and sku204 at checkout will split into two products in your reports, and your best-seller list becomes fiction. Consistency here is not a nicety; it is the thing that makes the data trustworthy.

Verifying your data

Setup is not finished when the code is deployed. It is finished when you have watched real data arrive and confirmed it is correct. GA4 gives you two tools for this, and you should use both.

DebugView shows events in near real time as they fire, with their full parameter payloads. Open it, then walk through your own store: view a product, add it to the cart, begin checkout, and place a test order. Watch each event appear, and click into the purchase event to confirm transaction_id, value, currency, and the items array are all present and correctly populated. This is the fastest way to catch a missing parameter or a misnamed event.

The Realtime and Monetisation reports confirm the data is not just firing but flowing into GA4’s actual reporting. Note that processed e-commerce reports can take 24 to 48 hours to fully populate, so do not panic if the monetisation overview looks thin an hour after your test. Check back the next day and reconcile the revenue GA4 reports against the orders your platform actually recorded. If they match, your GA4 store tracking is sound. If they do not, the gap tells you where to look — usually the purchase event.

Common pitfalls

A handful of mistakes account for most of the “my GA4 numbers look wrong” complaints. Knowing them in advance saves the debugging session later.

Double-counted purchases. Almost always a confirmation page that re-fires the event on reload without a unique transaction_id. Symptom: GA4 revenue runs higher than your real sales.

Missing or mistyped currency. GA4 silently drops value if currency is absent or invalid. Symptom: purchases recorded, revenue showing zero.

Inconsistent item IDs. The same product appearing under different IDs across events. Symptom: inflated product counts and a best-seller report that does not match reality.

Events fired at the wrong moment. A purchase event on “place order” rather than confirmation counts failed payments as revenue. Symptom: GA4 revenue higher than the bank, again, but for a different reason.

Reading the data wrong even when it is right. This is the subtlest pitfall, and the most expensive. Perfectly configured tracking still produces numbers that mislead if you read a seasonal dip as a crisis or a tracking change as a sales drop. We documented exactly this in a case study, GA4 Says We Lost Money, where a store nearly overhauled a working checkout because of a number it had misunderstood. Accurate data and accurate interpretation are two different problems, and the second is the one that quietly costs you.

Where WebSignalytics fits

Getting GA4 ecommerce tracking set up correctly is the hard, technical half. Reading it every week and knowing what the numbers mean is the half that quietly never happens. WebSignalytics handles the second half. It connects to your Google Analytics in the background and emails you a plain-language report every Monday: what changed in your store last week, why it likely matters, and what is worth your attention.

No dashboards, no logging in, no parsing the monetisation report yourself. If revenue moved, it tells you whether the cause looks like traffic, conversion, or a tracking issue worth checking — before you act on a number you have misread. The data was always there once you set it up. WebSignalytics reads it for you and tells you what it means, in a paragraph, not a spreadsheet.