GA4 for E-Commerce: Tracking the Metrics That Matter

No. Google renamed conversions to key events across GA4 in March 2024, updating the admin toggles, report columns and API fields. The word conversion is now reserved for Google Ads, which was the purpose of the change, since the two were never counted identically and the shared name caused persistent confusion. The mechanics are unchanged: you still mark an important event so it appears in key event reporting. If a guide tells you to mark an event as a conversion in GA4, it predates the rename.

GA4 counts a session as engaged if it lasts longer than ten seconds, includes at least one key event, or has two or more page or screen views. Engagement rate is the proportion of sessions meeting any of those conditions, and bounce rate, reintroduced in 2022, is simply its inverse. The improvement over the old metric is real: a visitor who reads one page carefully is no longer recorded as a failure. The weakness is that ten seconds is an arbitrary bar that shallow browsing clears easily.

The reserved names, spelled exactly. view_item when a product page loads, add_to_cart, begin_checkout, and purchase, plus optionally view_item_list, select_item, add_shipping_info, add_payment_info and refund. Each needs a properly structured items array carrying item_id, item_name, price and quantity. GA4 will happily accept an event called purchase_complete or product_view, but it will not appear in ecommerce reporting, because those reports key off the reserved names. Custom event names are for genuinely custom actions, not for renaming standard ones. Check the exact spelling in your tag configuration rather than assuming, because a single underscore or a capital letter in the wrong place breaks the match silently.

They measure different events. GA4 records what a browser successfully sent, so ad blockers, declined consent, network failures and shoppers closing the tab before the purchase event fires all create shortfalls. Your platform records what was actually charged, including phone, offline and manually created orders GA4 never observes. GA4 attributes revenue to the converting session, your platform to the order date. A few percent variance is normal. Use the platform as your financial record and GA4 for behaviour, and compare trends rather than totals.

Treat it as directional. GA4's lifetime value depends on identifying the same person across sessions and devices, which works well when users log in and User-ID is implemented, and poorly when they do not. Without login, cookie expiry, browser privacy controls and cross device behaviour all fragment one customer into several. Add the retention ceiling of 14 months on standard properties and the picture shortens further. For genuine lifetime value, calculate it from order data in your commerce platform or a BigQuery join, using GA4 to explain acquisition.

A session is a period of activity, ending after 30 minutes of inactivity by default. A user is an identified device or person, resolved through User-ID if you send it, then Google signals if enabled, then the device identifier. That ordering matters: the same shopper on a phone and a laptop is two users unless they log in on both. Active users, not total users, is the headline metric in most GA4 reports. Read the metric label carefully, because the two are frequently confused in dashboards.

GA4 withholds rows when a report could allow an individual to be identified, most often where Google signals is enabled and the segment is small. You get a notice in the report rather than an error, and demographic and interest breakdowns are affected most. Widening the date range, removing demographic dimensions, or reading the data through the BigQuery export all avoid it, since the export contains your own raw events and is not subject to reporting thresholds. It is a privacy control, not a bug.

A short list beats a dashboard. Revenue and transactions, for the outcome. Conversion rate segmented by session default channel group, because a blended figure hides everything useful. Add to cart rate and checkout completion rate, which localise where the funnel leaks. Average order value, since it moves margin without needing more traffic. Returning purchaser rate, because acquisition costs more than retention. Everything else is diagnostic, worth opening when one of those six moves and not before. Review them on a fixed cadence and write down what you expected to see before you open the report, which is the cheapest guard against reading whatever you hoped for.

Two months by default, which most properties never change. Standard GA4 properties can be raised to 14 months, the maximum outside Analytics 360 where 26, 38 and 50 months are available. The limit governs the user and event level data behind Explorations, funnels, path analysis and custom segments. Aggregated standard reports are retained longer. Change the setting today, because it does not apply retroactively and every day at the default quietly discards history you cannot recover afterwards. If you need year on year comparison, the BigQuery export is the only reliable answer, and it too begins collecting only from the day you enable it.

Increasingly yes, for one specific reason: it is the only way to keep event level history past the retention ceiling and to join GA4 behaviour against order, margin and returns data. The link is free to enable and you pay only for storage and queries, which is modest at typical store volumes. The catch is that it captures nothing retrospectively, so the cost of delay is permanent. Enable it now even if nobody will query it for a year, because the alternative is starting from zero later.

Monitor key events over time as a standing report and treat a sudden drop as an outage rather than a performance problem. Most tracking breaks silently after a theme update, a plugin change or a checkout redesign, and teams typically discover it weeks later when a report looks wrong. Set a threshold alert on purchase event volume, re run a test purchase through DebugView after every deployment that touches checkout, and check that transaction_id is present so duplicates are removed.

Verify the four core ecommerce events in DebugView with a real test purchase, then raise data retention to 14 months and link BigQuery, since neither is retroactive. Mark your genuine key events and ignore the rest. Build one funnel exploration for the purchase journey and review it weekly against the six metrics above. That configuration takes an afternoon and answers most commercial questions. Audiences, custom dimensions and predictive features add value later, but none of them compensate for unreliable event data.