One row per advertised product per day, for Sponsored Products. The "product" is the ad itself: ad_id, with the advertised_asin and advertised_sku it promotes, and the campaign_id, ad_group_id and portfolio_id it sits under. Where the campaign report tells you what a campaign did, this one tells you which product inside it did it.

The left-hand side is what the ad cost — impressions, clicks, cost and spend — and the right-hand side is what Amazon attributed back to it, repeated at four attribution windows (1, 7, 14 and 30 days) and repeated again for units and for same-SKU. That is how a report about one ad ends up 49 columns wide. The windows are cumulative rather than additive: sales_30d includes sales_7d, so picking a window is picking how much credit a click gets for a slow decision. Amazon's column reference defines each of them the same way — sales "occurring within N days of an ad click" — so the containment is definitional, not an artefact of the file.

Two columns exist only at 7 days: units_sold_other_sku_7d and sales_other_sku_7d. They are the halo — products other than the advertised SKU bought after the click — carried explicitly rather than left for you to derive. Amazon defines them as the part of the 7-day window where the purchased SKU differed from the one advertised, and the same-SKU columns as the part where it matched, so the two are complements by definition. Whether they reconcile to sales_7d exactly in a real file has not been checked.

Amazon also computes four ratios for you: click_through_rate, acos_clicks_7d, acos_clicks_14d, roas_clicks_7d and roas_clicks_14d. All of them are percentages or bare multiples, none is a 0-to-1 fraction, and all of them are null where their denominator is zero — which at this grain is most rows. The campaign's budget, budget type and budget currency are repeated on every one of its ad rows, so the row is self-contained, but they describe the campaign, not the ad.

Every one of the 49 requested columns arrives on every file. Nothing is conditionally absent; the sparse columns are present and null, which is a different thing.

Through the Amazon Ads API v3, request reportTypeId: spAdvertisedProduct with adProduct: SPONSORED_PRODUCTS, timeUnit: DAILY, format: GZIP_JSON and — the part that catches people — groupBy: ["advertiser"]. There is no advertisedProduct grouping to ask for; the report type already fixes the grain, and advertiser is the grouping it accepts. Name every column you want in the request. You POST that to /reporting/reports, get a report ID back, poll until it is COMPLETED and download the gzipped JSON. Amazon's own sample call for this report type is that same POST with adProduct: SPONSORED_PRODUCTS, groupBy: ["advertiser"], reportTypeId: spAdvertisedProduct and format: GZIP_JSON — at timeUnit: SUMMARY, where a row per day needs DAILY — and its reporting guide warns that generation can take as long as three hours.

The v3 API returns exactly the columns you asked for and nothing else. A column that is missing from your file is missing from your request, not from Amazon's schema, and a column you did not ask for will never appear. Reports are per-profile, so a seller advertising in several marketplaces runs one request per profile and gets one file per profile, each in its own currency.

In the Amazon Ads console, the same data is the Sponsored Products Advertised product report: Measurement & Reporting in the sidebar, then Sponsored ads reports, then Create report, at a summary or daily time unit. Amazon is retiring that section — unified reporting at Measurement and Reporting → Reporting carries an Advertised product template, and Sponsored Ads reports is being sunset by 31 December 2026 — so the API request above is the durable path. The console report's lookback is 90 days against the API's 95.

Product-level ACOS inside a campaign. A campaign's ACOS is an average over its ads. Divide cost by sales_7d per advertised_asin and you find the one product spending the budget while the others earn it — the thing the campaign report structurally cannot show you.

Total ad spend per product, across campaigns. Where the same ASIN is advertised from more than one campaign, summing cost over advertised_asin and date, ignoring campaign, gives the number a product manager actually wants: what it cost to advertise this product today.

Halo per product, not per campaign. sales_other_sku_7d against attributed_sales_same_sku_7d shows which advertised products pull other products with them. A hero ASIN with weak same-SKU ACOS and a large other-SKU column is doing a job the campaign total hides.

Pruning ads that never click. Around nine in ten advertised-product-days have zero clicks. Filter to rows with impressions above some floor and clicks of zero, sum over 30 days by ad_id, and you have the list of ads spending impressions on nothing.

Portfolio roll-ups. portfolio_id lets you aggregate spend and sales at the portfolio level without a second lookup — with the caveat that it is null on roughly 40% of rows, because those campaigns are in no portfolio, and a naive group-by drops them into one anonymous bucket.

Superseding a day cleanly. Because a re-pull of a window restates every day in it, and because each day is a complete statement of that day's rows, you can replace a day wholesale with its latest pull rather than deduplicating overlapping windows.

cost and spend are not always the same number here. On the campaign grain they agree on every row; on this grain they agree on 99.8% of rows and differ on the rest — 2,360 of 1,096,316 in production files. The evidence records that they differ, not why, and Amazon's documentation offers no cause: the v3 column reference gives both the identical description, Total cost of ad clicks, and the version 2 to version 3 migration guide derives both from the one v2 cost metric. Pick one, use it everywhere, and never add them together.

Null is not zero. cost_per_click, roas_clicks_7d and roas_clicks_14d are null on 90.7% of rows (no clicks); acos_clicks_7d and acos_clicks_14d on 98.6% (no attributed sales); click_through_rate on 10.6% (no impressions); portfolio_id on 39.5% (no portfolio). A tool that reads null as zero will report a 0% ACOS on ads that sold nothing, which is the opposite of the truth.

The ratios are percentages and multiples, not fractions. ACOS runs to 182.9 in production files, click_through_rate to 200.0, ROAS to 6,534. A dashboard expecting 0-to-1 values will show ACOS of 18,290%. And Amazon's ACOS and ROAS exist only at 7 and 14 days — a 1-day or 30-day ACOS you compute yourself from cost and sales_1d or sales_30d.

Don't trust the rounded ratios when it matters. acos_clicks_7d is a rounded quotient of two columns the row already carries at full precision. For anything you will be held to, divide cost by sales_7d yourself, and recompute rather than average when aggregating.

The ID columns arrive as numbers. campaign_id, ad_group_id, ad_id and portfolio_id come through the JSON as 12-to-15-digit numbers. Load them as text: they are join keys, and a numeric type drops a leading zero without a word.

The raw JSON is not stable file to file. Left to infer types, a money column comes out as an integer in a file where every value happened to be whole and as a float in the next; ACOS lands as an all-null column for an advertiser with no attributed sales; and the column order follows whatever order the JSON happened to carry, which varies between files. Read by column name against a fixed schema, never by position, and never let one file's inferred types define the table.

Attribution windows nest — never add them. sales_30d contains sales_14d contains sales_7d contains sales_1d — each is defined as what occurred within that many days of the click. Summing across windows roughly quadruples revenue.

Budget columns describe the campaign, not the ad. campaign_budget_amount is repeated on every ad row in a campaign. Summing it over the report counts each budget as many times as the campaign has advertised products.

An empty day is no file, not a file of zeros. A day on which the advertiser had no rows lands nothing. A gap in your table is not necessarily a failed pull.

Sponsored Products only. adProduct is SPONSORED_PRODUCTS. Sponsored Brands and Sponsored Display advertised-product data are separate reports with their own columns.