Mean vs Median: When to Use Each, and When the Answer Changes

1. What each average is, built from the same sixteen numbers

Before the definitions: if I paid every one of these sixteen orders the same amount, and the total still had to come to 9,890, what would each order be worth? Say the number before reading on.

You just computed the mean. The mean is the total shared out equally: add everything up, divide by how many there are. 9,890 ÷ 16 = 618.125. It answers "if these were all the same, what would each one be", which is why it is the average that budgets and forecasts use. Multiply it back by the count and you get the total again, exactly.

The median is built a completely different way. Sort the values smallest to largest, then take the one in the middle. Half the values are below it and half above. It answers "what does a typical one look like", and it does not care what the extreme values actually are, only that they are on one side or the other.

Both are honest summaries. Neither is a simplified version of the other. They are answers to two different questions, and the whole skill is knowing which question you are being asked.

2. Computing both by hand, so the arithmetic is not a black box

Before the walkthrough: the table has sixteen orders, an even number. There is no single middle value. Decide what you would do about that before I say.

Here are the sixteen revenues, sorted smallest to largest.

240  280  425  440  440  480  510  600  660  660  680  765  850  880  880  1100

The mean is the easy one. Add them: 240 + 280 + 425 + 440 + 440 + 480 + 510 + 600 + 660 + 660 + 680 + 765 + 850 + 880 + 880 + 1100 = 9,890. Divide by 16: 618.125.

For the median, count in from both ends. Sixteen values means the middle falls between the 8th and the 9th. The 8th is 600 and the 9th is 660, so the median is their average: (600 + 660) ÷ 2 = 630. With an odd count you would simply take the one in the middle and there would be no averaging step at all.

Here they are in the three tools an analyst actually has open.

-- SQL
SELECT AVG(Revenue) AS mean_revenue,
       MEDIAN(Revenue) AS median_revenue   -- PERCENTILE_CONT(0.5) on Postgres
FROM Orders;

# pandas
df['Revenue'].mean()      # 618.125
df['Revenue'].median()    # 630.0

' Excel
=AVERAGE(Orders[Revenue])   ' 618.125
=MEDIAN(Orders[Revenue])    ' 630

On this table the two are 30 apart, about 5 percent. That is close, and closeness is itself a finding: it says the values are spread fairly evenly rather than piled up at one end. If you want the SQL version of the median in more depth, it is one specific percentile, and percentiles, the IQR and outliers covers how percentiles get computed and why two tools can disagree on them.

3. One typo, and what it does to each

Before the numbers: order 1013 is 15 lamps at 40 each. Somebody keys it as 150 lamps instead of 15. The revenue on that row goes from 600 to 6,000. Guess how far each average moves before you read on.

Here is what actually happens.

The mean moved by 337.50 because it is built from the total, and the total moved by 5,400. Spread that error across 16 orders and each one picks up 5,400 ÷ 16 = 337.50 of it. That is not a coincidence, it is the definition: every value gets an equal say in the mean, so a value that is ten times too big brings ten times too much weight with it.

The median moved by 30, and only because the sorted order changed. Before the typo, positions 8 and 9 held 600 and 660. Moving that 600 up to 6,000 sends it to the end of the queue, so everything after it shuffles up one place. Positions 8 and 9 now hold 660 and 660, and the median becomes 660. The median never asked how big the moved value was. It only asked which side of the middle it landed on.

Say out loud why the median would give exactly the same answer, 660, if that row had been keyed as 6,000 or 600,000. It is the hinge of this whole page: the median counts positions, the mean weighs sizes.

The name for this property is robustness, and it has a number attached. You could corrupt up to half the values in this table, any way you liked, and the median would still land somewhere inside the range of the honest half. Corrupt one value in the mean and the mean can be dragged anywhere at all. That is why a median shows up in every summary of house prices and salaries you have ever read.

4. The question that picks between them

Before the rule: you are asked "how much does an order bring in?" by two different people. Finance is planning next quarter's revenue. A sales rep wants to know what a normal order looks like. Decide whether they need the same number.

They do not, and the reason is what makes this choosable rather than a matter of taste.

Use the mean when the total matters. Anything that gets multiplied back out by a count: revenue forecasts, capacity planning, budgets, cost per unit. If 400 orders are expected next quarter, 400 × 618.125 = 247,250 is a real prediction of the total. Do that with the median and you get 400 × 630 = 252,000, which corresponds to nothing. The mean is the only average that reconstructs the total, and that is its job.

Use the median when a typical case matters. Anything a person will compare themselves to, or any figure where a handful of huge values are real but not representative: salaries, house prices, time to resolve a ticket, session length, order value in a business with a few enormous accounts. "Half our orders are under 630" is a sentence a sales rep can use. "Our average order is 618.125" is one they will quietly disbelieve if they have never seen an order that size.

The two-sentence rule I actually use: if the number is going to be multiplied by a count, report the mean. If somebody is going to picture one case, report the median. When you cannot tell which, report both, because the pair is more informative than either alone and costs one extra cell.

