Skip to main content

How the reverse-ASIN lookup works

Every row in the table is either measured or modeled, and it always says which. This page is the method — including what it can and cannot claim.

Measured, not scraped-once

A lookup runs in two speeds. First, the index wave: every keyword we have previously observed this product ranking for, served in under a second and labeled with when it was last verified. Then the live sweep: the product's listing, category, Amazon's own search suggestions and our index propose candidate keywords, and the strongest are verified against live Amazon search results, one page at a time.

A keyword shows as ranking only when a live results page actually contained this product — position, page, and timestamp. Nothing modeled can ever appear as a rank.

Probe depth, stated per row

Every verified row carries the number of organic slots actually scanned. “Not in top 96” is a measured negative at a stated depth — a different fact from “not checked”, which the candidate section says in so many words. We never claim coverage deeper than we probed, and we never render a zero where the honest answer is that nothing was measured.

Comparing up to five ASINs on one probe budget

A multi-ASIN lookup sends exactly the same number of live probes as a single-ASIN one: each probed results page is scanned once for every input, so the marginal cost of adding competitors is zero and every column's rank comes from the same page at the same moment. 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 slots scanned while theirs was.

Variation families work the same way. Family scope scans each probed page for any member of the detected 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 modeled from the same evidence the free table shows: suggestion appearances across the run's fan-out, and signals read off the probed results pages (review counts, title matches, sponsored share, claimed result totals). Every estimate renders as a range with a confidence badge — High, Med, or Low — and the band is computed: it widens with thin evidence, stale evidence, and disagreement between the views we have. A keyword with no autocomplete 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 come from shared fan-out queries, so their errors are correlated. That design extracts more from each run — a claim of data efficiency, not one of statistically independent samples per keyword.

What we calibrate against

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. Our calibration source is our own Amazon Ads search-term impression reports, and against it we calibrate ordering, not magnitude: if the estimator says keyword A outranks keyword B, the impression data should agree. Calibration is ongoing— today's constants are structured priors, refit as our own probe outcomes and impression data accumulate. Every stored run is stamped with the algorithm version that scored it, and a version change re-scores history rather than mixing two methods in one view.

Freshness, history, trends

Index rows are honest about their age — a stale label with the last-verified time, and a one-click live re-check. Between stored runs, measured position movement compares freely: a rank is a fact whatever plan produced it. Modeled figures compare only between runs that executed the identical query plan, because a modeled delta across two different plans measures the plan, not the market. The suggestion-breadth sparkline draws only real observed points — fewer than two real observations renders no trend, never an interpolated one.