Rank Is Not Sales, and the Conversion Problem
Every rank-to-sales table is reverse-engineered from small self-reported samples. What they are worth and how to use one honestly.
The obvious question about any rank is how many units it represents. The answer exists in dozens of published tables and none of them is a measurement.
Where the tables come from
Sellers report their own numbers. Someone knows they sold forty units yesterday and observed a rank of 12,000, and contributes that pair.
Aggregators collect many such pairs and fit a curve.
The curve is published as a rank-to-sales conversion table.
That is the entire provenance. It is not derived from marketplace data, because marketplaces do not publish sales figures.
Why the tables are weaker than they look
Self-selected samples. People who share numbers are not a random sample of sellers. They skew toward successful, engaged, English-speaking sellers in popular categories.
Category skew. Most contributed data comes from a few large categories. Applying a books-derived curve to industrial supplies is unjustified.
Time skew. Catalogue size grows, competition changes, and the curve moves. A table from three years ago is describing a different marketplace.
Marketplace skew. A curve fitted on one country's marketplace does not transfer to another with a smaller catalogue.
Small numbers at the top. The most valuable part of the curve — the top thousand — has the fewest contributed data points, because few sellers are there and fewer share.
No published error bars. The tables give a number. The honest version would give a range spanning a factor of two or more in most bands.
Using one anyway
They are the best available and they are usable with discipline.
Use them for magnitude, not for quantity. "Somewhere in the tens of units per day" is supportable. "Fourteen units per day" is not.
Use the same table throughout an analysis. Consistency matters more than accuracy when comparing two products, because the errors partly cancel.
State the source and the date in any output. A figure without provenance will be quoted back at you as fact.
Never use a cross-category table. Find one for your category or do not estimate.
Sanity-check against anything you know. If you have real sales data for one product, calibrate the curve against it before applying it to competitors.
Building your own calibration
The strongest available approach, and it requires data you may have.
If you sell on the marketplace, you know your own units and can observe your own rank. Record both, daily, for a quarter.
You now have a category-specific, marketplace-specific, current calibration for the rank band your products occupy.
Extrapolating beyond that band is unsupported, and this is the limitation people ignore. A calibration built at rank 20,000 says nothing about rank 200.
Recalibrate periodically. The relationship drifts.
The error that compounds
Rank estimation errors do not stay put. They propagate into every downstream figure.
Market sizing built by summing estimated units across a category multiplies the error by the number of products.
Competitor revenue estimates multiply the unit error by an assumed price and an assumed margin, neither of which you know.
Share-of-market claims divide one uncertain estimate by another.
A market size figure derived this way can be wrong by an order of magnitude and it will be presented to three significant figures, because spreadsheets do that.
What to present instead
Ranges rather than points. "Between roughly X and Y units per day" with the basis stated.
Ratios rather than absolutes. "Roughly three times our volume" is much more defensible than two revenue figures, because the conversion error partly cancels.
Direction and magnitude bands. Growing, flat, declining; top hundred, top thousand, mid-field, long tail.
The rank chart itself, where the audience can handle it. It contains more honest information than any derived figure.
The line worth holding
Estimation from rank is legitimate analysis with wide error bars. Presented as such, it supports real decisions.
Presented as a measurement, it produces business cases built on a curve someone fitted to volunteered numbers from a different category three years ago, and nobody downstream knows that is what they are looking at.
Reading a published conversion table critically
Before applying any table, five questions establish whether it applies to your case.
What sample was it fitted to? Number of data points, and how they were obtained.
Which categories? A table fitted mostly on books does not apply to hardware.
Which marketplace and region?
When? Catalogue growth moves the curve. Anything over two years old is describing a different market.
What is the error? A table with no stated uncertainty is presenting a fit as a measurement.
A table that answers all five is usable within its stated scope. One that answers none is folklore, and it will still be quoted in your industry for years because it is the only thing anyone has.
Where no suitable table exists, the honest options are to build your own calibration from first-party data, or to present the analysis as ratios and bands without a unit estimate at all.