Judging a data claim

Read it first: "count of customers, per country, biggest first." The GROUP BY country is the granularity; the ORDER BY ... DESC just sorts the summary. Run it, then ask: would a headline of "we serve five countries" have told you the same thing? It would have hidden that the count is lopsided.

SELECT country, COUNT(*) AS customers
FROM customers
GROUP BY country
ORDER BY customers DESC;

When two teams argue about a number, they are usually grouping at different grains without realizing it. Sales counts revenue per deal; finance counts it per invoice; the product team counts it per active account. All three are "revenue", none agree, and none is lying. The fix is not a better database - it is naming the grain out loud.

• Per order vs per customer: a customer with five orders is one row in one view and five in the other.
• Per month vs per cohort: the same signups look like growth or churn depending on which you group by.
• The leader's habit: before debating a number, agree on its grain. Half of data disputes dissolve right there.

Read it: "how many products, the average price rounded to cents, and the highest price." Run it. The catalog has coffee bags around $15-22 and one Cold Brew Kit at $34. Watch how the average lands in the middle and says nothing about that top-end outlier - a leader who only saw "average price" would never guess a $34 item existed.

SELECT COUNT(*) AS products,
       ROUND(AVG(price), 2) AS avg_price,
       MAX(price) AS priciest
FROM products;

None of these is better; each fits a different question. Match the summary to the decision.

When you are handed an average, the follow-up is almost always "and what does the spread look like?" A median, a max, or a simple range often changes the story.

Read it: "count of orders, per status." Run it and you will see the completed, refunded and cancelled buckets side by side. This is the whole point: "we had 33 orders" is ambiguous until you say which of these statuses were meant to count. The refund trap lives right here.

SELECT status, COUNT(*) AS n
FROM orders
GROUP BY status;

Rates and percentages mislead through their denominator - the number on the bottom. "Conversion is up" means nothing until you know conversion out of what. A rate is only trustworthy when its top and bottom describe the same population over the same window.

• Mismatched populations: numerator counts all signups, denominator counts only paying accounts - the rate is meaningless.
• Shrinking denominator: a "churn rate improved" can simply mean the base you divided by got smaller.
• The leader's move: for any rate, ask "top over bottom - are they the same group, same period?" Session a4 goes deep on this.

Before you can trust an "average order", you have to know which orders count. Run this to see the status breakdown, then decide which rows the claim should have used.

SELECT status, COUNT(*) AS n
FROM orders
GROUP BY status;

Run this to see the average price sitting next to the max. If the two are far apart, an outlier is shaping the "healthy average" - and the claim needs the spread shown, not just the mean.

SELECT ROUND(AVG(price), 2) AS avg_price,
       MAX(price) AS priciest,
       MIN(price) AS cheapest
FROM products;