Product Data for Tyres: Getting the Label, Dimensions and Indices Right

A tyre looks like a simple product. It isn't — at least not as a data record. Behind every listing sits a block of legally mandatory information: the EU tyre label, the exact dimension and index string, the season marking, the EPREL identifier. Get one of them wrong, or leave it blank, and you're not looking at a content gap — you're looking at a warning letter. Tyres are one of the few automotive categories where the product data itself is regulated.

Product data for tyres is defined by two mandatory blocks: the EU tyre label classes and the dimension/index identity string. Everything else — brand, tread pattern, price — is ordinary content. These two blocks are the ones that have to be complete and correct. This is a sub-segment of the wider automotive & car parts challenge, where the rest of the catalog runs on vehicle linkage rather than labels.

Why is the tyre label a mandatory field, not optional content?

Since the EU tyre labelling regulation, every tyre sold has to carry a standardized label — and when you sell online, those values have to appear in the listing. Three values sit at its core:

• Fuel efficiency class (A to E) — the rolling resistance rating.
• Wet grip class (A to E) — braking performance on wet roads.
• External rolling noise — measured in decibels plus a noise class (A/B/C).

On top of those, a compliant listing references the EPREL product database entry — the official EU register where each tyre's label sheet lives. If any of these values is missing, wrong, or contradicts the EPREL record, the listing is non-compliant. That's why tyre data can't be treated like ordinary marketing content: it's a legally mandatory field, and an empty cell is a liability.

What does the dimension and index string encode?

The second mandatory block is the tyre's identity. It usually arrives as one compact string — for example 205/55 R16 91V — and a shopper filters by every part of it:

Every segment has to become its own filterable attribute in the shop, because customers search by exactly these values — a shopper looking for "205/55 R16" must not miss a tyre because the supplier wrote it as "205 55 16" in a single messy field. Add season (summer, winter, all-season), the 3PMSF snowflake and M+S markings, brand and tread pattern, and you have the full tyre record. The hard part is that suppliers deliver all of this inconsistently: label values in the title for one wholesaler, in separate columns for the next, blank for a third. This is the classic multi-supplier normalization problem — with legally mandatory fields on top.

How does Productbay keep tyre data complete?

Because tyre data is mandatory and unforgiving, the answer is completeness scoring — and that's exactly what Productbay is built for:

• Define the mandatory set: the required tyre attributes — label classes (fuel, wet grip, noise), dimension, load index, speed index, season, 3PMSF/M+S, EAN/GTIN and EPREL sheet — become a fixed schema every product is measured against.
• Parse and normalize: AI pulls the label values and the dimension/index string out of titles, feeds and PDF datasheets, splits the string into clean filterable attributes and maps every supplier's naming into one structure — always with a review step before publishing.
• Score completeness: Productbay runs a completeness score against the mandatory set, so a tyre with a missing noise class or a blank EPREL ID is flagged before it goes live, not after a warning letter.
• Publish: the clean record syncs to Shopify and Shopware and feeds to marketplaces, each with the label and dimension fields mapped to the right target.

Tyres sit in the same catalog as the rest of an automotive assortment, where the parts run on TecDoc vehicle linkage. Productbay handles both worlds in one place, and is built for specialist retailers running multi-supplier, multi-channel catalogs. For how the underlying standards fit together, see GDSN, ETIM and eCl@ss explained.

Frequently Asked Questions