Exploratory Data Analysis and Data Quality Questions

Direct answer

In practice, distinguishing missing completely at random (MCAR) from missing at random (MAR) relies on indirect statistical evidence, most commonly Little's MCAR test (a formal hypothesis test for whether missingness is unrelated to the observed data as a whole) or a simpler, more transparent approach: regress a binary missingness indicator against the other observed variables and see whether any of them significantly predict it. If observed variables do predict the missingness pattern, that's evidence against pure MCAR and toward MAR.

Honest limitations

Neither approach can ever fully confirm MCAR, since these tests can only tell you the missingness ISN'T explained by what you happen to have observed; they say nothing about whether it's explained by the unobserved value itself (which would make it MNAR, and no amount of testing against observed variables can rule that out). Little's test also assumes a particular structure (often multivariate normality) that real business data frequently violates, and with enough rows, even a trivially small, practically meaningless relationship can register as "statistically significant," which is a classic large-sample-size trap.

Worked example

Running a missingness-indicator regression on a customer dataset where income has missing values: regressing a binary "income is missing" indicator against age, tenure, and account type reveals that age significantly predicts missingness (older customers are more likely to have a missing income value), while tenure and account type don't. That's evidence consistent with MAR (missingness explained by an observed variable, age) rather than MCAR, but it's still not proof the mechanism isn't MNAR too, since income could ALSO be more likely to be missing specifically among high earners, a pattern this test can't see because it only checks against observed variables.

Trade-offs and pitfalls

Treat these diagnostics as evidence that shifts your confidence, not a final verdict: on a genuinely large operational dataset, run the check, but pair the statistical result with domain reasoning about WHY the missingness might occur, since the test alone can mislead in either direction (a trivial effect flagged as significant, or a real MNAR pattern invisible to any test built only on observed variables).

Direct answer

Run exploratory analysis to propose a concrete, measurable definition rather than accepting the vague request as-is: inspect what data sources plausibly relate to "satisfaction" (support tickets, survey responses, churn, product usage), look at their distributions and how they relate to each other, and sanity-check any candidate definition against cases where you already have strong intuition about whether a customer was satisfied or not.

Building toward a defensible definition

Start by asking what decisions this score is meant to inform, since that shapes what "satisfaction" should even mean operationally. Then explore candidate inputs (survey scores if they exist, support-ticket sentiment or volume, usage trends, churn or renewal behavior) individually: their distributions, how much missing data each has, and whether they move together or tell conflicting stories. Before publishing, sanity-check the proposed score against a handful of accounts where you already have strong outside knowledge of whether the customer is happy or not, since a definition that contradicts obvious cases needs revisiting before it goes on a dashboard.

Worked example

