What is average order value?

Average order value is the mean revenue per order over a period.

Revenue divided by orders is the dominant formula. That settles the shape of the fraction, not the population inside it. Publishers still disagree about which orders count, and one of those twelve divides by customers elsewhere on its own page.

Same formula. Different number.

Average order value, in short. It is the revenue a store took over a period, divided by the orders that produced it. That fraction is the dominant convention, not a universal one, and what goes into it is less settled: three guides strip taxes and shipping out of revenue, one keeps them in, and discounts and returns add further incompatible choices. Write down five choices before comparing: what revenue includes, which orders count, the window, the reporting currency, and whether your tool removed outlier orders for you. Then compare like-for-like windows in your own history. None of the four sets of category ranges read for this page says which revenue definition its figures use.

What is average order value?

It is the revenue a store took over a period, divided by the orders that produced it.

Salesforce puts the whole definition in one line: “AOV = Total Revenue ÷ Number of Orders”.

Twelve of the fifteen publishers behind this page’s sources print that shape.

One of those twelve then prints another denominator on the same page: its FAQ tells readers to “divide your total revenue by the number of customers who have made a purchase over the same period”. Another describes the result loosely, as revenue “per product sale”, while its formula divides by orders.

Do sessions or visitors belong under this number?

Under the dominant convention, no: three publishers use orders and reject sessions or visits. It is not universal — one benchmark page labels its own series per visitor, and one formula publisher divides by customers elsewhere on its own page.

The first is blunt: the number is “calculated by dividing total revenue by the number of orders placed — not by the number of customers or sessions”.

A dashboard tool lists it as a pitfall — “Counting sessions instead of orders: Average Order Value uses orders, not visits.”

The third rules out four things at once: the input is “all the completed, paid transactions that fall within your selected time period — not sessions, not carts, not abandoned checkouts.”

Does every analytics tool even have this metric?

One product’s dimensions-and-metrics reference does not name it. On Google Analytics’ published reference of its available dimensions and metrics, average order value, AOV and basket appear zero times. That check does not establish whether the product reports or calculates the number anywhere else.

The page carries averages based on people or days. “Average revenue per paying user (ARPPU) is the total purchase revenue per active user who made a purchase.” “Average daily revenue” is the average total revenue per day. “Average purchase revenue” names no denominator beyond its window.

Which revenue goes on top?

There is no single agreed numerator. Three publishers exclude taxes and shipping, one includes them and calls that the common choice, and one store platform’s own column uses gross sales less discounts while ignoring post-order adjustments.

The first says to subtract refunds, returns, discounts, shipping and taxes: “Do not include refunds, returns, promotional discounts applied at the order level, shipping costs, or taxes in your net revenue number.”

A second reports it as the common practice: “Most teams exclude taxes, shipping, and refunds so the value reflects what customers actually spend on products.”

A third says “Excluding tax and shipping — usually yes, so AOV reflects product revenue, not pass-through charges.”

The fourth prints the opposite. “Gross AOV: Includes taxes, shipping, and fees (most common)”, and its recommendation is “Choose gross AOV for general business reporting”.

Two pages, two opposite practices, both called the most common. Neither prints a measurement beside that word.

Do discounts come out?

Four publishers say yes, and one of the four says it is optional.

The clearest: “Net of discounts — subtract promo codes and automatic discounts; gross AOV overstates what you actually earn.”

What happens to returns and refunds?

Three incompatible treatments are published: subtract refunded revenue and refunded orders from both halves, ignore post-order adjustments in the numerator, or let the operator decide whether a refunded order still counts.

One publisher shows the first working: “AOV = (80,000 - 16,000) / (1,000 - 150) = 64,000 / 850 = $75.29”.

Its gross reading of the same 30 days is “AOV = 80,000 / 1,000 = $80”.

The gross reading is 6.3% above the refund-adjusted one, in one publisher’s worked illustration, from refunds alone.

What does a store platform actually compute?

A third revenue treatment appears in Shopify’s help centre, which defines the average order value column as gross sales less discounts, divided by the number of orders. Post-order adjustments — edits, exchanges and returns — are excluded from both parts of that numerator. The page does not say whether a reversal adds a record of its own to the order count.