Now picture the last summary table you sent to someone. Which of its averages would have been better as a median, and which would have broken a total if you had switched it? That distinction is the whole page.

5. The ranking that flips: East against South

Before the table: four regions, and you are asked which one has the strongest orders. Predict whether the mean and the median put the same region on top.

They do not. Here are both, per region, on the clean data.

By mean order, East wins at 760 and South is second at 667.50. By median order, South wins at 755 and East is second at 670. The top spot changes hands depending on which average you print, and neither table is wrong.

The reason is visible in the rows. East's four orders are 660, 680, 1100 and 600. One of them, the 1,100 desk order, is well above the others, and it lifts the mean without touching the middle. South's four are 850, 660, 280 and 880: three of them are large and one is small, so the middle sits high while the low one drags the mean down. East has one big order. South has one small one. The averages disagree because they are reading different features of the same four numbers.

This is the practical case for shipping both, and for shipping the count beside them. Four orders is not enough to rank anything, and a ranking built on four values will reorder itself the moment a fifth arrives. The same warning applies to any grouped average, which is why GROUP BY and HAVING insists on a size column next to every group statistic.

6. Mode, the third average, and the one job it has

Before the definition: which single number appears most often anywhere in this table? It is not in the Revenue column.

It is 220, the desk unit price, appearing on 7 of the 16 rows. The mode is the most common value, and unlike the other two it works on things that are not numbers at all. The modal region here is North with 5 orders. The modal product is Desk, on 7 rows against Chair's 5 and Lamp's 4. You cannot take a mean of "North", but you can absolutely take a mode of it.

That is the mode's real job: it is the only average that works on categories. For continuous numbers it is close to useless, because with enough decimal places every value is unique and the mode becomes whichever value happened to repeat by accident. On the Revenue column here the mode is 440 and 660 and 880, all tied at two appearances each, which tells you nothing at all.

Report a mode when the question is "which one is most common", and stop there. The rest of the time it is a curiosity.

7. The trimmed mean, and the middles in between

Before the idea: the mean uses every value and breaks when one is wrong. The median uses one position and ignores everything else. Ask yourself whether there is something in between, before I show you there is.

There is, and it is called the trimmed mean. Cut off a fixed percentage from each end of the sorted list, then take an ordinary mean of what is left. On our sixteen orders, a 10 percent trim drops the lowest value and the highest, so 240 and 1,100 go, and the mean of the remaining fourteen is 8,550 ÷ 14 = 610.71. Close to the median's 630 and close to the mean's 618.125, because this data has no real extremes to trim.

# pandas has no built-in; scipy does
from scipy import stats
stats.trim_mean(df['Revenue'], 0.10)     # 610.714...

' Excel
=TRIMMEAN(Orders[Revenue], 0.2)          ' 0.2 = 10% off each end

Watch the argument. Excel's TRIMMEAN takes the total proportion to remove and splits it across both ends, so 0.2 means 10 percent from each side. scipy's trim_mean takes the proportion for each end, so the same trim is 0.10. Two libraries, two conventions, one very easy way to trim twice as much as you meant.

The trimmed mean is what Olympic judging does when it drops the high and low score, and it is a reasonable default when you know the extremes are noise rather than signal. The catch is that trimming is a decision you have to justify, and a number that quietly excludes the top 10 percent of your customers is a number that needs a footnote. My own rule: use it when the extremes are known measurement errors, and use the median when the extremes are real but not representative.

Edge cases that catch people out

Six that each cost somebody an afternoon.

Averaging an average. The mean of the four regional means is (760 + 667.50 + 561.67 + 499) ÷ 4 = 622.04, and the true mean order is 618.125. They differ because the regions have different order counts, and a plain average treats a 3-order region as equal to a 5-order one. If you must combine group averages, weight them by their counts, or go back to the raw rows.

Averaging a percentage or a rate. The same trap with sharper teeth. The average of two conversion rates is not the overall conversion rate unless both had the same traffic. Add the numerators, add the denominators, then divide once.

Blanks are not zeros. AVERAGE in Excel and mean() in pandas skip empty cells, so a column that is a quarter blank is averaging the three quarters that answered. If those blanks mean "no sale", they are zeros and they belong in the denominator, and the answer changes a lot. Deciding which is which is the subject of handling missing values.

The median of an even count is not in your data. Our 630 is not any order's revenue. It is the average of two of them. Nobody is harmed by this until someone tries to look up "the median order" as a row and cannot find it.

SQL does not agree with itself on MEDIAN. DuckDB, Oracle and Snowflake have a MEDIAN function. Postgres and standard SQL do not, and want PERCENTILE_CONT(0.5) WITHIN GROUP (ORDER BY Revenue). SQL Server wants PERCENTILE_CONT(0.5) WITHIN GROUP (ORDER BY Revenue) OVER (), which returns one row per input row rather than one row overall. MySQL before version 8 has none of these.

A mean with no count beside it. This is the one I would put on a poster. "Average order 618" reads identically whether it rests on 16 orders or 16,000, and the two deserve very different amounts of trust.