One row per ad group per day, for Sponsored Products. ad_group_id plus date is unique on every row. The left-hand side is what the ad group spent — impressions, clicks, cost — and the right-hand side is what Amazon attributed back to it: purchases, units and sales, each at 1, 7, 14 and 30-day windows, and each repeated again for the advertised SKU alone. That is how a report about ad groups reaches 37 columns.

The thing to understand first is where this report comes from. Sponsored Products has no ad group report type of its own. Sponsored Brands and Sponsored Display do; Sponsored Products does not. This file is the campaign report — spCampaigns — asked for with groupBy: ["adGroup"], which swaps the campaign's identity columns for the ad group's own. The column set is genuinely different, confirmed against real files: the nine campaign identity and budget columns the campaign report carries are not available here, and ad_group_id, ad_group_name and ad_status take their place.

The one campaign attribute that survives is campaign_bidding_strategy, which describes the campaign the ad group sits in. campaignId and campaignName are not returned at this grain, so a row cannot be attributed to its campaign from this file alone — that is a property of Amazon's grouping, not a missing request. The mapping lives in the ad group export (POST /adGroups/exports), whose model carries campaignId next to adGroupId for Sponsored Products; Amazon's own advice is to pull metadata as an export and merge it into the report.

The attribution windows nest rather than add: purchases_30d includes purchases_7d, and the _same_sku_ columns are subsets of their unqualified partners. Amazon's column reference defines each of these as conversions "within N days of an ad click", and each same-SKU column as the same event counted only "where the purchased SKU was the same as the SKU advertised".

Through the Amazon Ads API v3, you POST to /reporting/reports with reportTypeId: spCampaigns, adProduct: SPONSORED_PRODUCTS, groupBy: ["adGroup"] and timeUnit: DAILY, naming every column you want. The groupBy value is the whole difference between this report and the campaign report — same report type, different grain, different column set. Amazon returns a report ID; poll it until the status is COMPLETED and download the gzipped JSON from the URL it hands back. The startDate and endDate you request are real data dates: the file covers exactly that window, one file per pull rather than one per day.

The trap is asking for campaign columns. The v3 API returns exactly the columns you requested and nothing else, so a missing column is your request, not Amazon's schema — but at the ad group grouping the campaign* identity and budget columns are simply not on offer, and a pipeline that converts this file against the campaign report's column set gets those columns all-null and drops ad_group_id, ad_group_name and ad_status as unrecognised, with nothing raising.

There is no ad-group report to download in the console either. Amazon's ad group report reference states that Sponsored Products has no separate ad group report and sends you to the campaign report's adGroup grouping, and its current help article on downloadable sponsored ads reports lists every report type the console offers for Sponsored Products, Sponsored Brands and Display without an ad group report among them. Take any console path lightly in any case: Amazon has announced it is sunsetting the console's Sponsored Ads reports section by 31 December 2026 in favour of unified reporting. The API request above is the route that outlasts that.

Ad group ACOS without the campaign average hiding it. ACOS is cost divided by sales_7d (or whichever window you standardise on). A campaign at a comfortable 20% ACOS routinely contains one ad group at 8% and another at 60%; this is the report that separates them.

Finding ad groups that spend and never convert. Filter for rows where cost is positive and purchases_30d is zero over a run of dates — the 30-day window is the most generous, so an ad group that is still at zero there is not waiting on attribution.

Separating same-SKU sales from everything else. The gap between sales_7d and attributed_sales_same_sku_7d is revenue from products other than the one advertised. An ad group whose same-SKU ACOS looks poor but whose total ACOS is healthy is doing a job; judging it on the advertised SKU alone would have you pause it.

Comparing bidding strategies across ad groups. campaign_bidding_strategy is on every row, so cost_per_click and ACOS can be grouped by legacy, manual, ruleBased and optimizeForSales without a join.

Building a daily ad group time series. date is a clean ISO day and (ad_group_id, date) is unique, so the file loads straight into a partitioned table. Join on ad_group_id, never on ad_group_name, which is free text the advertiser can edit.

No campaign on the row. campaignId and campaignName are not returned at this grouping. If a dashboard needs ad groups rolled up to campaigns, this file cannot do it alone; you need a second source that maps ad_group_id to its campaign. The documented one is the ad group export, which carries campaignId for every ad group. What will not work is joining this file to the campaign report: grouped by campaign, that report has no ad_group_id on it to join against. Amazon's other route is to ask for groupBy: ["campaign", "adGroup"] in one request, which returns both ids on the row — but that is a different pull from this one, not a join onto it.

Attribution windows nest — never add them. sales_30d contains sales_14d contains sales_7d contains sales_1d. Summing them counts the same orders up to four times over.

cost and spend are the same number. Equal on every row observed, at this grain as at the campaign grain. Adding them doubles your spend.

Recent days keep changing. The 30-day window means a click today can still attribute a purchase a month from now, so any snapshot of the last month disagrees with the same days re-pulled later. That is attribution settling, not a bug.

Don't average the rate columns. click_through_rate is a percentage computed per row and null where there were no impressions; cost_per_click looks like a rate but is money. Recompute both from clicks, impressions and cost when aggregating.

The raw JSON types wander. In the gzipped JSON Amazon returns, cost, spend and every sales* column arrive as an integer on some rows and a float on others, seller by seller. Anyone inferring types from the file will get one pull as int and the next as double; pin the schema.

Numeric IDs are not numbers. ad_group_id is a 13 to 15 digit JSON number. Read it as a string, or a leading zero disappears silently and the only join key in the file is corrupted.

Sponsored Brands and Sponsored Display are separate reports. Each has its own ad group report type. This one is Sponsored Products only, and the columns do not line up across the three.

KENP is invisible to ACOS. For KDP advertisers, kindle_edition_normalized_pages_royalties_14d is revenue no sales_* column includes. For everyone else both Kindle columns are zero on every row — present, not retired.