.d53b12e5.png&w=3840&q=75 "Trivas.ai")
by Trivas.aiFour events carry most of the weight in GA4 ecommerce tracking: view_item, , , and . These are the official google analytics ecommerce events view_item add_to_cart begin_checkout purchase official names, defined by Google in the Measurement Protocol and gtag.js docs, and each one maps to a stage of the shopping funnel.
add_to_cartbegin_checkoutpurchaseview_item fires when someone views a product detail page. add_to_cart fires when an item gets added to the cart. begin_checkout fires when checkout starts. purchase fires when a transaction completes.
These aren't custom events you get to name however you like. They're standard, recommended events, which is exactly why the naming has to be exact. Get the names wrong and GA4 stops auto-populating the reports and conversion imports these events were built for.
Universal Analytics had enhanced ecommerce actions like "add," "checkout," and "purchase." GA4 replaced that whole structure with a defined schema of snake_case event names: view_item, add_to_cart, begin_checkout, purchase, and a handful of others.
The naming isn't stylistic preference. It's a contract. If your tag fires addToCart or Add to Cart instead of add_to_cart, GA4 has no idea it's looking at an ecommerce event. It'll show up as a random custom event with none of the automatic item-level breakdowns, no revenue attribution, nothing in the Monetization section.
This matters beyond GA4's own interface too. Google Ads and Performance Max both pull conversion signals from these exact event names when linked to a GA4 property. Misname purchase and you're not just losing a report, you're potentially feeding bad or missing signal into campaigns that are optimizing spend off it.
If you're setting this up from scratch or auditing an existing GA4 property, GA4 funnel tracking is worth reviewing end to end before you touch individual event code, since a lot of these naming mistakes trace back to one bad template getting copied across triggers.
view_item needs an items array, and inside it, at minimum, item_id and item_name for each product shown.
Recommended parameters round out the picture: currency, value, item_category, item_brand, price. None of these are strictly required for the event to register, but skip them and your product reports in GA4 end up with blank fields everywhere.
Timing matters here too. view_item should fire when a user actually lands on, or scrolls into view of, a product detail page. Not on a thumbnail hover in a collection grid. Not on a quick-view modal open if that's not really "viewing" the PDP. Fire it too early or too often and your view-to-cart conversion rate gets diluted by phantom views that were never real product consideration.
Required parameters for add_to_cart: currency, value, and the items array.
One add-to-cart click should fire the event once. If someone bumps the quantity selector to 3 before clicking "add," that's reflected in the quantity field inside the items array, it's not three separate add_to_cart events. Firing per unit instead of per action will wreck your cart-add counts and make add-to-cart rate look inflated against sessions.
The most common mistake here isn't the parameters, it's the trigger. A lot of GTM setups accidentally bind add_to_cart to a page load or a cart drawer opening, rather than the actual click on the "Add to Cart" button. That'll fire the event every time someone glances at their cart, whether or not they added anything. If your add-to-cart numbers look suspiciously close to your session count, this is usually why.
begin_checkout requires currency, value, and items.
If a discount code gets applied before checkout even starts, for instance from a cart page promo field, pass it through the coupon parameter so it's attached to the session from the start rather than only showing up at purchase.
This event is the bridge between "has stuff in cart" and "is actually trying to buy." It's also, in practice, the one most likely to be broken in GTM setups. Either it never fires because the checkout trigger only catches a later step, or it fires twice because there are two triggers overlapping (one on the cart page's checkout button, another on the checkout page itself loading). Both failure modes quietly distort your cart-to-checkout conversion rate, which is usually one of the first numbers a growth lead checks when diagnosing funnel drop-off.
purchase has the strictest requirements of the four: transaction_id, currency, value, and items are all required.
Recommended parameters: tax, shipping, coupon. Leave these out and your revenue numbers in GA4 won't reconcile with what's actually in your order management system or Shopify admin.
The single most damaging implementation error with purchase is firing it on every load of the thank-you or order-confirmation page, including refreshes. Customer hits refresh on the confirmation screen, or navigates back to it from their email, and congratulations, you just recorded a second transaction with the same order. This inflates revenue in GA4 in a way that's easy to miss because the number looks plausible, just high. It's gradual, not an obvious spike, which is exactly why it goes unnoticed for months.
Don't trust the dashboard until you've watched the events fire raw. GA4's DebugView, paired with the Tag Assistant Chrome extension, lets you step through an actual add-to-cart or checkout flow and confirm each event fires exactly once, at the right moment, with a full parameter set attached. Open DebugView, walk through a test purchase yourself, and check that transaction_id, value, and items are all populated, not blank or null.
After that, cross-check GA4's Realtime report during a live test, then check the Monetization > Ecommerce purchases report against your actual order count from Shopify or your order system for the same window. If GA4 shows noticeably more transactions than orders placed, you've likely got a refresh-triggered duplicate purchase problem.
The cleanest way to catch that specific issue: pull transaction_id values and look for duplicates. Real orders have unique IDs. If the same ID shows up twice in GA4, that's your refresh bug, not a data processing glitch. For a deeper reference on what each parameter should contain and how it maps across systems, the data dictionary is useful when you're trying to confirm whether what you're seeing in GA4 actually lines up with what Shopify or your ad platforms are reporting.
Getting view_item, add_to_cart, begin_checkout, and purchase named and firing correctly is step one. It's necessary, but it doesn't actually answer the question most teams are really asking, which is "how does this funnel look next to what we're spending on ads."
That's a different problem. GA4 alone doesn't blend its own event data with Shopify order data or ad spend from Meta and Google in any usable native view. You end up exporting CSVs, or squinting at three separate tabs trying to mentally merge a GA4 funnel with a ROAS number from a different tool.
If you've already confirmed your events are clean and you're still stuck stitching that together by hand, that's the actual reporting gap worth solving next. Dig into how Trivas handles GA4 dashboards and analytics to see what a unified view of funnel stage, ad spend, and revenue looks like when it's pulled into one place instead of five.
Worth subscribing to updates if you want more of this kind of breakdown, GA4 setup details, funnel reporting, the stuff that actually changes what you see in your dashboard rather than just adding more tabs to check.
explore more insights
3 min read
3 min read
3 min read