You open the CSV your supplier sent you, expecting a clean list of products. What you find is something else: columns named differently from last time, barcodes turned into something like "5.01E+12", products with no identifier at all and the same item listed three times at three prices. Before you can enrich or publish anything, that mess has to be fixed. That's normalization's job: the most boring and most decisive stage in the catalog.
Why the supplier's CSV is always messy
It isn't bad faith; it's entropy. Every supplier exports in their own way, every export goes through an Excel that "helps" by breaking things, and the data has been handled by several people with different criteria. The result is that two files from the same supplier are almost never the same, and none of them is ready for your store.
The real problems (not the textbook ones)
- EANs in scientific notation: Excel turns 5012345678901 into "5.01E+12" and, if it saves it truncated, you lose the code.
- Leading zeros that vanish: an EAN that starts with a zero ends up one digit short, and a SKU "00123" becomes "123".
- Columns that change name and order with every export.
- Products with no EAN or SKU: they can't be identified or matched to your catalog.
- Duplicates: the same item several times, sometimes with contradictory data.
- Formats and categories done their own way: decimal commas in one file and decimal points in the next, and categories that look nothing like yours.
What normalization does
Recognizes which column is the title, which is the EAN, which is the price… even when they change names, and suggests the mapping.
Undoes the scientific notation, restores the missing leading zeros on the EAN and validates it with its check digit. If an EAN is broken beyond repair, it flags it instead of letting it slip through.
Spots the same item repeated and merges it, instead of creating three products where there's only one.
Reads Spanish-style decimals ("17,45", "1.234,56") and recognizes whether the file is separated by commas, semicolons or tabs.
Translates the supplier's categories into yours, which almost never match.
EAN or SKU: the identity rule
A decision that seems minor and changes everything: how you identify a product. Not every product has an EAN — in fact, a good share of a retail catalog doesn't — so requiring one leaves half the warehouse out. The sensible rule is "at least an EAN or a SKU, EAN preferred": match by EAN, then by SKU, and if there's neither, flag it. What you should never do is match on an empty EAN: it would match any other product without an EAN and mix up items that have nothing to do with each other.
Why such a boring stage matters so much
Because everything that comes after is built on top of it. If normalization fails, enrichment writes from bad data, images get assigned to the wrong product and publishing sends garbage to your store. It's the classic "garbage in, garbage out". Normalization doesn't shine in a demo, but it's the foundation that a catalog you can trust stands on.