When choosing a data analysis tool, most people watch demos, compare feature lists and ask for recommendations. All three share one problem: you cannot check whether what it says is right. You do not know the true answer to the numbers in a demo, and a feature list says what a tool computes, not how accurately.
This post covers one thing: how to test a tool with data whose answer you already know. It works for any kind of Amazon data tool. Choosing within specific categories has its own posts — product research tools, keyword tools and reverse ASIN lookup tools — and how to do the analysis itself is in separating facts, estimates and judgment.
First, be clear which kind of work you want done
Tools under the same "data analysis" label may be doing three different things:
| Type | What it does for you | Can you verify it |
|---|---|---|
| Collection | Moves visible fields (price, rating, review count, BSR) into a table | Easily: open the product page and compare |
| Estimation | Derives figures you cannot see (sales, revenue, search volume) from the visible ones | Hard: Amazon does not publish the true values |
| Judgment | Adds conclusions on top of the estimates ("this product is worth it") | Hardest: the conclusion mixes estimates with the tool's own rules |
Collection is checkable in a minute, and the rules behind judgment are usually opaque. The layer worth the effort is estimation — it is the foundation of every judgment built on top, and it happens to be the one where you already hold an answer key.
The most effective single test: quiz it on ASINs you know
Your own ASINs have real sales. The business reports in Seller Central give units ordered per child ASIN — the recorded actual, not an estimate.
Put the same ASIN into the tool, take its sales estimate for the same period, and compare. That tells you how far off the tool runs in your category and price band. Using this site as the example, the ASIN Sales Estimate endpoint returns monthItemList by month (each item a date, sales and amount) and dailyItemList by day (adding that day's bsr and price):
curl --request POST \
--url https://ecommercedataapi.com/v1/amazon/sales/prediction/asin \
--header "Content-Type: application/json" \
--header "X-API-Key: ${ECOMMERCE_DATA_API_KEY}" \
--data '{
"marketplace": "US",
"asin": "B08CK5Z5Q1"
}'Line the conditions up before you compare, or the gap you measure is one you created:
- The same child ASIN. A parent-level estimate counts the whole variation family; your Seller Central figure is one child.
- The same marketplace, stated explicitly. This endpoint's
marketplacedefaults toUSwhen omitted. Leave it out while checking Europe or Japan and you get US figures back, with no error. The full list of marketplace pitfalls is in product research across the US, Japan and Europe. - Compare monthly, not daily. Single-day estimates swing, and they may not attribute to the same day as your orders. Monthly totals show the tool's own bias better.
Read three things: direction, magnitude, ranking
Do not stop at "how far off". Read it three ways:
Direction: is it consistently high or consistently low? A steady bias can be corrected — if you know it usually overestimates by about a third, you can discount it in your head. Swinging both ways is the real problem.
Magnitude: how large is the error, and is it the same at different sales levels? A common pattern is that bestsellers are estimated fairly well and the long tail badly, or the reverse. That decides whether it is usable in the price band and rank range you care about.
Ranking: if you have several ASINs, check whether the tool puts them in the same order as your real sales. Product research and competitor analysis mostly need "which sells more than which", not "exactly how many units". A tool whose absolute numbers are off but whose ranking is stable is still useful for comparison. One that cannot get the order right should not be used for comparison, however reasonable its numbers look.
One or two ASINs cannot calibrate a whole model — error varies by category and rank range. Several ASINs at different rank levels is best. With only one, limit your conclusion to "in this category, at this volume, it is off by roughly this much".
Then ask four questions about definitions
Calibration answers "is it accurate". These four answer "am I reading it right". Each has its own post:
- Which kind of "search volume" is it showing? One response can carry several fields that all look like search volume — monthly marketplace searches, a weekly rank, an estimated exposure for one product. See choosing a keyword tool.
- What happens when you leave the marketplace out? Silently falling back to a default is far more dangerous than an error. See the marketplace parameter.
- Are ratio fields percentages or fractions? Both notations in one dataset is not unusual. See where the market size number comes from.
- Does it mark which figures are estimates? Can you tell from a field name, its description or the docs that a number is derived? See what Amazon sales data can and cannot tell you.
Can you get the raw data out
Charts in an interface are for looking at. Raw rows are what let you compute, compare and merge with your own Seller Central data. Ask three things:
- Can you export row-level data, not just summary charts?
- Are the fields documented — the meaning, type and unit of each one?
- Is there an API to pull the data on a schedule under a fixed definition, rather than exporting by hand each time?
This site keeps all three on the public side: the 46 endpoints are listed in the API catalog, fields, types and examples sit on each endpoint's page, and the full machine-readable definition is in OpenAPI. You can read every field definition before paying and decide whether it meets your definitions.
Work the pricing out against your own usage
The same budget buys very different things under different pricing models:
- Subscription per account or seat suits several people checking manually every day.
- Per-call pricing suits scheduled jobs and batch comparisons: you pay for what you use.
This site is the second kind: you buy a call pack once, every public endpoint draws on the same balance, and there are no per-seat fees. Pack sizes are on pricing. To tell which model is cheaper for you, estimate how many lookups you actually run a month first — that is more useful than comparing unit prices.
Three things no tool can do
Give you values Amazon does not publish. A competitor's real sales and real conversion rate exist only in their Seller Central. Every tool offers an estimate; the difference is how good it is and whether it is labelled honestly.
Decide for you whether to go ahead. However clearly a tool lays out the data, it knows nothing about your supply chain, your cash or your execution.
Guarantee that today's calibration holds forever. Platforms and categories change, and models get updated. Before a decision that matters, it is worth re-running the comparison on your ASINs.
FAQ
I am not selling yet and have no ASIN of my own. How do I calibrate? Ask a friend or partner who already sells for the Seller Central figures on one or two ASINs. Failing that, fall back to checking whether the ranking is plausible: pick a few products where you have clear common-sense knowledge of which sells more, and see whether the tool's order agrees.
Two tools differ by a factor of two on sales. Which do I trust? Neither, directly. Test each against ASINs you know and see which is steadier in direction and ranking. A twofold gap is common in itself because estimation methods and definitions differ; see how to analyze Amazon data.
How much estimation error is acceptable? It depends on the task. Comparison tasks (ranking, picking a top few) are insensitive to absolute error and sensitive to order. Tasks that need an absolute quantity, like setting an order size, should not use estimates directly in the first place.
Are free tools worth testing? Yes, and the method is exactly the same. The difference between free and paid is usually data coverage, history depth and bulk access rather than the accuracy of a single estimate. Which data is free to begin with is covered in where free Amazon data ends.