Exploratory Data Analysis and Data Quality Questions

Direct answer

Quantify class imbalance with the simple ratio or proportion of each class (for example, "1.2% positive, 98.8% negative"), and visualize it with a bar chart of counts or a single stacked bar. Imbalance becomes worth flagging once the minority class is small enough that a model (or a naive report) could look accurate while never actually recognizing that class, which in practice often starts becoming a real concern somewhere below a 10 to 20 percent minority share, and is a serious concern below 1 to 5 percent.

Why the threshold is fuzzy, not fixed

There's no single cutoff because "problematic" depends on what you're trying to detect and how costly a missed minority case is. A 20% minority class is barely worth mentioning for a low-stakes internal report, but a 20% "fraud" rate would be shockingly high in most real fraud datasets and worth double-checking your labeling before anything else. The right question during EDA isn't "is this technically imbalanced" but "does this imbalance change how anyone downstream should interpret an aggregate number or a model's apparent accuracy."

Worked example

A churn dataset has 10,000 rows: 9,500 labeled "did not churn" and 500 labeled "churned," a 5% minority rate. Reporting "our model is 95% accurate" is nearly meaningless here, since a model that predicts "never churns" for every single customer would already hit 95% accuracy without learning anything. Flagging this during EDA (a simple bar chart and a one-line note: "positive class is only 5% of rows, accuracy alone will be misleading") changes the conversation before anyone builds or evaluates a model on this data.

Trade-offs and pitfalls

Don't treat imbalance discovery as the same thing as imbalance handling: EDA's job is to notice and quantify it, not necessarily to fix it (oversampling, class weighting, and threshold tuning are downstream modeling decisions). Even a reporting-only analyst who never trains a model should still flag severe imbalance, since it changes how any summary statistic on the rare class should be interpreted and communicated.

Direct answer
Prioritize which KPIs make an executive dashboard using five criteria: business impact (does it materially affect a decision that will actually be made), data quality (is the underlying data trustworthy enough to act on), actionability (can someone do something differently if it moves), stakeholder needs (do the actual intended viewers care about it), and metric stability over time (does its definition and data source stay consistent, so trend comparisons remain valid).

Structured elaboration

• Business impact: prioritize metrics that materially affect a real decision someone will make, over metrics that are merely interesting or "nice to know."
• Data quality: a KPI built on unreliable, frequently-broken, or poorly-validated source data undermines trust in the whole dashboard the first time it's visibly wrong; don't promote a metric to the executive view until its underlying data pipeline is solid.
• Actionability: for each candidate KPI, ask what a viewer would actually DO differently if the number moved; a metric nobody would act on, regardless of its value, is a candidate for exclusion or demotion.
• Stakeholder needs: validate the candidate list against what the actual intended audience says they need to make their decisions, not just what's easiest to compute from available data (post-EDA, the analyst often has many candidate metrics ready to go, but not all of them matter to the audience).
• Metric stability over time: prefer metrics whose definition and computation won't need to change frequently, since a KPI that gets redefined every few months breaks trend comparability and undermines trust in historical context.

Worked example
After exploratory analysis surfaces a dozen candidate metrics, an analyst narrows to the 5-6 that combine strong business impact, validated data quality, clear actionability, explicit stakeholder buy-in, and a stable definition, deferring the rest to a secondary/analyst-facing view rather than including every metric that was merely interesting to compute.

Trade-offs and pitfalls
Including a metric primarily because it was easy to compute during EDA, without validating it against actual stakeholder needs and data quality, is how executive dashboards accumulate metrics nobody asked for and few people trust.

Direct answer

On a small sample table with age missing for one user and country missing for another, look at what else is known about each row before concluding anything: if the missingness seems tied to specific OTHER observed fields (say, both missing values belong to users with very short last_active_days, suggesting incomplete signups rather than a random gap), that points toward missing at random (MAR) rather than missing completely at random (MCAR); if there's no such pattern at all, MCAR is the more plausible working assumption, though a sample this small can't rule out much with confidence either way.

Reading the indicators in a small sample

