.d53b12e5.png&w=3840&q=75 "Trivas.ai")
by Trivas.aiFour events carry the entire GA4 ecommerce funnel: view_item, , , and . Together they track a shopper from product page to confirmed order, and they're the backbone of Google Analytics 4 ecommerce events view_item add_to_cart begin_checkout purchase official reporting that every GA4 ecommerce dashboard is built on.
add_to_cartbegin_checkoutpurchaseThis post follows Google's official GA4 ecommerce event reference. The event names are case-sensitive, exactly as written above, fired through gtag.js, Google Tag Manager, or a server-side Measurement Protocol call. Get the casing or parameter names wrong and GA4 won't throw an error. It'll just quietly accept bad data.
That's why this topic gets searched constantly. A broken add_to_cart event doesn't crash your site. It just makes your funnel reports wrong, your ROAS attribution wrong, and any remarketing audience built on cart behavior wrong too, and nobody notices until a monthly review doesn't add up.
Google's full recommended sequence runs eight events deep: view_item_list, select_item, view_item, add_to_cart, begin_checkout, add_shipping_info, add_payment_info, purchase. That's the complete shopping journey, from browsing a category page to the receipt.
Most teams don't configure all eight as conversions. They focus on four: view_item, add_to_cart, begin_checkout, and purchase. These are the ones GA4 treats as the core "key events" (what used to be called conversions pre-2023), and they map directly to the four stages a merchandiser actually cares about: interest, intent, commitment, revenue.
Every one of these events needs an items array parameter. Skip it, or malform it, and GA4 has no product-level data to report on, even if the event itself fires. This is the single most common reason a GA4 ecommerce report shows events firing but product reports sitting empty. If you're auditing your setup from scratch, Trivas's GA4 solutions page walks through how this funnel data should flow end to end.
view_item needs currency, value, and an items array containing at minimum item_id, item_name, price, quantity, and ideally item_category.
It should fire once, on product detail page load. Not on a hover card. Not on a quick-view modal from a collection grid, that's view_item_list territory, since the shopper hasn't actually landed on the dedicated product page yet.
The mistake we see constantly: view_item firing on every single page load because of a sitewide tag that wasn't scoped correctly. That inflates your funnel's entry point and makes your view-to-cart conversion rate look artificially low, because the denominator is stuffed with homepage and blog visits that were never product views to begin with.
Required parameters are currency, value, and items[], with value reflecting quantity times price, not just the unit price. If a shopper adds three units, your value field needs to show that, not the single-item price.
The trigger point matters here. Fire this on the actual successful add-to-cart response, the moment the item is confirmed in cart state, not on the click of the button itself. A button click can fail silently (out of stock, API timeout) and if you're firing on click alone, you're counting adds that never happened.
The classic bug: double-firing. One tag listens for the click, another fires on the AJAX success callback, and both push add_to_cart to the dataLayer. Now every cart add counts twice, and your cart-to-checkout rate looks half as good as it actually is. Check your dataLayer in GTM preview mode for duplicate pushes before you trust this number.
Required: currency, value, items[]. There's also an optional coupon parameter worth setting if you're tracking cart-level discount codes, since it lets you segment checkout behavior by promo usage later.
This fires at checkout page load, or on the "proceed to checkout" click, but critically, before shipping or payment details are entered. If you're firing it after add_shipping_info logic has already run, you've got your sequence backwards.
Here's the useful part. Compare add_to_cart volume against begin_checkout volume and you get a clean read on how many shoppers bail between adding something to their cart and actually starting checkout. That gap, before shipping forms, before payment fields, before any friction from the checkout flow itself, is pure cart abandonment. It's one of the cleanest diagnostic numbers in the whole funnel, and most stores never look at it in isolation because they jump straight to overall cart abandonment rate instead.
This one has the highest stakes. Required parameters: transaction_id (unique, every time), currency, value, items[], plus optional tax and shipping fields for full order-level detail.
Fire purchase on the order confirmation or thank-you page load, or server-side once payment is actually confirmed. Never on checkout submit. A submit click isn't a completed sale, payment can still fail, decline, or time out after that click, and if you've already fired purchase, GA4 now thinks you made a sale you didn't.
The transaction_id issue deserves its own warning. If it's missing, or if it gets reused (a common bug with page refreshes on the thank-you page, or with order confirmation emails that link back to the same page), GA4 either drops the duplicate or double-counts the revenue. Either way your reported revenue stops matching your actual order totals, and that's the kind of discrepancy that makes a founder stop trusting GA4 altogether, often for no reason other than a refresh bug on one page.
Don't take any of this on faith. Open GA4's DebugView alongside GTM Preview mode and watch the events fire in real time. Confirm three things: the event name matches exactly, the parameter names match exactly, and the items array structure is intact with every field populated.
The silent failure to watch for is parameter naming. item_id versus id, item_name versus name, these small mismatches don't throw errors. GA4 accepts the event, logs it, and then reports it with blank or missing product data, which looks like a reporting bug when it's actually a tagging bug upstream.
As a sanity check, pull up the Realtime report and look at event count by event name. Your counts should step down in order: more view_item events than add_to_cart, more add_to_cart than begin_checkout, more begin_checkout than purchase. If purchase count is somehow close to or higher than begin_checkout, something's duplicating. For teams building this out for the first time, Trivas's dashboard and analytics help docs cover a lot of these verification steps in more depth.
GA4 only reports what it's told. If your view_item through purchase events are miscounted, every downstream system pulling from that data inherits the same error, including the ad platforms using GA4 conversions to optimize bids.
This is the part that gets missed. Most teams troubleshoot GA4 in isolation, then separately troubleshoot Meta or Google Ads reporting, never realizing the root cause lives in the same broken items array on both sides. A clean Google Analytics 4 ecommerce events view_item add_to_cart begin_checkout purchase official implementation is the foundation both systems depend on.
Trivas's GA4 integration is built to show this funnel, view_item through purchase, sitting next to ad spend and Shopify or Amazon revenue in a single view, instead of tabbing between GA4's UI and your ad platforms trying to reconcile numbers by hand. If your BI reporting setup still means exporting GA4 funnel data and merging it manually with ad spend sheets, that's exactly the kind of rebuild Trivas's GA4 page is meant to replace.
If you're setting this up for the first time or auditing an existing implementation, it's worth bookmarking Google's spec and checking back against it. And if you want a second set of eyes on whether your funnel data is actually clean once it reaches reporting, Trivas's getting started guide is a reasonable next stop.
explore more insights
3 min read
3 min read
3 min read