GA4 e-commerce tracking: the small spec that survives redesigns

E-commerce tracking projects fail by ambition. Someone finds Google's full event reference, implements all of it in a heroic sprint, and ships forty events with nobody assigned to notice when half of them drift. Eighteen months later the store runs on gut feeling again, except now there is a GTM container nobody dares touch.

The setup that survives is smaller and stricter. Four events, correct, owned, and verified beat the full catalog every time, because the full catalog has never once stayed correct through a year of deploys without an owner.

Which events actually matter?

Start with the spine of the shopping journey, and only the spine:

• view_item: someone met a product.
• add_to_cart: someone committed a little.
• begin_checkout: someone committed a lot.
• purchase: money happened.

These four give you the funnel, revenue attribution, and remarketing audiences, which is most of what an e-commerce business does with analytics. Wishlist events, promotion views, checkout step micro-events: all real, all documented by Google, all worth adding later if a specific decision needs them. Each event you add is a maintenance promise. Make few promises and keep them.

Where do the values come from?

From your platform's commerce data, pushed into the dataLayer. Never from the rendered page.

This is the rule that decides whether your tracking survives redesigns. A dataLayer push says value: 129.90, currency: "EUR" because the backend said so. The alternative, a tag scraping .price-total off the DOM, works until a designer renames the class, and then your revenue tracking dies in silence during a Tuesday deploy. The contract idea, and why it is the whole ballgame, is in what is a dataLayer, and the naming discipline that keeps forty events from becoming soup is the event naming convention.

The purchase event: the one that pays rent

Three parameters deserve paranoia:

1. transaction_id, unique per order, always. It is the deduplication key; without it, page reloads become revenue. It is also the join key that lets you audit GA4 against your backend later.
2. value and currency, with a written decision about what value means: with or without tax, with or without shipping. Either answer is fine. An undocumented answer is not, because someday two reports will disagree by exactly the shipping cost and nobody will know why.
3. The items array, built to Google's schema: item_id, item_name, price, quantity per item. A malformed items array produces the sneakiest failure in GA4 e-commerce: order totals look right while product-level reports quietly rot, and you find out months later when merchandising asks why the best-seller report is nonsense.

How do you verify it in production?

Not in GTM preview. Preview is your machine, your consent state, your lack of ad blockers; production is where customers live. Place a real test order on the live store with the network tab open, find the purchase request, and read the payload: one event, correct id, correct value, items array populated.

Then do the arithmetic check: last month's GA4 purchases against the shop backend's order count. Expect a structural gap (consent, blockers), write the percentage down, and re-check it monthly. Drift in that number is your earliest warning that a deploy broke something. The generic version of this habit is in how to verify GA4 tracking.

The failure modes I keep finding

• Purchase fires on the thank-you page URL, so refresh, back button, and bookmark visits mint duplicate revenue. Diagnosing and fixing that is its own piece: GA4 duplicate transactions.
• Value scraped from the DOM (see above; it always ends the same way).
• Items array missing or half-built, so totals reconcile while product reports lie.
• Currency omitted on a store that sells in two currencies, mixing euros and forints into one meaningless sum.
• Checkout events wired to the theme while checkout actually runs on a platform-hosted page the theme cannot see, so begin_checkout fires and the funnel goes dark until purchase.

Every one of these renders dashboards that look plausible. That is what makes them expensive: nothing errors, nothing alerts, the numbers are simply wrong at unknown magnitude. The wider discipline that prevents this class of failure, ownership, contracts, verification, is the tracking implementation guide. If your setup predates anyone currently at the company, the four-event spec above is also the cheapest way to rebuild trust: implement it clean, run it parallel for a month, and retire the archaeology.