One row is one ASIN over one reporting period. The report answers a single question about that ASIN — of the customers who ordered it, how many had ordered it before, and what they spent — and the ten columns are the whole file. The ASIN alone is not the key: it is the ASIN and the period, so an ASIN recurs once per period and successive pulls stack rather than replace each other. Anything you join or deduplicate on has to carry both.

Four of them establish identity and scope: asin, the period bounded by start_date and end_date, and report_period, which names whether that period is a WEEK, a MONTH or a QUARTER. Two are the raw counts the rest rests on: orders and unique_customers. Because orders are counted per order and customers are deduplicated, unique_customers is at most orders, and the distance between them already says something about repeat buying inside the period.

The remaining four are the result. repeat_customers_pct_total is loyalty measured in people; repeat_purchase_revenue, with its own repeat_purchase_revenue_currency_code, is loyalty measured in money, and repeat_purchase_revenue_pct_total puts that money back into proportion. Note what is not here: neither total — not total customers, not total revenue — is a column. The percentages are the only route to the denominators, and only by division. Both of those columns are fractions in Amazon's schema, bounded at 0 and 1 rather than 0 and 100, so a repeat share of eighteen per cent arrives as 0.18.

Through the Selling Partner API, this arrives as a JSON report document rather than a flat file: a reportSpecification echoing the request you made, and a single dataByAsin collection holding the rows. Amazon states availability as sellers and vendors who hold the Brand Analytics Selling Partner API role and are registered in Brand Registry; on the seller path, Amazon adds that Brand Analytics needs a Professional selling account and Brand Representative status for the enrolled brand. The dataByAsin rows have to be rendered out of the document before they are a table at all, and there is only one row grain in the document — so one table, unlike the promotions and coupon documents that hold several.

Amazon publishes no clock for this one. The reference says the report can only be requested, never scheduled, and the period is a required reportOptions value you choose per request. So weekly describes the rows rather than a refresh rate: one row covers one week, which is what reportPeriod=WEEK returns. Amazon states no refresh rate for this report anywhere.

The trap is that file format. A tab-separated reader cannot read the raw JSON, so anything that assumes the downloaded document is already a table produces the right columns with nothing in them. The document has to be parsed as JSON and the dataByAsin collection flattened before the rows exist at all. If your first pull is empty or all nulls, you parsed a JSON document as a flat file.

The second thing to get right is the period. The report answers a WEEK, a MONTH or a QUARTER, and which one you asked for changes what every number means — a repeat rate over a quarter is not a worse-measured weekly rate, it is a different measurement, because a longer period gives customers more chance to come back inside it. A single request may also span several periods, and Amazon's schema says the per-ASIN data is then repeated for each of them — so even inside one document the same ASIN can appear more than once, keyed by the period it covers. report_period is in the row so you can tell files apart after the fact; keep it in anything you stack.

In the console, the same data is the Repeat Purchase Behavior dashboard. The route Amazon publishes is the seller one: reach Brand Analytics from the Seller Central main menu under Brands → Brand Analytics, with the Repeat Purchase Behavior dashboard under the Customer Behavior Analytics drop-down there, in either a Brand View or an ASIN View. Amazon writes no equivalent Vendor Central route anywhere public, so a vendor holding the Brand Analytics role has the API report documented but not the console path. Either way the dashboard and the report are not guaranteed to agree column for column, so use it to sanity-check a pull rather than to reconcile one.

Separating acquisition from retention on one ASIN. Sales rising while repeat_customers_pct_total falls is a growth story driven by new buyers; sales flat while it rises means you are living off the customers you already have. The two have completely different next moves, and no sales report distinguishes them.

Finding the consumables you did not know you had. ASINs with a high repeat-customer share are products people re-buy on their own. They are the ones worth a Subscribe and Save offer, a multipack variation, or a larger post-purchase spend — and the ranking is often not the one the catalogue would suggest.

Valuing a repeat customer. repeat_purchase_revenue divided by the repeat customers implied by repeat_customers_pct_total and unique_customers gives a per-repeat-customer figure from the file itself, which is the honest input to what a first order is worth paying for.

Spotting the ASINs where money and people disagree. An ASIN whose repeat_purchase_revenue_pct_total sits well above its repeat_customers_pct_total earns disproportionately from a small loyal group; the reverse means repeat buyers come back for something cheap. Both are real and they call for opposite merchandising.

Watching a launch mature. A new ASIN starts with no repeat customers by definition. Pulling the same weeks in sequence shows when the repeat share starts to build, which is the earliest evidence that the product itself — not the launch spend — is working.

Measuring the gap between orders and customers. orders well above unique_customers in a single week means people are re-buying inside the period, which is a different and faster signal than the period-over-period repeat share.

The totals are not in the file. There is no total customers column and no total revenue column. Every absolute number you want besides orders, unique_customers and repeat_purchase_revenue has to be reconstructed by dividing by a percentage, which fails outright when that percentage is zero — a common case on new or low-volume ASINs.

The period changes the answer. Repeat rates are not comparable across a WEEK, a MONTH and a QUARTER; a longer window mechanically produces a higher repeat share. Comparing files without grouping on report_period manufactures a trend out of nothing.

Weekly rows do not add up. A customer who bought in three different weeks is three unique customers if you sum the weekly rows. unique_customers is deduplicated within a period only, so a monthly figure has to come from a monthly pull, not from four weekly ones.

Money is not converted. repeat_purchase_revenue ships with its own currency code, so a union of pulls from different marketplaces mixes currencies in one column.

The row carries no marketplace. The marketplace is a property of the request, not the row: Amazon's schema keeps marketplaceIds in the report specification and accepts only one marketplace per report. The ten columns therefore say nothing about where the orders happened; marketplace, country and currency have to be attached to the table from the request rather than read off the row. If you stack files yourself, carry the marketplace or the rows become unattributable.

What counts as a repeat customer is Amazon's definition, not yours. The report counts customers who had ordered the ASIN before, and Amazon's own description of the matching console dashboard is that it shows how often unique customers place multiple orders of the same product — so the comparison is per ASIN, not across your brand. What Amazon does not say anywhere public is how far back it looks for that earlier order. Do not restate the number as "returning customers in the last N days" until someone confirms the window.

The schema stands on one file. These ten columns were validated against a production US file of 406 ASINs over one WEEK period. That is a real file, which is more than most schemas stand on, but it is one marketplace and one period — a monthly or quarterly pull, or another marketplace, is where a column you have not seen would first appear.