Ecommerce analytics and GA4: the complete guide

Start by writing down the numbers you will actually make decisions with, before touching any settings. A store needs about ten, and everything else is available when a specific question comes up.

The core set follows the four levers. For traffic: sessions by channel and the cost of the paid ones. For conversion: conversion rate overall, add to cart rate, and checkout completion. For order value: average order value and items per order. For repeat business: repeat customer rate and the second order rate for recent cohorts. Plus two that keep the rest honest: contribution after the cost of goods and marketing, and returns.

For each one, write three things beside it: where the number comes from, who looks at it, and what decision it changes. A number that changes no decision comes off the list. That single rule removes most of what clutters a typical dashboard, including bounce rate, time on page, and anything reported per user that nobody can act on.

Decide the source of truth for each number too, because you will have several candidates. Orders and revenue should come from your store admin or your accounting system, since that is the record that matches the bank. Behaviour on the site should come from your analytics. Ad costs come from the ad platforms. When two sources disagree about the same thing, the rule you wrote in advance settles it instead of a meeting.

Then agree the definitions in writing. Conversion rate divided by sessions or by users gives different answers. Revenue with or without tax and shipping gives different answers. Neither is wrong, but a store that changes definitions quietly will believe things improved when they did not.

This list is what the rest of the guide is built to produce reliably.

Put the list somewhere the whole team can see it. A shared page of ten numbers with their definitions prevents most of the reporting disagreements that otherwise take up a monthly meeting.

GA4 records everything as events rather than as pages, and once that clicks the rest of the tool makes sense. A page view is an event, an add to cart is an event, a purchase is an event, and each carries parameters that describe it.

Ecommerce events carry an items array, which is the part that matters for a store. Inside it each product is described with an identifier, a name, a price, a quantity and optional details such as brand, category and variant. Those item details are what make product reporting possible, so an events setup that fires the right event names with an empty or partial items array will produce reports that look complete and tell you nothing.

The standard sequence for a store is a view of a list, a view of an item, an add to cart, a view of the cart, a checkout start, and a purchase. Fire the ones you will use, name them exactly as the documented ecommerce events, and use the same item identifier throughout so a product can be followed from view to purchase.

Understand the difference between users and sessions, because your conversion rate depends on which you divide by. GA4 reports both, and it also distinguishes the source that first brought a user from the source of the session in which they converted. Those are two different reports answering two different questions, and mixing them up is the most common misreading in the tool.

One practical note on hosted checkouts. When the checkout runs on the platform rather than your own theme, the checkout and purchase events usually come from the platform's own integration or customer event system rather than from a tag you place on the page. Find out which mechanism is producing them in your store before adding another, because two sources firing the same event is how duplicate revenue appears.

Do not try to implement every event at once. Install them in the order of what they let you answer, verify each one, then move on. A partial setup that is correct is worth far more than a complete one that is wrong.

Start with purchase. It carries the order identifier, the value, the currency and the items, and it is the event every other number is compared against. Get it right and you can already answer most business questions. Verify it by placing a real order and checking that one event arrives, with the right total and the right products.

Add add to cart second, because purchase divided by add to cart gives you the cart and checkout picture immediately. Then the item view, which gives you add to cart rate per product and tells you which pages are failing. Then the checkout start, which splits the loss between the cart and the checkout itself. Those four events answer nearly everything a store owner asks.

After that, the optional ones earn their place case by case. List views and item selections help if you are working on collection pages. Shipping and payment steps help if your checkout has a real problem to diagnose. A refund event helps if returns are material in your category, and it is the only way to stop reported revenue drifting away from real revenue.

Use a tag manager if you have more than a couple of tags to maintain, and keep the naming tidy from the start. A container with clearly named tags and a written note of what fires where can be handed to someone else. One with a dozen unnamed tags cannot, and eventually somebody deletes the wrong one.

Verify with the live debugging view and with a real order rather than a test mode, then check again a week later. Events break silently after theme updates and app installs.