The judgment here is necessarily provisional: with only a handful of missing values, you're looking for suggestive patterns, not statistical proof. Check whether the missing values cluster on particular values of other observed columns (a specific signup channel, a specific date range, a specific last_active_days value) rather than spreading randomly across the table; a cluster is a hint worth chasing further, while a scattered, unpatterned handful of missing values in an otherwise unremarkable small sample is consistent with MCAR, though genuinely inconclusive at this size.

Worked example

In a four-row sample: age is missing for the user with last_active_days of 5, and country is missing for the user with last_active_days of 30. If this were the ENTIRE evidence, it's genuinely ambiguous at n=4, but the diagnostics worth running on a larger version of the same table would be: does age missingness correlate with recency of signup or activity level across many more rows (pointing toward MAR via activity level as the observed explanation), or does it look scattered across every level of activity (more consistent with MCAR)? The two concrete diagnostics to propose here are a missingness-versus-last_active_days crosstab and a simple bar chart of missingness rate by signup cohort, both cheap to run once you have more than four rows to work with.

Trade-offs and pitfalls

Resist over-interpreting a genuinely small sample: the honest answer at n=4 is "here's a hypothesis and here's how I'd test it on the full dataset," not a confident MCAR-versus-MAR conclusion drawn from four rows.

Direct answer

A good EDA report includes: a short summary of what was checked and what was found, a missingness and data-quality section, the key insights with supporting visuals, and an explicit list of risks or caveats. Attach the artifacts that let someone else verify or build on the work: the sample queries or code used, a small data dictionary for any non-obvious columns, and a list of known issues with recommended fixes.

Why each section earns its place

The summary orients a reader who won't read the whole thing; missingness and quality findings set expectations for how much to trust everything that follows; the key insights are the actual payload, but they're only as credible as the caveats section that sits next to them, since an insight presented without its limitations invites someone to over-trust it. The artifacts (queries, data dictionary, known issues) exist so the report is a starting point for the next person, not a dead end they have to reconstruct from scratch.

Worked example

Handing off an EDA on a new events table to the engineering team: the report opens with "500K rows, covers Jan-Mar, 12% null on device_type"; includes a chart of daily event volume with a clear anomaly flagged around March 3rd (later traced to a logging outage); lists three specific data-quality issues (the outage window, a duplicate-event pattern from client retries, and an inconsistent timezone field) each with a recommended fix; and attaches the exact SQL used to compute the daily volume chart plus a short data dictionary explaining what event_type values mean, since that's not obvious from the column name alone.

Trade-offs and pitfalls

Keep the report proportionate to the audience: a stakeholder wants the findings and risks in plain language up front, while the engineering handoff wants the queries and known issues in detail. Don't bury the caveats at the bottom where they'll be skipped, since the caveats are often the single most important thing preventing someone from over-trusting a headline number.

Direct answer

Compare the population your dataset claims to represent against what you can independently verify about the true population (known demographic splits, known day-of-week patterns, a trusted external benchmark), and look specifically for a systematic gap rather than random noise. A logging job that only runs on weekdays, or a data source that overrepresents one geography, both produce a dataset that LOOKS complete but silently underrepresents a real slice of the population it claims to describe.

Detecting the pattern

For a suspected weekday-only logging gap, plot event counts by day of week: a genuine flat pattern with only ordinary variation looks very different from a pattern where weekends are consistently and dramatically lower, which points toward a collection gap rather than genuinely lower weekend activity. For a suspected geographic overrepresentation, compare your dataset's regional mix against an independent, trusted benchmark of the true population (census data, a platform-wide user count) rather than assuming your own data's mix is representative just because it's what you have.

Worked example

A web analytics dataset shows weekend event volume at roughly 20% of weekday volume, while every other signal about the business (customer support ticket volume, revenue) shows weekend activity closer to 70-80% of weekday levels. That gap is a strong signal the logging job itself has a weekday-only schedule, not that users genuinely stop using the product on weekends. Separately, comparing a customer dataset's country mix against known national population figures reveals urban users at double their true population share, consistent with a collection method (like an app requiring reliable connectivity) that systematically favors more urban, more connected users.

Trade-offs and pitfalls

Flag this clearly before anyone builds a model meant to generalize to the full week or the true population: a model trained only on weekday-logged data, or on an urban-skewed sample, will confidently make predictions for exactly the population it under-observed, without any obvious warning sign in its own reported accuracy.