How the reverse-ASIN lookup works

Measured ranks

A keyword shows as ranking only when a live Amazon search results page actually contained this product — with its position, its page, and when it was checked. Nothing modeled can ever appear as a rank.

Some rows come from an earlier check rather than a live one in this run. They say so, with the time they were last verified, and they can be re-checked live.

Checked depth, stated per row

Every verified row says how many organic results were checked. “Not in top N” is a measured negative at a stated depth — a different fact from “not checked”, which the candidates section says in so many words. We never claim coverage deeper than we checked, and we never render a zero where the honest answer is that nothing was measured.

Comparing up to five ASINs

In a multi-ASIN lookup, every column's rank comes from the same results page at the same moment, so the comparison is like for like. Statuses stay per keyword, per ASIN — one keyword can be ranked for a competitor and measured absent for you at the same stated depth, which is precisely what the “they rank, you don't” filter surfaces. A gap row claims only what that one page showed: your listing was not among the organic results checked while theirs was.

Variation families work the same way. Family scope looks for any edition in the family and labels which edition actually holds the slot — a sibling's rank is reported as the sibling's, never silently credited to the ASIN you typed.

The modeled half, banded and labeled

The paid columns — search volume, demand, difficulty, opportunity, the ads-cost figure — are estimates based on publicly visible Amazon data, and they are labeled as estimates. Every estimate renders as a range with a confidence badge — High, Med, or Low — and the band is computed: it widens when the evidence is thin, older, or inconsistent. A keyword without enough evidence renders insufficient data in the volume column while its measured fields stand untouched. We think that beats a confident wrong answer.

One caveat we state up front rather than in a footnote: estimates for different keywords in one run are built from shared evidence, so their errors are correlated. That makes them useful for comparing keywords within a run — a claim of efficiency, not one of statistically independent samples per keyword.

What the estimates can and cannot claim

Absolute Amazon search volume is unverifiable without Amazon's own data. Nobody outside Amazon has it — including us, and including every tool that prints a bare integer. So we calibrate ordering, not magnitude: the estimates are built to rank keywords correctly against each other, and the scale is an index for comparison, not a count of searches. Calibration is ongoing, and the estimates are refined as evidence accumulates; when the method changes, stored history is updated with it rather than mixing two methods in one view.

Freshness, history, trends

Rows are honest about their age — a stale label with the last-verified time, and a live re-check a click away. Between stored runs, measured position movement compares freely: a rank is a fact whenever it was observed. Modeled figures compare only between lookups made the same way, because a modeled change between two differently made lookups would measure the difference between the lookups, not the market. The suggestion-breadth sparkline draws only real observed points — fewer than two real observations renders no trend, never an interpolated one.