"Amazon data analysis" usually gets treated as a tooling question: which software, which metrics.
What actually goes wrong is almost never the tooling. It is that three kinds of data with completely different standing end up in one table and get used as if they were the same thing.
Three kinds, three levels of trust
| Kind | Examples | Where it comes from | What it can support |
|---|---|---|---|
| Fact | Price, BSR, rating count, review text | Published publicly, checkable | Quote it directly |
| Estimate | Monthly units, revenue, market size | Derived from BSR and other public signals | Magnitude and direction only |
| Judgment | Worth entering, what the problem is | Added by a person or a model | Label whose judgment it is |
The expensive error is the second being used as the first.
The sales prediction endpoint names its fields estDailySales and estMonthSales — the est is the API's own label. The marketplace publishes no unit sales for any product, so "2,965 units a month" anywhere is calculated rather than looked up. Fine for ordering magnitudes; not fine as the basis for a purchase commitment. What Amazon sales data can and cannot tell you works through that layer.
The third kind leaking into the first two is the opposite error: putting "I think this category has an opening" in the same column as "83% of this category's units go to listings over three years old" leaves nobody able to tell, three months later, which sentence the data said.
Find the data from the question
Analysis starts with a question, not a dashboard. Common questions map to different data:
| Your question | What to read | Where |
|---|---|---|
| Can I still enter this category | The category's four distributions | Category analysis |
| Which product to pick | The four elimination layers | How to do product research |
| Why a competitor beats me | Keyword difference plus reviews | Competitor analysis |
| Where my traffic comes from | Organic versus paid placement | Monitoring keyword rank |
| Which terms to optimize | Four conversion classes | Optimizing keywords |
| What to bid | Bid ranges per match type | PPC bidding |
| What buyers complain about | Review sourcing and classification | Analysing reviews |
Starting from a question beats opening a dashboard and hunting for patterns. A dashboard pulls your attention to whatever moved most, and whatever moved most is usually noise.
One recording rule for all of it
Whatever you are analysing, every row needs two things recorded: which kind it is (fact, estimate, judgment), and when it was collected.
The timestamp is the one most often skipped and the most costly to skip. Without a collection time you cannot tell three months later whether the table is still usable — and ranks, prices and review counts all move daily.
It is also why every sheet we ship gives collection date its own column: the product research sheet, the competitor sheet and the review sheet.
Three things no public data can do
Whatever the tool, these three are not obtainable, because they are not on the public side:
Your own account data. Real order counts, ad spend, search term reports, inventory — those live in Seller Central as authorized data. Public endpoints cover the market side. The two are complementary and do not substitute for each other.
A competitor's account data. Same reason: only their account sees it. Anything claiming exact competitor sales or backend search terms is, underneath, an estimate.
Causation. Data tells you rank fell and conversion dropped. It does not tell you why. The cause needs your own change log — which makes timestamping listing edits more useful than any analysis tool.
For where these boundaries come from and why a model cannot answer across them, see Why AI cannot answer Amazon data questions. How the same authorization boundary splits the data into three blocks is laid out in where Amazon data comes from.
From reading data to calling endpoints
Manual lookup only becomes expensive once it repeats. The test is simple: when you start doing the same thing weekly — the same filters, the same fields exported, the same formula — it is time to make it a scheduled job.
The 46 endpoints grouped by job are in The complete guide to Amazon data APIs, and what to settle before integrating is in Five decisions before you integrate. Making the scheduled output comparable week over week is the subject of building an Amazon data report.
Questions
Which metric should a beginner start with? Do not start with a metric. Write down the one question you need answered and work backwards to the fields it needs — you will find most metrics have nothing to do with your question.
What if two tools disagree? Align three things first: marketplace, category level, and collection time. Only a difference surviving all three is a semantics difference. Public fields — price, BSR, rating count — should agree; sales figures disagreeing is normal.
How often should I re-check? At the speed the data moves. Prices and coupons change daily, rank is only meaningful weekly, category structure monthly or quarterly. Watching faster than the data moves shows you nothing but noise.
Can I feed this straight to a model? Yes, and classification suits it well. But require the output to land in the judgment kind, and keep the original fact and estimate columns — the model's conclusion and the data have to stay separable.