This is the seller-side answer to "what did that coupon actually do". Amazon returns it as a JSON document rather than a flat export, and the seller document holds two row grains at once: a flat list of coupons, each with its clips, redemptions, budget figures and sales; and, under each coupon, the ASINs it applies to. They land as two tables for that reason, and this page documents both.

A coupon row carries its identity (coupon_id, name, website_message, merchant_id), its schedule (start_date_time, end_date_time), its configuration (discount_type, discount_amount) and then the four things people actually open the file for: clips and redemptions on the demand side, budget, budget_spent, budget_remaining and budget_percentage_used on the cost side, and sales with total_discount on the outcome side.

An ASIN row carries only coupon_id and asin. That is the whole grain — there is no per-ASIN breakdown of clips, redemptions or sales here, which is the single most common expectation this report disappoints.

Money is never converted: currency_code rides on the coupon row, and every money column on that row takes its unit from it.

Both tables also carry context columns that Amazon's document does not — marketplace_id, country_code and snapshot_date, and on the ASIN table a currency_code as well. They are added when the document is stored rather than returned in it, so the column reference does not describe them.

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

Two traps sit in that one request. The first is that Amazon uses this single report type for both sellers and vendors and answers each with a different schema: a seller account gets the flat coupons[] list described here, while a vendor account gets campaigns[] with coupons nested inside them. Code written against one shape does not read the other, and nothing in the request says which you will get — your account type does.

The second is what the date range means. Coupons are selected by when their campaign started, so you get every coupon that starts in the window, not every coupon that was running during it. A coupon that began before your range and ran all the way through it is simply absent. If the question is "what ran last month", the window has to cover when those coupons started.

Amazon's report-type reference gives the entry an Availability of "Sellers" and a Role of Brand Analytics — an application-level SP-API role, not a seller entitlement — and says the report can only be requested, never scheduled. What the entry does not give is a store list. The "Amazon store availability" line that other report types carry is simply absent here, so which marketplaces offer this report is not something Amazon publishes, and this page does not guess.

Main table

asins

Judging whether a coupon paid for itself. sales against budget_spent and total_discount on the same row is the whole argument, and it is one join away from nothing else — no other Amazon report puts a coupon's cost and its attributed revenue side by side.

Reading the clip-to-redemption gap. clips counts shoppers who took the coupon; redemptions counts those who used it. A coupon clipped thousands of times and redeemed rarely is a discount that got attention and still lost the sale, which is a price or listing problem rather than a promotion problem.

Catching a coupon about to run out of budget. budget_remaining near zero well before end_date_time means the coupon will not survive its own schedule. What Amazon does at that moment is not established, but the warning is in the file days ahead of anyone noticing the coupon stopped working.

Auditing the live coupon calendar. One pull gives every coupon whose campaign starts in the window with its schedule, discount configuration and shopper-facing website_message already populated — which is a review of what is booked, from the same file that later reports how it went.

Building a coupon-to-ASIN map. The ASIN grain is the only place this report says which products a coupon covered. Joined on coupon_id, it is what lets coupon activity be lined up against ASIN-level sales and traffic reporting — which is also the only way to get anything ASIN-level out of a coupon at all.

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

The ASIN grain has no metrics. coupon_id and asin is the entire row. Anyone expecting the per-ASIN breakdown that the promotions performance report provides will not find one here, and a per-ASIN number built by dividing coupon sales across its ASINs is an invention, not a measurement.

There is no date column on the metrics. Nothing in either grain says which day the clips, redemptions or sales happened on, so the figures read as totals for the coupon so far: Amazon states that a coupon still in progress comes back with cumulative data up to the day before the request, and that a coupon which ended a day or more earlier comes back complete. A daily series means diffing successive pulls, not grouping a column.

Scheduled and still-running coupons are in the file with little to show. A coupon whose end_date_time is in the future has incomplete figures by definition, and averaging redemptions or budget_percentage_used across every row without filtering on the schedule drags the average toward zero.

The same report type answers vendors differently. A vendor account's document is campaigns[] with nested coupons, not the flat coupons[] documented here, so a parser shared between account types needs to branch on the shape it received.

discount_amount is not comparable across rows. Its unit depends on discount_type, so summing or averaging it across a file that mixes types produces a number that means nothing.

Do not assume every coupon brings ASIN rows. The schemas were validated against a production US file holding 3 seller coupons over 15 ASINs — a small file, which is also a reason to treat the column list as what that file contained. Join left from the coupon grain.

Money is not converted. Every money column takes its unit from currency_code on the same row, and a pull covering more than one marketplace mixes currencies in the same column.