Product Data
Product Feed Normalization
Normalization is the pipeline that turns inconsistent merchant feeds into a clean, queryable product layer.
Updated 2026-07-01 · 9 min read
A discovery platform ingests product data from many merchants, and no two merchants describe their catalogue the same way. Normalization is the stage that reconciles this — the set of transformations that takes a raw, retailer-specific feed and produces records that share a common vocabulary, common units and common structure. Everything downstream depends on it: matching, filtering, ranking and price comparison all assume the data has already been normalised.
This page is the hub for the normalization process. It sits between the messy inputs described in why product data is hard and the structured outputs described in canonical product records. It also feeds directly into product matching and depends on offer quality to know which fields to trust.
What a raw feed looks like
A merchant feed is a periodic export of a retailer's catalogue, delivered as a file or via an API in whatever format the retailer's platform emits. The fields vary widely in completeness and naming. Some feeds are rich and well-structured; many are sparse, with the brand, model, colour and size all crammed into a single free-text title and little else populated. Field names collide across feeds — one shop's colour is another's variant is another's nothing at all.
The first job of normalization is therefore not transformation but interpretation: reading each feed's idiosyncratic structure and deciding which incoming field corresponds to which canonical field. This mapping is per-merchant, maintained deliberately, and revisited whenever a merchant changes its export format without warning.
Canonical fields
Normalization targets a fixed schema of canonical fields — the internal vocabulary the platform uses regardless of source. A workable minimum for footwear looks like this:
| Canonical field | What it holds |
|---|---|
| brand | Normalised brand, resolved from spelling and sub-brand variants. |
| model | Canonical model name, with aliases stored separately. |
| style_code | Manufacturer style code, cleaned and de-formatted. |
| colourway | Official colourway name plus normalised colour tokens. |
| size | Per-variant size normalised to a common scale. |
| price | Current price and currency, with list price where available. |
| availability | Stock state, ideally at size level. |
| image | Best available image URL, with quality flags. |
| product_url | The merchant landing page for the offer. |
Mapping a feed to this schema is lossy in one direction and lossy in the other: some incoming data has no canonical home, and some canonical fields have no incoming value. Both cases must be handled explicitly rather than silently dropped.
Brand and model normalization
Brand normalization resolves the many surface forms of a brand to a single canonical entity. This is done with a maintained mapping of known variants plus rules for casing, punctuation and common abbreviations, rather than by trusting the incoming string. Sub-brands and collaboration partners are resolved to their parent where appropriate, but the original string is retained so nothing is lost.
Model normalization is harder because the model is frequently embedded in free text alongside the brand, colour and gender. The process extracts a candidate model, matches it against a known catalogue of models and their aliases, and records the alias that was matched so future listings using the same nickname resolve quickly. Where a style code is present, it short-circuits much of this — the code identifies the model-and-colourway directly, and the noisy title becomes a secondary signal.
Price and stock handling
Prices and stock are the most volatile fields and get special treatment. Each ingested price is stamped with the time it was observed, so the platform knows how fresh it is and can flag or suppress prices that have gone stale. Where a feed reports both a list price and a sale price, both are retained; where it reports only one, the platform records which it is and avoids inventing a discount that the feed does not support.
Stock is normalised to a consistent set of states, and — critically — held at the size level wherever the feed allows it. A product marked available overall but with no wearable sizes in stock is a common and misleading case, so normalization preserves the size grid rather than collapsing it to a single boolean. The reliability of these fields varies sharply by merchant, which is why normalization records a source and a timestamp for every value it stores.
Producing canonical product records
The output of normalization is not yet a finished product record — it is a clean, per-merchant offer expressed in canonical fields. The final step, matching, groups these normalised offers so that all the offers for one physical shoe attach to one canonical product. Normalization makes that grouping possible by ensuring the offers are directly comparable; matching then decides which ones belong together.
Seen end to end, the pipeline is: ingest raw feed, map fields, normalise brand and model, normalise price and stock, emit canonical offers, then match. Each stage is auditable, and each value carries its provenance. That provenance is what lets a discovery platform explain and defend the data it shows, rather than presenting an opaque merge of untraceable sources.
Sources & further reading
- Google Search Central, “Product data specification for merchant feeds” (2024)
Sources are attributed to their publishers and link to each publisher's own site. Figures reflect general market direction rather than point-in-time precision; consult the linked publishers for their current data.