Amazon Sales and Traffic Report by Date

One row is one day in one marketplace: the account added up, with no ASIN, SKU or title anywhere in it. sessions and page_views describe the demand that arrived and buy_box_percentage how often the buy box appeared on the page for a shopper to add your product to the cart; units_ordered, total_order_items and ordered_product_sales describe what it turned into; and unit_session_percentage and order_item_session_percentage are the two ways Amazon divides one by the other.

What makes this grain worth pulling separately is the columns the item grains simply do not have. The shipped side — units_shipped, orders_shipped, shipped_product_sales — sits on the same row as the ordered side. So does the unhappy side: units_refunded, refund_rate, claims_granted, claims_amount, feedback_received, negative_feedback_received and received_negative_feedback_rate. So do the per-order-item averages (average_selling_price, average_sales_per_order_item, average_units_per_order_item) and two columns describing the catalogue itself, average_offer_count and average_parent_items. None of these appear in the by-ASIN or by-SKU grain.

It also drops something. The item grains carry share-of-your-own-catalogue columns — session_percentage, page_views_percentage and friends — which are meaningless once the row is the whole catalogue, and they are absent here.

Every traffic column is split three ways, into a browser figure, an Amazon-app figure and a combined total, and the whole set is repeated for Amazon Business buyers with a _b2b suffix. The B2B columns are a subset of the main ones, never an addition; adding units_ordered_b2b to units_ordered counts every business order twice.

Money is an amount and a currency code together, even for the per-item averages, and one file can hold several currencies at once. reported_marketplace_id is the second half of the row's identity, and the column that keeps those currencies apart.

Through the Selling Partner API this comes from Data Kiosk, not the older Reports API. You submit a GraphQL document against the analytics_salesAndTraffic_2024_04_24 dataset selecting salesAndTrafficByDate with a start date, an end date and day-level aggregation, poll the query until Amazon returns a document id, then download the JSONL. In production those queries came back in roughly 20 to 60 seconds end to end.

The trap is the reverse of the one on the item grains. salesAndTrafficByDate at day granularity returns one row per day per marketplace across the whole range you asked for, so a five-day window is one query and five rows per marketplace. Its siblings collapse their range into one row per item, which is why they need a query per day. Code that copies the by-ASIN fetch loop here issues five queries to get what one would have returned.

One query also spans marketplaces. Rows come back per day and per marketplace id, each in its own currency — a four-marketplace query answered Canadian dollar rows beside US dollar ones — so there is nothing to fan out per marketplace and nothing to merge afterwards.

Two limits shape any scheduler around this. Data Kiosk accepts exactly 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 and are three separate jobs. And createQuery is rate limited to one a minute with a burst of fifteen per seller, so what you have to keep under control is a single credential's daily total, not the fleet's.

There is no authorization-vintage gate on this one: a credential that returns 403 on the 2024 Finances operations still answers Data Kiosk, so coverage is the whole seller fleet rather than a recently re-authorized subset.

In Seller Central the same numbers appear under Reports → Business Reports, where Sales and Traffic is one of the By date reports.

Reading a revenue move as price, basket or volume. Revenue is average_selling_price × average_units_per_order_item × total_order_items, and this is the only Amazon report that hands you all three for the same day. A drop with a flat unit price and fewer order items is a demand story; the same drop with steady order items and a lower average selling price is a pricing or coupon story.

Watching conversion without letting one ASIN speak for the account. unit_session_percentage here is the whole account. Tracked beside order_item_session_percentage it separates a real conversion change from a mix shift into multipacks, because only the first of the two moves when basket size does.

A daily refund and claims watch. refund_rate, units_refunded, claims_granted and claims_amount land on the same row as the sales they will eventually erode. A rising refund rate against flat orders is a quality or listing-accuracy problem showing up days before it reaches account health.

Fulfilment lag, measured. units_ordered against units_shipped and orders_shipped over a couple of weeks shows how much of a soft sales week was demand and how much was shipping backing up. The item grains cannot answer this at all — they have no shipped columns.

Sizing Amazon Business honestly. The _b2b columns give B2B's real share of sessions, units and revenue, plus a separate buy_box_percentage_b2b and average_selling_price_b2b. That is the input to whether business pricing and quantity discounts are worth configuring, and it does not require reconciling anything at item level.

A catalogue-size denominator. average_offer_count and average_parent_items turn "we added 400 listings in March" into a daily series you can put underneath sessions, which is how you tell catalogue growth apart from listing performance.

This file cannot name a listing. It is the correct file for an account trend and the wrong one for a diagnosis. The moment the question is "which ASIN", you need the by-ASIN or by-SKU grain, which is a different report and a different query.

Recent days get restated. Amazon keeps changing the last few days, which is why the by-date query re-states a rolling lookback window on every run rather than fetching yesterday once. Anything that snapshots a day and never revisits it will drift away from Seller Central.

One file, several currencies. Each row is in its marketplace's own currency and nothing is converted. Summing ordered_product_sales without grouping on ordered_product_sales_currency_code and reported_marketplace_id produces a number with no meaning.

Ordered, shipped and refunded are three different clocks. ordered_product_sales is counted on the order, shipped_product_sales and units_shipped on the shipment, units_refunded on the refund. Netting them within one row gives you a figure that describes no real day.

Sessions do not add up across days. They are a deduplicated visitor count, so a month's sessions are not the sum of the month's daily sessions — a shopper who returned on five days is counted five times in that sum.

The B2B columns are a subset. Every _b2b column is already inside its parent. Adding them is the most common way this report is read wrong.

unit_session_percentage can exceed 100. Units over sessions, and one session can buy several units. On multipacks and consumables this is expected, not corrupt data.

Do not expect the grains to tie out. The by-ASIN and by-SKU grains demonstrably do not reconcile with each other — the same seller on the same day answered 234 child-ASIN rows and 168 SKU rows, because Amazon attributes traffic to SKUs more narrowly than to ASINs. Against this grain the traffic side cannot tie at all: Amazon counts an item's sessions as the sessions that contained at least one page view of that item, so a shopper who looked at three of your ASINs is one session on this row and three in the by-ASIN sum. The sales side is a separate question and an untested one: nothing here establishes whether a day's units_ordered and ordered_product_sales equal the sum of that day's by-ASIN rows.