Mean

People can't hold a list of numbers in their head all at once. If last week's payments run $23, $9, $6, $35 and on like that for 200 lines, the list contains every fact without a single omission and still fails to answer the question anyone actually asks: how much does a customer spend at a time?

So the meeting stalls in the same place every week. One person says payments have been running high lately, another says they saw plenty of $6 charges, and both are quoting real numbers from the same file without reaching a conclusion. They were reading different stretches of the list. Without one number to anchor on, the same data supports two different stories.

The mean is the oldest and simplest way to compress those 200 lines into one. Every value counts exactly once toward a single number, and the conversation starts from there. The price is that compressing throws information away. Whether those 200 lines clustered near $18 or split between a few dollars and a few hundred is not something the mean can tell you.

Add every value, then divide by how many values there were. Payments of $23, $9, $6 and $35 sum to $73 across four charges, so the mean is $18.25.

The calculation has three steps.

1. Decide what goes in. This is where it goes wrong most often. Settle in advance whether refunded charges count, and whether test payments from internal staff accounts come out.
2. Add the values up. Decide how missing values are handled at the same time. Scoring a survey question as 0 for people who skipped it pulls the mean down; dropping them gives you the mean among people who answered. Those are two different numbers, so write down which one you took before anyone builds on it.
3. Divide by the count. The divisor has to match what you added. Sum payment amounts and divide by users, and you no longer have the mean payment — you have spend per user.

When items carry different weight, use a weighted mean. Averaging the mean of 900 self-serve customers with the mean of 20 enterprise accounts and dividing by two gives those 20 accounts the same pull as the 900. Multiply each group's mean by its headcount, add those, and divide by the total headcount.

There's no such thing as a high or low mean in the abstract. The question isn't the size of the number but whether this mean can stand in for the group at all. Three conditions decide it.

First, no values sitting far off to one side. Five response times of 0.3, 0.4, 0.3, 6.2 and 0.3 seconds give a mean of 1.5 seconds, and not one request actually took 1.5 seconds. A lone distant value like that is an outlier, and the mean gets dragged bodily toward it. For data with one long tail — salaries, response times — read the median or a percentile alongside it. A percentile marks where a value falls in the order: a 95th percentile of 6 seconds means 95 of every 100 requests finished within 6 seconds.

Second, enough values. Three new signups visiting 2, 3 and 40 times in their first week produce a mean of 15, and that 15 will not repeat next month. When a sample stands in for everyone, how it was drawn matters as much as how large it is.

Third, no groups mixed together that shouldn't be. Average document creation across free-plan users and enterprise accounts and you get a number that describes neither: group means of 4 and 210 landing at an overall 11. Nobody creates 11 documents; the two groups just happen to average out there. Split them and report each.

A quick way to see whether any of this applies is to print the standard deviation next to the mean. It expresses how far values sit from the mean in the original unit, so a mean of 20 minutes with a standard deviation of 3 means most runs land between 17 and 23, while a standard deviation of 25 means the 20 tells you nothing.

"Mean response time is 1.5 seconds but the 95th percentile is 6. Don't read the mean alone."

Most requests are fast, some users are having a very slow time, and that tail is where to look.

"Is this mean free and paid accounts together?"

Checking whether two groups with different behavior were poured into one bucket.

"The sample is eight people, so the mean doesn't mean much."

Too few values, and one or two of them are steering the whole number by themselves.

At Pagedeck this catches Mia every time she reads the weekly metrics. Mean documents created per team went from 11 last month to 19 this month, and she put that straight into the report. Theo opened the underlying values and found a single newly signed enterprise account that had created 3,400 documents. Drop that one account and the mean across the rest was 10.8, the same as the month before.

Since then Mia opens the largest few values before using any mean. The number wasn't wrong; means simply behave that way. The weekly report now carries documents per team as two lines, mean and median, side by side.

The most common misreading is that the mean describes a typical person. A mean payment of $18.25 invites you to picture someone spending around $18, and the name practically asks to be read that way. But the mean is neither the middle value nor the most common one. In those four charges, nothing lands anywhere near $18.25. Build a product on that assumption and you end up pricing for a range nobody occupies — a $18 plan aimed at customers who are really split between $35 and $6.

Reading a rising mean as everything rising has the same root. Because it is a sum divided by a count, the mean goes up when one value jumps and also when the users posting small values leave. Mean session length climbing in a month with heavy churn is a common sight: the people who used the product briefly and left dropped out of the calculation. A mean going up says nothing about direction on its own, so read the count and the spread with it.