Data Cleaning

Fixing collected data up into a usable state

  • Intro
  • 5 min read
  • 3 diagrams

Key points

  • 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 brand-new facts. Even when filling in a blank, the value gets marked as an estimate, and 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.

The 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.

In 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, a big share 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.

More 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.

Try it yourself

Common misconceptions

  • It's easy to think cleaning can be sloppy once there's a lot of data, but actually even with more data, flaws like duplicates or lopsided errors don't get buried, and they get learned as they are.

  • It's easy to think cleaning is mostly about deleting things, but actually filling in blanks, fixing wrong values, and matching up formatting take up as big a share of the work as 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.

One-line summary

In short

Data 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 updated 2026-10-17