Image by Author

Here’s a pattern I see more than almost any other: students who spend days building and tuning a model, only to discover the problem was in the data all along. Exploratory data analysis is where the real work of modeling begins, and it’s the step most students rush past. In this guide, I’ll share the three most common EDA mistakes I see students make, and why catching them early saves everything that comes after.

Quick Context: Why EDA Comes Before Everything Else

Exploratory data analysis is the process of examining your data before building any model. It covers distributions, missing values, relationships between variables, and the structure of what you’re trying to predict. Done well, EDA surfaces problems that would silently corrupt a model. Skip or rush it, and those same problems show up later, usually after hours of work, in the form of metrics that simply don’t make sense.

Common Mistake #1: Not Examining the Distribution of the Target Variable

Before any feature engineering, any model selection, any training loop, look at what you’re trying to predict. This sounds obvious. In practice, I see students skip it constantly, moving straight from loading data to fitting a model.

I recently worked with a student who spent three days building a regression model to predict customer spend. His performance metrics were poor regardless of what he tried. When we sat down and plotted the target variable together, the distribution was severely skewed to the right, with a small cluster of extreme values pulling every prediction off course. A log transformation resolved it. His model performance improved substantially in a single session, without touching a single feature or algorithm.

The target variable distribution tells you which algorithms are appropriate, whether transformation is needed, and whether your evaluation metrics will even be meaningful. Checking it takes two minutes. Not checking it can cost days.

Common Mistake #2: Treating Missing Data as Random When the Pattern of Missingness Is Informative

Once the target distribution is clear, missing data is the next place students go wrong. Most handle it one of two ways: drop the rows, or fill with the mean. Neither is inherently wrong, but both skip a more important question. Why is this data missing?

Missingness is rarely random. A missing income field in a loan application might indicate self-employment. A missing test result might mean the test was never ordered because a diagnosis was already clear. What’s absent often carries as much signal as what’s present.

I’ve seen students impute or drop without ever examining the pattern. In one session, a student couldn’t understand why her churn model consistently underperformed in one customer segment. The missing data in that segment wasn’t random. It reflected a distinct onboarding path the model had no information about. Understanding the missingness changed how she structured the entire feature set.

Before you impute or drop anything, map what’s missing and ask why. The answer is often a feature in its own right.

Common Mistake #3: Not Detecting Data Leakage Hiding Inside the Feature Set

Of the three EDA mistakes, leakage is the most dangerous because it produces the best-looking models. A model trained on leaked features will score exceptionally well during development and fail immediately in production. The metrics tell you everything is working. The deployment tells you otherwise.

Leakage happens when a feature contains information that wouldn’t be available at prediction time. A fraud detection model that includes a column flagging the transaction for review. A hospital readmission model that includes a discharge summary written after the outcome occurred. Students often miss these because the features look legitimate in isolation.

I’ve reviewed student projects where 94% test accuracy was explained almost entirely by a single leaky feature, a timestamp derived from the outcome rather than the input. Remove that column and the model drops to baseline. EDA is where you catch this: examine each feature, ask when it would realistically be known, and treat anything that correlates suspiciously well with the target as worth investigating before you go any further.

How to Avoid These Mistakes: Quick Checklist

• Plot the target variable distribution before selecting any algorithm or engineering any feature
• Assess whether transformation or outlier treatment is needed before moving to modeling
• Map missing data patterns and ask why each field is missing before deciding how to handle it
• Treat consistent patterns of missingness as potential features, not just gaps to fill
• For every feature in your dataset, ask: would this value realistically be known at prediction time?

Conclusion

These three mistakes share a common thread: they’re invisible until they’re expensive. A skewed target, a meaningful missing pattern, a leaky feature. None of them announce themselves. They surface later, in collapsed metrics or failed deployments, long after the EDA window has passed. The students who model most effectively treat EDA not as a preliminary step, but as the most important one. What does your EDA process look like before you start building?