Dropping every row with a missing value feels safe. It’s often the worst option available — handling missing data machine learning projects face is rarely as simple as deleting the gaps and moving on.
Handling missing data machine learning models actually need
Missing data isn’t random noise to discard — it’s information. Whether a value is missing at random, missing because of what it would have been (a high earner skipping an income field), or missing due to a collection quirk changes which fix is appropriate. Handling missing data machine learning pipelines encounter without asking why it’s missing is how quiet bias creeps in.
Mistake 1: dropping rows by default
Deleting every row with any missing value can silently shrink and bias a dataset — if the value tends to be missing for a specific subgroup, dropping those rows removes that subgroup’s signal from the model entirely, not just the missing cells.
Mistake 2: filling with the mean and moving on
Mean imputation is a reasonable default for a small amount of randomly missing numeric data, but applied carelessly it compresses variance and can create implausible combinations of features that never occur together in real records.
Mistake 3: fitting the imputer on the full dataset
Computing an imputation value (mean, median, mode) using the entire dataset, test set included, is a specific form of data leakage — the same category of mistake covered in data leakage in machine learning. The imputer should be fit on training data only, then applied to the test set.
What actually works: catching it at the source
The retail ETL pipeline gates raw exports behind explicit null checks before anything reaches the warehouse, so unexpected missing values get caught and flagged at ingestion rather than silently propagating into downstream reports. The retail analytics warehouse takes the same approach — not-null tests run as part of its 35 automated data-quality checks on every build, turning “missing data” from a surprise into a caught, visible failure.
Choosing the right fix once you know why data is missing
- Missing completely at random: mean/median imputation (fit on training data only) is usually reasonable.
- Missing with a pattern tied to another feature: model-based imputation (predicting the missing value from other features) captures more signal than a flat average.
- Missing because of the value itself: often better to add a “was missing” indicator flag alongside the imputed value, so the model can still use the fact that it was missing as a signal.
- Missing at high rates for a whole column: sometimes the column itself should be dropped rather than heavily imputed.
A quick checklist
- Do you know why the data is missing, or are you assuming it’s random?
- Is your imputation strategy fit on training data only, or leaking test-set information?
- Are you validating for unexpected nulls automatically, or discovering them manually after something breaks?
- Would a “was missing” indicator flag preserve information your imputation strategy would otherwise discard?
FAQ
Is it ever fine to just drop rows with missing data?
Yes, when the missing rate is very low and genuinely random — but that assumption is worth verifying, not assuming by default.
What’s a “missing indicator” column?
A binary column marking whether a value was originally missing before imputation, which lets the model use “this was missing” as a signal rather than losing that information entirely.
Should missing-data handling happen in the pipeline or in the model?
In the pipeline, and tested automatically — catching missing data at the ETL stage, as in the retail ETL project, is more reliable than hoping the model handles it gracefully downstream.