Its term tables print that as “gross sales (excluding adjustments) - discounts (excluding adjustments) / number of orders”, which is unparenthesised: read strictly, division binds first. A note under the same page’s average-order-value report removes the doubt — the metric “is equal to ((gross sales - discounts ) / orders), excluding post-order adjustments such as edits or exchanges” — and works it on ten December orders: “($1000 USD - $200 USD) / 10 = $80 USD”.

Gross sales is “product price x quantity (before taxes, shipping, discounts, and sales reversals)”, and adjustments are “all edits, exchanges, or returns that are made to an order after it’s initially created”.

The same page defines two neighbours. Net sales is “gross sales - discounts - sales reversals”. Total sales is “gross sales - discounts - sales reversals + taxes + duties + shipping charges + fees”.

The column is neither. Unlike net sales it ignores sales reversals; unlike total sales it excludes taxes, duties, shipping and fees.

Why can one company give two answers?

Because Shopify’s blog and its help centre print different formulas for the same admin figure — total revenue over orders on one and gross sales less discounts over orders on the other.

The blog’s version is “AOV = Total Revenue ÷ Number of Orders” and it points at the product — “You can track this metric directly in your Shopify admin under Reports > Customers.”

Total revenue is not a term the documentation defines. Its vocabulary has gross sales, net sales and total sales, and no fourth thing.

What goes wrong when one tool reads another tool’s number?

Klaviyo’s help centre tells readers to divide the store platform’s Total Sales card by its Total Orders card, and warns that returns or cancellations may cause “slight discrepancies”. The store platform’s own documentation carries a separate definitional mismatch: Total Sales adds taxes, duties, shipping charges and fees, and its average order value column does not.

Its ratio is “Total store revenue / total number of orders”.

It then says to “double check your own calculations” against the platform’s own report.

Do cancelled and pending orders count?

Four publishers say no. The platform says yes.

“Only count completed orders (exclude cancelled or fully refunded transactions)”, says one, and another writes it as a database condition — WHERE o.financial_status = 'paid'.

The documentation is explicit the other way: “Pending, unpaid, and canceled orders are included in the reports. Test orders aren’t included.”

Can the order count itself be wrong?

Yes. When custom columns are added to one platform’s sales-over-time report, its CSV export can count each product row as an order; an edit made after the order date can display as a separate order even though no new order exists.

The platform documents both. Add custom columns to a sales report and export it, and “each individual row counts as an order, resulting in a higher number of orders than displayed in the admin”.

Does a return remove the order it reverses?

On Shopify’s documented sales reports, no. The order stays in the count for the date it was placed, and the numerator excludes the post-order adjustment. The page does not state whether the reversal adds a separate order-count record.

Orders are “The number of orders that were placed on a given date.” Reversals are recorded apart: they “display as a negative value for the day that they were processed.”

What period should you use?

Any window, applied consistently. Several publishers describe a monthly cadence, and another recommends either weekly or every 30 days. Four converge on consistency, though not on what must stay consistent — one the window, two the revenue definition, and one that revenue and orders cover identical timeframes.

“AOV can be tracked for any time period, but most companies monitor the moving monthly average”, one writes. Another states the rule that binds: “AOV is only meaningful when you explicitly define your selected time frame and then consistently apply it to your calculation.”

Not every report lets you choose. One customer report is fixed at 365 days and “updates daily”. That report can still be compared across like-for-like 365-day windows with the same revenue definition.

Is this number a mean?

Under the standard formula, yes. When a tool removes orders before calculating it, the result is the mean of the orders left, not of all your orders. Three publishers warn that large orders can make the mean mislead, and they prescribe three different fixes.

“order values are right-skewed, so a few big orders inflate the average”, one writes, and the fix is to “report the median next to the mean”.

A second offers “medians or winsorised averages as a second view”, and a third removes the “outlier orders (like B2B bulk purchases)” instead.

One page slips into a fourth statistic. It defines the metric as total revenue over total orders, then advises twice on the basis of a “modal AOV” — a mode, not a mean, and never defined.

What if your tool removes outliers for you?

Then the figure on your screen is not the mean of all your orders. One platform “excludes outliers (unusually high or low orders)”, so “if most orders are $50–$150, a one-time $1,000 bulk order won’t inflate your average.” No threshold, method or share of orders removed is published, and no way to turn it off appears on that page.

Why does a blended number hide the answer?

Because the segments underneath it are far apart. One vendor’s own example table, labelled “example data”, runs paid social at $38, direct at $55, organic search at $61 and email at $74 — the top channel nearly twice the bottom.

