Google Analytics · Guide

How to Set Up Ecommerce Tracking in GA4

Most shops are told this is already done, because the platform sends some of it automatically. Partial implementation is the normal state and it is worse than none, since the reporting looks complete while quietly omitting the parts you would want to see.

Updated: August 2026
Written by: Andrew Odgers, Managing Director
Reading time: 11 minutes
The state we find most shops in

Your Platform Probably Half Did It

Commerce platforms send some purchase information to analytics without anybody configuring it. That is genuinely useful and it is rarely the whole journey. What you end up with is a property reporting sales confidently while several stages of the process were never recorded at all.

What usually arrives automatically. The ends.

A purchase completing and products being viewed are the parts most often handled out of the box. Those are the easiest to send and the least informative on their own.

What usually does not. The middle.

Baskets, checkout steps and the points where people abandon. Those are precisely the stages that tell you where sales are being lost.

Why partial is worse than nothing. False confidence.

An empty report prompts a question. A report showing revenue and product data invites conclusions. Nothing in it indicates that half the journey is missing.

Who told you it was done. Usually nobody deliberately.

A platform enabled a setting, a developer ticked a box during a build and everybody assumed the rest followed. It is an assumption rather than a claim.

Why this page is marked advanced. It needs a developer.

Little of this is a settings change. Getting it complete is development work. This guide is written so you can brief that work rather than perform it.

Described as stages rather than as code

What Complete Actually Means

A purchase is a sequence and each step should be recorded. Think of it as the journey a customer walks through your shop, since gaps in the middle break the whole view rather than merely omitting one figure.

Seeing a product. The start.

Somebody looking at an item. Without this you cannot tell which products attract attention as distinct from which sell.

Adding to the basket. Intention.

The moment interest becomes intent. This is the single most useful stage after the purchase itself and it is frequently the first one missing.

Beginning and progressing through checkout. The narrow part.

Each step people pass through on the way to paying. Recording these is what lets you see where the process loses people, which is usually the most valuable finding available to a shop.

Completing the purchase. The end.

The order itself with its value and contents. Almost always present, which is why so many shops believe they are covered.

Why gaps break the view. No sequence.

With the middle missing you can see arrivals and sales and nothing about what happened between them. The funnel view, which is the point of all this, does not exist.

What we will not publish. The implementation.

No code, no data layer examples and no event naming. Those belong with your developer and they change, which makes any version printed here a liability.

The problem every shop has

Revenue That Does Not Match The Till

Every online business eventually compares the revenue in analytics against the money it actually received and finds they disagree. Both figures are right about what they measure. Five causes account for nearly all of the difference.

Consent choices. The largest.

A customer declining measurement can complete a purchase that is never recorded. The money arrived and the analytics did not see it.

Blocked scripts. Increasingly ordinary.

Browser settings and extensions that prevent tracking outright. Same outcome, a real sale invisible to the reporting.

Failed pages after payment. The technical one.

If the purchase is recorded when a confirmation page loads and that page does not load, the sale goes unrecorded. Slow connections and closed tabs both produce this.

Refunds not recorded. Inflation.

Reversed sales remaining in the reporting forever, which block seven covers because most shops have never configured it.

Duplicates. The other direction.

One sale counted twice, which is block five. Note that four of these five push the figure down and one pushes it up, so the net error is unpredictable.

What to do about the gap. Measure its shape.

A consistent difference month after month is normal and workable. A difference that jumps about points at a fault worth finding.

The position

Never Report Analytics Revenue As Actual Revenue

The revenue figure in analytics is an approximation of what happened on the website. It is not a record of money received, it does not belong in a financial report and it should never be presented to anybody as turnover.

What it is genuinely for. Comparison.

Which channels, campaigns, pages and periods produced more than others. For that purpose an approximation is entirely adequate, since every figure is wrong in the same direction.

What it is not for. Anything financial.

Accounts, tax, board reporting or anything a bank or accountant will read. Your payment provider and your accounting system are the record of money.

Why this needs stating. It gets used anyway.

The number looks precise, it appears in a Google product and it is available a fortnight before the accounts. That combination is why it ends up in documents it has no business being in.

What happens when it does. An argument.

Somebody notices the mismatch, everybody assumes something is broken and an afternoon disappears into reconciling two figures that were never going to agree.

How to present it properly. Label it.

Call it recorded or observed revenue rather than revenue, on every report. One word prevents most of the trouble.

The same rule elsewhere. Consistent across our work.

We apply this to enquiry values in the conversions guide too, for the same reason.

The fault that flatters

Duplicate Transactions

One sale recorded twice inflates both your order count and your revenue. Unlike every other cause on this page, it pushes the figures up. That makes it the one most likely to go unquestioned, since nobody investigates a report that looks better than expected.

The commonest cause. A reloaded confirmation page.

Somebody refreshes after ordering. Or presses back and forward. Or returns to the page later from their history. Each visit can record the sale again.

The second cause. A shared link.

A customer sending the confirmation page to a partner. Or a page that gets bookmarked. Every subsequent visit adds another order.

