Amazon Sales and Traffic Report by SKU

One row is one seller SKU, on one day, in one marketplace. The row carries the demand side — sessions, page_views split between browser and the Amazon app, and the buy_box_percentage that records how often the buy box appeared on the page for a shopper to add your product to the cart — beside the outcome side: units_ordered, total_order_items and ordered_product_sales. Every traffic and sales column is repeated for Amazon Business buyers with a _b2b suffix, and those columns are a subset of the main ones rather than an addition to them.

Column for column this is the child-ASIN report with sku added; upstream the two tables share one extractor. What the extra column buys you is a join. Traffic and conversion arrive keyed on the identifier your cost, price, repricer and inventory systems already speak, so you can put sessions next to landed cost without a SKU-to-ASIN mapping table in between.

parent_asin and child_asin still travel on every row, so a SKU tells you which listing it sits on. Two of your SKUs listed against the same child ASIN — an FBA and an FBM offer, say — appear as two rows here and as one row in the ASIN report. What that does not mean is that this report is the ASIN report broken down further; see the first gotcha below, which is the single most important sentence on this page.

Through the Selling Partner API, this comes from Data Kiosk, Amazon's GraphQL successor to GET_SALES_AND_TRAFFIC_REPORT, rather than the older Reports API. You submit a GraphQL document to createQuery against the analytics_salesAndTraffic_2024_04_24 dataset, asking for sales and traffic at SKU granularity with a start and end date, poll the query until Amazon hands back a document id, then download a JSONL document — the familiar create, poll, download shape with a query language in front of it. In production these queries come back in roughly 20 to 60 seconds. Data Kiosk checks roles per field at query creation, and Amazon lists Brand Analytics as the required role for every one of its operations — that is an authorisation the calling application holds, not a subscription the seller buys.

Two traps sit in the query itself. Data Kiosk allows exactly one root field per query — an aliased document asking for two is rejected outright with "Versioned domain cannot select multiple query fields" — so the by-date, by-ASIN and by-SKU grains have to be three separate queries. And the by-SKU query aggregates its whole date range into one row per SKU. Ask for a month and you get one row per SKU for the month, not thirty daily rows. Daily grain means one query per day, which is what Trellis issues: a rolling five-day window, re-requested every day because Amazon keeps restating recent days.

A third thing is worth knowing before you plan the fan-out: one query spans marketplaces. Rows come back per day and marketplace, each in its own currency, so there is no need to issue a query per marketplace — partition on reported_marketplace_id afterwards instead. Budget against the createQuery quota, which is one per minute with a burst of fifteen per seller; a day of all three grains for one credential is eleven creates, inside the burst.

In Seller Central the same family of numbers lives under Reports → Business Reports, where Amazon names the detail-page reports as Detail Page Sales and Traffic, Detail Page Sales and Traffic By Parent Item and Detail Page Sales and Traffic By Child Item. It names no by-SKU view among them, so the SKU grain is documented on the API path and nowhere public in the console.

Telling two offers on one listing apart. An FBA SKU and an FBM SKU on the same child ASIN are one row in the ASIN report and two rows here. unit_session_percentage, units_ordered and ordered_product_sales per SKU show which offer the demand actually went to, which is the question behind most "should I keep the merchant-fulfilled offer" arguments. buy_box_percentage sits beside them as how often the buy box appeared on the page at all — Amazon's own definition — rather than as a win rate between your two offers.

Putting margin next to conversion. ordered_product_sales and units_ordered land on the same key your cost table uses, so realised average selling price per SKU per day — sales divided by units — can sit beside unit cost without a mapping step. The ASIN grain cannot do this for a listing you sell under more than one SKU.

Watching a repricer's effect on demand, not just on price. A price move shows up in this report as sessions and unit_session_percentage on the SKU the repricer acted on, rather than averaged across every offer on the listing — so a week where traffic held and conversion fell can be read against the offer whose price actually moved.

Feeding replenishment with the demand signal, not just the shipment signal. units_ordered per SKU per day is the series most forecasting models want, and it arrives already keyed to the SKU the purchase order will be written against.

Sizing Amazon Business demand per offer. The _b2b columns show whether business buyers concentrate on particular SKUs — typically case packs and multipacks — which is the honest input to whether B2B pricing or quantity discounts are worth configuring, and on which offers.

The SKU grain is not a superset of the ASIN grain, and the two do not reconcile. This is the thing to take away from this page. The same seller, on the same day, answered 234 child-ASIN rows and 168 SKU rows: Amazon attributes traffic to SKUs more narrowly than it does to ASINs, so the SKU file is not the ASIN file with more rows in it, and the columns you might expect to tie out do not. Pick the grain that matches the question. Do not sum SKU sessions and expect the ASIN total, do not use one report to audit the other, and do not build a pipeline whose correctness check is that they agree. Amazon documents the SKU grain only as a granularity of the same query and says nothing about why the two row counts differ, so this page reports the difference and offers no mechanism for it.

Recent days get restated. Attribution settles over several days, so yesterday's numbers will move. Anything that snapshots a day once and never revisits it drifts away from Seller Central; a re-pulled rolling window is the fix.

The percentage columns share a moving denominator. session_percentage, page_views_percentage and their browser, app and B2B variants are shares of your own account's total for the day, not of the category — Amazon's schema defines each one against the total "for all products". A SKU's share can fall in a week where its own sessions rose. Amazon does not say whether that account total is enumerated over SKUs or over ASINs, and since the two grains do not answer the same number of rows, a SKU share and an ASIN share should not be treated as shares of one denominator.

Money is never converted. Every money column ships beside its own currency code, and because one query answers every marketplace, a single file mixes currencies freely — a four-marketplace query returned CAD rows next to USD ones. Group on ordered_product_sales_currency_code, or on reported_marketplace_id, before you sum anything.

The B2B columns are a subset. Adding units_ordered to units_ordered_b2b, or either sales pair, double counts every business order.

start_date equals end_date only because the query asked for one day. Widen the range and the same row shape comes back as a range total — the dates say so, and nothing else does.

unit_session_percentage can exceed 100%. It divides units by sessions, and one session can buy several units. On multipacks and consumables this is ordinary.

Sessions are de-duplicated per shopper over 24 hours. Amazon counts all browser and mobile app activity by one user within a 24-hour period as a single session, so summing daily sessions across a month overstates the month. Whether a SKU with no activity comes back as a zero row or no row at all is not documented at this grain — Amazon states the omit-it behaviour only for the separate salesAndTrafficTrends query — so code that wants a dense SKU-by-day grid should fill gaps itself rather than rely on either shape.