Amazon Market Analysis: Where the Market Size Number Comes From

Almost every Amazon market analysis starts by hunting for one number: how much money this category makes in a month.

Once found, it goes on page one of the business case and becomes the foundation for every judgement that follows.

The problem is that this is the least reliable number in the entire dataset. The platform does not publish it and nobody counted it. It is computed on top of two layers of estimation. Without understanding how it is produced, it is easy to treat a figure that is right in magnitude and wrong in every detail as a fact.

This post is not a generic market-analysis walkthrough. It takes apart one thing: how the market size number is built, where its error comes from, and what to look at besides it.

First check how many products the number covers

The market statistics endpoint returns a set of metrics per category node. Two of its fields look almost identical:

5,127 and 100. That is the first source of error: market size is not a census, it is a head sample. avgUnits, avgRevenue and avgPrice are averages over those 100 products, not over 5,127.

This is not a defect but a necessity — no data source can obtain true sales for five thousand products in a category. It does, however, decide how the number may be used:

• Valid for comparison: under the same method, category A being three times category B is a sound conclusion
• Not valid as an absolute figure in a financial model: it is the size of the head, not of the whole category

So the first thing to do with any size figure is to compute the ratio between products and totalProducts. 100/5127 and 100/120 carry very different levels of confidence.

Market statistics endpointPer category node: total products, products actually covered, average units, average revenue and average price

Revenue is estimated units times price, so two layers of error

The second layer: revenue is not counted, it is multiplied.

The platform does not publish unit sales. Units themselves are estimated from BSR, and revenue is those estimated units multiplied by price. Two estimates stacked on each other.

One detail in the documentation proves this directly. In the market statistics example:

• avgUnits = 26,255
• avgPrice = 13.91
• avgRevenue = 344,369

Multiply them yourself: 26,255 × 13.91 = 365,207, about twenty thousand away from avgRevenue. Divide the other way: 344,369 ÷ 26,255 = 13.12, roughly 6% below the 13.91 in avgPrice.

The data is not wrong. The two "averages" are simply not the same kind of average. Average revenue is the mean of per-product revenue; average price is the mean of per-product price. They can only be derived from each other when every product sells the same number of units, which never happens.

The practical rule is direct: do not multiply the fields back together. Take avgRevenue when you need revenue and avgPrice when you need price, treat them as two independent observations, and do not try to validate one against the other. The full boundary of this estimation layer is covered in what sales data can and cannot tell you.

Ratio fields do not share one unit

This is where the dataset most often bites, and the first thing to confirm before any market analysis.

Within the same family of market endpoints, ratio fields appear in two different notations:

Fractions and percentages coexist. Read the 67 in newProductProportion as a fraction and the new-product share becomes 6700%. Read the 0.4478 in totalUnitsRatio as a percentage and a leading brand's share shrinks from 44.78% to 0.45%. The second mistake is the dangerous one, because 0.45% looks entirely plausible and triggers no alarm.

When integrating, annotate the unit on every ratio field explicitly rather than guessing from its name — both notations end in Ratio. The safe approach is to normalise everything to fractions in the parsing layer and log any ratio above 1, since that indicates the percentage notation.

Unit mismatches like this compound once the numbers go into a recurring report; how to handle that is covered in building an Amazon data report.

Unit share and revenue share are not the same thing

Market size is only a total. What decides whether you can enter is how that total is divided.

The brand concentration endpoint returns share per brand. The top two in the documented example:

The runner-up's two shares are nearly equal (12.89% / 12.76%). The leader's differ by 22 points: it sells 44% of the units and takes 66% of the money.

The cause is price — 41.71 against 35.99. A higher average selling price turns the leader's unit advantage into a much larger revenue advantage.

That difference changes the conclusion. Looking at total size alone, 55% of the units appear to be up for grabs; by revenue, only 34% is. In a market measured in money, the head is stronger than the unit counts suggest.

So read both ratios together:

• Unit share > revenue share → this seller competes on volume at low prices, and there may be room left in the mid and upper bands
• Revenue share > unit share → this seller lives on a premium, and entering cheaply will not necessarily take its money
• The two are close → its pricing is the market average, and the share gap is pure scale

Brand concentration endpointUnit share, revenue share, average price and matching ASINs for each brand

Read one category three times: by brand, by seller, by product

Concentration is not one number but three views, and the three endpoints share essentially the same response shape, so one parser handles all of them:

The three views often disagree. High brand concentration with dispersed sellers describes a market where authorised brands distribute through many storefronts. Dispersed brands with concentrated sellers means large sellers are running several brands at once. In the first case your competitor is a brand; in the second it is a handful of storefronts.

The product view additionally returns sellerType and shelfDate, showing directly whether the leading listings are FBA or FBM and how long they have been up. All three return concrete ASINs (asins / asinSet / asin), so a market-level judgement drops straight down to the product level — carry those ASINs into competitor analysis instead of searching for them again.

The internal structure of a category — how listing age, seller type and price band are distributed — comes from a different set of endpoints, covered in four distributions that decide whether a category is still open. Moving the same analysis to another marketplace means redoing amounts, keywords and category paths per marketplace; see product research across marketplaces.

Two things market size does not answer

Size and concentration are both static. Two further metrics decide whether the business is pleasant to run, and neither is contained in the size figure.

The market performance endpoint returns two pairs:

The endpoint supplies its own frame of reference. This category's return ratio of 1.38 sits below the 2.72 reference, and its search-to-purchase ratio of 3.17875 sits above the 2.6 reference — fewer returns, better conversion, a more comfortable market than average.

Return rate matters most, because it appears in no size figure at all. A category doing a million a month with returns well above the reference delivers far less cash than its headline size suggests, and that gap is completely invisible in the market size number.

Note that asinCount and returnRatio are documented as String, so convert them explicitly rather than assuming they arrive as numbers.

Market performance endpointReturn ratio and search-to-purchase ratio for the category, each with its own reference average

Three things this data cannot do

It cannot give you an absolute figure for a financial model. A head sample plus two layers of estimation makes it a tool for comparison and ranking, not prediction. Using it to establish that A beats B, or that this year beats last year, is sound. Using it to compute "how much money I can take" is not.

It cannot tell you why the leader leads. The data says a brand holds 66% of the revenue; it does not say whether that comes from ad spend, brand recognition, or a product structure you cannot reproduce. That reasoning lives in its reviews and competitive structure.

It cannot define "the market" for you. Which node level you pick determines every number. The same product can be a major player at a third-level node and nothing at all at the first level. nodeIdPath must be recorded and held fixed; two analyses run on different nodes cannot be compared. Where the whole dataset comes from, and its limits, is covered in where Amazon data comes from.

Common questions

How large is the error in market size? There is no published accuracy figure and none should be assumed. The workable approach is to stop chasing absolute precision: hold the method fixed and compare across categories and across time, where much of the error cancels out. How to classify the fields for use is covered in how to do Amazon data analysis.

Why do different tools produce very different market sizes? Because both the sample range and the estimation model differ. That divergence is itself the argument against taking absolute values seriously. Pick one source, stay on it, and do not mix.

How much concentration counts as "closed"? There is no universal threshold. It is more useful to read revenue share rather than unit share, and to combine it with the price band — a head holding 66% of the money in the premium band says nothing about the lower bands.

What population does the market performance reference average cover? Take it as the endpoint defines it and do not assume it is a site-wide mean. For cross-category comparison, comparing each category's deviation from its own reference is more robust than comparing raw values.