Skip to main content
Workforce LibreTexts

5.10: Common Mistakes in EDA and How to Avoid Them

  • Page ID
    48066
  • \( \newcommand{\vecs}[1]{\overset { \scriptstyle \rightharpoonup} {\mathbf{#1}} } \)

    \( \newcommand{\vecd}[1]{\overset{-\!-\!\rightharpoonup}{\vphantom{a}\smash {#1}}} \)

    \( \newcommand{\dsum}{\displaystyle\sum\limits} \)

    \( \newcommand{\dint}{\displaystyle\int\limits} \)

    \( \newcommand{\dlim}{\displaystyle\lim\limits} \)

    \( \newcommand{\id}{\mathrm{id}}\) \( \newcommand{\Span}{\mathrm{span}}\)

    ( \newcommand{\kernel}{\mathrm{null}\,}\) \( \newcommand{\range}{\mathrm{range}\,}\)

    \( \newcommand{\RealPart}{\mathrm{Re}}\) \( \newcommand{\ImaginaryPart}{\mathrm{Im}}\)

    \( \newcommand{\Argument}{\mathrm{Arg}}\) \( \newcommand{\norm}[1]{\| #1 \|}\)

    \( \newcommand{\inner}[2]{\langle #1, #2 \rangle}\)

    \( \newcommand{\Span}{\mathrm{span}}\)

    \( \newcommand{\id}{\mathrm{id}}\)

    \( \newcommand{\Span}{\mathrm{span}}\)

    \( \newcommand{\kernel}{\mathrm{null}\,}\)

    \( \newcommand{\range}{\mathrm{range}\,}\)

    \( \newcommand{\RealPart}{\mathrm{Re}}\)

    \( \newcommand{\ImaginaryPart}{\mathrm{Im}}\)

    \( \newcommand{\Argument}{\mathrm{Arg}}\)

    \( \newcommand{\norm}[1]{\| #1 \|}\)

    \( \newcommand{\inner}[2]{\langle #1, #2 \rangle}\)

    \( \newcommand{\Span}{\mathrm{span}}\) \( \newcommand{\AA}{\unicode[.8,0]{x212B}}\)

    \( \newcommand{\vectorA}[1]{\vec{#1}}      % arrow\)

    \( \newcommand{\vectorAt}[1]{\vec{\text{#1}}}      % arrow\)

    \( \newcommand{\vectorB}[1]{\overset { \scriptstyle \rightharpoonup} {\mathbf{#1}} } \)

    \( \newcommand{\vectorC}[1]{\textbf{#1}} \)

    \( \newcommand{\vectorD}[1]{\overrightarrow{#1}} \)

    \( \newcommand{\vectorDt}[1]{\overrightarrow{\text{#1}}} \)

    \( \newcommand{\vectE}[1]{\overset{-\!-\!\rightharpoonup}{\vphantom{a}\smash{\mathbf {#1}}}} \)

    \( \newcommand{\vecs}[1]{\overset { \scriptstyle \rightharpoonup} {\mathbf{#1}} } \)

    \(\newcommand{\longvect}{\overrightarrow}\)

    \( \newcommand{\vecd}[1]{\overset{-\!-\!\rightharpoonup}{\vphantom{a}\smash {#1}}} \)

    \(\newcommand{\ket}[1]{\left| #1 \right>}\)
    \(\newcommand{\bra}[1]{\left< #1 \right|}\)
    \(\newcommand{\braket}[2]{\left< #1 \vphantom{#2} \right| \left. #2 \vphantom{#1} \right>}\)
    \(\newcommand{\braopket}[3]{\left< #1 \vphantom{#2}\vphantom{#3} \right| #2 \vphantom{#1}\vphantom{#3} \left| #3 \vphantom{#1}\vphantom{#2} \right>}\)
    \(\newcommand{\qmvec}[1]{\mathbf{\vec{#1}}}\)
    \(\newcommand{\op}[1]{\hat{\mathbf{#1}}}\)
    \(\newcommand{\expect}[1]{\langle #1 \rangle}\)
    \(\newcommand{\dfn}[1]{\emph{\textbf{#1}}}\)

    \(\newcommand{\avec}{\mathbf a}\) \(\newcommand{\bvec}{\mathbf b}\) \(\newcommand{\cvec}{\mathbf c}\) \(\newcommand{\dvec}{\mathbf d}\) \(\newcommand{\dtil}{\widetilde{\mathbf d}}\) \(\newcommand{\evec}{\mathbf e}\) \(\newcommand{\fvec}{\mathbf f}\) \(\newcommand{\nvec}{\mathbf n}\) \(\newcommand{\pvec}{\mathbf p}\) \(\newcommand{\qvec}{\mathbf q}\) \(\newcommand{\svec}{\mathbf s}\) \(\newcommand{\tvec}{\mathbf t}\) \(\newcommand{\uvec}{\mathbf u}\) \(\newcommand{\vvec}{\mathbf v}\) \(\newcommand{\wvec}{\mathbf w}\) \(\newcommand{\xvec}{\mathbf x}\) \(\newcommand{\yvec}{\mathbf y}\) \(\newcommand{\zvec}{\mathbf z}\) \(\newcommand{\rvec}{\mathbf r}\) \(\newcommand{\mvec}{\mathbf m}\) \(\newcommand{\zerovec}{\mathbf 0}\) \(\newcommand{\onevec}{\mathbf 1}\) \(\newcommand{\real}{\mathbb R}\) \(\newcommand{\twovec}[2]{\left[\begin{array}{r}#1 \\ #2 \end{array}\right]}\) \(\newcommand{\ctwovec}[2]{\left[\begin{array}{c}#1 \\ #2 \end{array}\right]}\) \(\newcommand{\threevec}[3]{\left[\begin{array}{r}#1 \\ #2 \\ #3 \end{array}\right]}\) \(\newcommand{\cthreevec}[3]{\left[\begin{array}{c}#1 \\ #2 \\ #3 \end{array}\right]}\) \(\newcommand{\fourvec}[4]{\left[\begin{array}{r}#1 \\ #2 \\ #3 \\ #4 \end{array}\right]}\) \(\newcommand{\cfourvec}[4]{\left[\begin{array}{c}#1 \\ #2 \\ #3 \\ #4 \end{array}\right]}\) \(\newcommand{\fivevec}[5]{\left[\begin{array}{r}#1 \\ #2 \\ #3 \\ #4 \\ #5 \\ \end{array}\right]}\) \(\newcommand{\cfivevec}[5]{\left[\begin{array}{c}#1 \\ #2 \\ #3 \\ #4 \\ #5 \\ \end{array}\right]}\) \(\newcommand{\mattwo}[4]{\left[\begin{array}{rr}#1 \amp #2 \\ #3 \amp #4 \\ \end{array}\right]}\) \(\newcommand{\laspan}[1]{\text{Span}\{#1\}}\) \(\newcommand{\bcal}{\cal B}\) \(\newcommand{\ccal}{\cal C}\) \(\newcommand{\scal}{\cal S}\) \(\newcommand{\wcal}{\cal W}\) \(\newcommand{\ecal}{\cal E}\) \(\newcommand{\coords}[2]{\left\{#1\right\}_{#2}}\) \(\newcommand{\gray}[1]{\color{gray}{#1}}\) \(\newcommand{\lgray}[1]{\color{lightgray}{#1}}\) \(\newcommand{\rank}{\operatorname{rank}}\) \(\newcommand{\row}{\text{Row}}\) \(\newcommand{\col}{\text{Col}}\) \(\renewcommand{\row}{\text{Row}}\) \(\newcommand{\nul}{\text{Nul}}\) \(\newcommand{\var}{\text{Var}}\) \(\newcommand{\corr}{\text{corr}}\) \(\newcommand{\len}[1]{\left|#1\right|}\) \(\newcommand{\bbar}{\overline{\bvec}}\) \(\newcommand{\bhat}{\widehat{\bvec}}\) \(\newcommand{\bperp}{\bvec^\perp}\) \(\newcommand{\xhat}{\widehat{\xvec}}\) \(\newcommand{\vhat}{\widehat{\vvec}}\) \(\newcommand{\uhat}{\widehat{\uvec}}\) \(\newcommand{\what}{\widehat{\wvec}}\) \(\newcommand{\Sighat}{\widehat{\Sigma}}\) \(\newcommand{\lt}{<}\) \(\newcommand{\gt}{>}\) \(\newcommand{\amp}{&}\) \(\definecolor{fillinmathshade}{gray}{0.9}\)

    Common Mistakes in EDA and How to Avoid Them

    Even experienced analysts can fall prey to pitfalls during exploratory analysis. Here are some common mistakes in EDA along with tips to avoid them:

    1. Skipping EDA or Rushing Through It: One of the biggest mistakes is to go directly to modeling or conclusion-drawing without thoroughly exploring the data. This can result in overlooking critical data issues or patterns. Analysts under time pressure sometimes do a perfunctory EDA, potentially missing key insights. To avoid this, allocate dedicated time for EDA in your project plan. Remember that insights from EDA often save time later by preventing mistakes. As noted, patience is key – take the time to explore the data from multiple angles. If you catch yourself saying “I’ll assume the data is fine,” that’s a red flag to slow down and actually verify.
    2. Confirmation Bias in Exploration: It’s easy to have an initial hypothesis and then subconsciously give more weight to plots that support it while ignoring those that don’t. For instance, you might expect a upward trend and upon seeing a somewhat upward scatter, conclude it's confirmed, disregarding variability or contrary cases. To combat this, adopt a mindset of skepticism – actively look for evidence that contradicts your assumptions. Exploratory analysis should be about learning, not proving. If you have a hypothesis, also explore scenarios where it wouldn’t hold. It may also help to have a colleague review your findings; they might see what you overlooked.
    3. Overwhelming with Excessive Plots (Analysis Paralysis): EDA can generate a huge number of plots and statistics. Sometimes analysts produce pages of charts without interpreting them, leading to confusion rather than clarity. Dumping every possible plot (“brute force EDA”) is not efficient. Instead, be purposeful: for each plot you draw, know what question you’re trying to answer. It’s fine to generate many visuals during exploration, but try to organize them (maybe label sections of your notebook: distribution plots, correlation plots, etc.) and periodically consolidate what they mean. If certain plots aren’t illuminating, move on. Quality of insight trumps quantity of charts.
    4. Ignoring Data Quality Issues: Failing to detect and handle data issues is a critical mistake. Missing values, duplicate records, out-of-range values, inconsistent categories (e.g., "USA" vs "United States"), and other quirks can all wreak havoc if not addressed. Imagine not noticing that a sensor’s readings were occasionally in different units – any analysis on that variable would be garbage. The way to avoid this mistake is to incorporate data quality checks as part of EDA. Always check basic things like: Are there negative values where there shouldn’t be? Do totals add up? Are there strange spikes or drops over time that might indicate collection problems? If something looks too weird to be true, it probably deserves investigation. EDA is the time to clean data or at least mark suspicious data points for potential exclusion or correction.
    5. Misinterpreting Correlation and Causation: EDA might reveal correlations or associations, but a common mistake is to start implying causation from them. For example, you might find that users who use a certain feature of an app tend to be the ones who stay longer (correlation). It would be a mistake to immediately conclude “that feature causes retention” – it could be that engaged users both use the feature and stay longer, or some third factor is at play. To avoid this, always remember EDA is exploratory: use phrases like “associated with” rather than “leads to” when noting findings. Keep a list of plausible explanations for any correlation. Later, confirmatory analysis or controlled experiments are needed to establish causality. Essentially, treat EDA results as hypotheses, not conclusions.
    6. Failing to Differentiate Signal from Noise: In any dataset, especially large ones, some patterns will appear simply by random chance. If one is not careful, EDA can turn into a “p-hacking” exercise where you find an exciting pattern that doesn’t actually generalize. For instance, in a dataset with 100 variables, purely by chance some variable will correlate 0.2 with another, which might not hold in new data. To mitigate being fooled by noise, use common sense and, if possible, validation within EDA: for example, split your data (if you have enough) and see if a pattern holds in both halves. Or check if outliers are driving a pattern: remove a couple and see if correlation drops drastically (if it does, your pattern might be fragile). Another technique is to simulate or shuffle data to see how often a pattern could appear by random – though this is more advanced, it can put things in perspective. Above all, temper excitement over a discovery with a consideration: “Could this be a fluke?”
    7. Poor Choice of Visualizations: Using the wrong type of chart or an ineffective visualization can obscure the truth. Common errors include using pie charts for too many categories (making it hard to compare slices), using 3D charts (which often add confusion without adding insight), or plotting unaggregated time-series with too many points (creating a noisy mess). Also, not adjusting axes properly (like not using log scale for data spanning several orders of magnitude) can make a plot uninformative. To avoid this, follow basic data visualization principles: choose a chart that matches the data story. If comparing parts of a whole, maybe a bar chart is clearer than a pie. If data ranges widely, consider a log scale. Leverage preattentive attributes (color, position, size) appropriately – for example, use color to distinguish categories, but not too many distinct colors as that can be confusing. Ensure labels and legends are clear. It’s often useful to start with simple plots (even just a sorted bar chart) before trying fancy ones. Remember, the goal is to see the pattern, not to impress with complex visuals. If a plot isn’t revealing anything, try another approach.
    8. Not Considering the Need for Split EDA (Segmenting): Sometimes, data has natural segments (e.g., male vs female, or different experimental groups). A mistake is to only look at the aggregate data and miss that segments behave differently. For example, the average trend might be flat, but maybe it’s because one group is increasing and another is decreasing, canceling out. Failing to stratify can hide important insights. The antidote is to ask: “Should I separate the data by some key category during exploration?” If your dataset has an obvious grouping (like control vs treatment, or different product lines), do EDA on each subset as well as on the whole. Compare them – differences between subsets can be just as important as overall patterns.
    9. Forgetting to EDA the Target (for predictive tasks): In predictive modeling scenarios, sometimes analysts jump into modeling relationships without carefully examining the target variable (the outcome they want to predict). Not exploring the target can be disastrous – e.g., if the target has class imbalance (say 95% of instances are class A, 5% class B) and you didn’t notice, your model evaluation could be flawed. Or if the target has outliers or errors, your model might chase those. Always do a thorough EDA of the outcome variable itself: distribution, outliers, time trends, etc. Ensure you understand how the target is defined and if there are any caveats (like censoring or cut-off values). This will guide modeling (choice of loss function, need for stratified splits, etc.).
    10. Not Iterating or Revisiting EDA After Model Insights: EDA is not necessarily one-and-done. A mistake is to put the EDA aside once modeling starts, and not return even if the model yields surprises. In reality, you should be ready to go back to EDA when needed. For instance, if a model indicates variable X is very important, but you didn’t see that in initial EDA, maybe you should visualize X against the outcome again or with an interaction. Sometimes model residuals analysis (looking at where the model errs) can be a new dataset to do EDA on – revealing patterns the model couldn’t capture. The lesson is: keep EDA and analysis in a dialogue. Avoid the mentality “I did EDA, check, now ignore data feelings and just trust the model.”

    By being mindful of these common mistakes, you can significantly improve the quality of your exploratory analysis. EDA is partly about avoiding false steps: catching errors before they propagate, not getting seduced by misleading patterns, and not missing the obvious due to oversight. Good EDA habits – like those outlined in best practices and the avoidance of the pitfalls above – ultimately lead to more robust and credible analyses.


    This page titled 5.10: Common Mistakes in EDA and How to Avoid Them was last modified on Thu, 06 Aug 2026 20:29:15 GMT and is shared under a CC BY 4.0 license and was authored, remixed, and/or curated by Felix Amoruwa.

    • Was this article helpful?