Define the Metric Before Writing SQL

SQL can execute a rule precisely, but it cannot decide whether that rule matches the business meaning. Many disagreements between queries are not syntax errors. They come from different definitions of the same metric.

A one-sentence definition

Before writing the query, complete this sentence:

Within a stated time window, count or calculate a defined business subject that meets explicit conditions, and state the exclusions.

“Monthly paying customers,” for example, still requires answers. Are customers counted by account or order? Are refunded orders excluded? Is a renewal counted once or more than once? Which time zone applies?

Five checks before the query

1. Subject: Are you counting customers, orders, products, or events?
2. Time: Does the metric use creation, payment, or completion time?
3. Status: Which states are included or excluded?
4. Deduplication: What is the unique key, and can a join duplicate it?
5. Missing data: How are null, unknown, and delayed values handled?

Keep the SQL reviewable

Use meaningful CTE names and separate filtering, joining, and aggregation into inspectable steps. Fewer lines are not automatically better if the result is harder to review. For material queries, record the data version and run date as well.

Validate with a small sample

Choose a few known records, calculate the expected result manually, and compare it with the query output. Matching totals are not enough; check category distributions, boundary dates, and duplicate records.

A metric definition is an interface between business and technical work. When that interface is explicit, SQL becomes a reproducible implementation.