The Sales and Traffic report by child ASIN answers one question: for a single variation, on a single day, how many shoppers arrived and how many of them bought. Each row carries the traffic side — sessions, page_views, 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.

Amazon splits nearly every traffic column three ways: a browser figure, an Amazon-app figure, and a combined total. It then repeats the whole set for Amazon Business buyers, suffixed _b2b. The B2B columns are a subset of the main ones, never an addition, so a report that adds units_ordered and units_ordered_b2b together double-counts every business order.

The row's identity is the triple child_asin + start_date + reported_marketplace_id. A single pull can span marketplaces, each row carrying its own currency code, so a sales total that ignores ordered_product_sales_currency_code silently adds pounds to dollars.

In Seller Central, it lives under Reports → Business Reports, where Amazon lists it among the By ASIN reports as Detail Page Sales and Traffic By Child Item. Pick a date range, then download it as CSV. Amazon refreshes this grain daily — only the by date reports update hourly — so the UI is fine for a spot check, and the API is the better route for anything recurring.

Through the Selling Partner API, it comes from Data Kiosk rather than the older Reports API. You submit a GraphQL query against the analytics_salesAndTraffic_2024_04_24 dataset, calling salesAndTrafficByAsin with aggregateBy: CHILD and a start and end date, then poll the query until Amazon hands back a document ID and download the JSONL. Data Kiosk checks roles per field when the query is created, and Amazon lists Brand Analytics as a required role on every one of its operations. That is a role the developer applies for and Amazon approves for the calling application — not an entitlement the seller buys — so it is not a prerequisite you can go and purchase.

One detail catches everyone: salesAndTrafficByAsin aggregates its whole date range into one row per ASIN. Ask for a month and you get one row per ASIN for that month, not thirty daily rows. To keep daily grain you have to issue one query per day — and to re-issue the most recent days, because Amazon keeps restating them, so a day fetched once and never revisited will drift.

Data Kiosk also refuses more than one root field per query ("Versioned domain cannot select multiple query fields"), so the by-date, by-ASIN and by-SKU grains cannot be fetched together.

Separating a traffic problem from a conversion problem. A listing that lost sales has either lost sessions or lost unit_session_percentage, and the fix is completely different. Both sit in the same row here, so the comparison needs no join, and because the query sweeps the whole catalogue you can rank every ASIN by which of the two moved.

Spotting the days the add-to-cart link was missing. Amazon defines buy_box_percentage as the share of page views where the buy box appeared for a shopper to add your product to the cart, so a fall means visitors reached the page and were not offered that path. Read it beside sessions and unit_session_percentage: traffic holding steady while conversion drops, on a day the buy box share also drops, is the shape worth investigating. Amazon's definition says nothing about competing offers, pricing or stock, and it publishes no account of why the buy box stops appearing — so treat the column as the symptom and go looking for the cause elsewhere.

Finding the weak child in a strong family. Grouping on parent_asin shows which variations absorb the family's traffic. A colour or size with healthy sessions and a conversion rate well below its siblings usually has a listing problem — a bad main image, a missing size chart, a price out of line — not a demand problem.

Sizing the Amazon Business opportunity. The _b2b columns show what share of demand is already business buyers, which is the honest input to whether B2B pricing and quantity discounts are worth configuring.

Building a real conversion baseline for ad decisions. Advertising reports give you ad conversion; this gives you the organic-plus-paid rate for the same ASIN, and the gap between them is what tells you whether the ads are buying incremental sales or subsidising traffic that converted anyway.

The SKU grain is not a superset of the ASIN grain. The by-SKU version of this report attributes traffic more narrowly, and the two genuinely do not reconcile — the same seller, the same day, can answer 234 child-ASIN rows and 168 SKU rows. Pick the grain that matches the question and do not try to tie them out.

Recent days get restated. Attribution settles over several days, so yesterday's numbers will change. Anything that snapshots a day once and never revisits it will drift away from Seller Central. Re-pull a rolling window instead.

Sessions are deduplicated per user per 24 hours, so they do not add up the way page views do. Summing daily sessions across a month overstates monthly sessions, because a shopper who came back on five days counts five times.

unit_session_percentage can exceed 100%. It divides units by sessions, and one session can buy several units. On multipacks and consumables this is normal, not a data error.

Zero-session ASINs are absent, not zero. A variation nobody viewed produces no row at all. Code that expects a dense grid of ASIN × day has to fill the gaps itself.

Money is not converted. Every money column ships with its own currency code, and a multi-marketplace pull mixes them freely.