What churned_at actually contains in saas-subscriptions

Working through saas-subscriptions again. churned_at is the column people trip over, so here is what it actually looks like.

2,500 rows, 1,444 nulls (57.8%), 624 distinct values. Cancellation date, or empty if still active.

It runs from 2023-03-17 to 2026-01-24, covering 624 distinct days.

It is a date rather than a timestamp, so there is no time zone to get wrong here. That is worth noticing, because the moment a column like this gains a time component, every daily aggregate silently shifts for anyone not in UTC.

1,444 rows have no value at all here, which is 57.8% 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 1,056 rows, not 2,500, and the two denominators produce different answers.

select
  count(*)                     as rows,
  count(churned_at)            as present,
  count(*) - count(churned_at) as nulls,
  count(distinct churned_at)   as distinct_values
from saas_subscriptions;

Check the range before filtering on it. Half the "the dashboard is empty" reports we have seen are a date filter outside the data's actual range, and the query is not wrong so nothing errors.

Where this bites: 624 populated days is what any window function over this column has to work with. A seven-day lag counts rows, not days — so if a day is missing, lag(7) quietly compares against eight days ago and the week-over-week number is wrong in a way that looks plausible.

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