How to read Amazon's Search Query Performance report

Almost every report Amazon gives you describes your own traffic. Search Query Performance describes the market, and then puts your slice of it in the next column. For a given search query in a given week it reports how many shoppers searched, how many clicked something, how many added something to a cart and how many bought — and alongside each of those, the share that went to your ASIN.

That is a different question from the one your advertising reports answer. The Sponsored Products search term report can tell you a keyword drew 400 impressions and 12 clicks. It cannot tell you whether 400 impressions was most of that query or a rounding error, or whether the shoppers who didn't click you clicked a competitor or clicked nothing at all. Those are different problems with different fixes, and only one report on Amazon distinguishes them.

It is also the sharpest-edged export in Brand Analytics. Its percentage columns use the opposite convention from its siblings, some of its rate columns legitimately exceed 100%, it caps how much of your catalog you can request at once, and the numbers you pulled last week are not necessarily the numbers Amazon will show you next week. None of that is documented in a way you'd find before you tripped over it. This guide is the procedure plus the traps.

Last updated: September 2, 2026

Verified as of 2026-09-02.

1. What the report actually tells you

One row of Search Query Performance is one (week, ASIN, search query) combination. The week is a completed Sunday-to-Saturday window — that is the only shape the report comes in, so every comparison you build has to be week-on-week.

The columns split into two families, and reading the report is mostly a matter of keeping them apart:

• total* columns describe the query itself, across all of Amazon. Search query volume, total impressions, total clicks, total cart adds, total purchases, plus median prices at each step (totalMedianClickPrice, totalMedianCartAddPrice, totalMedianPurchasePrice). This is the denominator. It is market data, and you have it for queries you have never advertised on.
• asin* columns describe your slice: your impression, click, cart-add and purchase counts, the four share columns derived from them, and your own median prices (asinMedianClickPrice and its cart-add and purchase equivalents).

The total* family is what turns "this keyword is small for us" into either "this keyword is small" or "this keyword is large and we are absent from it" — two situations that look identical in an advertising report. The median-price columns are the most under-used part of the export: asinMedianPurchasePrice against totalMedianPurchasePrice tells you where you sit against what shoppers on that exact query actually paid, not against the list prices of products you assume are your competitors.

On finding it: Search Query Performance lives in Seller Central under Brand Analytics, and requires an enrolled Brand Registry account. Amazon relabels and relocates these menu entries without notice, so search the Seller Central menu for the report name rather than trusting a click-by-click path from any article, including this one.

2. The method: reading the funnel

The analysis this report exists for is a four-step funnel, read in order:

impression share → click share → cart-add share → purchase share

You are not looking at the levels. You are looking for the step where your share falls off — the one place where you hold less of the market than you held a step earlier. That step names the problem:

Then there are the total*Rate columns — totalClickRate, totalCartAddRate, totalPurchaseRate. These are not about you at all. They describe how engaged the whole market is on that query. A query with high volume and a low market-wide purchase rate is a browsing query, and you should expect poor conversion from it no matter how well you execute. That is worth knowing before you build a campaign around it.

There are no benchmarks here, and be suspicious of anyone who gives you one

We do not publish numeric thresholds for "low" and "high" share, and we haven't found a credible source that can. Share is a function of how many sellers compete on a query; a 4% impression share can be dominant on a broad head term and negligible on a long-tail one. Anyone quoting you "a good click share is X%" is guessing.

Use relative comparisons instead: this query against the median of your own query set, this week against prior weeks for the same query, and step against step within one row. The funnel read above is the last of those — it is internal to a single row and needs no external benchmark at all, which is exactly why it's the part worth doing first.

Two unit traps that will cost you real money

Trap one: the share columns are already percentages. asinImpressionShare, asinClickShare, asinCartAddShare and asinPurchaseShare are on a 0–100 scale. A value of 0.41 means 0.41%, not 41%.

