Ecommerce Analytics: Margin, Not Revenue

Most ecommerce analytics setups measure traffic in detail and revenue badly. The reason is that the standard tools were built to analyse sessions, and a store cares about orders, customers and margin, which are not the same objects.

So the reports are full of numbers that are technically correct and do not answer a business question. Here is what actually matters and where the usual setup misleads.

The numbers that decide things

Revenue per session. Conversion rate on its own is misleading, because a change that pushes everyone toward the cheapest item improves it while taking less money. Revenue per session catches that.

Contribution margin, not revenue. Revenue by channel is the most commonly reported and least useful figure in ecommerce. A channel selling high-margin items at a low acquisition cost and one selling low-margin items with free returns can report identical revenue while one funds the business and the other drains it. If your analytics does not know cost of goods, shipping cost and refund rate, it cannot tell you which channel to spend more on, which is the question you are asking it.

Repeat rate and time to second order. The second purchase is the one that predicts a customer's value, and the gap before it tells you when a reminder is worth sending. Both are order-level facts that session analytics cannot see.

Returns and refunds by product. A product with strong sales and a high return rate is losing money twice, and it looks like a winner in every standard report.

Stock availability at the moment of the visit. Traffic to out-of-stock products is a category of loss nobody measures. It is not a conversion problem, and it shows up as one.

Where standard setups mislead

Last-click attribution. Credits the final touch, which is usually a branded search or an email to somebody who had already decided. This systematically overvalues the bottom of the funnel and undervalues whatever created the demand, and budgets get moved accordingly.

Browser-side tracking that does not fire. Ad blockers, consent refusals, network failures, single-page apps that forget to fire on route changes. Client-side ecommerce tracking commonly undercounts, and it undercounts unevenly across audiences, which is worse than undercounting consistently.

Sessions that are not people. A customer on a phone at lunch and a laptop that evening is two sessions and one person. Anything cohort-shaped built on sessions is wrong at the edges.

Refunds that never get subtracted. Most setups record the purchase and never the refund, so reported revenue is gross and the reports drift from the accounts over time.

The thing that fixes most of it

Treat your own order database as the source of truth for money, and analytics as the source of truth for behaviour.

Revenue, margin, refunds, repeat rate and customer value come from your orders, where they are exact and already net of everything. Pageviews, sources, search terms and on-site behaviour come from analytics, where a small inaccuracy does not matter.

This sounds obvious and is not what most stores do. Most stores read revenue out of a tool that is missing a share of it, then wonder why the dashboard and the bank do not agree.

The practical version: send purchase events from your server rather than only from the browser, so an ad blocker cannot remove an order that definitely happened, and keep an order identifier on the event so the two systems can be joined later.

A reporting set that is enough

Most stores need far less than they build.

Weekly: orders, revenue, average order value, refund rate. A single line each, watched for movement rather than admired.

Monthly: contribution margin by channel, repeat rate by acquisition month, top products by margin rather than by units, and returns by product.

On demand: the funnel, when something has moved and you want to know where.

That is a page. Beyond it, most dashboards are decoration, and a dashboard nobody acts on is a cost rather than an asset.

Where we fit, and where we do not

The order data is the part we hold, and it is queryable: orders with line-level detail, refunds as their own records, customers with their full history, and stock at the time of the order, all over the same API. Which means margin and cohort reporting are a query rather than an export, and server-side purchase events are something your code emits from a source that cannot be blocked.

Where we are the wrong answer: we are not an analytics product. We do not do attribution modelling, session recording, funnels or heatmaps, and dedicated tools do all of that well. If you want a dashboard rather than an API, buy one. This is about which system you trust for which number.

The short version

Money questions go to your order data. Behaviour questions go to analytics. Report margin rather than revenue, watch revenue per session rather than conversion rate, and subtract refunds.

If you want to see what the order and customer endpoints expose for reporting, the docs have them.