One row per manual keyword per day, for Sponsored Products. This is the keyword half of Amazon's spTargeting report: grouped by targeting, daily, and filtered to the keywordType values BROAD, PHRASE and EXACT. Across 14 production files and 511,413 rows the split was 219,531 exact, 148,495 phrase and 143,387 broad, and every file carried the same 52 columns.

The columns fall into four groups. Where the keyword lives — campaign_, ad_group_ and portfolio_id, with the campaign's budget and its currency copied onto every row. The keyword itself — keyword_id, keyword, targeting, keyword_type, match_type and keyword_bid. Delivery — impressions, clicks, click_through_rate, top_of_search_impression_share, cost and cost_per_click. Outcomes, repeated at 1, 7, 14 and 30 days for purchases, units and sales, then again for the same-SKU subset of each, and at 7 days only for the other-SKU remainder. acos_clicks_ and roas_clicks_ at 7 and 14 days are Amazon's own ratios of money columns already in the row.

Two column pairs are the same thing twice, and knowing that saves a morning. keyword and targeting are equal on every one of the 511,413 rows, and so are keyword_type and match_type. targeting and keyword_type are the general spTargeting spellings that cover automatic targets too; this report filters to the keyword types, where they collapse onto the keyword's own text and match type. All four are carried because all four are in Amazon's vocabulary and a consumer reading either name should find it.

In the Amazon Ads console, this is Measurement & Reporting → Sponsored ads reports → Create report, with Sponsored Products as the ad product and Targeting as the report type, on the daily rather than the summary time unit. There is no keyword-only report for Sponsored Products in the console — the console's Keyword report is the Sponsored Brands one — so separating keywords from automatic targets is something you do in the API request.

Through the Amazon Ads API v3, you POST to /reporting/reports with reportTypeId: spTargeting, adProduct: SPONSORED_PRODUCTS, groupBy: ["targeting"], timeUnit: DAILY and format: GZIP_JSON, listing the 52 columns above, with a keywordType filter of ["BROAD", "PHRASE", "EXACT"]. Amazon returns a report ID; poll it until COMPLETED and download the gzipped JSON array it hands back. Generation can take as long as three hours. That request is Amazon's own “Sponsored Products: Keywords only” sample, filter and all.

The filter is the report. The targeting report is this exact request with keywordType set to the automatic target types instead. Leave the filter off and both halves land in one file with the same 52 columns and nothing but the values in keyword_type to tell them apart. Keep the two pulls separate and separately named.

Three properties of the v3 response to rely on. You get exactly the columns you asked for: all 52 arrived in every one of 14 files, in one identical set, so a missing column is your request, not Amazon's schema, and the sparse columns are present-and-null rather than absent. The order of keys in the JSON is whatever Amazon produced that day — it differed in all 14 files — so read by name, never by position. And keyword_id, campaign_id, ad_group_id and portfolio_id arrive as JSON numbers of 12 to 15 digits; cast them to strings on the way in, because they are join keys and a numeric type loses a leading zero silently.

Reports are per-profile, so a seller in five marketplaces runs five requests and gets five files, each in its own currency — campaign_budget_currency_code tells you which.

Comparing your bid with what the auction charged. keyword_bid is what you set and cost_per_click is what a click actually cost, on the same row. A keyword whose CPC sits well under its bid has headroom you are not using; one whose CPC equals its bid is being capped by you, not by competition. Where keyword_bid is null the campaign's bidding strategy is setting the bid, and there is nothing at the keyword level to compare.

Deciding which match types earn their spend. Group by match_type, sum cost and sales_7d, and compute ACOS yourself over the aggregate. Broad, phrase and exact behave differently for most catalogues, and this is the report that separates them by day and by keyword rather than rolling them into the campaign.

Buying top of search deliberately. top_of_search_impression_share sits on the same row as cost and purchases_7d, so you can see whether the keywords winning the top slot are the ones that convert or just the ones that cost most.

Separating halo from direct sales. sales_other_sku_7d and units_sold_other_sku_7d are products people bought other than the advertised one. A keyword with weak same-SKU ACOS and strong total ACOS is introducing shoppers to the range; judged on attributed_sales_same_sku_7d alone it looks like waste.

Building a keyword history that survives re-pulls. date is a plain day with no offset, so partition on it. A re-pulled window restates every one of its days completely, which means you can supersede a day by its latest run instead of deduplicating overlapping windows — and you should, because the attribution columns keep moving for 30 days.

Multi-marketplace roll-ups. campaign_budget_currency_code is populated on every row and agrees with the profile's marketplace, so it is the column to convert on when ten currencies land in the same table.

Attribution windows nest — never add them. purchases_30d contains purchases_14d contains purchases_7d contains purchases_1d, and the same holds for units and sales. Summing the four inflates the number roughly fourfold.

The ACOS and ROAS columns are mostly null, and that is correct. acos_clicks_7d and acos_clicks_14d are null on 98.3% of rows (no attributed sales) and roas_clicks_7d and roas_clicks_14d on 92.8% (no clicks). A null is not a zero: a keyword with spend and no sales has an undefined ACOS, not 0%. Recompute both from cost and sales_7d over any aggregate, which also gets you full precision instead of a rounded ratio.

ACOS is a percentage; ROAS is a multiple. In the measured files ACOS ran as high as 548.8 and ROAS as high as 10,886. click_through_rate and top_of_search_impression_share are percentages bounded at 100. None of the four is a 0 to 1 fraction, and a pipeline that divides by 100 on one and not another will be quietly wrong.

A null bid is not a zero bid. keyword_bid is null on 7.3% of rows, where a campaign bidding strategy sets no per-keyword bid. Treating it as 0 makes those keywords look free.

keyword equals targeting here — do not assume it everywhere. The equality is a consequence of filtering to the keyword types, where the general spTargeting spellings collapse onto the keyword's own. Outside those types the two need not agree, so a pipeline built on this report should not carry that assumption into the targeting report.

Other-SKU exists only at 7 days. Amazon's columns reference carries salesOtherSku and unitsSoldOtherSku at 1, 14 and 30 days too, but not for spTargeting — this report type gets the 7-day pair and nothing else. A halo analysis at 14 or 30 days therefore has to subtract attributed_sales_same_sku_Nd from sales_Nd, which assumes the same-SKU and other-SKU figures partition the total. Amazon's definitions of the three are complementary but it publishes no such identity, and none is measured in the files behind this page, so treat that subtraction as an estimate.

Budget columns repeat per keyword. campaign_budget_amount is the campaign's budget copied onto every keyword row in that campaign. Summing it across an ad group multiplies the budget by the number of keywords.

There is no spend column. cost is the only spend figure — a difference from the campaign report, where both names are carried and equal.

Column order is not stable. The JSON key order differed in every one of 14 files, and a schema inferred from values flips money columns between integer and float according to whether that seller happened to have a fractional value that window. Pin the schema and read by name.

An empty day withdraws nothing. A re-pull fully restates every day that has rows, but a day on which the advertiser had no keyword rows produces no file at all. If you rely on re-pulls to clear out a bad day, check that the day actually came back.

Recent days keep changing. Amazon publishes initial click and impression data within 12 hours and can still adjust it for three days while invalid traffic is filtered; conversions arrive within 24 hours and are restated 1, 7 and 28 days after the conversion event. With a 30-day attribution column on the row, the last month restates on every re-pull.