The most expensive SQL mistake isn't a bad JOIN. It's answering a precise version of the wrong question.
Before writing any query, separate the vague version of the question from the precise version, because the gap between them is where most wasted analysis lives.
Vague question | Precise version that's actually queryable | The decision it's meant to inform |
|---|---|---|
"Is engagement down?" | "What's the weekly count of users completing the core action, for the last 12 weeks, and how does the most recent complete week compare to the 8-week average before it?" | Whether to investigate a specific recent change |
"Are we losing customers?" | "Of users active in month N, what percentage were still active in month N+1, for each of the last six cohorts?" | Whether churn is a current problem or a historical one that's improving |
"Is the new onboarding better?" | "Comparing users who signed up after the launch date to a matched group before it, what's the 7-day activation rate for each?" | Whether to roll the new onboarding out further or roll it back |
Notice that the precise version always specifies: what counts, over what time window, compared to what baseline. A query built against the vague version will still run and still return a number, and that number will still be wrong for the actual decision at hand, because it was never really answering it.
YOUR MOVE THIS WEEK
Take a vague question currently floating around your team ("is X working," "are users happy with Y"). Write the precise, queryable version yourself, on paper, before writing any SQL. This single translation step is frequently the entire value of a good analyst, and it's a skill independent of SQL syntax itself.