Ecommerce Analytics · focused work
GA4 ecommerce tracking
GA4 knows nothing about what a store sold unless the store tells it, in the exact shape it expects. The ecommerce events, the items array inside them and the identifiers that connect a session to an order are the difference between a property full of page views and one that can say which product, channel or template produced revenue.
This is the right work if
- Analytics revenue and store revenue differ by an amount nobody in the business can account for
- Only the purchase is tracked and every step before it is invisible in reporting
- The items array is missing, or carries product names with no stable identifier
- Checkout or payment runs on another domain and sessions restart part way through
- Some orders appear twice in the transaction reports
What it is
What a complete implementation includes
The event set runs the length of the funnel: a list of products being seen, a product being selected from it, a product page viewed, items added to and removed from the cart, checkout started, shipping and payment details supplied, the purchase, and refunds when they happen. Each of those carries an items array with an identifier, name, brand, category, variant, price and quantity, and the purchase carries currency, value and an order identifier. Implemented properly, the values come from the order and product records through a data layer, not from reading text out of the page.
The rest of the work is everything that quietly breaks it. Purchases firing twice because a confirmation page can be refreshed. Sessions restarting because payment happens on another host. Currency reported inconsistently across markets. Item identifiers that do not match the ones used in the product feed or the store's own reports, which makes any product-level analysis unreliable. Consent choices removing events entirely. Configuration matters too: which events count as key events, which item attributes are registered as dimensions, whether internal traffic is filtered, and how long data is kept. The last step is a monthly reconciliation against the platform's own numbers, aimed at explaining the gap rather than eliminating it.
How it is done
The work, in order
What changes
- The path from browsing a list to buying is visible step by step
- One product identifier joins analytics, advertising and the product feed
- Each order is counted once, so revenue reports can be trusted
- The difference between analytics and the platform is explained rather than argued about
Write the measurement plan before tagging
List every event, its parameters, the item fields and the single product identifier that will be used consistently across analytics, the ad platforms and the product feed. Agreeing the identifier at this point prevents the most expensive rework later.
Push a real data layer
Emit the events from the store's own templates so the values come from the product and order records. Scraping a price out of rendered text works until a currency symbol or a sale badge changes, at which point the numbers drift without anything appearing broken.
Make purchase fire exactly once
Key the event on the order identifier and make it resilient to a page refresh, a back button and a confirmation page reached twice. Test by placing a real order and repeating each of those actions rather than by trusting the tag preview alone.
Protect session continuity
Configure cross-domain measurement wherever checkout, payment or an account area sits on a different host, and add referral exclusions for payment providers so a returning shopper is not recorded as a new visit from the payment company.
Configure the property deliberately
Mark the key events, register item-scoped dimensions for the attributes the business actually analyses by, filter internal and agency traffic, set data retention, and connect the ad accounts so campaign data joins the behavioural data.
Reconcile monthly and write the gap down
Compare orders and revenue against the platform's own report for the same window, list the causes of the difference such as consent, blockers and cancelled orders, and keep that explanation where the whole business can see it.
Platform notes
Shopify
Custom tracking on checkout runs through the platform's customer events sandbox rather than as script in the page, so checkout step events are configured there, and the built-in channel integration should be checked for which events it already sends before adding more.
WooCommerce
Data layer output usually comes from a plugin, and full page caching can serve a cached page with a previous visitor's values embedded in it, so cache exclusions for cart, checkout and confirmation pages are part of the implementation.
Should analytics revenue match the store's revenue exactly?
No, and chasing an exact match wastes time. Consent declines, blockers, cancelled and test orders, and different timezone boundaries all create a gap. The useful goal is a gap that is stable, understood and documented, so a sudden change in it becomes a signal that something broke.
Is the platform's built-in integration enough on its own?
Sometimes for the basics and rarely for the full funnel. Built-in connections tend to cover product views and purchases well and leave list impressions, selections and checkout steps thin. Audit what it actually sends before deciding whether to extend it or replace it.
How much do consent choices affect the reports?
Enough to matter, and the amount depends on the banner design and the markets served. Events from visitors who declined are either not collected or collected without identifiers, which reduces user counts and attribution more than it reduces totals. It is a fact to report around, not a problem to engineer away.
Which identifier belongs in the items array?
The same one used in the product feed and in the store's own reporting, which for most catalogs means the variant level identifier rather than the parent product. Mixing levels between systems is the reason product reports refuse to reconcile, and it is much cheaper to settle before implementation.
Related work and answers
Find the leak.
A free Growth Analysis ranks what your store should fix first, by revenue at stake.