Exploring three candidate signals: an NPS-style survey (Net Promoter Score, only 15% response rate, but where it exists it's directly interpretable), support-ticket volume normalized by account size, and month-over-month usage trend. The survey alone is too sparse to use on its own; ticket volume alone conflates a heavy but happy power-user with a genuinely frustrated one. Combining usage trend with ticket volume (weighted more heavily since it covers 100% of accounts) and validating the resulting score against ten accounts the account management team already has strong opinions about shows reasonable agreement in eight of ten cases; the two disagreements turn out to be accounts with unusually low usage for legitimate seasonal reasons, prompting a seasonal adjustment before the definition ships.

Trade-offs and pitfalls

A metric built this way should ship with its definition and known limitations attached, not just a number, since "customer satisfaction score" invites people to treat it as an objective fact rather than the constructed proxy it actually is.

Direct answer

Organize an EDA project so raw data, processed/derived data, notebooks, and outputs (charts, summary tables) each live in their own clearly separated folder, with notebooks kept thin (orchestration and narrative) while the actual logic lives in importable scripts or functions. Version both the code and, where practical, a snapshot or hash of the dataset you ran against, so someone else (including future you) can regenerate exactly what you found.

What makes it actually reproducible

The core discipline is separating "what changes every run" (raw inputs, generated charts) from "what defines the analysis" (code, parameters). Notebooks are great for narrative and iteration but terrible as the single source of truth for logic that needs to be re-run reliably, since cell execution order can silently diverge from the file's visual top-to-bottom order. Moving real logic into scripts or a small package, and having the notebook just call into it, means the analysis can be re-run from a clean state and get the same answer. Recording a data snapshot (a hash, a date-stamped extract, or a fixed query with a pinned date filter) closes the other common gap: source data changing under you between when you ran the analysis and when someone tries to reproduce it.

Worked example

A concrete layout: data/raw/ (untouched extracts, never edited by hand), data/processed/ (derived tables, each generated by a named script so you know how they were built), notebooks/ (numbered, narrative-focused, each one calling into shared code rather than redefining logic inline), src/ (the actual transformation and profiling functions, unit-testable and importable), and outputs/ (charts and summary tables, each named with the date and the script that generated it). A lightweight CI check that re-runs the core profiling script on a small fixture dataset catches silent breakage before it becomes someone's afternoon mystery.

Trade-offs and pitfalls

Don't over-engineer this for a one-off, half-day exploratory look, the ceremony of scripts, packages, and CI is worth it once an analysis is going to be revisited, shared, or built upon, not for genuinely throwaway exploration. The most common failure mode is a notebook that "worked" once, in an execution order nobody wrote down, and can't be reliably re-run six months later when someone needs to check the numbers again.

Direct answer

Investigate a near-constant column (95% one value, 5% something else) by first checking whether the rare non-null values are genuinely informative or just noise, and whether the column's near-constant nature is a real property of the world or an artifact of how the data was collected. If the rare values correlate meaningfully with anything else you care about, the column is worth keeping, likely as a flag ("is this the common value or not") rather than as a raw feature; if the rare values look like noise or errors, the column may be safe to drop.

What would change the answer

Check whether the 5% of non-default values cluster around anything specific (a particular time period, a particular customer segment, a particular data source), which would suggest they're a real, meaningful minority case rather than noise. Also check whether the dominant value looks like a genuine business state (say, "active" status for most rows) versus a suspicious default that might indicate a field nobody actually fills in reliably (like an optional form field left at its pre-filled default 95% of the time). The two scenarios call for very different conclusions even though the raw statistics look identical.

Worked example

A subscription_tier column is "free" for 95% of rows and something else for the remaining 5%. Checking whether that 5% correlates with anything: it turns out those users have dramatically higher engagement and retention, meaning the column, despite being heavily skewed, is carrying real, valuable signal about a small, genuinely different population. Contrast that with a referral_source field that's the literal string "unknown" for 95% of rows and a mix of real values for the rest: checking whether "unknown" correlates with a specific signup date range reveals it was simply never collected before a certain date, meaning the near-constant value here is a data-collection artifact, not a meaningful state.

Trade-offs and pitfalls

Don't drop a near-constant column reflexively just because it looks like "not much information": a rare-but-meaningful minority value can be one of the most useful signals in the whole dataset, precisely because it's rare and distinguishes a small group from everyone else.

Direct answer

Before anything else, get the shape of the problem: how many rows and columns, what each column's type actually is (not what it claims to be), how much is missing, and whether the target or key business columns look plausible. That first pass tells you whether you can trust anything else you compute.

A repeatable process

1. Load and inspect the skeleton. Row count, column count, dtypes, memory footprint, and the first/last few rows. Check that dtypes match what the column names imply (a "date" column stored as a string is the most common surprise).
2. Quantify missingness and duplication. Null rate per column, exact and near-duplicate row counts. A column that's 60% null changes everything downstream.
3. Univariate pass. For numeric columns: min, max, mean, median, standard deviation, and a histogram or boxplot. For categorical columns: cardinality and the top values by frequency. This is where you catch impossible values (negative ages, dates in the future) and near-constant columns.
4. Bivariate pass. Correlations among numeric features, and cross-tabs or grouped summaries for categorical-versus-target relationships. Look for anything suspiciously strong, since a feature that predicts the target almost perfectly is often leakage rather than a genuine signal.
5. Sanity-check the story. Do the aggregate numbers match what you'd expect from domain knowledge? If revenue should be roughly flat month over month and it triples, that's worth chasing before you build anything on top of it.
6. Write it down. A short profile (what you checked, what you found, what's still unresolved) is the artifact that lets someone else pick up where you left off, and it's the difference between EDA that informs a decision and EDA that lives only in your head.

For non-tabular data (text, images, audio), the same shape applies at a different unit: token-length or file-size distributions and corrupt-file checks stand in for the numeric-column checks above.

Worked example

Say you're handed a 50,000-row CSV of orders. In the first pass you find: order_date is stored as text with three different formats, 8% of rows are missing customer_id, and amount has a maximum value 40 times the 99th percentile. None of that tells you the final answer yet, but it tells you exactly what to chase next: normalize the date formats, decide whether the missing customer_id rows are guests or a logging bug, and pull the handful of extreme amount rows to see whether they're real (bulk orders) or data-entry errors (a misplaced decimal point).

Trade-offs and pitfalls

The most common failure is treating EDA as a checklist you complete once and never revisit: as you clean and re-derive columns, re-run the same univariate and bivariate checks on the new versions, because a fix to one column can introduce a new artifact in another (for example, dropping "impossible" rows can quietly shift a category's proportions). The other common failure is skipping straight to modeling-relevant checks (correlations, class balance) before confirming the basics (types, missingness, duplicates), which means you build early conclusions on data you haven't actually verified yet.