Data Cleaning
Fixing collected data up into a usable state
- Data cleaning means fixing up whatever's wrong or missing in collected data until it's usable.
- There are four main things it deals with: duplicates, blanks, wrongly entered values, and inconsistent formatting.
- It's not about inventing facts that aren't there. Cleaning stops at selecting and tidying what's already there.
- It happens before training, so whatever flaw slips through here carries straight into everything after it. Cleaning often lifts a score more than switching models does.
- Don't just delete anything that looks off. It might really have happened, so whether to keep or drop it needs its own judgment call.
Contents
1The analogy
Few households scoop rice straight from the bag into the pot. You add water and rinse it a couple of times, skim off the husks and debris floating on top, and pick out the small stones your fingers catch. None of this changes the rice grains themselves. It just gets them into a state where they can become rice. Data cleaning is exactly this kind of work.
Miss one stone and the rice still cooks. Someone just bites down on it and chips a tooth. Leave too much husk in and the rice smells off. Skipping this step to save time feels tempting, but every process downstream ends up carrying that flaw along with it.
Wash away perfectly good rice grains along with the debris, though, and there isn't enough rice left. Deciding what to skim off and what to keep is half of what cleaning actually is.
2In detail
Rinsed away: duplicates and blanks
The same customer registered twice, or the same photo saved under two different filenames, happens constantly. Leave a duplicate in and that one record ends up carrying double the weight. Training treats whatever it sees more often as more important, so results skew toward whatever happened to get entered twice.
Blanks are trouble too. A row with an empty age field and an empty address field can stop a calculation cold. Pick one of a few approaches: drop the row entirely, fill it with something like the middle value of what's there, or mark it explicitly as "no value." Whichever gets picked, writing it down matters, so the result can be explained later.
The stone your fingers catch: wrongly entered values
A height entered as 300 centimeters, a birth year in the 1800s, a negative order quantity, these turn up. They're the trace of a slipped finger during entry, or a machine misfiring for a moment. One value like this can drag an average way off course.
Not every outlier is a mistake, though. Daily sales thirty times the usual amount might be a typo, or it might really have been an event day. So cleaning is really two jobs fused together: spotting values that look off, and checking whether they're real. When there's no way to check, it often gets flagged instead of deleted, and passed along.
Matching the scale: inconsistent formatting
The same meaning written different ways shows up constantly. If one column mixes "NYC," "New York City," and "New York," a machine counts those as three separate places. Dates cause the same problem, one row written year-month-day, another month-day-year, and the timeline gets scrambled.
Units need matching too. Mix kilograms and grams in a weight column and some rows end up a thousand times heavier than they should. Small things like a stray leading space, mismatched capitalization, or a hyphen in a phone number, a machine treats every one of those as an entirely different value.
Leaving a trail of what was done
Cleaning isn't a one-time tidy-up. What got deleted under which rule, and what got filled in, needs to be written down as a list, so the same rule can be reapplied when new data comes in. Without a record, the standard used two months ago and the one used today quietly drift apart.
Keeping the original untouched matters too. Save the cleaned file separately and leave the raw one alone, and there's somewhere to go back to if a call turns out to be wrong. Keeping the removed rows in their own pile is even better, that's the first place worth checking when a result looks strange.
It's worth knowing how much effort cleaning actually takes. In practice, more than half of the time spent handling data commonly goes into cleaning. It's not the flashy part, but skimping on it means spending far longer later hunting for the cause of a weird result.
3More precisely
Data cleaning is usually one part of the larger stage called preprocessing. Preprocessing also covers rescaling values, converting formats, and selecting which features to use. Cleaning specifically handles the job of fixing what's wrong and filling what's missing.
The analogy breaks in one place. Rinse rice and you can see how clear the water runs to judge how clean it got, but there's no way to eyeball whether data has finished being cleaned. So cleaning gets checked indirectly instead, plotting how values are distributed, or counting how many rows still break the rules.
Timing matters too. Decide what value to fill blanks with by looking at the whole dataset before splitting it into training and test sets, and information from the test set slips into training. The fill value should be decided using only the training data, then applied to the test data as-is, that order needs to be kept.
Cleaning rules also need to be reusable, not one-off fixes typed directly into a spreadsheet. Writing them as a small script that can run again on the next batch of data is what turns cleaning from a chore repeated by hand into a step that scales.
4Try it yourself
5Common misconceptions
It's easy to think cleaning can be sloppy once there's a lot of data, but actually more data means more bad rows too, so skipped cleaning leaves an even clearer trace.
It's easy to think cleaning is mostly about deleting things, but actually filling in, fixing, and matching up formatting make up far more of the work than deleting does.
It's easy to think cleaning is done once and stays done, but actually as long as new data keeps arriving, the cleaning rules need to keep being revisited too.
7One-line summary
In shortData cleaning fixes up duplicates, blanks, and wrongly entered values in collected data until it's usable, and whatever flaw slips through here shows up plainly downstream.
Spotted an error or have a better analogy? Suggest an edit · Last updated2026-09-02