This matters more than it sounds, because it is the opposite convention from every sibling Brand Analytics report — Search Terms, Search Catalog Performance, Repeat Purchase and Market Basket all return 0–1 fractions, where 0.41 does mean 41%. Put both exports in one workbook, apply a single percentage format across them, and one side is now wrong by 100x with nothing on screen to say so.

The check takes ten seconds on every fresh export: Amazon's impression share is 100 × asinImpressionCount / totalQueryImpressionCount. Recompute one row from the counts and see which scale the published column is on.

Trap two: rates above 100% are correct. totalClickRate, totalPurchaseRate and totalCartAddRate can legitimately exceed 100 — we have seen values above 4,000. The denominator is search query volume, a de-duplicated count of searchers, not impressions: one shopper who searches once and clicks five products adds one to the denominator and five to the numerator. Don't clamp these columns or rescale them. Filtering out rows above 100% as bad data deletes your highest-consideration queries.

A third, smaller one, if you sell in more than one country: the share columns come back as a numeric type on some marketplaces and as text on others. A multi-marketplace roll-up needs an explicit cast on those columns or it will silently drop the text-typed ones from your aggregates.

3. Doing it by hand

Honest estimate: 90 minutes to two hours a week for a 40–60 ASIN brand, once you have the batches set up and know where everything is. The first run takes longer. This is per marketplace.

Step 1 — Open the report. Seller Central, under Brand Analytics, with Brand Registry enrolled.

Step 2 — Pick a completed Sunday-to-Saturday week. Not "the last 7 days". A partial or misaligned week isn't a smaller version of this report; it's a window that doesn't exist.

Step 3 — Don't pull it too early. Amazon publishes a weekly window several days after it closes, and the ramp is steep. Across 2,062 requests we measured on 2026-08-18: asking one day after the window closed succeeded 0.8% of the time (16 requests out of 2,062). By day 4 it was 60%. By day 7, 88%. If your weekly routine runs Monday morning, you are mostly pulling nothing. Wednesday or later, and expect the occasional retry.

Step 4 — Export in batches of about 18 ASINs. Amazon requires an ASIN list on the request and caps that list at 200 characters. At 10 characters per ASIN plus a separator, that's 18 ASINs per request, and there is no parameter that lifts it. A 60-SKU brand needs four passes; 150 SKUs needs nine. Every week.

Two things follow that are easy to get wrong. Keep batch membership fixed, or your week-over-week comparisons quietly shift with it. And choose the batches by what's at stake rather than alphabetically — a skipped batch is a hole in that week's history for those ASINs, and you can only backfill it until the window ages out.

Step 5 — Fix the units before any formula touches the data. See the traps above. Do this as an import step, not as something you remember to do.

Step 6 — Re-pull the last two to three weeks. Amazon restates this report after publication. Measured across our fleet on 2026-08-18: 16% of one-week-old windows and 24% of two-week-old windows returned a different row count on re-pull. Nothing older than two weeks changed. So the most recent two weeks are provisional and everything before that is stable. If you archive each week once, as first published, your history diverges from Amazon's — silently, and in the direction of looking more stable than reality.

Step 7 — Export the Sponsored Products search term report separately, from the Amazon Ads console, for the same Sunday-to-Saturday dates. Roll its daily rows up to that single week so both sides share a grain.

Step 8 — Join them on search-term text. Details in the next section.

Step 9 — Pivot. One row per query, with the four shares side by side, your week-over-week delta on each, and the ad spend from step 8. Sort by spend, read the funnel, work down.

A note for 1P sellers: this report does not exist for you. It is seller-only. When we requested it on vendor accounts, Amazon accepted the request with a 202 and then failed it within about nine seconds with the message that the API is not available to vendors — including on a vendor account enrolled in Brand Analytics. There is no vendor equivalent. Plan around Vendor Central's own traffic and conversion reporting plus Amazon Ads search term data, and accept that you don't get the market-wide denominator.

4. The join Amazon doesn't give you

