Look at the data before you average it
The usual order of operations with a new file is: open it, glance at the first few rows, and start computing. The first few rows are almost always fine. That is why they are not evidence of anything. What you actually need to know before you trust a column is how many values are missing from it, how many distinct values it holds, and what its smallest and largest values are — because each of those changes what your arithmetic means.
An eight-row file that looks fine
date,region,rep,units,revenue2026-01-04,North,Alice,12,4802026-01-05,South,Bob,,3202026-01-06,North,Carla,9,2026-01-07,East,Dan,7,2802026-01-08,north,Alice,-3,1202026-01-09,South,Bob,11,4402026-01-10,North,,15,6002026-01-11,South,Bob,8,320
Summarised, that is the true output:
5 column(s), 8 row(s)region — filled 8 / 8 blank 0 distinct 3rep — filled 7 / 8 blank 1 distinct 4units — filled 7 / 8 blank 1 distinct 7units numeric: min -3.0000 median 9.0000 mean 8.4286 max 15.0000 sum 59.0000revenue — filled 7 / 8 blank 1 distinct 6revenue numeric: min 120.0000 median 320.0000 mean 365.7143 max 600.0000 sum 2560.0000
What each line just told you
Revenue is blank on one row in eight. That is 1 ÷ 8 = 12.5% of the file, and it changes the average depending on a decision nobody consciously made. The mean printed is 2560 ÷ 7 = 365.7143, because the blank is skipped. If you had divided by the row count instead, you would get 2560 ÷ 8 = 320.00. Those are 365.71 − 320.00 = 45.71 apart, about 14 percent, and both are defensible — the blank might be a genuine zero-revenue day, or a day nobody filled in. Only you know which. The point is that this is a decision, and until you count the blanks you are making it by accident.
Units has a minimum of −3. Nothing else in the summary would have caught that. Negative units might be a return, in which case fine, or a sign error, in which case the sum of 59 is wrong. It is one line of output and it puts the question in front of you before the number reaches a slide.
Rep has one blank and four distinct values. One row's sale belongs to nobody, so any per-rep breakdown will silently be missing a row. Better to know now than to wonder later why the parts do not add to the whole.
The distinct count is your typo detector
If a column that should hold four regions reports nineteen distinct values, you have spelling variants, stray whitespace or a mis-aligned row, and you have found it in one glance. That is the single most useful number in the whole summary.
One caveat, and it matters: the distinct count folds case. The file above spells the region four ways — North, South, East and north — and the summary reports distinct 3, because North and north are counted as the same value. That is helpful for reading the real shape of the data and unhelpful for spotting inconsistent capitalisation, which it hides. If casing matters to whatever you are feeding this into, check it separately.
What counts as blank, and what counts as a number
Blank means the cell is empty. A cell containing N/A, -, unknown or 0 is filled, and will be counted as a value. If your export writes missing data as text, the blank count will read zero and be perfectly accurate and completely misleading — so look at the distinct count too, where N/A will show up as one of the values.
Numbers are read loosely: currency symbols and thousands separators are stripped, so $1,234 is 1234. That also means 12 kg is read as 12. A column mixing 10 kg and 10 lb will average happily and mean nothing, so keep units in their own column.
Number statistics only appear when a column has at least two numeric values and at least half of its filled values parse as numbers. That is why the date column above got no numeric line: a column of postcodes or invoice references with an average is worse than no line at all.
Two more limits worth knowing
The median is the middle value of the sorted list, and on an even count it takes the upper of the two middle values rather than averaging them. A column of 10, 20, 30, 100 reports median 30.0000, not 25. For a quick sanity check that is fine; for a figure you are publishing, work it out properly.
And it reads about five thousand rows from a paste and then stops, without saying so. A 6,000-row file summarises as 4999 row(s), which is a wrong answer that looks like a right one. If your file is genuinely large, this is the wrong instrument — use a real spreadsheet application or a database, where the row count is the file's row count.
Nothing is uploaded; the CSV Column Summary counts in your browser and produces no file. Ten seconds of looking before you compute is the whole method, and the tool is only what makes it fast.