"Product research for Amazon US", "how to research products for Amazon Japan" and "Amazon Europe product research" are often asked as three separate questions, as though each marketplace had its own secret.
In fact the order of judgement is the same everywhere: first rule out the categories you cannot enter, then look for mismatches between demand and competition in what is left. What changes by marketplace is not the method but the data — currency, language and category structure are all independent per marketplace.
So when switching marketplaces, the thing to be clear on is what can be reused and what has to be redone.
The marketplace parameter: leave it out and you get the US, silently
The marketplace data endpoints accept 13 marketplace values: US, JP, UK, DE, FR, IT, ES, CA, IN, MX, BR, AU, AE. One query answers one marketplace — there is no "global sales" figure and no "search volume across all marketplaces".
On most endpoints marketplace is required and omitting it returns an error. Four commonly used endpoints are the exception: their marketplace is optional and defaults to US when omitted:
| Endpoint | Docs |
|---|---|
| Traffic keyword reverse lookup | Keyword reverse lookup |
| ASIN details | ASIN details |
| Competitor lookup | ASIN competitors |
| Sales estimate | ASIN sales estimate |
This is the most hidden trap in multi-marketplace research: leave the parameter out while analysing Japan and the endpoint does not complain, it quietly returns US data. And these four happen to be the endpoints used most when looking at a single product.
So the basic rule for multiple marketplaces is: send marketplace explicitly on every request, even where it is optional; run the same set of queries once per marketplace, store the results separately, and record the marketplace on every row. The full list of marketplace codes and currencies is in the marketplace table in the appendix.
Take the currency from the response, not from the marketplace code
The market statistics response carries a currency field, with USD in the example. Every amount field — avgPrice, avgRevenue — is in that currency.
This is worth spelling out because in the appendix marketplace table, the currency column is blank for Mexico, Brazil, Australia and the UAE. If your code looks the currency up in a table you maintain yourself, keyed by marketplace code, those four will break. The safe approach is to always follow the currency in the response and never infer it.
Comparing amounts across marketplaces has another precondition: conversion uses an exchange rate you choose, with a date, and that date goes in the sheet. The endpoints do not convert currencies.
Across marketplaces, ratios work better than amounts. New product share, market share and return rate are unaffected by currency and compare directly — after confirming whether each ratio field is a fraction or a percentage, a unit issue covered in Amazon market analysis.
Market statistics endpointStatistics per marketplace and category node, including currency and a translated category name"Amazon Europe" is not one marketplace
In the data, "Europe" is five marketplace codes: UK, DE, FR, IT and ES.
DE, FR, IT and ES share one currency (EUR) and the UK uses GBP. A shared currency makes it tempting to add the four marketplaces together and call it "the European market", but their demand, search terms and competitive structure are each independent. The popular terms in Germany and in France are two sets of words in two languages, and a leading brand in a German category does not necessarily hold the same position in Italy.
The more sensible order is to run a full analysis on each of the five separately, then compare the conclusions rather than the raw numbers.
Keywords are stored in each marketplace's language
In the order keyword reverse lookup, each term carries two translation fields alongside keyword: keywordCn and keywordJp. The documented example:
| Field | Example |
|---|---|
keyword | phone holder for desk |
keywordCn | 办公桌上的电话支架 |
keywordJp | デスク用フォンホルダー |
The translation fields exist to help you read, not to do your keyword research. Shoppers on Amazon Japan search in their own phrasing, not in a translation of your US keyword list. A literal translation may be a term nobody searches, while the real high-frequency terms are ones you would not think of.
So keyword research on Japan or Germany starts from that marketplace's own data: build the library from its ABA and reverse lookup results, then use the translation fields to understand them. Why keywords have to be handled per marketplace is also covered in how to optimise Amazon keywords.
Order keyword reverse lookupConverting terms per marketplace, with Chinese and Japanese translation fieldsCategory paths are defined per marketplace
A category is located by nodeIdPath, such as 1064954:1069242:1069784:1069820:1069838:1069828 in the example. Those node IDs are defined per marketplace — do not assume a US nodeIdPath points to the same category in Japan; locate the category again in each marketplace.
The market statistics endpoint returns two name fields together: nodeLabelPath is the category name path on the marketplace and nodeLabelLocale is a translated name. When reading the category structure of Germany or Japan, nodeLabelLocale saves a lot of effort; for locating and recording, nodeIdPath is the reference.
What carries over is the method
These can be reused as they are when switching marketplaces:
- The order of judgement: rule out first, then search, as in how to research Amazon products
- How to read category structure: the listing age, seller type and price distributions in four distributions that decide whether a category is still open
- What fields mean: anything prefixed
estis an estimate, andproductsandtotalProductshave to be kept apart, in every marketplace
These have to be redone per marketplace:
- Every threshold: "how many monthly sales count as big" and "how much new product share counts as open" are not the same numbers in the US and Japan
- Keywords: rebuilt in the marketplace's language
- Category location: find
nodeIdPathagain in each marketplace
Three things this data cannot do
It does not cover logistics, compliance or tax. Fulfilment options, product certification and tax obligations differ greatly by marketplace. They decide whether you can enter it at all, and none of them is in the market data.
It does not convert currencies. Amounts come in each marketplace's currency; conversion is yours to do, with the rate date recorded.
It does not judge your localisation. The data can say a category in Japan has room. It cannot say whether your listing reads well in Japanese or whether your after-sales support can keep up.
Common questions
Which marketplace should a beginner start with? The data does not make that decision. The workable approach is to run the same metrics on each candidate marketplace, compare the ratio results side by side, and then weigh your own supply chain and language capability.
Does US data represent the other marketplaces? No. Demand, competition and price bands are independent per marketplace, so a US conclusion is only a hypothesis to test elsewhere.
Can I look up the same ASIN in different marketplaces?
Yes, by sending the matching marketplace on each query; results come back per marketplace. ASIN details and the sales estimate default to the US when it is omitted, so always specify it for any other marketplace. For what an ASIN identifies, see what an ASIN is.
Can data from several marketplaces go in one sheet? It can, with a marketplace column and a currency column, and never summed across marketplaces. Keyword data is best kept in separate sheets per marketplace; how to judge market structure is in Amazon market analysis.