The structural gap: Search Query Performance contains no cost data and lives in Seller Central, while your ad spend lives in Amazon Ads, and Amazon provides no key between them — no query ID, no join column, nothing.

So the join is on the query text itself, which is a dirty key. Normalize both sides first (lower-case, collapse whitespace, trim), then XLOOKUP from the Search Query Performance side — not the ads side, because Search Query Performance contains queries you never bid on, and those unmatched rows are the most interesting output of the exercise.

What the joined view gives you that neither half gives alone:

That fourth row is the reason people do this work manually despite the cost. Nothing else on Amazon surfaces it.

5. What breaks at scale

For one brand with 40 SKUs in one marketplace, the routine above is genuinely sustainable. Here is where it stops being:

• The 18-ASIN cap multiplies. 60 SKUs is 4 pulls. 150 SKUs is 9. Three marketplaces is 27, every week. The cap doesn't scale with your catalog, so your effort scales linearly with SKU count while the value per pull stays flat.
• The restatement horizon triples the work. You are never pulling a week. You are pulling this week plus re-pulls of the previous two — so the real weekly volume is roughly 3× the batch count.
• Publication lag makes it a retry loop, not a task. A day-4 pull fails 40% of the time. At one brand that's an annoyance; across a portfolio it's a queue that needs tracking.
• Amazon gives you the report, not the history. There is no archive to go back to. If nobody saved week 34 and re-pulled it inside the restatement window, week 34 is gone. Trend analysis on this report is only as good as your own storage discipline.
• The join is per-brand and per-week. Every one of those spreadsheets is a hand-built artifact that decays the moment anyone renames a column.

The practical threshold, in our experience, is around 100–150 tracked ASINs, or the first week somebody is on holiday. That's not a claim about anyone's competence; it's arithmetic.

6. Doing it with AI

Start with the capability, not the product: any MCP-connected assistant can do this analysis well, provided it has real access to the data. The report is structured, the funnel logic is mechanical, and "share drops here, therefore look at that" is exactly the reasoning a language model is good at. This is not a hard analysis. It is a hard data supply problem.

What that assistant needs, concretely:

1. An authenticated Selling Partner connection with Brand Analytics access on a seller account. No connection, no report; there's no public source for this data.
2. Chunked requesting. Something has to split the catalog into ≤18-ASIN batches, request each, and stitch the results back into one table.
3. Retry against publication lag. A day-4 request that fails is normal, not an error to surface to a human.
4. Stored history with a re-pull policy. Every pull kept, and the last two to three weeks re-pulled and overwritten. Without that, week-over-week comparisons are built on numbers Amazon has since revised.
5. Advertising data on the same weekly grain, so the join is a query rather than a VLOOKUP.
6. The unit conventions encoded where the model can see them. This is the one people miss. Hand an LLM a raw Search Query Performance CSV with no note about the 0–100 convention and it will confidently read 0.41 as 41%, because that is what the column name implies and what every other Brand Analytics report would mean. The fix is not a better model; it is telling it the convention.

If you're building this yourself, that list is the spec. If you'd rather not, that is roughly what Marketplace Ad Pros does: it pulls Search Query Performance on the weekly window, handles the ASIN chunking and the restatement re-pulls, stores every version, keeps your Amazon Ads data on the same grain so the join is already made, and exposes the whole thing to Claude or ChatGPT over MCP with the unit conventions attached to the columns — so you can ask "which queries am I losing at the cart-add step" and get an answer rather than a spreadsheet.

You can read more about that on Amazon Search Query Performance reports and Amazon Brand Analytics reports.

Frequently asked questions

What is the difference between Search Query Performance and the search term report?

They describe different things. The Sponsored Products search term report is an advertising report: it shows the queries that triggered your ads, and what those clicks cost. Search Query Performance is a Brand Analytics report: for each query it shows the whole market's activity that week alongside your ASIN's share of it, and it contains no cost data at all. The search term report tells you a keyword drew 400 impressions; Search Query Performance tells you whether 400 was most of that query or a rounding error, and whether the shoppers who did not click you bought from someone else or bought nothing. They also differ in grain and coverage: Search Query Performance is one row per week per ASIN per query on a Sunday-to-Saturday window, and it includes queries where your product appeared organically and you never bid a cent.

