Averages hide distributions. That is a truism everywhere and it has a specific, expensive consequence on a marketplace.
Coverage reported across the whole catalogue takes a seller who fills every field and a seller who filled three, and returns a number in the middle. Onboard a large seller whose listings are thin and the whole-catalogue figure moves by a fraction of a percent, because four thousand listings against a million is noise. The category those listings landed in is now materially worse.
Coverage averaged across a million listings cannot tell you that one seller just made a category unshoppable.
What a four-thousand-listing onboarding does to two different numbers
illustrative, on a one-million-listing catalogueSame event, two numbers. Only one of them is the one a buyer experiences, and it is not the one on the dashboard.
View as table
| Value | |
|---|---|
| Whole-catalogue coverage | 1 pt drop |
| That category's coverage | 31 pt drop |
The buyer notices before the reporting does
What the buyer experiences is a filter that stopped working. They narrow by material in a category that was fine last month, and now a third of the results have no material recorded. Either those listings vanish from the filtered set, which makes your inventory look thin, or the filter is quietly widened to keep them, which makes it look broken. Both teach the same lesson, which is that the filters on this marketplace are not to be trusted.
This matters more here than on a single-brand catalogue because you do not control who writes the data. A retailer with a coverage problem has a process problem it can fix internally. A marketplace has thousands of independent parties each making their own decision about how much effort to spend on a listing.
Measure where the buyer shops
The unit of measurement has to match the unit of the experience. A buyer does not shop your catalogue, they shop a category, so coverage has to be computed per category and attributed back to the sellers inside it.
- Per category, not per catalogue, because that is the set a filter operates on
- Attributed per seller, so an onboarding event is visible as a cause rather than as a mystery
- Weighted by whether a purchase in that category turns on the attribute, so effort goes to the three fields that matter rather than to every empty cell
- Tracked over time, because the failure mode here is a step change on a Tuesday rather than a gradual decline
What sellers actually respond to
Generic completeness nudges get ignored, and reasonably so: they treat every empty field as equally urgent, which is obviously untrue and the seller knows it. A request for three named fields, in one category, with a reason attached, is a different message and it gets acted on.
Producing that message requires knowing which three, which is a ranking problem rather than a reporting one.