Analytics revenue will never match your store admin exactly, but it should be close and the gap should be explainable. When it is not, every decision made from that data is suspect, so treat this as the foundation rather than a detail.

Work through the usual causes in order. Duplicate events, where the purchase fires twice because a customer refreshed the confirmation page or because two integrations are both sending it. A unique order identifier on the event lets the tool remove duplicates, so make sure the real order number is being sent. Missing events, where customers who leave the confirmation page quickly, block scripts or decline tracking never fire one. Currency, where multi currency stores report in mixed units unless the currency is sent with every event. And the treatment of tax and shipping, which may be included in one system and excluded in the other.

Refunds and cancellations are the slow drift. If refunds are never sent to analytics, reported revenue keeps rising above the money you actually keep, and the gap grows over time. Either send the refund event or accept that your analytics revenue is gross and label it that way everywhere.

Exclude your own traffic and your test orders. Staff placing test orders, developers browsing the store and a support team checking a product all pollute both behaviour and revenue in a small store.

Then measure the gap deliberately. Once a month, compare orders and revenue in analytics against the store admin for the same period, in the same time zone, and write down the difference. A stable gap you can explain is workable. A gap that moves around means something is broken, and you will notice it in the month it happens rather than a quarter later.

Time zones deserve their own check, since a mismatch between the analytics property and the store shifts every daily comparison you make.

Some of your visitors will not be measured, and that is now a permanent feature of ecommerce analytics rather than a problem to solve. Set consent up correctly and then build your reporting so it works with incomplete data.

Get the legal part right first. Where consent is required, the banner has to ask before tracking tags run, and refusing has to be as easy as accepting. Your analytics and advertising tags should respond to the consent state rather than firing regardless. Beyond the legal exposure, a store that ignores this ends up with data it cannot use in the markets that matter most.

Expect the gap and stop trying to close it with more tools. Ad blockers, privacy settings, refused consent, apps that open links in their own browser and people moving between devices all remove sessions from your reporting. The share varies by audience and country, and technical audiences hide more than general ones.

Server side tracking helps with reliability, since events are sent from your server rather than the visitor's browser, which makes them less likely to be blocked and gives you control over what is sent. It is not a way around consent, it costs more to build and maintain, and it is worth it for stores at a scale where the data drives significant spend. Below that, a clean browser setup plus honest use of store data is enough.

The practical response is to lean on the numbers that are not affected. Your store admin knows every order. Your ad platforms know every dollar spent. Comparing total spend against total orders and total revenue gives you a picture that no tracking gap can distort, and it becomes the anchor when the detailed reports disagree.

Write the known gaps down so nobody rediscovers them every quarter and calls it a crisis.

Channel reports are only as good as the tags on your links. Untagged links from email, social posts, partner sites and printed codes land in direct or in a vague other bucket, and then nobody can tell what is working.

Tag every link you control. Ads, email campaigns and flows, social posts, affiliate and partner links, links in packaging inserts, and anything in a supplier newsletter. Ad platforms can add tags automatically, and it is worth checking that they do, but the links you place by hand are the ones that get forgotten.

Agree a naming convention and write it in a shared document. Lower case only, no spaces, a fixed list of allowed source and medium values, and a campaign name format that includes the date or season. The convention matters more than the specific choices, because analytics treats different spellings as different channels and a report split across four spellings of the same campaign is useless.

Use the fields for what they mean. The source is where the click came from, the medium is the type of traffic such as email or paid search, and the campaign is the activity. Putting the campaign name in the source field is the most common mistake and it breaks the grouped channel report permanently for that traffic.

Do not tag internal links between pages of your own store. It restarts the session attribution and makes your own navigation look like an acquisition channel.

Keep a simple log of campaign names, so that six months later somebody can tell what a particular tag referred to. A spreadsheet with the date, the campaign, the link and who created it costs nothing and saves an afternoon of guessing every quarter.

Then review the unassigned and direct traffic monthly. A growing direct bucket usually means somebody is publishing untagged links, not that your brand suddenly got famous.

