Exploratory Data Analysis and Data Quality Questions

Direct answer

Include what the data can and cannot support: known missingness and what's assumed about why it's missing, any imputation or handling choices made and their potential effect on the numbers, and any known bias (a sampling gap, a measurement issue) that might affect how the results should be read. Phrase it in plain language first, naming the specific limitation and its practical consequence, before any technical detail about how it was measured or corrected.

Writing it for a non-technical executive

Lead with the practical "what this means for you" framing rather than the mechanism: not "the missingness mechanism was assessed as likely MAR" but "some records are missing this field, and we filled in a reasonable estimate rather than the real value, which means numbers based on this field could be off by a few percentage points in either direction." Name the specific decision made, the specific consequence, and roughly how much it could matter, rather than a vague, catch-all "data has limitations" statement that gives the reader no way to judge how seriously to take it.

Worked example

"Limitations due to missingness and imputation choices: about 12% of customer records were missing an income value. We filled these in using the median income for similar customers rather than leaving them blank, which lets the overall analysis proceed but means individual estimates for these customers are less certain than for customers with a directly reported value. This is unlikely to meaningfully shift the overall trend we're reporting, but if you're looking at results for a specific small segment, check whether that segment has a higher-than-average share of filled-in values before treating the number as precise." That paragraph names the specific limitation, the specific fix, its likely practical impact, and a concrete condition (a specific segment) under which the reader should be extra cautious.

Trade-offs and pitfalls

The goal is calibration, not maximal hedging: naming every conceivable caveat regardless of how much it actually matters trains readers to skip the caveats section entirely, which defeats its purpose the next time a caveat genuinely matters.

Direct answer

Treat this as an evidence-gathering exercise for each flagged point, not a blanket rule: check whether the value is physically plausible, whether it correlates with a known legitimate cause (a VIP account, a bulk order, a specific promotion), and whether removing or capping it would change a downstream decision. Only remove a point once you have a specific reason to distrust it, not just because it's far from the rest.

A decision process

1. Check plausibility first. Is the value even possible given the business (a negative quantity, an age of 300)? If so, it's very likely an error, not a legitimate extreme value.
2. Look for corroborating signal. Does the account have a history of similarly large orders? Is there a promotion or bulk-purchase flag active that explains it? A genuine VIP purchase usually has supporting evidence elsewhere in the row or the customer's history; a data-entry error usually doesn't.
3. Consider the downstream use. If you're reporting a sum (total revenue), an error needs fixing but a legitimate large value should stay in. If you're reporting a "typical" value (median order size), a genuine extreme value can often stay in the data untouched, since the median won't be swayed by it anyway.
4. Choose the least destructive fix that solves the actual problem. Removing a row throws away information permanently; winsorizing (capping at a threshold) keeps the row but limits its influence; a log transform reduces the influence of all large values proportionally rather than singling one out. Reach for the most surgical option that addresses what's actually wrong.

Worked example

Say a $50,000 order shows up in a dataset where the 99th percentile is $1,200. Checking the account: it belongs to a corporate customer with three other orders over $30,000 in the past year, and the order line items list 500 units of the same product, consistent with a bulk purchase. That's a legitimate outlier, kept as-is for a sum, and probably fine to leave untouched for a median too since it won't move it much. Contrast that with a second $50,000 order from a first-time individual customer buying a single unit of a $12 product: no supporting evidence, and a quick check shows the quantity field was likely fat-fingered as 4,000 instead of 4. That one gets corrected (or excluded and flagged), not because it's large, but because there's a specific, checkable reason to distrust it.

Trade-offs and pitfalls

The temptation to "just remove outliers because they skew the numbers" is a real trap: skewing the numbers is sometimes the entire point, if the numbers are genuinely skewed. Document whatever decision you make and why, since a silent removal is invisible to anyone auditing the analysis later, and a wrong call here (removing real revenue, or keeping a fat-fingered order) directly changes a business number.

Direct answer

The common data types you'll encounter are integer, float, string, datetime, boolean, and categorical, and the most frequent pitfall is a column being stored as the wrong type: most commonly a date or number stored as a plain string. That single mis-typing silently breaks anything downstream that assumes the correct type: date filtering, numeric aggregation, or sorting will either error out or, worse, quietly return a wrong answer without any error at all.

Detecting a mis-typed column

Check the declared or inferred dtype against what the column NAME and a sample of its VALUES imply. A column called signup_date that comes back as a generic object or string type, rather than a proper date type, is the single most common surprise in a first pass. Similarly, a numeric-looking column stored as text (often because of a stray currency symbol, a thousands separator, or a mix of numbers and placeholder text like "N/A") will silently fail to aggregate correctly, or will sort as if "10" comes before "9" because it's comparing characters, not values.