In the Search Query Performance report, does 0.41 mean 0.41% or 41%?

It means 0.41%. The four ASIN share columns in this report are already percentages on a 0 to 100 scale, so multiplying by 100 inflates every share by 100x. This is the single most expensive mistake in the report, because it is the opposite convention from the sibling Brand Analytics reports, which return 0 to 1 fractions. Paste a Search Query Performance export and a Search Terms export into the same sheet and apply one percentage format to both, and one of them is now wrong by two orders of magnitude with nothing on screen to say so. The check is arithmetic: Amazon's impression share equals 100 times your ASIN impression count divided by the query's total impression count, so recompute one row from the raw counts and see which scale it lands on.

Why is my Search Query Performance purchase rate over 100%?

Because the denominator is not impressions. The total click rate, total cart-add rate and total purchase rate columns are computed against search query volume, which is a de-duplicated count of searchers, not a count of times a result was shown. One shopper who searches once and then clicks five results contributes one to the denominator and five to the numerator. Rates above 100 are therefore normal on high-consideration queries, and values above 4,000 do occur. This is Amazon's definition rather than corrupt data, so do not clamp these columns or rescale them to fit under 100.

How many ASINs can you pull per Search Query Performance request?

About 18. Amazon requires an ASIN list on the report request and caps that list at 200 characters. With 10-character ASINs and one separator each, 18 is what fits. There is no page-two parameter that lifts it, so full catalog coverage means repeating the pull with a different batch of ASINs: four passes for a 60-SKU brand, nine for 150 SKUs, every week, for every marketplace. This is the constraint that decides whether weekly Search Query Performance analysis is sustainable by hand. Choose the batches deliberately rather than alphabetically, keep them fixed week to week, and prioritize by the revenue or ad spend actually at stake, because a batch you skip is a week of missing history for those ASINs that you cannot backfill later without another pull.

Can vendors get the Search Query Performance report?

No, and there is no vendor equivalent of it. The report is seller-only. When we requested it on vendor accounts, Amazon accepted the request with a 202 and then failed it within about nine seconds with the message that the API is not available to vendors. We re-confirmed the same result on a vendor account enrolled in Brand Analytics, so Brand Analytics registration does not unlock it. If you sell 1P, the closest substitutes are your own Vendor Central analytics for traffic and conversion and the Amazon Ads search term reports for query-level advertising data. Neither gives you the market-wide denominator that makes Search Query Performance useful, so plan the analysis differently rather than looking for the equivalent export.

Why did last week's Search Query Performance numbers change?

Because Amazon restates the report after it publishes, and a pull is not final. Measured across our fleet on 2026-08-18, 16% of one-week-old windows and 24% of two-week-old windows returned a different row count when pulled again, while nothing older than two weeks changed. In practice that means the most recent two weeks are provisional and everything older is stable. Two consequences follow. First, do not make a decision that only works if last week's number is exact; wait or size the decision to the uncertainty. Second, if you are storing history, re-pull a rolling two-to-three-week tail and overwrite it, because a one-shot archive of each week as first published will drift away from what Amazon reports today, and nothing will tell you it has.

Related reading

• Amazon Search Query Performance reports — the same report through an AI assistant instead of an export
• Amazon Brand Analytics reports — the sibling reports and their 0–1 convention
• Amazon listing quality audit — what to do about a low cart-add share
• Amazon keyword automation — acting on the coverage gaps the join surfaces
• Amazon advertising report automation — the export-and-join problem generalized
• Best Amazon ads management tools in 2026 — if you're evaluating something to carry this
• All guides

Verified as of 2026-09-02. Amazon changes Seller Central menu labels and report mechanics without notice; this page is re-verified quarterly.