---
name: review-decision
description: Work out the real review bar in a niche, who converts sales into reviews fastest, and which review counts are variation-merge fakes. Returns the number of reviews a launch actually has to clear. Use before launching into a category, or when a competitor's review count looks impossible.
---

# The review decision

You are helping a 7 or 8 figure Amazon seller answer one question: **what review bar does a new product actually have to clear here, and is the leader's count real?**

Review counts are the most lied about number on Amazon. Not by sellers breaking rules, mostly, but by variation merging, which is legal and which inflates a parent's count by pooling every child. A seller who benchmarks against a merged parent will conclude a category is unwinnable when it is not.

## What you need

- **The niche.** A keyword, a category, or a competitor ASIN to anchor on.
- **Marketplace.** Default US.
- **Their intended price**, so the bar is computed at their tier and not the category's.

## The metric that does the work

Helium 10 gives you **`sales_to_reviews`**: units sold per review left. It is populated on every row.

Flip it for something a seller can feel:

```
reviews per 100 sales  =  100 / sales_to_reviews
```

A `sales_to_reviews` of 40 means one review per 40 units, or 2.5 reviews per 100 sales. That is a normal, honest rate. A value near 1 means one review per unit sold, which does not happen naturally.

**Do not use `review_velocity`.** It is a filter-only field and returns `null` on every row. This is the most common way this analysis goes wrong.

## The work

### 1. Pull the field at their price tier

```
mcp__helium10__search_products(
  filters={
    title_include_keyword: "<the product noun>",
    price_from: <their price in CENTS minus 30%>,
    price_to:   <their price in CENTS plus 30%>,
    monthly_revenue_from: 300000
  },
  marketplace="US",
  sort_by="-monthly_revenue"
)
```

Project what you need out of the saved file:

```
jq -c '.data.products[0:30][] | {asin: .amazon_standard_identification_number, parent: .parent_amazon_standard_identification_number, title, brand, price, child_monthly_sales, review_count, reviews_rating, sales_to_reviews, variation_count, year_sales, age}' <file>
```

Two things to add to the filter set: a `category`, because `title_include_keyword` is a plain substring match on the title and will pull in unrelated products, and an awareness that `monthly_sales` is the parent total repeated on every child. Deduplicate by `parent_amazon_standard_identification_number` before you compute any field median, or a brand with 200 children will drag the whole median to its own numbers.

**`age` here is a raw unix timestamp, not a month count**, the README's own trap, and it is easy to reintroduce by habit inside this specific skill because step 3 needs an age in months. Convert it: `age_in_months = (now_unix - age) / 2629746`. Do not name the projected field `age_in_months` in the jq call above, that key does not exist on `search_products` rows and will silently come back `null`, a confident wrong answer of exactly the kind the field notes warn about. If you only need it for a handful of finalists, `get_listing_details(main_asin=asin)` returns `age` already in months, no conversion required, just do not mix the two units in the same table.

### 2. Separate the honest counts from the merged ones

For every product in the top 10 by revenue, compute:

```
reviews per 100 sales     100 / sales_to_reviews
variation count           from the row
plausible monthly reviews child_monthly_sales / sales_to_reviews
```

Then flag each one:

- **`variation_count` above about 8 with a very high review count** is a merge. The count belongs to the parent, not the product a shopper is looking at. Say so and exclude it from the bar.
- **`sales_to_reviews` far below the field median** means they convert sales into reviews unusually well. Sometimes that is a great insert and a good follow up sequence. Sometimes it is not. Report the number, note it is an outlier, do not accuse anyone.
- **A young listing with a large count** is the loudest signal of all. Cross check `age_in_months` (converted, see above) against `review_count`. A listing four months old with 3,000 reviews did not earn them one at a time.

### 3. Set the bar, precisely, for the finalists

`sales_to_reviews` is a snapshot: current monthly sales against a review count earned over the listing's entire life. That mismatch is fine for a fast first pass across 20+ competitors, but it quietly understates the honest rate for anything old (a 20-year-old listing's current run rate is not what built its review count) and overstates it for anything young and currently spiking. For the handful of finalists that will actually set the bar, tighten it:

```
lifetime_sales_estimate  =  age_in_months < 12
                             ? year_sales
                             : monthly_sales * age_in_months

reviews per 100 sales (precise)  =  review_count / lifetime_sales_estimate * 100
```

`year_sales` is a real field on `search_products`, trailing 12 months, so a listing under a year old is well approximated by it directly. Anything older needs the reconstructed lifetime figure, because a fixed trailing-year window would miss every review the listing earned before that window opened. This is the version to publish in the final table; `100 / sales_to_reviews` is the version to screen with.

The bar is **not** the leader's review count. It is the median honest review count (by the precise measure, for the finalists) of the products actually winning at their price tier, after you have thrown out the merged parents.

Then answer the question that matters:

```
months to clear the bar  =  bar / (expected monthly sales * field median reviews-per-100-sales / 100)
```

Use the precise (finalist) reviews-per-100-sales here, not the raw `sales_to_reviews` field, or the timeline inherits the same age distortion the precision pass exists to remove.

That number, in months, is the real cost of entry. It is usually the thing that changes the seller's mind.

## The output

```
THE REAL BAR: [n] reviews at $[their price tier]

Field median review rate: [x] reviews per 100 sales
Time to clear the bar at [n] units/mo: [n] months

Who is real and who is merged:
product            reviews   variations   per 100 sales   verdict
[brand]            [n]       [n]          [x]             honest / merged / outlier
...

The leader's [n] reviews are [real / pooled across n children]

DECISION: [enter / enter narrow / do not enter]
Why: [two sentences]

What would change this: [the one thing]
```

## Rules

- **Never accuse a seller of buying reviews.** Report the rate, note that it sits outside the field, and let the number speak. You cannot see their inserts and you cannot see their traffic.
- **Always throw out merged parents before computing the bar.** Leaving one in can double the bar and kill a viable launch.
- **Give the answer in months, not in reviews.** "You need 800 reviews" is a statistic. "That is fourteen months at your expected volume" is a decision.
- **If the bar is unclearable, say it plainly.** A category where the honest bar is three years of sales is a category to skip, and saying so is the most valuable output this skill has.
- **Screen with `sales_to_reviews`, publish the lifetime-sales-estimate version.** The raw field is fine for ranking 20+ competitors fast. The number that ends up in the output table and sets the bar should be the age-corrected one, or an old incumbent's naturally low current-run-rate rate reads as a moat that isn't there.
- Review counts move daily. Date your pull.