Run the failure
Use the red CTA to create the analytical problem intentionally.
Practice Lab · 03 · SQL for Analytics
The Join Explosion
Run a payment-attempt join that quietly multiplies order value, then diagnose it with control queries.
JOIN cardinalityControl queriesPre-aggregation
Case brief
Find why GMV moves from $110 to $135 although the business only has three orders.
01
Your task
Break it. Run the checks. Explain the evidence.
Predict the result
Before validating, decide what you expect row counts or metrics to do.
Run validation
Use the green CTA to reveal the checks that catch the failure.
Explain it
Say what broke in plain business language, not only SQL language.
02
Interactive case
Run this.
RUN THIS CASE ↓
The Join Explosion
Find why GMV moves from $110 to $135 although the business only has three orders.
Ready — run the case. Rows increase; distinct orders do not.
orders3 rows
1001$251002$401003$45GMV$110
LEFT JOIN payments
query outputsafe summaryraw attempts
1001 · failed$251001 · paid$25extra row1002 · paid$401003 · paid$45GMV$110$135
Rows34
Distinct orders3
Control query catches it: row count changed while distinct orders did not. Pre-aggregate payment attempts to one row per order.
Debrief unlocked
What should the analyst learn?
- A query can run and still be analytically wrong.
- COUNT(*) vs COUNT(DISTINCT key) exposes join inflation.
- Pre-aggregate many-side tables to the intended grain.
03
Transfer
Use the same checks at work.
A query can run and still be analytically wrong.
COUNT(*) vs COUNT(DISTINCT key) exposes join inflation.
Pre-aggregate many-side tables to the intended grain.