Field note · April 11, 2024
What revenue_usd actually contains in retail-orders
7,000 rows, 5,719 distinct values, and the one fact about revenue_usd that changes how you query it.
Working through retail-orders again. revenue_usd is the column people trip over, so here is what it actually looks like.
7,000 rows, no nulls, 5,719 distinct values. units × unit_price × (1 − discount), rounded to cents.
The five-number version: min 5, p10 20, median 60, p90 245, max 2,318. The mean is 111.
The p10 to p90 band — 20 to 245 — is where ordinary rows live, and it is the pair worth quoting when somebody asks what to expect. Min and max describe the two strangest rows in the table and nothing else; they are useful for spotting impossible values and misleading for everything else.
select
count(*) as rows,
count(revenue_usd) as present,
count(*) - count(revenue_usd) as nulls,
count(distinct revenue_usd) as distinct_values
from retail_orders;The mean sits 84% above the median, which is the whole story: anything that reports the average of revenue_usd is reporting a number most rows are below. Put the median next to it or drop the mean.
Where this bites: a filter like revenue_usd > 111 reads as "above average" and selects a minority of rows — a smaller minority than the phrase suggests to whoever asked for it. If the request was "the typical ones", the threshold they meant was 60.
The grain is one row per order line, which is the context every one of those numbers depends on. None of them survive a change of grain, which is why "profile the column" and "profile the table" are the same job. Full schema, and the CSV, on the dataset page.