Tags: analytics commerce concept
Revenue Metrics
Date: 2026-08-16
Six decisions sit between an order and a revenue figure — tax, shipping, discounts, refunds, currency and timing — and analytics tools default differently on every one. That’s why your number never matches finance’s.
What it is
Revenue metrics are any figure derived from order value. The complication is that “order value” isn’t one number.
list price £30.00
− discount −£5.00
───────
net goods £25.00
+ shipping £3.99
+ VAT @ 20% £5.80
───────
customer paid £34.79
− refunds later −£0.00
───────
recognised £34.79
Which of those is “revenue”? Analytics tools usually take gross including tax and shipping. Finance usually recognises net of VAT and refunds. Both are right for their purpose, and neither will match the other.
The six decisions
Settle each explicitly, in the metric definition:
| Decision | Options | Common default |
|---|---|---|
| Tax | Include or exclude VAT | Analytics includes; finance excludes |
| Shipping | Include or exclude | Analytics includes |
| Discounts | Gross or net of promotions | Usually net, but codes applied at basket level often aren’t reflected per item |
| Refunds | Deducted, or ignored | Usually ignored in analytics — revenue only goes up |
| Currency | Transaction, or converted; which rate, which date | Rarely thought about until multi-market |
| Timing | Order placed, or dispatched, or payment settled | Analytics uses placed; finance may use dispatched |
Refunds are the big one. Most implementations never fire a refund event, so analytics revenue is permanently overstated by the return rate — which in some retail categories is substantial. See Return Rate and Reverse Logistics.
The 100× error
The most common ecommerce tracking bug, and worth its own mention:
Shopify and most commerce APIs store 2400 (pence)
The ecommerce schema expects 24.00 (decimal)
Pass the subunit value and revenue is 100× too high. It’s usually caught quickly because it’s absurd — but the same mistake at £1.00 versus 100p passes review. Always check the magnitude of a revenue figure against a known order — Ecommerce Event Schema.
Multi-currency
Three separate questions, and tools conflate them:
- What did the customer pay? In their currency. The only figure that’s a fact
- What’s that worth in reporting currency? Needs a rate and a date. The tool’s rate and yours will differ
- Which rate applies to a refund three weeks later?
For a single-market UK retailer none of this matters. For anyone selling in more than one currency, store the transaction currency and amount as collected, and convert at query time with a rate table you control — never rely on the tool’s conversion, which you can’t audit or restate.
Derived metrics inherit everything
Every metric built on revenue inherits all six decisions:
- Revenue per visitor — plus the User Counting problem in the denominator
- Average order value — plus the fact that AOV is heavily skewed, so the mean misleads. Report the median alongside — Skewed and Heavy-Tailed Distributions
- Lifetime value — plus identity, plus a time horizon — Customer Lifetime Value
- Return on ad spend — plus Attribution Models, which is a larger source of variance than any of this
And none of them are margin. Revenue rising while contribution margin falls is entirely possible, and common with discounting — Contribution Margin, Discount Impact on Margin.
Reconciling
Do it monthly, and expect a gap:
1 align the period and the timezone first — most of the
apparent gap is date boundaries
2 agree the definition — tax, shipping, refunds
3 what remains is tracking loss: consent, blockers,
delivery failure
4 record the residual as a known factor, and watch it
A stable gap is a correction you can explain. A moving one is an incident — Guide - Auditing a Tracking Plan, Tool Discrepancies.