Exploratory Data Analysis

Exploratory data analysis, usually shortened to EDA, is the step where you actually look at your data before doing anything more sophisticated with it — summaries, distributions, and a hunt for anything that looks wrong or surprising.

Start with simple summaries

Before anything else, get a basic feel for each column: how many values, how many are missing, what's the smallest and largest, what's roughly typical. This alone catches a huge number of problems — an "age" column with a value of -4 or 250 is obviously a data entry error, and you want to know that before it quietly distorts every later step.

>>> a first look at a column
order_totals = [42.50, 38.00, 51.25, 6400.00, 45.75, 39.99]

print(f"Count: {len(order_totals)}")
print(f"Min: {min(order_totals)}")
print(f"Max: {max(order_totals)}")
print(f"Average: {sum(order_totals) / len(order_totals):.2f}")
Output
Count: 6
Min: 6.4
Max: 6400.0
Average: 1102.9166666666667

That 6400.00 immediately stands out against five orders that are all under $52 — either a genuinely huge order, or more likely, a data entry mistake missing a decimal point. Either way, it's exactly the kind of thing you want to catch by looking, before it drags the average up to a number that doesn't represent any typical order at all.

Look at the shape of the data, not just one number

A single summary number hides a lot. Two datasets can have the exact same average while looking completely different — one tightly clustered around that average, another spread across a huge range with a few extreme values. Understanding the distribution, not just a single summary statistic, is most of what EDA is for.

Hunt for outliers

An outlier is a value that sits far outside the rest of the data. Sometimes it's an error (like the 6400.00 order above); sometimes it's completely real and important (a single viral post driving huge traffic on one specific day). EDA is where you find these and decide, deliberately, whether to fix them, exclude them, or keep them front and center.

Why not skip straight to modeling: a model trained on data with an unnoticed error like that $6,400 order will happily learn a distorted pattern as if it were normal. Looking at the raw data first, even briefly, is often the cheapest bug-catching step in the entire workflow — and it's the one most often skipped under time pressure.