Worked example

A signup_date column is stored as text with a mix of formats ("2024-01-05" and "01/05/2024" both appear). Filtering "signups after 2024-01-01" using a plain string comparison will get some rows wrong, since string comparison doesn't understand calendar order the way a proper date comparison does. Converting the column to an actual datetime type first, and confirming there are no unparseable values left over, is a five-minute fix that prevents a much harder-to-spot downstream bug: a report that's silently wrong for exactly the rows in the less-common date format.

Trade-offs and pitfalls

Don't just trust the dtype the tool infers automatically: automatic type inference can guess wrong (a column of all-numeric-looking product codes like "007" gets inferred as an integer, silently dropping the leading zero) just as often as a human assumption can. Always spot-check a sample of actual values against the inferred type, not just the type label itself.

Direct answer

Exploratory analysis is open-ended pattern-finding on data you already have, meant to generate hypotheses and build intuition; confirmatory (inferential) analysis is a pre-specified test of a hypothesis, ideally on fresh data, meant to decide whether an observed pattern is real or noise. The distinction matters because a pattern discovered through open-ended exploration hasn't been tested against anything yet: if you go looking hard enough across many slices of the same data, you WILL find something that looks interesting purely by chance, and treating that discovery as already-proven is how EDA quietly turns into unintentional p-hacking.

The transition from one to the other

EDA should end with a specific, falsifiable hypothesis ("weekend signups convert at a lower rate than weekday signups"), not a conclusion. Confirmatory analysis then tests that specific hypothesis, ideally against data or a time window you didn't use to generate the hypothesis in the first place, using a pre-registered test rather than whichever test happens to come back significant. Descriptive statistics (what happened) and inferential statistics (what we can conclude about the broader pattern) map onto this same boundary: summarizing last quarter's churn rate is descriptive, while estimating whether a new pricing tier will reduce churn going forward requires inference.

Worked example

While exploring an engagement drop, you notice active users dipped 8% the week a UI change shipped. That's an EDA finding, a hypothesis, not a proof: the same week also had a holiday, a competitor promotion, and normal week-to-week noise. Confirmatory analysis means designing a specific test (a difference-in-differences comparison against a similar prior period, or ideally a proper A/B test on the UI change itself) and pre-specifying what result would count as support versus refutation, rather than continuing to slice the exploratory data until you find a cut that confirms your initial hunch.

Trade-offs and pitfalls

The most common failure is presenting an EDA finding with the confidence of a confirmatory result, skipping the formal test entirely because the pattern "looks obviously real." The complementary failure is over-formalizing every EDA finding with a full statistical test when a quick sanity check would do, which slows down the exploratory phase without adding real rigor if the underlying hypothesis was going to be tested properly downstream anyway.

Direct answer

Make the case with concrete evidence rather than a general appeal to rigor: bring data on what share of past incidents or bad decisions were traceable to a data issue that a thorough EDA pass would likely have caught, and propose a lightweight, time-boxed process instead of framing it as an all-or-nothing choice between "skip EDA" and "take a full day."

Building the advocacy case

Quantify the cost of skipping EDA in terms the team already tracks: incidents, wasted engineering time chasing a bad number, or a shipped feature that had to be walked back because of a data problem that could have been caught earlier. Then propose something concrete and cheap enough that "compress sprints" and "keep basic EDA" aren't actually in tension: a lightweight, standardized checklist (the kind of first-pass structural checks that take an hour, not the deep case-study kind that takes days) built into the sprint cadence rather than treated as a separate, cuttable phase.

Worked example

Reviewing the last two quarters of incidents, three of eleven were traceable to a data issue (a schema change nobody caught, a duplicate-event bug, a currency-unit mix-up) that a basic first-pass EDA checklist would very likely have surfaced before shipping. Bringing that specific number ("roughly a quarter of our incidents this half were data issues a one-hour check would likely have caught") alongside a proposed lightweight checklist template that fits inside a normal sprint, rather than asking for a separate EDA phase, reframes the ask from "give me more time" to "let's not cut the one-hour version of this."

Trade-offs and pitfalls

Avoid over-claiming: not every future incident would have been caught by a basic EDA pass, and inflating the number undermines the credibility of the argument. The strongest version of this pitch pairs a specific, honest track record with a concrete, low-cost proposal, rather than a general appeal to "we should always be thorough."