Amazon Brand Analytics publishes search-term data as a ranking. Each week, every search term gets a position; how many searches sit behind that position is not published.
That shapes how to use it. Anything that looks like a search count is a model built on the rank. The rank itself, and how it moves, is the part you can lean on. This post reads one row of the ABA weekly endpoint in the order that produces decisions: movement first, then who holds the clicks, then what it costs to get in. Assembling the terms into a library is covered in building your own keyword library; this post is about reading one term properly.
One row is one term in one week
The weekly endpoint returns a row per search term. Two parameters set the week and the scope:
datetakes the week-ending date, and it has to be a Saturday: the documented example is20250802, which is one. Leave it empty and you get the latest week.includeKeywords,excludeKeywordsanddepartmentsnarrow the terms.
The monthly endpoint returns the same shape for a calendar month, and the ABA trends endpoint returns a term's rank and searches as a series, with timeGranularity set to W for weeks or M for months.
curl --request POST \
--url https://ecommercedataapi.com/v1/amazon/aba/research/weekly \
--header "Content-Type: application/json" \
--header "X-API-Key: ${ECOMMERCE_DATA_API_KEY}" \
--data '{
"marketplace": "US",
"date": "20250802",
"includeKeywords": "screen protector",
"page": 1,
"size": 20
}'The rank is the data; the sizes are modelled
The documented row for "screen protector" has searchRank 9038. Next to it sit searches (22012), purchases (1035), clicks (3403) and impressions (451341). The rank is what the platform publishes. The sizes are estimates built on top of it, and they are internally consistent rather than independently verified: purchases ÷ searches is 1035 ÷ 22012 = 0.047, which is the purchaseRate of 0.047 in the same row.
Use the sizes to compare terms with each other. Do not use them to plan stock. Why tools disagree about "search volume" is covered in choosing an Amazon keyword tool.
Read the movement, and watch the sign
Each row carries the rank now and the rank at three earlier points:
| Field | Meaning | Example value |
|---|---|---|
searchRank | Rank this week | 9038 |
w1SearchRank | Rank one week ago | 8300 |
w4SearchRank | Rank four weeks ago | 7989 |
w12SearchRank | Rank twelve weeks ago | 8738 |
Next to each is a change value and a change rate (w1RankGrowthValue, w1RankGrowthRate and so on). Work them out from the example and the rule is: change = earlier rank − current rank, and rate = change ÷ earlier rank.
| Against | Earlier rank | Change | Rate |
|---|---|---|---|
| One week ago | 8300 | 8300 − 9038 = −738 | −738 ÷ 8300 = −0.0889 |
| Four weeks ago | 7989 | 7989 − 9038 = −1049 | −1049 ÷ 7989 = −0.1313 |
| Twelve weeks ago | 8738 | 8738 − 9038 = −300 | −300 ÷ 8738 = −0.0343 |
All three come out exactly as the example reports them. The trap is the sign. A lower rank number is a more popular term, so a negative change means the term got less popular. Here the rank went from 8300 to 9038, and the change is −738. Read "growth −0.0889" as a decline of 8.9% and you have it right; read the −738 as "the rank fell by 738 places" and you have it backwards.
Two more things follow from the same table.
One comparison point misleads. Against twelve weeks ago the term is down 3.4%; against four weeks ago it is down 13.1%. The four-week point, 7989, was the best rank of the four. The real picture is a rise from 8738 to 7989 followed by a slide back to 9038. Read all three anchors together, or pull the series from the trends endpoint.
The rate is not symmetric. It divides by the earlier rank, so an improvement can never exceed +100%, while a decline has no floor. The documented monthly example shows −1.1357: the rank went from 4548 to 9713, and 5165 ÷ 4548 is 1.1357. If you sort a growth rate ascending you will mostly see decliners, and the biggest numbers are not the biggest moves.
The monthly response reuses the w1, w4 and w12 field names. Check which period they cover there before comparing across the two endpoints.
Read who holds the clicks
Two fields describe how concentrated a term is:
clickShareRateis the share of clicks taken by the top three products, andcvsShareRateis their share of conversions.top3Brandsnames the brands, andtop3AsinDtoListgives each top product'sclickRateandconversionRate.
In the example, clickShareRate is 0.1489 and cvsShareRate is 0.0842: the top three take about 15% of clicks and 8% of conversions, so the term is fragmented and a newcomer can get a share. A term where the top three take most of both is a different proposition. The field table shows examples of 54.2 and 43.5 where the response example shows fractions, so check the first response you get and normalize before you compare terms. Getting onto page one covers how the click split decides whether ranking pays.
Read what it costs to get in
Three fields put a price on entry:
cprExact: the sales needed within about eight days to put the term on page one. The example is 64. It is an estimate. The appendix's sort table labels the same field SPR, and the request filters are namedminSPRandmaxSPR.titleDensityExact: how many first-page products use the term exactly in their title. The example is 50, so a large share of page one already does; using the term in your own title earns little edge.bid,bidMin,bidMax: the sponsored-products bid and its range, 3.36 and 2.52–4.2 in the example. Adjusting from there is covered in keyword bidding.
A term with a rising rank, fragmented clicks and a low cprExact is cheap to enter. A term with all three the other way is expensive, and the rank alone would not have told you.
Turn it into a watchlist
The same endpoint filters on rank, growth, clicks and concentration, so a watchlist is one request per category:
curl --request POST \
--url https://ecommercedataapi.com/v1/amazon/aba/research/weekly \
--header "Content-Type: application/json" \
--header "X-API-Key: ${ECOMMERCE_DATA_API_KEY}" \
--data '{
"marketplace": "US",
"date": "20250802",
"includeKeywords": "protector",
"maxSearchRank": 50000,
"minRankGrowthRate": 0.1,
"order": { "field": "searchfrequencyrank", "desc": false },
"page": 1,
"size": 20
}'This asks for terms containing "protector", ranked 50,000 or better, that have improved by at least 10% over the last week, best rank first. The numbers are examples. Assuming the filter follows the same sign as the response fields, a positive minRankGrowthRate selects climbers; confirm that on your first page of results before relying on it. order.field accepts searchfrequencyrank, cprExact, titleDensityExact and searches (Table 2.4).
The searchModel parameter takes 1 to 6 and pre-applies a market view: hot, abrupt-change, continuous-growth, fast-rising, potential and long-tail markets. Its values are described in the Chinese reference only, so treat it as a shortcut and test it against your own filters.
Limits
- The rank is published by the platform; everything sized (
searches,purchases,clicks,impressions) is a model on top of it. Compare terms with it, and do not read it as a count. - One week is noisy. Rank moves week to week for reasons unrelated to demand, so a single week's change is a prompt to look at the series, not a conclusion.
- The data describes search behaviour on the platform. It does not know whether a term fits your product; that check is yours.
FAQ
Is this the same data as Brand Analytics in Seller Central? It covers the same kind of search-term ranking data that Brand Analytics reports, returned as JSON.
Does a better rank mean the term will sell my product? No. The rank says how popular the term is, not whether shoppers who search it will buy yours. The click share and entry-cost fields tell you more about that than the rank does.
How often should I pull it? Weekly, on the same day, and keep every week. The series is more useful than any single pull.
Can I do this from an AI agent? Yes. The endpoint is available through the remote MCP server, so an agent can pull a term and read the movement for you.