Accessories and spare parts product data: turning a “fits” list in a description into rows a store can use

The part is in the file, but its fit is not

A fridge water filter arrives in a supplier spreadsheet like this. Title: “Water Filter KFR320”. Category: Fridge Freezers, the range the supplier sells it under. Compatible models: “See description”. The description says “Fits KFR320W/325W & S variants, see PDF”, with a link to a two-page fitting guide. The part has no number of its own in the row, only the fridge’s.

Good accessories and spare parts product data does four things with that row. It gives the part an identity of its own: a title that names it, and its own manufacturer part number. It holds the compatibility list as data, one model code per row, not as a sentence. It names the relationship, because a spare part, an accessory and a consumable are bought for different reasons. And it files the part with parts, not inside the category of the product it fits.

Everything a shopper needs to buy the right filter is in that row somewhere. None of it is in a form a store, a feed or a marketplace can use.

Three relationships, and the words schema.org has for them

Schema.org, the shared vocabulary for structured data on web pages, has two properties that state fit. isAccessoryOrSparePartFor is “A pointer to another product (or multiple products) for which this product is an accessory or spare part.”² isConsumableFor is the same pointer for a product “for which this product is a consumable”.³

Three looser properties sit beside them. isRelatedTo points to “another, somehow related product”, isSimilarTo to “another, functionally similar product”, and isOftenBoughtWith to “a product that is often bought with the described product”.⁴⁵¹ None of the three says that one product fits another, so keep them for recommendations.

The relationship earns a column of its own. A spare part replaces something the product came with, and the shopper has the broken one in hand. An accessory adds something new. A consumable, such as a fridge water filter, is used up and bought again. Schema.org folds the first two into one property, but a Relationship column can keep all three apart.

Both fit properties expect a Product as their value.²³ So before the markup can point at the fridges a filter fits, the data has to hold each fridge as an item with its own model code, not as words in a sentence. Few sites use either property. Schema.org’s usage figures, drawn from Google’s web index, put isAccessoryOrSparePartFor on 1,000 to 10,000 domains and isConsumableFor on fewer than 1,000, against at least 10 million for the Product type itself.²³¹

Five ways a supplier file loses the fit

Parts and accessories are where supplier data is thinnest. The fit reaches you in one of five forms, often more than one at once.

• The list is prose. “Fits KFR320W, KFR325W and the S variants of each” is a sentence. A filter menu cannot read a sentence, and neither can a marketplace’s compatibility check.
• The codes are in a document or a link. A PDF called fitting-guide.pdf, or a “goes with” link whose address ends in kfr-320w-fridge-freezer. The code is there, but it has to be recovered before it is data.
• The part is filed as the product it fits. Category Fridge Freezers, a title that starts with the fridge’s model, and the filter listed between two fridges. A shopper browsing fridges meets a filter; one browsing filters never sees it.
• The codes are ranges and wildcards. “& S variants”, “all models from 2019”, “fits most”. A range is a claim about members it does not name.
• The part has no identity of its own. No manufacturer part number and no barcode, so the row can be matched to the fridge’s page but not to the filter’s. What each identifier is for is in GTIN, EAN, UPC and MPN explained.

The fifth is the one to fix first, because every other fix leans on it. Once the filter has its own MPN, the manufacturer’s page for that MPN is the list to check the supplier’s sentence against.

The same row, before and after

Here is the filter’s row as it arrived and as it should go into a store or a PIM. The four model codes come from the fitting guide, which names both S models.

Google’s own product taxonomy shows why the category row goes wrong. It files Refrigerator Accessories under Kitchen Appliance Accessories, a branch beside Kitchen Appliances rather than inside Refrigerators.⁷ The same file has Water Filters under Kitchen Appliances, Water Filter Cartridges under plumbing, and Air Purifier Filters under household appliance accessories.⁷ A fridge water filter has at least three plausible homes in that file alone.

One of our recent jobs was refrigeration accessories for an appliance retailer. We filed these across nine categories: water filters, filter cartridges, even air purifier filters. The client moved every one of them to the same place, accessories for the fridge, and 19 of 19 corrections pointed one way. Nobody told us that rule. We read it off their own corrections rather than pushing a standard taxonomy back at them.

The rule to take from it is the retailer’s, not the taxonomy’s: parts go in a parts category named for what they fit. The rest of the job, mapping a supplier’s tree onto yours, is in mapping supplier categories.

Where each channel can hold the list

Once the list is data, each channel has a place for it.

Shopify and WooCommerce generate related products themselves but leave complementary items to you, so the compatibility rows are where the pairs come from.¹³¹⁴ Google’s product_detail page lists no schema.org property for the attribute, so the feed and the page markup are separate jobs, filled from the same rows.⁶

eBay’s parts compatibility, the worked example