Most analytics setups fail because nobody looks at them. Build four reports, put them where the team already works, and delete everything else from the daily routine.

The first is the funnel: sessions, product views, add to carts, checkouts started and purchases, with the drop between each step. This is the report that tells you which of the four levers to work on this month, and it should be the first thing you look at.

The second is landing page to revenue. Which pages people arrive on, how many sessions each gets, and what those sessions are worth. This is how you choose what to fix and what to promote, and it is far more useful than a report of your most visited pages, because a page can be busy and worthless.

The third is channel performance, with cost included for the paid channels. Sessions, orders, revenue and cost per channel, in one table, for a period you choose. Cost has to be pulled in from the ad platforms since analytics only knows about some of it, and a table that shows revenue without cost will make every channel look good.

The fourth is product performance: views, add to carts, purchases and revenue per product. This drives merchandising, feed priorities and what you photograph next.

Build them once, save them, and give them names people can find. Then set the comparison period deliberately, because the same data compared against last week, last month and the same period last year tells three different stories, and seasonal businesses need the year comparison to avoid panicking every January.

Add annotations for anything that moved the numbers: a sale, a site change, a stock out, an ad budget change. A chart nobody can explain a year later is a chart nobody trusts.

Give each report an owner. A saved report nobody is responsible for stops being maintained the first time a field name changes, and then quietly reports the wrong thing for months.

Every platform claims the sale, and none of them are lying. Ad platforms count conversions they influenced using their own view and click windows, your analytics counts the last channel it could see, and your store admin only knows an order arrived. Three systems, three questions, three answers.

Decide in advance what you use each for. Ad platform numbers are for managing that platform, comparing one campaign against another inside the same account. Your analytics is for comparing channels against each other on a consistent basis. Your store admin is for the truth about how much money came in. Trouble starts when a platform's own figure is used to judge whether the whole business is profitable.

Understand what changing the attribution model does. Switching between last click and a model that spreads credit across the journey moves credit between channels without changing a single order. Channels that assist, such as social and email, gain under distributed models. Channels that close, such as brand search, lose. Neither view is the truth, and picking whichever flatters this month is how stores fool themselves.

The number that no attribution debate can distort is the blended one: all marketing cost against all revenue for the period. Track it every month. When blended performance improves while a platform reports a decline, the platform is measuring less, not performing worse.

When a decision genuinely depends on whether a channel is adding sales rather than recording them, test it. Pause the channel in one region, or hold back a group, and compare total orders. That is more work than reading a report, and it is the only method that answers the question.

And keep the same window everywhere. Comparing a platform reporting on a long window against analytics reporting on a short one produces an argument rather than an insight.

Analytics only pays for itself when it is part of a routine. Set the rhythm, name the owner, and keep the meetings short enough that they actually happen.

Weekly, look at a single page: orders, revenue, spend, blended return, conversion rate and anything that changed sharply. Fifteen minutes. The purpose is to catch breakage, not to plan. Most weeks the answer is that nothing needs doing, and that is a useful answer.

Monthly, go through the four reports properly. Where did the traffic come from, where did people leave, which products moved, what did each channel cost and return. Decide the one or two things to work on next and write them down. Also do the data health checks in this session: compare analytics revenue against the store admin, check the direct bucket, and confirm the key events still fire.

Quarterly, look at cohorts and contribution. Are customers acquired recently worth more or less than a year ago. Is repeat rate moving. What is a customer worth over twelve months and what does that allow you to spend to get one. This is the session where budgets and priorities change.

Keep a written log of changes: site releases, campaign launches, price changes, stock outs, supplier problems. Nearly every strange number in a report has a boring explanation, and the log is where you find it.

And revisit the list of numbers from the first chapter once a year. Stores change, and a metric that mattered when you were starting can become noise. Removing a number from the routine is as valuable as adding one, because attention is the scarce resource in a small team.

If a report has not changed a decision in six months, stop producing it.

Keep the meetings to the agenda. Sessions about numbers expand to fill whatever time they are given, and a long one is usually a sign that nobody has decided which numbers matter.