Data normalization

A buyer searching for 1/2" copper fittings won't find the SKU your supplier cataloged as ".5 in" — even if it's the exact part. Faceted filters are unforgiving: the filter logic compares stored values directly, and "0.5 in", "1/2 inch", "12.7 mm", and "½"" are four different strings, not one size.

This is the core problem data normalization solves. It has nothing to do with whether the data is accurate. A weight of "2.3 kg" is just as correct as "5.07 lbs" — but if your catalog holds both formats across 80,000 SKUs, your weight filter is broken for roughly half of them.

In industrial distribution, where catalogs routinely span dozens of supplier feeds arriving in different schemas, the damage is measurable. Research from Akeneo's 2024 Product Experience Report found that 30% of product returns are driven by inaccurate or incomplete product information — a category that includes mismatched formats causing a buyer to select the wrong spec. The failure mode isn't always a missing field; sometimes it's a field present in a format that no system downstream can reconcile.

Normalization is not a single step. A complete pass across a B2B catalog typically involves five distinct operations:

1. Canonical value mapping. Every variation of the same value is collapsed to a single accepted form. "lbs", "lb", "pounds", "LBS", and "lb." all map to "lb". This requires a controlled vocabulary — a master list of accepted values for each attribute — and a mapping table that translates incoming variants.

2. Unit of measure standardization. Decide on a primary unit per measurement type and convert all values to it. Length might normalize to inches; weight to pounds; voltage to volts. Conversion happens at ingest, and the original supplier value can be stored separately for reference.

3. Attribute name reconciliation. Suppliers call the same attribute by different names. One calls it "Ship Weight", another "Shipping Weight", a third "Item Wt (lbs)". Before any value normalization can work, those need to resolve to a single attribute name in your schema — in this case, something like "shipping_weight_lb".

4. Format enforcement. Dates in one consistent format. Booleans as true/false rather than "Yes" / "Y" / "1" / "✓". Numeric precision set to two decimal places where appropriate, not left to whatever the supplier exported.

5. Null and missing-value conventions. Decide whether a missing attribute is stored as null, an empty string, or omitted entirely. Inconsistency here breaks downstream logic just as readily as inconsistent units.

None of this requires AI. A well-maintained normalization ruleset running at ingest — often called a transformation pipeline or data prep layer — handles the deterministic cases automatically.

Normalization and enrichment are often conflated, but they solve different problems and the distinction matters when scoping a catalog project.

Normalization fixes the form of what you already have. A SKU enters with "weight: 5.07 lbs" and exits with "weight_kg: 2.30". The attribute was there; the format was wrong. Normalization corrects it.

Enrichment adds what was never there. That same SKU might be missing tensile strength, certifications, application guidance, or a description written for how a buyer actually searches — not for how the manufacturer documented the product internally.

A catalog can be fully normalized and still convert poorly, because normalization doesn't fill the gaps buyers use to make decisions. The industrial HVAC buyer filtering by refrigerant compatibility needs that attribute to exist, not just to be consistently formatted.

Anglers's approach treats normalization as table stakes — a prerequisite, not the goal. The work that moves conversion metrics is buyer-signal enrichment: identifying the attributes buyers actually use to evaluate and compare, then filling those from every available source and scoring completeness against that standard, not against an arbitrary field count. A catalog where every weight is in kilograms but 40% of SKUs are missing compatibility data is consistent, not complete.

Normalizing to internal codes instead of buyer language. A distributor might normalize product colors to internal color codes ("BLK", "SLV", "GRN") for inventory reasons. But the buyer searches "black" and "silver". Normalization needs to produce output that matches buyer vocabulary, not just internal shorthand.

Treating it as a one-time project. Supplier feeds update on their own schedule, with their own format changes. A normalization run in Q1 is undone by a supplier who adds new attribute variants in Q2. Without automated governance at ingest — rules that catch and flag new variants before they enter the catalog — normalized data degrades back to entropy within months.

Over-normalizing into precision loss. Forcing every product into Small / Medium / Large when the buyer's decision depends on exact dimensions is worse than leaving the raw values. Not every attribute should be normalized to a controlled vocabulary. Some should be normalized to a unit and a precision, and left as a number.

Normalizing values without normalizing attribute names first. If "length" and "Length (in)" and "Dim_L" are still three separate fields in your schema, normalizing the values inside each of them doesn't help the search layer — it still sees three attributes where there should be one.

No feedback loop from channel failures. Retailers and marketplaces reject feeds for format reasons. Those rejections are a real-time signal about where normalization broke down. Teams that don't route rejection logs back into the normalization ruleset are missing the cheapest source of ground truth they have.