Segment arithmetic is also easy to get wrong. One page computes a $230 average from $276,000 over 1,200 orders, splits out 400 returning-customer orders worth $120,000 for a $300 average, then prints $156 for the remaining 800.

The remaining revenue is $156,000 and the remaining orders are 800, so that figure is $195. Blend $300 and $195 and you get the page’s own $230. Blend $300 and $156 and you get $204.

Where does this number sit in the revenue maths?

In an identity three publishers write the same way. “Sessions × Conversion Rate × AOV = Revenue”, one puts it. Another calls it one of “the three levers of e-commerce revenue — traffic × conversion rate × AOV”.

That also settles the session question. Revenue per visitor is its own metric, the average revenue “generated for each visitor to your website”.

The dominant convention puts orders under this number and visitors under revenue per visitor.

Does raising it always help?

Not by itself. Five publishers name the same trade-off, and it runs through conversion.

“Optimizing for AOV at the expense of conversion rate - aggressive upsells can increase AOV but reduce the percentage of visitors who buy.”

The leverage is real when it holds. “A $10 increase on 50,000 yearly orders adds $500,000 in sales”, one page prices it, and adds “before considering margin” in the same sentence.

Where should you set a free-shipping threshold?

Nobody has shown their working, and four publishers answer anyway. One says 15-20% above your current figure. One says “roughly 30% above your current AOV” and calls it “the sweet spot”. One says just above. One works an example from $45 to $50. None of the four prints a source, a test or a sample beside the number.

Can you trust a published benchmark?

Not without its scope and its numerator. Of four category-band pages, one names no source and one gives only a generic attribution. A third links its figures to the fourth, a vendor benchmark that says its data is aggregated across its own customer base, “200M monthly unique users collected over 300M total sessions”, over the past twelve months. None ties its figures to a numerator. Shopify gives an order-value example including shipping. count.co describes gross and net variants. Neither says which produced its bands.

The bands disagree too: fashion runs $80-150, $50-$150 and $40 to $170, electronics $150-300 against $200-$500.

The one that does cite links its three figures to the benchmark page in the next section. The best-documented set is the exception that proves the point. It publishes its calculation as “Revenue ÷ Orders” and its data as “calculated directly from operational trading data”, and it still never defines revenue.

Does a benchmark citation stay true?

Not on its own. A rolling benchmark can change after a page cites it, and the citing page does not change with it.

One benchmark page reads “The average order value globally is $192”. A page citing that exact URL says “the global AOV is approximately $145 across all industries”.

The benchmark page’s figure is 32% above the one quoted from it. The citing page carries an update stamp of September 2025 and the cited figure rolls twelve months, so it may have been right when written.

The cited page has its own problem. It prints eight month-over-month falls above 100% — one reads “fell by 141% in average order value, from $530 in June to $92 in July” — on pairs of positive dollar values. From $530 to $92 is a fall of 82.6%.

What should you check before comparing your number to anyone else’s?

Check five things: what revenue includes; which orders are counted; whether both sides use the same window; whether revenue is in one reporting currency; and whether the tool removed outliers for you.

What is inside revenue. Taxes and shipping split the guidance two ways — three pages exclude them, one includes them — and discounts and returns add further incompatible choices.

Which orders are in the count. Cancelled, pending and unpaid orders are out for four publishers and in on the platform that ships the figure.

What the window is, on both sides. Seven days against thirty is not a comparison, and one customer report fixes the window at 365 days.

What currency the revenue is in. Two publishers say to convert revenue into one reporting currency before dividing; neither says which rate or which date.

Whether anything was removed for you. One platform says it excludes outlier orders and publishes no rule for it.

The checklist assumes one-off orders. None of the sources read for this page says whether a subscription renewal counts as an order.

Where does that leave the metric?

Worth computing, and worth writing down what you computed.

Revenue over orders is the dominant convention rather than a universal one: one of the twelve formula publishers divides by customers elsewhere on its own page, and one benchmark page labels its series per visitor. What goes into the fraction is less settled again, and that disagreement runs inside single companies — between a help centre and a blog, and between a tool and the platform it reads from.

Compute it, record the five choices, and compare like-for-like windows in your own history — not a band that never tied its figures to a numerator.

Here, the numerator is the argument.