Marketplaces
One taxonomy, thousands of sellers, and no two filling it the same way
A marketplace does not control who writes its product data. Coverage reported across the whole catalogue averages a well-described seller against one who filled in three fields, and the average tells you nothing about which listings a buyer can actually reach.
Coverage per seller, not per cataloguefrom one category export
The market
What Marketplaces looks like right now
Where the fact already is
The value exists. A filter cannot reach it.
Nothing here is missing from the catalogue. It is missing from the schema, which is a different problem with a cheaper fix.
In the description, as prose
Material
Dimensions
Compatibility
In the filters, as a field
- Material41%
- Dimensions55%
- Compatibility28%
- Country of origin88%
The last row is already a field, which is why nobody ever files a complaint about it.
What happens here
Your category coverage went up and your search results got worse.
A marketplace onboards a large seller with four thousand listings. Catalogue coverage barely moves, because four thousand against a million is noise. The category those listings landed in is now materially worse and nothing in the reporting says so.
The buyer notices before you do. They filter by material in a category that was fine last month, and now a third of the results have no material recorded, so either they vanish from the filter or the filter is quietly widened to keep them. Either way the buyer stops trusting it.
Measuring per seller rather than per catalogue makes the cause obvious and the fix specific: not "improve your listings" to everyone, but the three fields that decide purchases in that category, to the sellers who are missing them.
Coverage averaged across a million listings cannot tell you that one seller just made a category unshoppable.
AttributeRecordedDecides it
- Material41%Yes
- Dimensions55%Yes
- Compatibility28%Yes
- Country of origin88%No
Illustrative of this sector's shape. The measured figures are on the method page, with the command that reproduces them.
The situation
What usually goes wrong in Marketplaces
What a buyer here is trying to decide: Which seller's listing actually matches what I asked for?
Category coverage reported as an average that hides the sellers dragging it down
Onboarding a large seller quietly moving a whole category backwards
No way to tell a seller which fields matter rather than which fields are empty
Buyers filtering into an empty result set because coverage is uneven, not because stock is
Attribute coverage on a typical Marketplaces catalogue
illustrative of this sector's shape; the measured figures are on the method pageMaterial41%
Dimensions55%
Compatibility28%
Country of origin88%
Red rows are the ones a purchase turns on and the catalogue mostly does not record. Those are the rows an audit surfaces and a coverage report buries.
View as table
| Value | |
|---|---|
| Material | 41% |
| Dimensions | 55% |
| Compatibility | 28% |
| Country of origin | 88% |
Where it usually already lives: Uneven by seller rather than by field, so the repair is usually a mapping job against feeds you already receive plus a ranked list of what to ask sellers for.
What happens
What we do about it
Three things, and only the first one needs anything from you.
- 01
Send one category
A CSV or JSON export of a single category. Product name, description, category, price, and whatever attributes you already record.
- 02
We rank what to record first
Every missing attribute scored by how much recording it would change what a buyer in your sector can decide, with the affected products attached.
- 03
You fix it, then we verify
Most of the repair is work your own team can do. When it is done we recompute on the repaired catalogue and show you exactly what moved.
- One category export
- No code
- No tag on your site
- No customer data
Questions from this sector
What Marketplaces teams ask us
- How do we tell sellers which fields actually matter?
- Rank the fields by what recording them would do for a buyer's ability to choose in that category, then ask for those. Sellers ignore a generic completeness nudge because it treats every empty field as equally urgent. A list of three fields with a reason attached gets filled in.
- Why does catalogue-wide coverage hide our real problem?
- Because it is an average, and averages hide distribution. A category can go from shoppable to unshoppable while whole-catalogue coverage moves by a fraction of a percent. Coverage has to be measured at the level a buyer actually shops at, which is the category, and attributed to the sellers inside it.
- A new seller just made a category worse. How would we know?
- You would see it as a drop in that category's decision readiness, with the attribute and the products responsible named. That is what Decision Monitor watches for, and onboarding a large seller is the most common cause of the drop.
- Do you need our seller data?
- No. The audit runs on the product listings themselves: title, description, category, price and whatever attributes are recorded. No seller accounts, no buyer records, no order history, no personal data of any kind.
Other sectors
- Ecommerce and retailA category with hundreds of near-identical products, where the fact that separates them was never a column.
- B2B and distributionYour buyers choose on specification, and the catalogue was built to be ordered from rather than searched.
- Shopping feeds and paid mediaShopping platforms match on the attributes in your feed, so a missing field is spend delivered against the wrong query.
- Travel and hospitalityTwo properties at the same price on the same street, and the thing that decides between them is not a field.
- AI shopping agentsAn agent comparing products cannot infer a fact you never recorded, and it will not guess in your favour.
Send us one Marketplaces category.
Pick the shelf where you most suspect buyers struggle. You get a ranked list, the affected products, and half an hour with whoever owns merchandising.
A fixed fee, no obligation, and if your catalogue is already fine we will say so.