Most people export reviews by selecting the page, copying, and pasting into Excel.
Slowness is the lesser problem. The real one is that a sheet built that way is missing the columns you need to judge anything — you get the title, the body and the star rating, and you lose whether the review was a real purchase, which variation it belongs to, and how many people found it helpful. Those three decide whether a review belongs in your conclusion at all.
The 21 columns in four groups
Group one, provenance (4 columns). Marketplace, ASIN, collected on, review date.
Collection date and review date must stay separate. The review date says which batch the feedback belongs to; the collection date says when the sheet goes stale. Record only one and two months later you cannot tell whether the sheet is still usable.
Group two, the review itself (4 columns). Star, review title, content excerpt, variation SKU.
The variation SKU column is the one most hand-built sheets lack. It maps to the skus field and names which variation the review attaches to — a parent listing pools every variation's reviews into one display.
Group three, source and reach (8 columns). Verified purchase, Vine, free, early experience, has image, has video, helpful votes, author labels.
The first four map to the verified, vine, free and experience booleans and decide whether a review belongs in your baseline. The last four decide its actual reach: a 47-vote negative with a photo and a zero-vote text-only one are not the same thing. The four sources of an Amazon review covers what each source field means.
Group four, your judgment (5 columns). Counted in baseline, issue category, stage, actionable, notes.
The endpoint supplies none of this, so it is filled by hand — which is exactly why it is physically separated from the first three groups. Merging observation and conclusion into one column is a well-worn route to shipping a guess as a finding.
Which endpoint field is behind each column
The sheet's third row is the field mapping row, written into the file itself:
| Column | Endpoint field |
|---|---|
| Review date | date (timestamp) |
| Star | star |
| Review title | title |
| Content excerpt | content |
| Variation SKU | skus |
| Verified purchase | verified |
| Vine | vine |
| Free | free |
| Early experience | experience |
| Has image / has video | image / video |
| Helpful votes | likes |
| Author labels | authorLabels |
Fill it by hand in this order and the columns do not move when you switch to the endpoint. That is the point of the sheet: the manual version and the API version are the same sheet.
Three traps when exporting
One: array fields do not go straight into a cell.
skus, images, videos and authorLabels all come back as arrays. Dropping one into a cell gives you bracketed text that cannot be sorted or filtered. Either take the first value or join with a separator — but be consistent across the whole sheet, and do not mix commas with semicolons, because a comma will shift your columns in CSV.
Two: date is a timestamp, not a date string.
It returns milliseconds since the epoch (the documented example is 1772380800000). Pasted as-is you get a run of digits, and sorting by date gives the wrong order. Convert to YYYY-MM-DD at export time rather than leaving it for analysis.
Three: booleans need one spelling.
The four source fields return true/false. Write them consistently as TRUE/FALSE or as yes/no, but not both. Mixed spellings make it impossible to select "verified and not Vine" with a single filter — which is the first step in computing a baseline rating.
Pagination and star filtering
The endpoint paginates by ASIN, and a stars parameter takes an array of ratings.
Problem analysis does not need every review — pulling 1 and 2 stars alone gives you the defect list. For the most specific writing, take the 3-star band.
One thing to watch with pagination: reviews accumulate. Page 5 today and page 5 next week need not hold the same content. So the collection date column is not decoration — it is the version number of that batch of data.
Review endpointPaginated reviews by ASIN with star filtering; the full request parameters and response field tables are in the docsWhen the manual sheet stops being enough
Filling this sheet for 50 reviews on one ASIN takes roughly 30 to 40 minutes.
The signals that it no longer fits are clear:
- More than one ASIN to watch. Five competitors at 50 reviews each is most of a day
- Periodic re-checks. Reviews keep arriving, so last month's sheet already misdescribes today
- Grouping by variation. Sorting by
skusby hand is fine once and not fine monthly
That is the point to turn it into a scheduled job. For turning the sheet into conclusions, see How to analyse Amazon reviews. The columns do not change — the mapping row already holds the endpoint field names.
Questions
Can I export every review in one call? The endpoint returns pages, so paging happens in a loop on your side. With many ASINs this drives call volume, so estimate it first.
Why did I export fewer reviews than the page shows?
Check the ASIN level first. A parent page pools all variations and you may have queried a single child. Reconcile with the skus column.
Should the sheet keep the full review text? Keep an excerpt. Full text makes the sheet very hard to read, and the first two sentences usually carry the judgment. Go back to the original by review date plus star rating when you need it.
Can a model categorize the issues automatically?
Yes, and that is the column best suited to handing to a model. But put its output in the issue category column — in the judgment group. It has to stay separate from factual columns like content.