What first_response_min actually contains in support-tickets

Working through support-tickets again. first_response_min is the column people trip over, so here is what it actually looks like.

4,000 rows, 149 nulls (3.7%), 622 distinct values. Minutes to first human reply. Blank if never answered.

The five-number version: min 1, p10 18, median 83, p90 355, max 4,444. The mean is 155.

The p10 to p90 band — 18 to 355 — 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.

149 rows have no value at all here, which is 3.7% of the table. That is enough to move an aggregate and small enough that nobody notices it doing so — every average above is computed over 3,851 rows, not 4,000, and the two denominators produce different answers.

select
  count(*)                             as rows,
  count(first_response_min)            as present,
  count(*) - count(first_response_min) as nulls,
  count(distinct first_response_min)   as distinct_values
from support_tickets;

The mean sits 86% above the median, which is the whole story: anything that reports the average of first_response_min is reporting a number most rows are below. Put the median next to it or drop the mean.

Where this bites: a filter like first_response_min > 155 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 83.

The grain is one row per ticket, 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.