October 4, 2026 · 3 min read

The Average Lies: Mean vs. Median on Skewed Metrics

Average revenue per user is up 40% — because one whale landed. On skewed metrics the mean is a hostage to the tail; here is when to trust the median instead.

"Average revenue per user is up 40% this month." The team celebrates — until someone notices that one enterprise deal explains the entire jump, and the typical customer pays exactly what they paid last month. The mean did not lie, exactly. It answered a question nobody asked: what would each user pay if the total were spread evenly? On skewed metrics, that question is a trap.

Revenue, latency, deal size, session length, order value — most business metrics skew right. A long tail of large values drags the mean upward while the bulk of observations sits well below it. Knowing which "average" to report is one of the cheapest analytical upgrades you can make.

The Rule in One Picture

Take ten response times in milliseconds: 40, 45, 48, 50, 52, 55, 58, 61, 70, 900. The mean is 138 ms. The median is 53 ms. Nine out of ten users experienced something close to the median; nobody experienced anything close to the mean. The mean describes the tail; the median describes the typical case.

The gap between the two is the skew detector. When mean and median nearly agree, the distribution is roughly symmetric and either summary works. When they diverge, the distribution is skewed and you must choose deliberately:

  • Mean above median — right skew (revenue, latency, order value). The tail pulls up.
  • Mean below median — left skew (test scores near a ceiling, uptime percentages). The tail pulls down.
  • Mean far from median — the mean is mostly a statement about outliers. Pair any mean with an outlier check before quoting it.

Which One to Report

Report the number that matches the decision. If you are capacity-planning servers, you care about total load — the mean (equivalently, the sum) is the right input, because every millisecond in the tail consumes real resources. If you are describing user experience, the median answers "what does a typical user feel?" If you are setting a sales target from historical deal sizes, the median tells a rep what a normal deal looks like; the mean tells them what the founder's whale deal looks like.

The honest default: report both, plus the sample size. "Median order value $48, mean $71, n = 12,400" fits in one line and lets every reader pick the right number. A single average with no companion statistic is where deception — usually accidental — begins.

Trimmed Means: The Compromise

Sometimes neither extreme satisfies: the median ignores the tail entirely, the mean is dominated by it. A trimmed mean discards a fixed share of the smallest and largest values (commonly 5–10% from each end) and averages the rest. Sports judging panels do this by instinct when they drop the highest and lowest scores.

A trimmed mean is a good headline metric for dashboards that must be both stable week-to-week and sensitive to genuine shifts. Just state the trim percentage next to the number — "10% trimmed mean" — so the metric is reproducible. Anything fancier (see winsorization for the gentler cousin) belongs in the methodology note, not the headline.

What to Do This Week

Open your most-quoted dashboard metric and compute its median alongside the mean. If they differ by more than about 20%, you have been reporting the tail as if it were the typical — rewrite the headline, add both numbers, and watch how many "surprising" movements turn out to be one tail observation arriving or leaving. In KPI Master, numeric summaries show mean, median and spread together for exactly this reason: the interesting story is usually in the gap between them.