Product Data API

What we measured, and why it matters

Most writing about product data APIs describes an idealised catalogue. We went and measured a real one: 1,993 products and 11,265 variants across nine industries — apparel, home, jewellery, beauty, accessories, food, electronics, kitchen and outdoor. The gap between the ideal and the actual is where integrations break.

Identifier coverage is wildly uneven

GTIN coverage is near-universal in electronics and grocery and effectively zero in apparel and jewellery. Public storefront catalogues frequently strip the barcode field entirely — it exists in the schema and is empty on every row.

Where identifiers do exist, verify the check digit. An identifier that fails its own checksum is worse than an empty field, because it looks authoritative and corrupts every join built on it downstream.

Three fields that lie

Vendor is frequently not the brand

We observed a phone-case catalogue where the vendor field held “Galaxy S25 FE Series” — a device-compatibility string, on a product made by Spigen. Copying vendor straight through as brand would split one manufacturer across dozens of phantom vendors and destroy any brand-level analysis. Brand has to be resolved, not copied.

Availability is silent a third of the time

Only about 68% of real variant rows publish a usable stock flag. The rest say nothing. Treating silence as in-stock means confidently recommending things nobody can buy — so unknown has to be a real, returnable value.

Stock also hides in strange places. One storefront encoded it as a product option: a “Status” axis whose values were “Preorder — Ships in 45 Business Days” and “Out of Stock”, sitting alongside colour as though it were a choice.

Tags are operational exhaust

Real tags in our sample included 50EmployeeDiscount, BFCM40 and DFS check — internal operations leaking into a public field. Tags are a weak search signal and worthless for identity, which is why they should never be promoted into structured attributes.

Attributes are category-specific, and that is not a schema failure

One flat attribute schema cannot serve those. Note the electronics row in particular: the dominant axis is what a thing fits. Compatibility is an attribute, not a category, and a comparison that ignores it will happily compare a case for one phone against a case for another.

Images are abundant and unevenly linked

Median five images per product across the sample, rising to eighteen in electronics. About 64% of variants carry a distinct primary image; the rest inherit the product's, which means a colour variant may be illustrated by the wrong colour unless the response tells you so.

Serve images from your own storage rather than hot-linking. Retailer image URLs rotate, expire and are frequently blocked cross-origin — hot-linking produces a catalogue full of broken images about three months later.

Matching, and the failure that does not announce itself

With a valid GTIN, matching is a join. Without one it is inference, and inference fails three ways. A false positive maps to a cheaper different item. A false negative leaves a competitor unmatched. Silent drift breaks a correct match when a seller relists under a new title or bundles the product — and nothing tells you.

The third is the dangerous one, which is why a mapping whose confidence falls should emit an event rather than degrade quietly, and why every match should return a method and a confidence you can filter on.

Coverage is a distribution, not a percentage

Every product data vendor publishes a coverage figure and none of them mean much, because coverage is not uniform — it clusters by category and by source in ways that determine whether a given field is usable for your catalogue specifically. A provider at 85% GTIN coverage might be at 99% for your packaged goods and 4% for your apparel, and the headline number tells you nothing about which.

What we measured across 1,993 products and 11,265 variants in nine industries: identifier coverage near-universal in electronics and grocery, near-zero in apparel and jewellery. Stock state published on roughly 68% of real variant rows, which means unknown is a legitimate value rather than a gap to be filled with a guess. And on public storefront endpoints the barcode field is present in the schema and empty on every store measured.

The fields that are almost always wrong

• Vendor is not brand. Feeds routinely put the storefront's own name in a brand field, and a catalogue built on it will report hundreds of distinct brands that are one retailer.
• Category is the seller's taxonomy, not a universal one. The same product sits in different trees at different sellers, and mapping between them is work, not a join.
• Weight and dimensions frequently describe shipping packaging rather than the product, which breaks any unit-price or fitment logic built on them.
• Image URLs can be session-bound and decay to a placeholder after a token expires — a failure that looks like working data until someone opens the page weeks later.
• Description is marketing copy, not specification, and attributes extracted from it should carry lower confidence than attributes supplied as fields.

Why attributes need units and provenance

An attribute without a unit is not data. A capacity of 64 is meaningless — gigabytes, ounces, litres — and normalising across sellers who express the same property differently is most of the work in building a usable attribute layer. The same applies to provenance: an attribute the seller published as a structured field is stronger evidence than one parsed out of a description, and a system that flattens both into one value has discarded the information needed to resolve a disagreement between them.

Questions

Common questions

Related