One row is a pairing: an ASIN of yours, an ASIN that was bought in the same customer order, the rank of that pairing among the ASINs most often bought with yours, and the share of qualifying orders the pairing accounts for. An ASIN of yours therefore occupies several rows — one per partner ASIN — ordered by purchased_with_rank, and the six columns are the entire file.

The grain is listed as one row per ASIN, and that names the anchor rather than the whole row. The row's real key is the pair (asin, purchased_with_asin): count rows and you are counting pairings, count distinct asin values and you are counting your own products. Anything that expects one row per ASIN — a join, a GROUP BY left off, a row count read as a product count — will multiply by the length of the ranked list.

The asymmetry between the two ASIN columns is the report. asin is always in the selling partner's catalogue. purchased_with_asin need not be, and the interesting answers are usually the ones you do not already sell. What the file gives you about that partner ASIN is an identifier, a rank and a share — no title, no brand, no price, no seller, no order count — so anything else about it comes from a catalogue lookup you do yourself.

start_date and end_date bound the period the counting happened over. Nothing in the row is dated more finely, and there is no marketplace column: the marketplace is a property of the request that produced the file, not of the row.

Amazon states availability for this report type as sellers and vendors who hold the Brand Analytics Selling Partner API role and are registered in Brand Registry, so this is not a seller-only report even though it is filed here under Seller Central. The gates Amazon publishes for Brand Analytics on the seller side are a Professional selling account and Brand Representative status on a brand enrolled in Brand Registry. The Brand Analytics role is a different kind of thing — a permission on the application you authorise, not an entitlement you hold as a seller — which is why it is named here rather than among this report's requirements.

Through the Selling Partner API the report type is GET_BRAND_ANALYTICS_MARKET_BASKET_REPORT, and the document that comes back is JSON rather than a flat file: a reportSpecification echoing the request that was made, and a single dataByAsin collection holding the rows. Flattening that collection gives the table of pairings.

The trap is the file format. A tab-separated parser aimed at this document produces a file with the right columns and nothing in them, so if a first pull comes back all nulls, a JSON document was read as a flat file.

There is no publishing clock to wait on. Amazon's reference says this report can only be requested and never scheduled, and every request names a reportPeriod of DAY, WEEK, MONTH or QUARTER, with dataStartTime and dataEndTime having to fall on valid first and last days of that period — a WEEK request has to start on a Sunday and end on a Saturday. The daily cadence is the period a row covers, not a rate at which anything is refreshed: on a DAY request start_date and end_date are the same day. Amazon publishes no refresh statement for this report.

The second trap is the marketplace. Amazon rejects a request naming more than one marketplace for this report type outright — not a truncated answer, a refused request — so one request per marketplace is a hard requirement here, and combining marketplaces is something you do after the fact.

In Seller Central, the same analysis lives at Brands → Brand Analytics from the main menu, under the Customer Behavior Analytics drop-down, as the Market Basket Analysis dashboard. That is the only console path Amazon publishes: a vendor holding the Brand Analytics role pulls the same report type through the API, and where the equivalent dashboard sits in Vendor Central is not written down anywhere outside the login. Either way the dashboard is not the same artefact as the report — Amazon describes it as showing the top three products most frequently bought with yours, where the API answers a ranked list you pull one marketplace at a time.

Deciding what to bundle. Take the pairings where purchased_with_asin is already in your catalogue and purchased_with_rank is 1 or 2, and you have a shortlist of combinations customers are already assembling themselves, ordered by combination_pct.

Finding the gap in your own catalogue. The partner ASINs that do not resolve against your listings are the point of the report: they are identifiers of things bought alongside yours that you do not currently offer. The file will not tell you what they are — that is a catalogue lookup — but it tells you which ones to look up first.

Ordering a cross-sell module. purchased_with_rank gives a defensible order for anything that has to show "goes with this" in a fixed number of slots, rather than ordering by whatever you happen to want to sell.

Watching a pairing move. Because each row carries its own period, successive pulls let you track one pairing's combination_pct and its rank over time. A pairing climbing the rank list is a different signal from one whose share rose while everything else rose too.

Segmenting the anchor ASINs. Grouping rows by asin shows which of your products sit in large baskets at all. An ASIN whose top pairing has a low combination_pct is bought on its own more often than one whose top pairing is large, which is a different merchandising problem.

The schema is a contract, not a file. These six columns are the ones Amazon's published sellingPartnerMarketBasketAnalysisReport.json in amzn/selling-partner-api-models declares, and it pins all six as required. They have not been settled against a production pull. The thing to watch on a first live run is schema drift: a field in the answer that this schema does not carry will be dropped silently by anything built to the schema.

It is a ranked list, not a whole basket. The rows are the ASINs most often bought with yours, so shares will not sum to anything meaningful and a pairing's absence is not evidence that the combination never happened — only that it did not make the list.

One marketplace per file, and the file does not say which. Since Amazon refuses a multi-marketplace request, every file is single-marketplace by construction, and there is no marketplace column in the row. If you union pulls together you have to carry the marketplace yourself or the rows become unattributable.

purchased_with_asin will not join. Code that inner-joins the partner ASIN to your own catalogue silently discards precisely the rows the report exists to surface. Use an outer join and treat the misses as results.

It is a co-occurrence count, not a reason. Two ASINs in one order is what the row records. The file carries nothing about who sells the partner ASIN, what it costs, whether it is a substitute or an accessory, or whether either purchase influenced the other.

Do not compare combination_pct across anchors without care. The denominator is per anchor: Amazon's schema counts the orders that contained that asin alongside at least one other different item. So a 0.10 pairing on a low-volume ASIN and a 0.10 pairing on a high-volume one stand on very different numbers of orders — and the file does not give you those order counts.