Forecasting and Baselines

By the end of this lesson, you should be able to: build baselines that beat most dashboards in one line of SQL, score them honestly, explain why the standard seasonal comparison is biased in a growing business, and put a number on how big a drop has to be before it means anything.

You have been forecasting all along

Every lesson so far has quietly assumed something. "Conversion fell 1.78 points" compares the last four weeks with the first four. "Churn rose" compares this month with last. Each one has a hidden counterfactual: what the number would have been.

That counterfactual is a forecast. You are making one every time you say a metric moved, and the only question is whether you make it deliberately or by accident.

Making it by accident is where the damage happens, because the accidental version is almost always "compare with last period", and that comparison has two problems built in.

Problem one: the week has a shape

Basket's daily actives, expressed as a share of that week's own average:

Saturday runs 37% above Tuesday. Every week, forever, with no product change involved.

So "DAU dropped 25% since Saturday" said on a Tuesday isn't a finding. It's a description of the calendar. A dashboard showing day-over-day change on a product with a weekly rhythm generates a false alarm most Mondays and a false celebration most Fridays.

The fix is to compare like with like: the same weekday, not yesterday. That's the seasonal naive baseline, and it's the one most teams land on.