EDA — 7 questions before you open a model

I've seen it many times. A team trains a model. The model performs poorly. They blame the architecture, try a bigger model, retrain with different hyperparameters. The model still performs poorly. Eventually someone looks at the data and finds — surprise — the labels are noisy, half the features have systematic missing values, and the train/test split has a temporal leak. The truth was visible in the first hour of EDA, and the team spent three weeks ignoring it.

Don't be that team. EDA isn't a step you skip when you're in a hurry. It's the step that prevents the slowness.

My seven questions for every fresh dataset, asked in order:

One — what's the row count and column count? Frames the rest of the analysis. 100 rows is a different problem from 100M.

Two — what types are each column? df.info() in pandas. Strings as categories vs strings as IDs vs strings that should be parsed as dates.

Three — where are the missing values? df.isna().sum().sort_values(ascending=False). Some columns missing 90% of values are essentially noise. Some missing 5% need imputation strategy.

Four — what's the target distribution? Skewed? Imbalanced? For classification, value_counts() on the target. If 99% of rows are one class, accuracy is meaningless.

Five — any obvious correlations? df.corr() and look at the top correlations with target. Anything above 0.95 is suspicious — likely a leaky feature.

Six — any duplicated rows or near-duplicates? df.duplicated().sum() catches exact duplicates. Near-duplicates need fuzzy matching, but worth checking on critical fields.

Seven — any leak? Features that 'know' the answer at training time but won't be available at inference. Date fields, customer IDs that map 1-1 to label, anything created downstream of the target.

Answer these in 30 minutes. Then model.

Three pandas calls. Run them in order, every time. Thirty seconds of effort. They answer questions one through three from this morning's checklist.

df.info() — shape, dtypes, non-null counts. Tells you the row count, the column count, and how many non-null values each column has.

df.describe(include='all') — summary statistics. mean, std, min, 25th/50th/75th percentile, max for numeric columns. count, unique, top, freq for object columns. The 'include=all' makes it work for both types.

df.isna().sum().sort_values(ascending=False).head(20) — missing-values census. Sum the boolean isna mask per column, sort descending, show the top 20. Reveals which columns have the most missing data.

Look at the snippet. Add a fourth call — top correlations with the target.

corr = df.corr(numeric_only=True)
corr['target'].sort_values(ascending=False).head(10)

Gives you the ten features most positively correlated with the target. Look at the bottom too (corr.sort_values().head(10)) for the most negative correlations. Anything above |0.95| is a leakage suspect.

In 30 seconds you've seen — dataset shape, type distribution, missing-values pattern, summary stats, top correlations. From there you decide what to clean, fill, drop, or one-hot encode. You decide whether the target needs reframing (log transform a skewed regression target). You decide what feature engineering to try first.

The trio runs in any Jupyter notebook in seconds even on multi-GB DataFrames. There's no excuse to skip it. Most ML failures I've seen would have been prevented by 30 minutes of running these four calls and looking carefully at the output.

For production-grade EDA, ydata-profiling (formerly pandas-profiling) generates a full HTML report from these primitives. Useful for sharing findings with stakeholders. For your own first pass, the trio is sufficient.

Look at the data first. Always.

Data leakage is the silent killer of ML projects. A leaked feature is one that wouldn't be available at prediction time but accidentally got into your training data. Your model learns to use it. Validation accuracy looks great. Production accuracy is garbage. The model is useless.

A quick diagnostic. Compute correlations between every numeric feature and the target. Anything with |correlation| > 0.95 is suspicious.

Why 0.95 — most genuinely useful features in real datasets correlate with the target between 0.1 and 0.7. Anything dramatically higher is usually one of:

A derived feature created from the target. Someone's preprocessing pipeline computed mean_target_for_this_user and shipped it as a feature. Now the model is essentially given the answer.

A timestamp or ID that maps 1-1 to the target. Customer ID 5847 always has label A; that's not a feature, it's the answer in disguise.

A feature created downstream of the target. The target is 'did the user churn'; you have a feature 'days since last login' and that feature was computed for churned users by going to the date they churned. Knows the answer.

The diagnostic doesn't catch all leakage (categorical features won't show in numeric correlation; complex non-linear leakage hides). But it catches the most common cases in 30 seconds.

After spotting suspicious features, the second diagnostic — temporal split. Sort the data by time, train on early, test on late. If validation accuracy drops dramatically when you do this versus a random split, you have temporal leakage somewhere.

Leakage costs trust. A model that performed great in development and fails in production loses you political capital. Catch it during EDA, before training. The few minutes you spend looking for it pay off enormously.

Notebooks die. I've opened 18-month-old EDA notebooks and found them broken — kernel state lost, charts re-running differently because the underlying data drifted, library versions incompatible. The notebook was a snapshot of a thought process; the thought process is gone.

My fix is dual-format documentation. Alongside every EDA notebook, I write a 1-page markdown summary.

The notebook captures the WORK — every chart you made, every aggregation you ran, every hypothesis you tested. It's the audit trail.

The markdown captures the FINDINGS — top observations, key decisions made, charts saved as PNG with captions. It's the memory.

Twelve months later, you read the markdown. The notebook is there if you need to verify or rerun something.

What goes in the markdown:

1. Dataset summary — n rows, n columns, sources, time range. Two sentences.
2. Top 3-5 findings with one-sentence explanations. 'The target is heavily imbalanced (95/5).' 'Feature X has 40% missing values, but only for users in segment Y.'
3. Decisions made — 'Will drop column Z due to leakage suspicion.' 'Will use log-transform on price target.'
4. Open questions — 'Why does feature A spike on weekends?' Note for future investigation.
5. Links to key charts saved as PNG — 'See pair_plot_v1.png in figures/'.

Keep it under one page. The discipline of fitting in one page forces clarity.

For team work, the markdown is what you share. Stakeholders don't read notebooks; they read markdowns. Engineers reading the project six months later read the markdown first; only dive into notebooks when they need specifics.

Notebook for the work. Markdown for the memory. Both, every time.

End of Day 34. EDA wrapped.

What we covered.

Morning, the seven questions to answer about every dataset before you train any model. Shape, types, missingness, target distribution, correlations, duplicates, leakage. Thirty minutes of effort that prevents weeks of debugging downstream.

Midday, the holy trio of pandas calls — info, describe, isna.sum. Plus the correlation top-10 with target. Together they answer five of the seven questions. The trio runs in seconds; there's no excuse to skip.

Afternoon, leakage detection in 4 lines. Correlation > 0.95 with target is suspicious. Catches 80% of common leakage cases — derived-from-target features, ID-mapped labels, timestamps that encode the future. Quick diagnostic; massive payoff.

Evening, the dual-format documentation rule. Notebook for the work; markdown for the memory. The notebook records every chart and every aggregation; the markdown captures the key findings and decisions. In 12 months, future-you reads the markdown.

A broader theme. ML failures are usually data failures. Skipping EDA to 'save time' is the biggest false economy in the field. The 30 minutes to look at the data is among the highest-ROI activities you'll do on any project.

Tomorrow, Day 35, the cleaning workflow. Patterns I run on every dataset to handle the messiness — strip whitespace, parse dates, coerce numbers, dedup, bucket rare categories. Then we close week 5.

See you in the morning.