How to read any new dataset in 15 minutes, before you write a single line of real analysis.

THREAD 👇👇👇👇👇 1. SHAPE AND GRAIN

Row count and column preview are not data validation.

They only tell you the table exists.

The real question is:

What does one row represent?

I once worked with a “customer” table that looked clean until the grain was checked.

It was not one row per customer.

It was one row per customer per device.

That small difference changed everything:

➝ Average order value was overstated
➝ Repeat purchase rate was distorted
➝ Churn logic became unreliable
➝ Customer count looked larger than reality
➝ Segmentation was built on duplicated behaviour
The table did not look broken.
That was the danger.

Check the grain before you trust the analysis:

SELECT customer_id, COUNT(*)
FROM table
GROUP BY customer_id
ORDER BY 2 DESC;

If this returns anything above 1 when you expect one row per customer, stop.

Do not build the dashboard.
Do not train the model.
Do not calculate churn.

Rebuild your assumptions first.
Because once the grain is wrong, every metric after it becomes confidently wrong.

Data Analyst/Pro: This thread breaks down the most-used SQL patterns in real organisations, with practical scenarios you’ll actually face on the job 👇👇👇👇

Save this. Bookmark it. Reshare it.
You’ll come back to it when a metric breaks. 1/ JOINs (the #1 source of broken metrics)

JOINs aren’t about combining tables.
They’re about preserving truth.

For example:
- You join orders to order_items
- One order → multiple items
- Revenue suddenly doubles after the JOIN

Nothing “broke”.
Your logic did.

Senior analysts always ask:
→ What is the base table?
→ What happens to row counts after the JOIN?

If you can’t explain the multiplication effect, you can’t defend the number in a meeting.