AOV explained simply
Contents:
Why AOV matters
Average Order Value (AOV) is the smallest e-commerce metric that still moves revenue on its own. It sits inside the identity Revenue = Traffic x Conversion Rate x AOV, which means a 10% lift in AOV is a 10% lift in revenue with no extra ad spend, no extra sessions, no extra checkout fixes. That is why every growth review at Amazon, Shopify, DoorDash and Stripe-powered storefronts starts with the AOV chart before anyone touches the funnel.
The other reason it matters is the interview reason. Junior and mid analyst loops at retail and marketplace companies — Uber Eats, Wayfair, Etsy, Glovo-style apps — almost always include the AOV question. The interviewer is not testing whether you can divide revenue by orders. They are testing whether you know the metric lies when the basket distribution is fat-tailed, and whether you reach for the median without being prompted. Most candidates do not. That is the gap this post closes.
Roadmap:
- The one-line formula, with a worked example that shows how 10 whales move the number
- Why mean, median and P95 belong in the same dashboard
- A concrete CAC payback constraint AOV gives you
- Segmentation cuts that change pricing and merchandising decisions
- The five mistakes that get caught in interview follow-ups
The formula and a worked example
AOV = Total Revenue / Number of Orders
Read it out loud: the average amount a customer spends in a single order over the chosen window. Pick a window — day, week, month, quarter — and stick to it across the dashboard. AOV without a window is a vibe, not a metric.
Worked example. A mid-size apparel shop closed 1,000 orders in March for $50,000 in gross revenue.
- AOV = 50,000 / 1,000 = $50
Now the trap. Suppose 10 wholesale customers each placed a $2,000 order in the same month. Add them in:
- New revenue = 50,000 + 20,000 = $70,000
- New orders = 1,010
- New AOV = 70,000 / 1,010 ≈ $69.31
Ten orders just moved the headline number by +39% while the experience of the typical buyer did not change at all. This is the single most important intuition in the post. If you remember nothing else, remember that the mean is hostage to the tail.
Load-bearing trick: always publish AOV alongside median order value and a tail percentile (P95 or P99). One number alone is a marketing slide, not analysis.
Mean vs median vs P95
Pretend you pulled the order table and ran three aggregations on the same March window:
| Statistic | Value | What it answers |
|---|---|---|
| Mean (AOV) | $69 | Total dollars divided by order count |
| Median | $32 | The middle order — what 50% of buyers spend below |
| P95 | $180 | The cutoff that 5% of orders exceed |
| Max | $2,000 | The whale that drags the mean |
A gap of $69 mean vs $32 median is not a rounding error. It is a structural signal: a handful of large orders are inflating the headline. The right merchandising response is not "raise prices" — the typical shopper already buys at $32. The right response is to either segment the whales out and report two AOVs, or to design promotions for the $25-$45 band where most of the volume lives.
In practice this is why daily snapshots and percentile rollups beat a single monthly mean for fast-moving SMB books. You see the tail forming in week 1 and you decide whether to report it separately before the month closes.
How to lift AOV without burning margin
There are five plays that actually move AOV in production. None of them are clever, all of them require discipline.
Cross-sell on the product detail page. "Frequently bought together" beats "you may also like" by a wide margin because the algorithm is anchored to revealed co-purchase behavior, not vibes. Amazon's PDP cross-sell module has been the highest-AOV-lifting surface on the site for over a decade. Even a heuristic SQL implementation — top 3 items by co-occurrence in the same order over the last 90 days — typically beats nothing by 5-12% on basket size.
Upsell at the configuration step. A $39 plan with a one-click "+$10 for the pro tier" tile inside the cart drawer is the classic Stripe checkout pattern. The conversion lift on the upsell tile usually sits in the 8-15% range when the price gap is under 30% of the base price.
Bundles that hide a discount. A two-product bundle priced at the sum minus 10% is read by the shopper as a discount but lands as a larger absolute basket. The margin trade-off is real and you should model it: bundle margin = (revenue - cost) / revenue should not drop below your contribution-margin floor.
Free shipping threshold. "Free shipping over $50" is the single highest-leverage AOV lever in apparel and home goods. The trick is to set the threshold at roughly 1.3x to 1.5x your current median basket, not your AOV. If you anchor on the inflated mean, the threshold sits above what most buyers will stretch to.
Quantity discounts. "Buy 2 save 15%" works on consumables and gift categories, fails on considered purchases. Use it where the repeat-purchase cycle is short.
Sanity check: every AOV play has to clear a margin floor. A bundle that lifts AOV 20% while cutting contribution margin from 35% to 22% is a worse business than the baseline. Always model contribution margin alongside AOV.
AOV and the marketing budget
AOV is also the constraint on how much you can pay to acquire a customer. The breakeven CAC identity:
CAC_breakeven = AOV x contribution_margin x expected_orders_per_customerPlug in the apparel shop above. AOV $50, contribution margin 30%, expected orders per customer over 12 months = 2.
- CAC_breakeven = 50 x 0.30 x 2 = $30
You cannot pay more than $30 to acquire an average customer without burning cash on that cohort. That single line should sit on the wall of every paid acquisition team. If a channel's CAC is $45, either AOV has to rise, margin has to rise, or repeat rate has to rise — or you stop spending on that channel.
This is the lever that connects merchandising to performance marketing. A cross-sell module that lifts AOV from $50 to $58 also lifts CAC_breakeven from $30 to $34.80, unlocking a chunk of paid inventory that was previously unprofitable. Growth teams that don't connect these two dashboards leave money on the table.
Segmentation that actually changes decisions
Aggregate AOV is a vanity number. The cuts that change decisions:
| Segment | Why it matters |
|---|---|
| New vs returning | Returning AOV is usually 1.4x-2.1x new — fund retention |
| Channel | Paid social AOV often under organic AOV — adjust bids |
| Category | Home goods AOV vs apparel AOV are different businesses |
| Device | Mobile AOV is typically 15-25% below desktop |
| Cohort | First-month vs month-6 reveals merchandising decay |
| Geography | DMA-level AOV exposes pricing-power gaps |
The new-vs-returning cut almost always justifies a retention budget. If returning customers spend $70 while new spend $42, the per-order economics of a loyalty program at, say, $5 per redemption is trivially positive — you are paying $5 to convert a $42 buyer into a $70 buyer.
The mobile-vs-desktop cut almost always exposes a checkout problem. Mobile baskets are smaller partly because of intent (browse-on-phone, buy-on-laptop) but mostly because the checkout flow is harder on a 5-inch screen. The fix is rarely a discount — it is a one-page checkout and Apple Pay.
Common pitfalls
The most common mistake is shipping AOV alone with no companion statistic. A single number gives the reader no way to detect that the distribution is fat-tailed. Whenever you publish AOV, publish median and P95 in the same module. If your BI tool makes that hard, the BI tool is wrong, not the metric.
A second trap is not filtering by order status. Cancelled, refunded and chargebacked orders should not be in the denominator and their revenue should not be in the numerator. A sloppy SELECT SUM(amount) / COUNT(*) FROM orders over a raw table almost always over-counts both sides and produces a number that quietly disagrees with finance. Always filter to status = 'paid' (or your shop's equivalent) and net out refunds in the revenue column.
A third trap is confusing AOV with ARPU. AOV is per order. ARPU is per user. If a customer places three orders in the window, AOV sees three data points and ARPU sees one. A retention-led business should be tracking ARPU as the headline and AOV as a supporting metric — the inverse is true for one-shot purchase categories like furniture. Mixing the two on the same dashboard without labels is the fastest way to get a PM to make the wrong call.
A fourth trap is mixing B2B and B2C orders in the same aggregation. A B2B wholesale order on a marketplace platform can be 50x to 200x the size of a consumer order. A single B2B order in the denominator-of-one position drags the monthly AOV upward by hundreds of dollars and tells you nothing about the consumer experience. Split the report or filter the segment — never average across customer types.
A fifth trap is not stripping outliers when the business owner asks "what is a typical order". The honest answer there is the median, not the mean, but if you have to report a mean, winsorize at P99 first. Cutting the top 1% before averaging produces a number that is far more representative of the customer experience without hiding the tail (which still appears in P95 and P99 columns).
Related reading
- How to calculate AOV in SQL
- ARPU explained simply
- Median vs mean
- CAC explained simply
- How to calculate GMV in SQL
If you want to drill metric questions like this every day, NAILDD is launching with 500+ analyst interview problems across exactly this pattern — formula, edge cases, follow-ups.
FAQ
What window should I use for AOV?
It depends on the business cadence. For high-velocity e-commerce — apparel, beauty, food delivery — a rolling 7-day or 28-day window smooths daily noise while staying responsive to merchandising changes. For considered-purchase categories like furniture or appliances, 90 days is the floor because order frequency is low and a 7-day window is mostly noise. Whatever window you pick, hold it constant across the dashboard so week-over-week comparisons are apples to apples.
How is AOV different from ARPU?
AOV is revenue divided by orders. ARPU is revenue divided by users (or paying users for ARPPU). If a customer places three orders in the month, that customer contributes three rows to AOV's denominator and one row to ARPU's. For a category with high repeat rates — coffee, pet food, subscriptions — ARPU is typically the more honest headline. For one-shot categories like wedding registries or mattresses, AOV is the better choice. Showing both on the same dashboard is fine as long as they are labeled clearly.
What is a "good" AOV?
There is no universal benchmark — the number is a function of category, not company skill. Food delivery sits roughly in the $25-$40 range. Apparel ranges from $45 to $120 depending on price tier. Consumer electronics can clear $300. Luxury and B2B wholesale sit at $1,000+. The right question is not "is my AOV good?" but "is my AOV trending in the right direction at constant traffic mix, and does it clear the CAC payback constraint?"
Should I optimize for AOV or for purchase frequency?
That is a category-level question. Subscription and delivery businesses live and die on frequency — DoorDash does not need a $200 burrito, it needs you to order three times a week. Considered-purchase and luxury businesses live on AOV — Tesla does not need you to buy three cars a year, they need each car to clear a high basket. Run the unit-economics math both ways and pick the lever with higher elasticity for your category.
Why does my AOV jump around week to week?
Two main causes. First, whale orders: one B2B or wholesale buyer in a small week dominates the mean — fix this by reporting median and segmenting the wholesale channel out. Second, promotion timing: a sitewide discount lowers AOV by definition because the same baskets ring through at a lower price. Both are statistical artifacts, not real business signals. If you cannot tell which one is driving the swing, plot the order-size histogram for the two weeks side by side — the picture answers it in five seconds.
Can I A/B test AOV directly?
Yes, but with one caveat. AOV has higher variance than conversion rate, which means you usually need 2x to 4x the sample size of a conversion test to detect the same relative lift. Pre-compute the required sample size with a power analysis, and use variance-reduction tricks like CUPED if your platform supports them. Otherwise a real lift will sit inside the confidence interval and you will ship nothing.