If you already run an operating store, you don't need a sermon on why GA4 replaced Universal Analytics. You need the event list, the parameters, and an honest read on what the documentation measures — and what it quietly leaves out. This is that read, written for someone who already watches their numbers.
The GA4 ecommerce event model, in one pass
GA4 is event-based. Every shopper action — viewing a product, adding to cart, checking out, buying — is sent as a discrete event with named parameters, rather than the "standard vs enhanced ecommerce" split Universal Analytics used.
There is no separate "enhanced ecommerce" toggle anymore. The full funnel is expressed through a fixed set of recommended events, and GA4 maps those events to predefined dimensions and metrics in your reports automatically, according to Google's ecommerce measurement docs.
Your job as an operator is to make sure each event fires once, with the right parameters, at the right moment. Get that wrong and every downstream report inherits the error.
The ten recommended ecommerce events (and when each fires)
These are the events Google documents, in the order a shopper triggers them. The names are case-sensitive and must match exactly, as listed in Google's reference.
| Event | Fires when a shopper… |
|---|---|
view_item_list |
sees a list of products (a collection or search results) |
select_item |
clicks a product from that list |
view_item |
opens a product detail page |
add_to_cart |
adds an item to the cart |
view_cart |
opens the cart |
begin_checkout |
starts checkout |
add_shipping_info |
submits shipping details |
add_payment_info |
submits payment details |
purchase |
completes an order |
refund |
receives a full or partial refund |
The two events operators under-use are view_item_list with select_item. Together they tell you which collection placements actually earn clicks — the difference between a hero product and dead inventory taking up a grid slot.
The parameters that actually matter
Most ecommerce events share three top-level parameters: currency (an ISO code like USD), value (a number), and items (an array). The purchase event adds transaction_id, and usually tax and shipping.
The items array is where the real detail lives. Each object inside it can carry item_id, item_name, price, quantity, item_category (up to five nested levels), item_brand, item_variant, coupon, and discount.
Two checkout events carry their own context parameters. add_shipping_info takes a shipping_tier (say, "Standard" or "Express"), and add_payment_info takes a payment_type. Those let you see where a funnel leaks by method, not just in aggregate.
A clean purchase payload, conceptually, is: currency USD, value 40.00, transaction_id "1234", and an items array naming each SKU with its price and quantity. If the value doesn't equal the summed line items plus tax and shipping, your reports will quietly disagree with your store admin.
Where the documentation goes quiet: profit
Here is the gap every ranking guide skips. GA4's value parameter is revenue — the amount the shopper paid. There is no documented parameter for your cost of goods, your fulfillment charge, your payment fees, or your ad spend.
That omission is by design: GA4 is a behavioral analytics tool, not your general ledger. But it means the "revenue" column that looks like performance is really just top-line. The number you actually run a business on — contribution margin after ads — is nowhere in the event schema.
For a print-on-demand seller the gap is brutal, because COGS is a large share of every order. GA4 will happily show a product as your "top performer" by revenue while it loses money on every sale once the blank, the print charge, and the ad allocation come out.
A worked example: what GA4 shows vs what you keep
Say your store does 1,000 orders a month at a $40 average order value. GA4's purchase events sum cleanly to $40,000 in "revenue," and that is the number you'll see headlined in every ecommerce report.
Now walk one order the way your P&L does. Revenue is $40.00. Subtract product cost of $16.00, carrier shipping of $5.00, payment processing of $1.60 (four percent of $40), and pick/pack labor of $1.40 — that leaves $16.00 of contribution margin before ads.
Then subtract the ad spend that order carried. If you run at a 4.0 return on ad spend, roughly $10.00 of ads is allocated to that $40 order, so you keep $40.00 − $16.00 − $5.00 − $1.60 − $1.40 − $10.00 = $6.00. GA4 showed $40; you kept six. That ratio — not the revenue line — is what tells you whether to scale the SKU or kill it.
This is the move from revenue thinking to profit thinking that our guide to ecommerce business intelligence walks through end to end, and it's the reason a revenue-only dashboard flatters you right up until the bank balance disagrees.
The refund event most stores never send
refund is a documented event, yet it's the most commonly skipped one. If you only fire purchase, your reports count day-one revenue and never net it back down when the return is processed a week later.
That matters most for apparel, where returns cluster on sizing. A campaign that looks profitable on purchase alone can flip negative once refunds book — which is exactly the reconciliation our Shopify refund reporting guide exists to catch.
If you're standing up tracking from scratch, send refund from the start. Retrofitting it later means a period where your net-revenue trend has a structural break you'll spend an afternoon explaining.
Validating your implementation
Before you trust a single report, confirm each event fires exactly once per action. Duplicate add_to_cart events (a common tag-manager mistake) inflate your funnel and understate drop-off.
Use GA4's DebugView to watch events arrive in real time as you click through your own store. Check that value matches the order total and that every items object has an item_id — a missing ID silently drops the product from item-level reports.
The begin_checkout-to-purchase ratio is your most honest on-site number. For context, the average documented cart abandonment rate across studies is about seventy percent, per the Baymard Institute, so a large gap there is normal — but a sudden change in it usually means a tracking break, not a conversion collapse. A deeper teardown of that funnel lives in our ecommerce analytics and KPI dashboard guide.
From events to decisions — and the profit layer GA4 can't give you
GA4 answers "what are shoppers doing?" with precision. It does not answer "which of these orders made money, after everything?" — because the cost side simply isn't in the event model.
That's the line between behavioral analytics and operating decisions. You still want GA4 for funnel and on-site behavior; you need a separate source of truth for true per-order profit. Our ecommerce performance analytics guide covers how the two fit together, and an analytics audit is a sane first step if your numbers feel off.
PodVector AI closes the profit gap a different way. Victor is an AI employee that reads your live Shopify orders, your Meta Ads and Google Ads spend, and your Printify, Printful, or Gelato supplier costs, then computes true per-order profit — the $6, not the $40 — and delivers the report to your Google Drive. Victor is not a dashboard and does not touch GA4; it works the data GA4 structurally leaves out, and every write action it takes is approval-gated before anything runs. Put Victor on your store's numbers and see the profit line your event schema was never built to show.
FAQs
Does GA4 track profit or just revenue?
Just revenue. The value parameter on a purchase event is the amount the customer paid; GA4's documented schema has no field for cost of goods, fulfillment, fees, or ad spend. To get profit you have to combine GA4's revenue with cost data from your store, suppliers, and ad platforms — which is the work GA4 deliberately leaves to other systems.
What is the difference between the value parameter and the items array?
The value is a single top-level number for the whole event — the order total. The items array is the line-item breakdown: each product with its own item_id, price, and quantity. Reports built on value show you money; reports built on items show you which specific SKUs drove it. You want both, and they should reconcile.
Do I need Google Tag Manager to send GA4 ecommerce events?
No. You can send events directly with gtag.js, through Google Tag Manager, or via a platform plugin that emits the data layer for you. GTM is the common choice because it lets you change tags without touching code, but the event names and parameters are identical whichever path you use.
Why don't my GA4 purchase numbers match my Shopify payouts?
Several structural reasons: GA4 counts revenue at checkout while refunds book later, ad blockers and consent choices drop some events, and value may or may not include tax and shipping depending on your setup. GA4 is a sampled behavioral view, not an accounting record — treat a small gap as normal and a large or growing one as a tracking bug to chase.
Which GA4 ecommerce event should an operator watch first?
The begin_checkout-to-purchase conversion, because it isolates the part of the funnel you most directly control. After that, pair view_item_list with select_item to see which merchandising placements earn clicks. Both are leading indicators you can act on before the revenue — or the lack of it — shows up in your bank account.