eBay’s parts compatibility is the most developed example of a fit list held as data: a feature that “uses structured data to associate compatible assemblies with parts listed on eBay”.¹⁰ It is built around vehicles, and supported “in select Parts & Accessories categories only”, on five eBay sites, the UK among them.¹⁰

Through eBay’s Inventory API, the list is attached to the part’s own SKU, and each vehicle is defined by aspects “such as make, model, year, engine, and trim”.¹¹ eBay’s own example of one compatible vehicle is three name and value pairs: Make Ford, Model F-150, Year 2004.¹²

On eBay UK the list is a form. After choosing the category you “select Add compatible vehicles” and enter at least the make, model and variant of each, up to 3,000 vehicles, drawn from eBay’s own vehicle lists.⁸ eBay also makes this post’s point about identity: the correct MPN and brand “helps match your product with valid k-type or vehicle data”.⁸

The list decides what the buyer is told, and what happens when it is wrong. Under eBay Assured Fit, when a buyer searches with their vehicle details and there is a match, “fit is confirmed with a green checkmark on the listing”. If the part then does not fit, the buyer can return it under “Doesn’t fit my vehicle”, and eBay pays the return postage, with some exclusions. Items without fitment data are not eligible.⁹

What carries over to a fridge filter is the shape: one row per model, codes as the manufacturer writes them, the part’s own MPN and brand as the key, and no claim for a model that is not on the list.

Google’s product_detail, and its rule on confirmed values

In a Google Merchant Center feed, a fit list can go in product_detail, which lets you “describe any aspect of the product that is not explicitly covered by other attributes”.⁶ Each detail is a section name (optional but recommended), an attribute name and an attribute value (both required). A product can carry up to 100 details: room for four entries like “Compatibility:Fits model:KFR-320W”, with plenty to spare.⁶

The page sets minimum requirements, and says a product that does not follow them will be disapproved. Two bear on fit: “Only provide an attribute name and value when the value is confirmed”, and “Avoid listing keywords or search terms.”⁶ A fit copied from “fits most” is not confirmed, and a model list padded to catch searches is a list of keywords.

Recovering the codes from links and text

This looks like reading and is really matching, and it can be done in a spreadsheet, one supplier at a time.

1. Gather every place a fit is stated. The description, the title, the compatible models cell, every “goes with” link and any linked PDF, in one column beside the part’s SKU, each with its source.
2. Pull out every candidate code. Anything that looks like a model number: letters and digits together, with or without a hyphen. “KFR320W/325W” yields two, once the shared prefix is copied onto the second.
3. Normalise the spelling. KFR320W, KFR-320W and kfr-320w are one model. Pick the manufacturer’s form and fold the rest onto it.
4. Match each code against your catalogue. Use the SKU, MPN and GTIN columns, not titles. No match may just mean a fridge you do not sell, which a shopper can still own.
5. Expand ranges only from a named source. “& S variants” becomes KFR-320WS and KFR-325WS because the fitting guide lists them. Where nothing names the members, leave the range as a flag.
6. Write one row per pair. A Compatibility tab with four columns: part SKU, fits model, relationship, source. Four fridges means four rows for the filter.
7. Build every output from the tab. The compatible models cell, the product_detail entries and the page markup come from the rows, and cross-sells from the rows whose model you stock. Nothing is typed twice, so nothing drifts.

When the fit is uncertain

Some supplier claims will not resolve. “Fits most” has no members. “All models from 2019” depends on launch dates the file does not hold. The temptation is to carry the wording through as a value, because a value looks complete.

Google and eBay both point the other way. Google’s rule is to provide a detail only “when the value is confirmed”.⁶ eBay’s advice is that “it’s important to be accurate when adding compatible vehicles, to avoid returns”.⁸ A false fit claim can come back as a return. A fit you never claimed costs, at worst, a sale.

So keep three states, not two. Confirmed: a source you can point to names the model. Flagged: the supplier claims a fit that no source names, kept as a note on the row rather than as a value. Unmatched: a code that matches nothing in your catalogue or your sources, listed for someone to look up rather than dropped.

Much of this is what RefynData’s product data enrichment service does with a supplier file. Each part is matched to the real product, and each value keeps a link to the source it came from. Parts and spares are separated from the products they fit and filed in the retailer’s own category tree. Product codes are recovered from supplier “goes with” links and matched to catalogue items, and values that do not agree with their source are flagged.

Accessories are one strand of what product data enrichment covers, and the one where a source matters most: a fit claim is only worth what stands behind it.

What to do with the file you have

Start by finding the parts. Filter the supplier file for filter, cartridge, spare, replacement, kit, cover and “fits”, then look through each product category for anything that is not the product.

Give each part its own title and MPN before touching its fit list. Recover the codes with the seven steps above, keep the compatibility rows as the master, and generate every channel’s version from them. Whatever will not confirm is a flag, not a value.

Then run the parts through the same product data quality checklist as the rest of the catalogue, with one check added: every compatibility row names its source.