What this report contains
One row per automatic target, per shopper search term, per day, for Sponsored Products. It is the standard spSearchTerm report with one filter applied: only rows whose target is an automatic targeting expression — TARGETING_EXPRESSION_PREDEFINED or TARGETING_EXPRESSION — so what you get is every query that Amazon's auto targeting matched your ads to, and what happened next.
The row's identity is three columns: keyword_id, search_term and date. Across 99,630 rows from 14 production files that key was unique every time, so the same search term shows up once for each auto target it matched on a given day, and summing cost over a day is safe.
The left-hand side describes the target. keyword, targeting, keyword_type and match_type sound like four columns but are closer to two. keyword_type and match_type are equal on every row. keyword and targeting, though, differ on 7.2% of rows, and the difference is the useful kind: for a category target keyword carries the category id and targeting carries its name. This is the reverse of the manual keyword report, where the two are identical on every row, and it is why both are carried here. The word "keyword" in keyword_id and keyword_bid is Amazon's vocabulary, not a description — there are no keywords in this file, only targets.
The right-hand side is the same attribution block every Sponsored Products report carries: impressions, clicks, cost, then purchases, units and sales at 1, 7, 14 and 30 days, each repeated for the advertised SKU alone. The windows nest — the 30-day figure contains the 7-day figure — and acos_clicks_7d and roas_clicks_7d are pre-computed ratios of money columns you already have. Only the 7-day window is carried for the other-SKU (halo) columns.
How to get it
Through the Amazon Ads API v3, POST to /reporting/reports with reportTypeId: spSearchTerm, adProduct: SPONSORED_PRODUCTS, groupBy: ["searchTerm"], timeUnit: DAILY, format: GZIP_JSON, and a filters entry of field: keywordType with values: ["TARGETING_EXPRESSION", "TARGETING_EXPRESSION_PREDEFINED"]. Name all 53 columns you want in columns; Amazon returns a report id, you poll it until the status is COMPLETED, and download the gzipped JSON array of flat objects it points to. The response contains exactly the columns you asked for and nothing else, so a column that is missing is a request you did not make, not a schema change.
The filter is the whole report. Without it, the same request returns the manual keyword rows too, and the keyword_type column is how you would tell them apart afterwards: the auto rows carry the two TARGETING_EXPRESSION values, the manual rows carry BROAD, PHRASE or EXACT. Requesting the auto slice separately keeps the two vocabularies from ever sharing a table.
In the Amazon Ads console, there is no separate auto-targeting search term report. Amazon's own instructions are to click Measurement & Reporting in the sidebar, then Sponsored ads reports, then Create report; the Sponsored Products search term report you get there "contains both keyword and targeting data broken out by search term", so you filter to the auto rows yourself in the download.
The console file is not the same population as this one. Amazon states that the console search term report contains every search term that had an impression, while the API report only contains impressions that also had at least one click — so the console will always show more search terms than this file does.
Reports are per-profile, so a seller advertising in several marketplaces runs one request per marketplace and gets one file each, in that marketplace's currency.
Sample rows
Illustrative values, not data from a real account. Shown to give the shape of the file.
| date | campaign_name | keyword_type | keyword | targeting | search_term | impressions | clicks | cost | sales_7d |
|---|---|---|---|---|---|---|---|---|---|
| 2026-09-14 | Auto - Compression Socks | TARGETING_EXPRESSION_PREDEFINED | close-match | close-match | compression socks women | 18420 | 231 | 142.22 | 612.40 |
| 2026-09-14 | Auto - Compression Socks | TARGETING_EXPRESSION_PREDEFINED | loose-match | loose-match | socks for nurses | 6310 | 58 | 31.90 | 89.97 |
| 2026-09-14 | Auto - Compression Socks | TARGETING_EXPRESSION_PREDEFINED | substitutes | substitutes | knee high support stockings | 2740 | 33 | 24.75 | 0.00 |
| 2026-09-14 | Auto - Compression Socks | TARGETING_EXPRESSION | category="1234567890" | category="Women's Compression Socks" | medical compression socks 20-30 mmhg | 9105 | 97 | 71.78 | 244.95 |
| 2026-09-14 | Auto - Compression Socks | TARGETING_EXPRESSION | category="1234567890" | category="Women's Compression Socks" | travel socks | 1280 | 9 | 5.40 | 0.00 |
Field reference
| Column | Type | Description |
|---|---|---|
date | date | The advertising day the row's metrics are attributed to, as a plain ISO date with no time component. It was YYYY-MM-DD on every one of 99,630 measured rows, so there is no marketplace date-order ambiguity to read through. This is the column daily partitions are cut on. |
campaign_id | string | Amazon's numeric campaign identifier, a 10-15 digit number carried as a string because it is a join key and a numeric type would silently drop a leading zero. |
campaign_name | string | The campaign name as it stood when the report ran. Join on campaign_id, not on this. |
campaign_status | string | Whether the campaign was enabled, paused or archived at report time. |
campaign_budget_amount | decimal | The campaign's configured budget, in campaign_budget_currency_code. |
campaign_budget_type | string | Whether the budget is daily or a lifetime total. |
campaign_budget_currency_code | string | The currency of campaign_budget_amount. Populated on every row and matching the credential's marketplace in every file measured (BRL, CAD, EUR, GBP, MXN, USD). Kept under its own name rather than a generic currency column because it strictly describes the budget, even though in practice it is the currency every money column in the row is denominated in. |
ad_group_id | string | Amazon's numeric ad group identifier, carried as a string for the same join-key reason as campaign_id. |
ad_group_name | string | The ad group name at report time. |
portfolio_id | string | The portfolio the campaign belongs to, as a string identifier. Null on roughly a third of rows (31.4% measured) because many campaigns sit in no portfolio; that is structural, not missing data. |
keyword_id | string | Amazon's identifier for the automatic target that matched the search term. Despite the name there is no keyword here — it identifies the targeting expression. Together with search_term and date it forms the row's unique key: 99,630 distinct keys over 99,630 rows. |
keyword | string | The automatic target in Amazon's internal form. For a category target this is the category id — category="3589004031" — while targeting carries the same target by name. The two differ on 7.2% of rows, so never assume one from the other. |
targeting | string | The automatic target in its human-readable form. For a category target this is the category name — category="Calze a compressione da donna" — where keyword has the id. Equal to keyword on the remaining 92.8% of rows. This is the opposite of the manual keyword report, where the two are identical on every row. |
keyword_type | string | Which kind of automatic target matched: TARGETING_EXPRESSION_PREDEFINED (Amazon's built-in auto match groups, 88% of measured rows) or TARGETING_EXPRESSION (an expression the advertiser wrote, such as a category, 12%). These two values are what this report is filtered to; you will not see BROAD, PHRASE or EXACT here. |
match_type | string | Identical to keyword_type on every measured row. Both are requested and carried because both are in Amazon's vocabulary; treat them as one column. |
keyword_bid | decimal | The bid on this specific target, in money. Null on 0.5% of rows, where the campaign's bidding strategy sets no per-target bid. |
ad_keyword_status | string | The status of the target (enabled, paused or archived) at report time. |
search_term | string | The shopper's query. Free text, never null in the measured files, and different from keyword on every row — one is the query, the other is what matched it. This is the column keyword harvesting and negative lists are built from. Not every value is something a shopper typed. Amazon states that this column also carries alphanumeric entries such as b00ipgvvz4, which are ASINs identifying the product detail page an ad displayed on, and that those entries appear only for automatic-targeted campaigns and product-attribute-targeted ad groups — which is exactly this report. Amazon also states that a placement with no search keyword associated with it on a detail page is reported as an asterisk *. Neither shape appeared in the files measured for this page, so look for both before treating the column as pure search text. |
impressions | int64 | Times an ad was displayed for this target against this search term on this day. |
clicks | int64 | Clicks on those impressions. The billable event. |
click_through_rate | float64 | Clicks divided by impressions, expressed as a percentage (values up to 200.0 were measured), not a 0-1 fraction. Null on 0.1% of rows. Recompute from the counts when aggregating rather than averaging this column. |
cost | decimal | What the clicks cost, in the campaign's currency. This report does not request a spend column, so cost is the only spend figure and there is nothing to reconcile it against. |
cost_per_click | decimal | Average cost per click for the row. Typed as money, because cost per click times clicks is cost. Recompute from cost and clicks when aggregating. |
purchases_1d | int64 | Orders attributed to a click within 1 day. |
purchases_7d | int64 | Orders attributed within 7 days. Includes everything in purchases_1d. |
purchases_14d | int64 | Orders attributed within 14 days. Includes everything in purchases_7d. |
purchases_30d | int64 | Orders attributed within 30 days. The widest window, and the slowest to settle. |
purchases_same_sku_1d | int64 | The subset of purchases_1d that were the advertised SKU itself rather than another product bought after the click. |
purchases_same_sku_7d | int64 | Same-SKU subset of purchases_7d. |
purchases_same_sku_14d | int64 | Same-SKU subset of purchases_14d. |
purchases_same_sku_30d | int64 | Same-SKU subset of purchases_30d. |
units_sold_clicks_1d | int64 | Units sold in click-attributed orders within 1 day. Counts units, where purchases_1d counts orders. |
units_sold_clicks_7d | int64 | Units sold in click-attributed orders within 7 days. |
units_sold_clicks_14d | int64 | Units sold in click-attributed orders within 14 days. |
units_sold_clicks_30d | int64 | Units sold in click-attributed orders within 30 days. |
units_sold_same_sku_1d | int64 | Units of the advertised SKU specifically, within 1 day. |
units_sold_same_sku_7d | int64 | Units of the advertised SKU specifically, within 7 days. |
units_sold_same_sku_14d | int64 | Units of the advertised SKU specifically, within 14 days. |
units_sold_same_sku_30d | int64 | Units of the advertised SKU specifically, within 30 days. |
units_sold_other_sku_7d | int64 | Units of products other than the advertised SKU, within 7 days — the halo in unit terms. Only the 7-day window is carried for the other-SKU columns. |
sales_1d | decimal | Attributed sales value within 1 day, in the campaign's currency. |
sales_7d | decimal | Attributed sales value within 7 days. The denominator behind acos_clicks_7d. |
sales_14d | decimal | Attributed sales value within 14 days. The denominator behind acos_clicks_14d. |
sales_30d | decimal | Attributed sales value within 30 days. |
attributed_sales_same_sku_1d | decimal | The portion of sales_1d from the advertised SKU itself. |
attributed_sales_same_sku_7d | decimal | The portion of sales_7d from the advertised SKU itself. |
attributed_sales_same_sku_14d | decimal | The portion of sales_14d from the advertised SKU itself. |
attributed_sales_same_sku_30d | decimal | The portion of sales_30d from the advertised SKU itself. |
sales_other_sku_7d | decimal | Attributed sales of products other than the advertised SKU, within 7 days — the halo in money. Carried at full decimal precision; the schema this report used to be read with flipped this column between integer and double from file to file, which is one of the reasons the schema is now pinned. |
acos_clicks_7d | float64 | Advertising cost of sales at 7 days, as a percentage — cost over sales_7d times 100, with values up to 497.0 measured. Null on 92.9% of rows, because most (target, search term, day) combinations have no attributed sales at all. For exact figures divide the two money columns yourself. |
acos_clicks_14d | float64 | Advertising cost of sales at 14 days, as a percentage. Null on the same 92.9% of rows as the 7-day figure. |
roas_clicks_7d | float64 | Return on ad spend at 7 days, as a bare multiple (values up to 15,463 measured), not a percentage. Null on 0.1% of rows. |
roas_clicks_14d | float64 | Return on ad spend at 14 days, as a bare multiple. |
Use cases
Harvesting search terms into manual campaigns. Sort search_term by purchases_7d or sales_7d and pull the winners into exact-match keywords in a manual campaign. keyword_type tells you whether the match came from Amazon's predefined groups or from a category expression you wrote, which changes how much credit the term deserves.
Building negative keyword lists. Search terms with high clicks and cost but zero purchases_7d — the 92.9% of rows where acos_clicks_7d is null are mostly these — are the negative-exact candidates. Because the grain is per target, the same wasteful term can appear under several targets on the same day; group by search_term before deciding.
Seeing which auto match group actually converts. Group by targeting and compare cost against sales_7d. A predefined group that spends without selling can be paused without touching the rest of the campaign.
Separating direct from halo sales. sales_other_sku_7d is revenue from products other than the one advertised, and the gap between sales_7d and attributed_sales_same_sku_7d is the same idea arrived at by subtraction. Auto targeting is where halo tends to be largest, and a search term with poor same-SKU ACOS may still be paying for itself.
Reconciling category ids to names. Because keyword carries a category target's id and targeting its name, this report is a ready-made lookup between the two — useful when another export gives you only the id.
Standardising ACOS across reports. acos_clicks_7d and acos_clicks_14d are here, but so are cost and sales_7d; computing the ratio yourself from the money columns gives you exactness and a consistent window across the campaign, keyword and search term reports.
Limitations and gotchas
keyword and targeting are not interchangeable here. They differ on 7.2% of rows — category id versus category name. A join or a GROUP BY on the wrong one splits a target in two. Pick one and use it everywhere; if you need a human-readable label use targeting, if you need something stable use keyword or better keyword_id.
Do not hard-code the predefined target labels. Amazon names the four automatic targets created for every auto ad group CLOSE_MATCH, LOOSE_MATCH, SUBSTITUTES and COMPLEMENTS, but defines the report's targeting column only as "a string representation of the expression object used in the targeting clause" and never says how a predefined expression is written out in the file. The production files behind this page carried only category-style expressions, so the predefined labels in this page's sample rows follow Amazon's console vocabulary rather than a measured value. Read the literal strings off your first pull before filtering on them.
ACOS and CTR are percentages, ROAS is a multiple. acos_clicks_7d reached 497.0 in production files, click_through_rate reached 200.0 and roas_clicks_7d reached 15,463. None is a 0-1 fraction, and treating ACOS as one understates it a hundredfold.
Most ACOS values are null, and that is correct. 92.9% of rows have no attributed sales, so Amazon returns no ratio. Filtering to non-null ACOS silently drops every unconverted search term — which is precisely the set a negative-keyword job needs.
Attribution windows nest — never add them. sales_30d contains sales_14d contains sales_7d contains sales_1d. Summing across windows inflates revenue roughly fourfold.
The other-SKU columns exist only at 7 days. There is no sales_other_sku_14d. Amazon defines sales_14d as the total value of sales within 14 days of a click and attributed_sales_same_sku_14d as the part of that where the purchased SKU was the one advertised, so the difference between the two is the nearest thing to halo at 14 or 30 days. Amazon does not state anywhere that the two columns are exact complements, and the production files behind this page were not checked for it, so treat the subtraction as an estimate until you have verified it on your own pull — at 7 days, where sales_other_sku_7d is given outright, use the column instead.
Recent days keep changing. A click today can attribute a purchase 30 days from now. Yesterday's row re-pulled in a fortnight will show more sales; that is settling, not a bug.
Do not average the rate columns. click_through_rate, cost_per_click, ACOS and ROAS are computed per row. Recompute from impressions, clicks, cost and sales_Nd when aggregating.
Ids are strings. keyword_id, campaign_id, ad_group_id and portfolio_id arrive from Amazon as 10-15 digit JSON numbers and are typed string. Cast them back to integers in a spreadsheet and you lose leading zeros and precision.
Names are as-of-now. campaign_name, ad_group_name and the status columns reflect the account at report time, not on the row's date. A renamed campaign has its new name on rows from three weeks ago.
Sponsored Brands has its own search term report. This is Sponsored Products only. The Sponsored Brands search term report is a different report type with different columns.
FAQ
They are the same Amazon report type, spSearchTerm, split by the kind of target that matched. The auto report is filtered to TARGETING_EXPRESSION and TARGETING_EXPRESSION_PREDEFINED targets; the manual report is the BROAD, PHRASE and EXACT keyword rows. Same columns, different vocabulary in keyword_type and match_type.
For a category target, keyword holds the category id and targeting holds its name. On the other rows the two are equal. This only happens in the auto report; in the manual keyword report the two columns are identical on every row.
Because most search terms on most days produce clicks but no attributed sale, and Amazon does not return a ratio with a zero denominator. In production files about 93 percent of rows have a null ACOS. Those rows are not broken; they are your negative keyword candidates.
A percentage. Values above 100 are common and values near 500 have been observed. Click-through rate is a percentage too, while ROAS is a plain multiple.
There is none. This report requests cost only, so cost is the single spend figure. The campaign report carries both cost and spend, which are the same number.
No. The 30-day figure already includes everything in the 7-day figure. Pick one window, use it consistently, and say which one you used.
Sources
Every researched claim on this page, and the Amazon or Walmart page it came from.
- marketplaces — advertising.amazon.com/faq — version 3 reporting is 'available worldwide (NA, EU, FE) wherever you can run sponsored ads'. The search term report type page names no marketplace restriction of its own.
- marketplaces — advertising.amazon.com/G3HEFZYWZF84NPS9 — Amazon's console help scopes the Sponsored Products search term report by account type ('available for sellers, vendors, authors, and book vendors running Sponsored Brands and Sponsored Products campaigns'), not by marketplace.
- marketplaces — advertising.amazon.com/features — the per-marketplace list (US, CA, MX, BR, DE, ES, FR, IT, UK, NL, SE, TR, PL, BE, UAE, EG, SA, JP, IN, AU, SG, ZA) was checked and deliberately not used as the basis for an enumeration. It names 22 marketplaces and omits Ireland, yet the sibling Sponsored Products advertised-product report was pulled from an IE profile on 2026-09-16, so the list is incomplete. Enumerating from it would have told a reader this report is unavailable in a marketplace that production files exist for; `all` follows the v3 reporting FAQ instead.
- history_window — advertising.amazon.com/search-term — the search term report configuration table gives `spSearchTerm` a maximum date range of 31 days and data retention of 65 days. That table has only two columns, Sponsored Products and Sponsored Brands, and 65 days is the Sponsored Products figure (Sponsored Brands is 60). Retention is per report type, not per ad product — the campaign and targeting tables at the same level give Sponsored Products 95 days.
- history_window — advertising.amazon.com/G3HEFZYWZF84NPS9 — 'The search term report has 2 time units available summary or daily. The lookback window for the search term report is 65 days.' The console surface and the API agree at 65 days for this report.
- history_window — advertising.amazon.com/faq — the FAQ's 'longer historical reporting window of up to 95 days' is a general claim about version 3 versus version 2, not about this report type; where the two differ the report type page and the console help both say 65.
- latency — advertising.amazon.com/faq — 'Initial impression and click data is available using the API within 12 hours', changes 'may happen up to three days after the initial click date due to the traffic validation process', 'Initial conversion data is available within 24 hours', 'Restatements of conversion data occur 1, 7, and 28 days after the conversion event', and 'Report generation can take as long as three hours.'
- latency — advertising.amazon.com/overview — conversion data 'is subject to change for up to 60 days back from the current date', invalid-traffic detection 'monitors the traffic data for up to 30 days after the fact', and Amazon recommends 'waiting at least 5 days for the most accurate click data'.
- how-to-get-it — advertising.amazon.com/advertising-console — 'To access your reports, click Measurement & Reporting in the sidebar, then click through to Sponsored ads reports. From here, click on Create report'; the search term report is named there as one of the report types you choose.
- how-to-get-it — advertising.amazon.com/advertising-console — 'The console search term report contains both keyword and targeting data broken out by search term', which is the mixed manual/auto claim, and 'search terms only appear in the API report if they have at least one click while in the console report, search terms without clicks are included'.
- grain — advertising.amazon.com/search-term — the `spSearchTerm` configuration table gives `searchTerm` as the only `groupBy`, which is why the single taxonomy term `search-term` matches Amazon's own vocabulary for this report. The unique key measured in the production files is (keyword_id, search_term, date), so a search term appears once per auto target it matched on a day; that second axis is carried in the summary and in the overview rather than in a compound grain term, per the directory decision to keep the closest single term.
- fields / search_term — advertising.amazon.com/G3HEFZYWZF84NPS9 — 'In the column labeled customer search term, you may notice alphanumeric entries such as "b00ipgvvz4" ... These alphanumeric entries correspond to ASINs and the related product detail page on which your ad displayed. You'll only see ASIN-related entries listed as customer search terms for your Sponsored Products automatic-targeted campaigns and product-attribute-targeted ad groups.' That is this report, so the caveat is in the column description. The column was measured as never null and always different from `keyword`; ASIN values were not looked for, and nothing measured was changed.
- fields / search_term — advertising.amazon.com/search-term — 'If a placement does not have a search keyword associated with it on a product detail page, the search term in the report will be an asterisk `*`.' The v3 column reference defines `searchTerm` only as 'The search term used by the customer. Same as query.'
- sample / targeting — advertising.amazon.com/auto-targeting — Amazon names the four automatically created auto targeting expressions CLOSE_MATCH, LOOSE_MATCH, SUBSTITUTES and COMPLEMENTS, but advertising.amazon.com/columns defines `targeting` only as 'A string representation of the expression object used in the targeting clause' and neither page states how a predefined expression is written out in the report file. The sample's close-match, loose-match and substitutes are console vocabulary, not a measured or documented value, and the limitations section now says so.
- limitations / halo — advertising.amazon.com/columns — `sales7d` is 'Total value of sales occurring within 7 days of an ad click', `attributedSalesSameSku7d` is the same 'where the purchased SKU was the same as the SKU advertised', and `salesOtherSku7d` is the same 'where the purchased SKU was different from the SKU advertised'. Three independent definitions, consistent with sales_7d = attributed_sales_same_sku_7d + sales_other_sku_7d but not a statement of it; the identity was not measured. The page no longer asserts it.
- how-to-get-it — advertising.amazon.com/faq — 'The search term report in the advertising console contains all search terms that had an impression, regardless of if that term resulted in a click. The API search term report only contains impressions that also had at least one click.'