This is the deal-level answer to "what did that promotion actually do". Amazon returns it as a JSON document rather than a flat export, and the document holds two row grains at once: the promotion, with its own glance_views, units_sold and revenue; and the per-ASIN breakdown of those same three figures across the products the promotion included. This page documents both as two tables for that reason — the columns prefixed product_ are the second grain.

A promotion row carries its identity (promotion_id, promotion_name, type, status), its schedule (start_date_time, end_date_time) and its record history (created_date_time, last_updated_date_time) beside the three performance numbers. A product row carries only promotion_id, asin, product_name and the three product_ figures, so it means nothing without joining back to the promotion it belongs to.

Money is never converted: both grains ship their own currency column, revenue_currency_code and product_revenue_currency_code.

Through the Selling Partner API, request the report type GET_PROMOTION_PERFORMANCE_REPORT for a marketplace with a start and end date, poll until Amazon returns a document id, then download it. What comes back is JSON, not the tab-separated text many other report types answer with, so a pipeline that assumes TSV fails on the first byte rather than on a column.

The trap is what the date range means. The window is matched against each promotion's start date, and it reaches forward as well as back: ask for a range and you get every promotion that starts in it, including deals scheduled for days that have not happened yet. A promotion that began before your window and ran all the way through it is simply absent. If the question is "what ran last month", the request window has to cover when those promotions started, not when they were live.

Who can request it. Amazon lists this report for sellers and vendors. A seller needs the Selling Partner Insights Selling Partner API role on the application making the request; a vendor needs the Brand Analytics role. Amazon's availability line attaches "who are also registered in Amazon's Brand Registry" to the vendor clause alone, so nothing published gates a seller on Brand Registry — which is why this page claims no entitlement beyond those API roles. Both are roles on the SP-API connection rather than anything switched on inside Seller Central. Amazon documents no console route to this report type at all — its reference covers only the API request, and notes the report can be requested but not scheduled — so no Seller Central path is stated here.

Where it exists is not published. Amazon's report-type reference names the roles and the seller type for this report and stops there — unlike its FBA entries, it carries no "Amazon store availability" line naming regions. An absent restriction is not an availability list, so this page records its marketplaces as not published rather than guessing a region set. The file behind it was a US pull, which says where the request was made, not where Amazon offers it.

Main table

products

Measuring what a deal moved. glance_views, units_sold and revenue on one row give the traffic and the outcome for the promotion as a whole, which is the number people mean when they ask whether a deal was worth it.

Finding which ASIN carried the promotion. A multi-ASIN deal is rarely evenly used. Sorting the product grain by product_units_sold within one promotion_id usually shows one or two ASINs taking almost all of it, which is the argument for narrowing the next deal rather than widening it.

Auditing the deal calendar before it runs. Because the window reaches forward, a pull returns scheduled promotions with their start_date_time, end_date_time, type and status already populated. That is a review of what is booked, from the same file that later reports how it went.

Spotting promotions that were edited after scheduling. last_updated_date_time moving away from created_date_time marks deals someone changed after setting them up — worth checking against what was approved.

Building a promotion-to-ASIN map. The product grain is the only place the file says which ASINs a promotion actually included, which is what lets promotion activity be joined to ASIN-level sales and traffic reporting.

The window selects on start date, not on activity. This is the mistake that silently loses rows: a long-running promotion that started before the requested range does not appear in it, however much it sold during it.

Scheduled promotions are in the file with nothing to show. Deals that have not run yet come back alongside finished ones. Averaging units_sold across every row without filtering on status or start_date_time drags the average toward zero.

Two grains, one file — do not sum them together. revenue and product_revenue describe the same money at different levels of detail. Adding them, or joining product rows onto promotion rows and then summing the promotion column, double-counts.

Do not assume every promotion has product rows. The schemas were validated against a production US file holding 4,282 promotions and 7,390 included products — fewer than two ASINs per promotion on average. Join left from the promotion grain; the evidence does not establish that a promotion always brings at least one product row with it.

There is no date column on the metrics. Nothing in either grain says which day the glance views or units happened on. Amazon states the figures are cumulative for the promotion up until the day prior to the request, and that a promotion is only reported completely once it ended a day or more before you asked — so a running deal's numbers are promotion-to-date and one pull behind, not live. Every pull is therefore a snapshot of totals as they stood that day, not a period of data, which is what this page's cadence records. Getting a daily series out of this report means diffing successive pulls, not grouping a column.

Money is not converted. Both grains carry their own currency code per row, and a pull covering more than one marketplace mixes currencies in the same column.

Vendors: the funding columns Amazon documents are not in this list. Amazon's schema marks vendorCode, amountSpent, amountSpentCurrencyCode and fundingAgreementId on a promotion, and productAmountSpent on an included product, as vendor-only — and none of them appears among the columns above, which were measured on a seller file. Whether a vendor's own pull carries them is not something this page's evidence settles; check your own document before building on promotion spend.