The third. Analytics installed twice.

Which doubles everything rather than only sales. It is covered in our installation guide. Worth ruling out first, since it is quick to check and explains everything at once.

How to spot it. Compare order counts.

Not revenue. Count the orders your shop actually processed last month against the orders recorded. Duplicates show up cleanly there.

What fixing it involves. A developer.

The purchase needs recording once per order rather than once per page load, which is an implementation matter rather than a setting.

Why it matters commercially. Decisions get made on it.

An inflated figure makes a channel or campaign look better than it is, so money follows a result that never happened.

Practical

What To Verify Before Trusting Anything

Three checks, in this order. None takes long and together they tell you whether the reporting is worth reading at all, which is worth establishing before anybody builds a strategy on it.

Buy something yourself. A real purchase.

Go through the whole process as a customer, then confirm the order was recorded once, with the right value and the right items. Refund yourself afterwards.

Compare a month of orders. Counts first.

Your actual order count against the recorded one. Recorded higher means duplicates. Recorded lower is normal and worth quantifying so you know the usual shape.

Check the middle stages exist. The funnel.

Look for basket and checkout activity rather than only purchases. If those are absent, you have the partial implementation from block one.

What to do with the result. Write it down.

Note the usual gap between recorded and actual. That single figure turns every future report from a puzzle into something you can interpret.

When to repeat it. After any change.

A theme update, a checkout change, a new payment provider or a platform upgrade can all break this silently.

Where the wider incompleteness sits. The troubleshooting guide.

Why analytics is not tracking data covers sampling, consent and the reasons the data is never complete.

The half nobody configures

Refunds And Cancellations

A refunded order stays in the reporting as a completed sale unless somebody tells the tool otherwise. Most shops have never configured this, so their recorded performance is overstated permanently and gets worse over time.

What it distorts. Everything downstream.

Revenue, average order value, which products appear successful and which channels look profitable. All of it computed on sales that were reversed.

Where it hurts most. High return categories.

Clothing, footwear and anything bought in multiple sizes. A product with a substantial return rate can look like your best performer while contributing far less.

Why nobody notices. The error only grows.

It accumulates quietly rather than appearing as a break. There is no month where the figures suddenly look wrong, so nothing prompts an investigation.

What configuring it involves. Development again.

Your system needs to tell analytics when an order is reversed. That is a job for whoever built the shop and it belongs in the same brief as everything else here.

The alternative if that is not possible. Adjust manually.

Know your return rate and discount the reporting accordingly when making decisions. Cruder and considerably better than ignoring it.

Where the trading side sits. Our ecommerce material.

Reducing returns and improving the shop itself belong there. Everything on this tool sits on the Google Analytics guide.

Partial tracking is worse than none

Your reporting
shows revenue.
It is not the
same as sales.

Most platforms send the beginning and the end of a purchase automatically and leave out the middle, which is exactly where sales are lost. The result is a report that looks complete, invites conclusions and cannot show you where the checkout is failing.

What we check on a shop:

Whether the middle stages exist A real test purchase Recorded orders against actual Duplicates from reloaded pages Analytics installed only once Refunds recorded The usual gap written down Revenue labelled as recorded

If your analytics revenue disagrees with your payment provider, that is expected. If the disagreement jumps about month to month, that is a fault.

The full guide series

Every guide.
One tool.

Getting it installed and configured properly, reading the reports without being misled, measuring outcomes rather than activity, the advanced reporting and what to do when the numbers look wrong.

Questions people ask

Ecommerce Tracking, Briefly

My platform already sends ecommerce data. Do I need to do anything?
Almost certainly yes. Most platforms send some of the purchase journey automatically and rarely all of it, which is the normal state rather than a fault. Partial implementation is worse than none, because the reporting looks complete and quietly omits stages you would want to see.
Why does my analytics revenue not match my actual sales?
Because they are measuring different things. Consent choices and blocked scripts mean some purchases are never recorded, pages that fail after payment go uncounted, refunds are frequently not recorded and duplicates inflate the total. A difference is expected and only a sudden change in it is worth investigating.
What is a duplicate transaction?
One sale recorded more than once. It usually happens when somebody reloads the confirmation page, bookmarks it or shares the link. It can also happen where analytics has been installed twice. It inflates both order counts and revenue, which makes it among the commonest faults on established shops.
How do I check my ecommerce tracking is working?
Make a real purchase yourself and confirm it was recorded once with the right value. Then compare a month of recorded orders against your actual orders and look at the shape of the difference. A consistent gap is normal. An erratic one points at a fault.
Does it record refunds and cancellations?
Only if somebody configured it to, which most shops have not. Without it, a refunded order stays in the reporting as a completed sale forever, so performance is overstated permanently and any product with a high return rate looks better than it is.
Can I use the analytics revenue figure for my accounts?
No. It is an approximation of what was observed on the website rather than a record of money received. It will disagree with your payment provider and your books. Use it to compare periods and channels against each other. Use your accounting system for anything financial.