Product Data
Canonical Product Records
One shoe, one record — with every merchant offer and every size hanging off it in a defined structure.
Updated 2026-07-01 · 8 min read
Everything in this section converges on a single object: the canonical product record. It is the one authoritative entry a platform holds for a given shoe — the thing that all the messy incoming listings are resolved into, and the thing every user-facing feature reads from. Without it, a platform is just a pile of listings; with it, there is a stable product layer that search, comparison and recommendation can all build on.
This page defines the canonical record and the two structures that hang off it — offers and variants — and explains why a discovery platform needs this layer rather than operating directly on raw feeds. It is the destination of the pipeline that normalization and matching feed, and the foundation on which AI-driven discovery depends.
What a canonical record is
A canonical product record is the single, deduplicated representation of one physical product — for footwear, one model in one colourway. It holds the resolved, authoritative values for that shoe: its normalised brand, its canonical model name with aliases, its style code, its official colourway and colour tokens, and a chosen representative image. It is what the platform means when it refers to "the shoe", independent of any single merchant.
The record is built by matching, which decides that a set of normalised offers all refer to the same product and attaches them to one canonical entry. Once it exists, it becomes the stable identity that everything else references — a shopper browses canonical products, filters canonical products, and compares offers within a canonical product.
Products, offers and variants
The structured product layer has three levels, and keeping them distinct is what makes the layer work:
| Level | What it represents |
|---|---|
| Product | The canonical shoe: one model, one colourway, resolved and deduplicated. |
| Offer | A specific merchant's proposition for that product — price, stock, link, image. |
| Variant | A size within the product, whose availability and sometimes price differ per offer. |
A product has many offers; an offer covers a set of variants; a variant is the size a shopper actually buys. This structure is what lets the platform answer "which shops have this shoe in my size and at what price" — a question that is impossible to answer cleanly if products, offers and sizes are mashed into a single flat listing.
Why offers must stay separate
Offers are deliberately kept as their own layer beneath the product rather than being averaged or merged into it. Each offer carries its own price, its own stock, its own quality signals and its own freshness, and these must remain independently addressable. Collapsing offers into the product would destroy exactly the comparison the platform exists to provide.
Keeping offers separate also localises trust and volatility. A stale price or a broken link belongs to one offer, not to the product, so the platform can suppress a bad offer while still showing the shoe through its other offers. The canonical product stays stable and clean while the offers around it churn — which is precisely the separation of concerns a discovery platform needs.
Why variants belong to the product
Sizes are modelled as variants of the product rather than as separate products, because a shoe in size eight and the same shoe in size nine are the same shoe. Treating sizes as distinct products would fragment the catalogue and make "in my size" queries incoherent. Instead, the size grid lives as a set of variants under the product, and each offer reports availability at the variant level.
This is what lets availability be answered precisely. A shopper asking for a specific size queries the variant across all of the product's offers, and the platform can say which merchants have that size, at what price and how fresh the information is. Colour, by contrast, is not a variant but a separate product, because a different colourway carries a different style code and is genuinely a different shoe — a distinction the record has to enforce.
Why discovery needs this layer
A structured product layer is not an implementation nicety; it is what makes higher-level features possible at all. Consider what depends on it:
- Comparison needs one product with many offers to compare across.
- Filtering needs canonical fields to filter on, not raw feed strings.
- Availability queries need variant-level structure to answer "in my size".
- Recommendation and AI need stable product identities to reason over, which is why AI discovery assumes this layer exists.
Operate directly on raw feeds and every one of these features has to re-solve the deduplication and normalisation problem on the fly, unreliably and repeatedly. Build the canonical layer once and each feature reads from clean, stable ground. The product record is, in the end, the interface between the messy world of merchant feeds and the clean world a shopper — or an assistant — actually experiences.
Sources & further reading
- Google Search Central, “Product and offer structured data reference” (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.