Most product research sheets grow the same way. You see a product, open a sheet, add a few columns. Next week it is a different category, so you add two more. Someone else takes over and renames the headers. Three months later the sheet cannot answer a basic question: why did we pass on that one?
The problem is not that the maths was wrong. It is that every row was filled in against a different definition.
The sheet is for comparability, not accuracy
A product research sheet is not there to produce a score you buy against. It is there so that the same person a month apart, or two people on the same afternoon, produce rows that can sit side by side.
That takes three things: fix the definitions, mark which numbers are estimates, and record what you did not fill in.
What each group of columns answers
The 26 columns fall into four groups, and each answers a different question.
Definitions. Marketplace, collection date, source, ASIN, title, brand, category path.
This group looks like bookkeeping and is actually the foundation. The same ASIN in the US and in Japan is two businesses. A BSR read today and one read last month do not belong in the same column. Fill the collection date per row, not once for the sheet — you are not going to review twenty candidates in a single sitting.
Demand and competition. Price, BSR, monthly units, monthly revenue, rating, ratings count, sellers, fulfilment, listed since.
The listed-since column gets dropped a lot, and it answers something the others do not: was the top of this category taken three years ago, or in the last six months? The first means fighting uphill. The second means the window is still open.
Cost and margin. FBA fee, unit cost, freight, ad spend assumption, return rate assumption, unit margin.
Risk and action. Missing fields, assumptions to verify, decision, owner.
Which numbers are facts and which are estimates
The second row of the sheet marks every column as fact, estimate, assumption, calculation or free text. Do not delete that row.
Price, BSR, ratings count and seller count are facts. They are visible on the listing and anyone checking gets the same number.
Monthly units and monthly revenue are estimates. Amazon does not publish unit sales for any listing. Every third-party "monthly sales" figure is derived from BSR, the models differ between providers, and the same ASIN coming out twice as high in one tool as another is routine.
That does not make the estimate useless. Ranked against other products in the same category, the relative size is informative, and it is fine for deciding whether something sells in the hundreds or the thousands. Treating it as what you will sell after you buy stock is where it goes wrong.
Unit cost, freight, ad spend and return rate are assumptions — they come from a quote or from experience and have not happened yet. They are marked separately so that when you review the decision later, you know which numbers were looked up and which were guessed.
Missing fields and assumptions to verify
These two columns are the easiest to skip and the ones most worth keeping.
A row with 22 columns filled and 4 blank can produce much the same unit margin as a row with all 26. The confidence behind it is far lower, and nothing in the arithmetic shows that.
So the sheet asks you to write it down: what is missing, and which numbers were guessed. The worked row says "no measured return rate" and "ad spend set to the category rule of thumb, unverified". Three weeks later, those two notes are what tell you what the decision rested on.
Leave them out and the sheet decides for you, because a computed number always looks more convincing than an empty cell.
How long a row takes, and when the sheet stops working
One ASIN takes roughly 8–15 minutes by hand: about half the fields from the listing, the FBA fee from the fee calculator, the unit cost from a supplier.
Up to about 20 candidates, by hand is the right call — and opening every listing has value that no field captures. You notice the image quality, the A+ content, the complaints in the Q&A.
Past 50, or on a weekly refresh, it stops working. Not because it is slow, but because it becomes inconsistent: you cannot guarantee row 47 and row 3 were read on the same day against the same definition. And an inconsistent sheet is worse than no sheet, because it still produces numbers.
That is this template's own boundary.
From the sheet to the endpoint
The third row of the sheet names the API field behind each column. It is the lookup table for the day you stop copying by hand.
| Column | API field |
|---|---|
| ASIN, title, brand | asin, title, brand |
| Category path | nodeLabelPath |
| Price, BSR | price, bsr |
| Monthly units, revenue | units, revenue |
| Rating, ratings count | rating, ratings |
| Sellers, fulfilment | sellers, fulfillment |
| Listed since | availableDate |
| FBA fee | fba |
Unit cost, freight, ad spend and return rate have no field beside them. They are your business, and no endpoint can supply them. What the API replaces is the copying, not the judgement.
If you have already decided to automate, Bulk product research with three endpoints covers chaining market research, product research and sales estimation into a scheduled job. This post is about getting one evaluation right before that.
Questions
When is this sheet the right tool? When you have 5–50 candidates and need a buy / revisit / drop decision on each. Below five, reading the listings is faster. Above fifty, filling it by hand loses the consistency that makes it worth having.
Sales estimates disagree between tools. Which one is right? Neither, entirely. Read them as an order of magnitude: hundreds, thousands and tens of thousands are three different decisions, and the exact figure inside a band is not worth arguing about. For more confidence, look at the trend over time rather than at a second tool's number for today.
A positive unit margin means buy, right? Not on its own. Read the missing-fields and assumptions columns first. If the return rate was guessed and the ad spend was invented, the margin was guessed too.
Can I add a total score column? You can, but do not display it while the missing-fields column is non-empty. A high score computed over four blanks is exactly what this sheet exists to prevent.