.d53b12e5.png&w=3840&q=75 "Trivas.ai")
by Trivas.aiFour events decide whether your GA4 ecommerce reporting is usable or garbage: view_item, add_to_cart, begin_checkout, and purchase. Together, Google Analytics 4 ecommerce events view_item add_to_cart begin_checkout purchase track a shopper's entire path from looking at a product to paying for it. Miss one, or fire it wrong, and your funnel has a hole in it.
Here's the one-line version of each, in order. view_item fires when a product detail page loads. add_to_cart fires the moment someone adds a product to their cart. begin_checkout fires when checkout starts. purchase fires once an order is actually completed.
These four specifically matter because they're the backbone of GA4's default ecommerce funnel report. Every ROAS calculation, every attribution model, every "why did conversion rate drop last week" investigation downstream of GA4 is built on these events firing correctly. Get the setup wrong and you're not just missing data, you're making decisions on bad data, which is worse.
view_item should fire exactly once, when a user lands on a product detail page (PDP). Not a category page. Not a search results grid. The actual product page, with one specific product on it.
At minimum, GA4 needs an items array containing item_id, item_name, price, and currency. Without those four, the event technically fires but the data underneath it is close to useless for revenue reporting.
The mistake we see constantly: teams wire view_item to fire on collection or category pages too, usually because it's easier to implement at that level in Google Tag Manager. The result is an inflated top-of-funnel number that makes your add_to_cart rate look artificially low. If 50,000 people "viewed" a product but half of those were really just scrolling a collection grid, your view-to-cart ratio is lying to you. Check your GTM trigger conditions against the actual PDP URL pattern, not just "page view fires somewhere near a product."
add_to_cart fires on the explicit add-to-cart action. That includes the standard "Add to Cart" button, but also quick-add buttons on collection pages and quantity updates in the cart drawer, if you've configured those separately (most setups miss the quantity-update case entirely).
Pass the items array again, plus value and currency at the event level. Without value and currency, you can count adds but you can't calculate cart-level revenue, which defeats half the point of tracking this event.
One thing worth watching closely: the ratio of add_to_cart to view_item. This is an early, fast signal for product page health. If view_item volume is healthy but add_to_cart is consistently thin, that's a pricing problem, a product photo problem, or a page layout problem, not a traffic problem. It's one of the cheapest diagnostic numbers in GA4 because it doesn't require waiting for a full purchase cycle to tell you something's off.
begin_checkout fires when a user starts checkout, typically by clicking "Checkout" from the cart page. It's the first real commitment signal: someone's not just browsing, they're trying to pay.
Parameters here should include items, value, and currency, plus coupon if a discount code gets applied before this step. If coupons get applied later in the checkout flow, that detail belongs on the purchase event instead.
Here's the gap a lot of Shopify merchants hit: Shopify's hosted checkout sits on a different domain than your storefront, and standard GTM container tags often don't fire there at all. If your begin_checkout numbers look suspiciously low, or your funnel just stops cold between add_to_cart and begin_checkout, that's usually why. You need checkout.liquid customization (on legacy plans) or Shopify's native Pixels setup to get this event firing reliably. This is one of the more common reasons GA4 ecommerce data looks broken on Shopify specifically, and it's worth checking before you assume your product pages are the problem. If you're setting this up for the first time, Trivas's GA4 integration guide covers the checkout-tracking gap in more detail.
purchase should fire exactly once, on the order confirmation or thank-you page. Exactly once. Not on every page refresh, not if the customer hits back and forward again.
Required parameters: transaction_id, value, currency, and the items array. If you want net revenue accuracy rather than gross order value, add tax and shipping as separate parameters too, since GA4 treats value as total order value by default.
transaction_id is the whole ballgame here. GA4 uses it to deduplicate purchase events, so if a customer refreshes the thank-you page and the event fires again with the same transaction_id, GA4 won't double-count it. Skip this parameter, or implement it inconsistently, and you'll see revenue numbers in GA4 that don't match your Shopify or Stripe totals. This is one of the most common GA4-vs-backend revenue mismatches we see, and it's almost always a transaction_id problem, not a GA4 problem.
Once all four events are firing correctly, you can build the view_item to add_to_cart to begin_checkout to purchase funnel inside GA4's Explore reports using a funnel exploration. Set the four events as sequential steps and GA4 will show you the drop-off percentage at each stage.
Watch the cart-to-checkout step first. In most ecommerce funnels we see, that's the steepest drop, steeper than checkout-to-purchase. It's where shipping costs get revealed, account creation gets forced, or page load gets slow. If you're only going to investigate one gap, start there.
The native reporting has real limits, though. GA4's funnel exploration resets at session boundaries, so a shopper who adds to cart on Monday and buys on Thursday doesn't show up as one clean funnel path. And Explore reports only show you GA4 data: no ad spend, no Shopify order data, no blended view of what channel actually drove the add_to_cart. For a single-session glance, it's fine. For ongoing funnel health tracking, you'll hit the ceiling fast.
GA4's own sampling and data retention settings create a second problem. Standard GA4 properties cap event-level data retention at 14 months, and high-traffic properties get sampled in Explore reports once you're querying large date ranges. Try to compare this quarter's add_to_cart rate against the same quarter two years ago and you're often out of luck.
This is the part of the job that gets tedious fast: exporting Explore reports every week just to track whether your begin_checkout rate is trending up or down. Trivas's BI reporting pulls these same GA4 ecommerce events into Redshift-backed dashboards, sitting alongside your Shopify order data and ad platform spend, so the funnel doesn't live in isolation anymore. You can see that a dip in begin_checkout correlates with a shipping cost change you made, or a Meta campaign that shifted mid-funnel traffic quality, without manually joining three exports in a spreadsheet.
The Wingman AI layer inside Trivas's insights product goes a step further: instead of you eyeballing a funnel chart and guessing which stage moved, it flags the specific stage driving a conversion rate change and surfaces it directly. That's the difference between building a new Explore report every time something looks off and getting told where to look.
view_item, add_to_cart, begin_checkout, and purchase are the minimum viable setup for accurate GA4 ecommerce tracking. Get the triggers and parameters right on all four, and you've got a funnel you can actually trust. Get even one wrong, like firing view_item on category pages or skipping transaction_id dedup, and the whole thing is compromised.
If you're tired of exporting GA4 Explore reports by hand just to check funnel health, start a trial and connect GA4 alongside your Shopify and ad data in one place instead.
explore more insights
3 min read
3 min read
3 min read