Ready to take your Amazon Vendor data ops to the next level?
Request access today and let InsightLeap help grow your business!
August 23, 2026 by InsightLeap
Someone asks you to pull the Sales Diagnostic, or to explain why Net PPM slipped, or why the forecast your planner is working from doesn't match what Vendor Central shows this morning, and the report name is always the easy part. The hours go into working out what's actually in it: which fields, at what granularity, how far back it reaches, and how stale the data already is by the time the screen loads.
What follows is a definition for every report a vendor sees, grouped by what the report is for. Two things are worth knowing before the list. Vendor Central's analytics come from two separate systems: Retail Analytics covers your own ordered and shipped performance, traffic, inventory, margin, and forecast, while Brand Analytics covers shopper search and purchase behavior and is gated by Brand Registry. Most of these screens also have a programmatic counterpart in Amazon's Selling Partner API, and that public documentation is the only place the granularity, refresh timing, and lookback limits are stated exactly. So where a documented API report covers the same ground as a screen in the UI, it's named below with its limits, because those limits decide whether the number you want is available at all.
This is the screen most vendors open first. It reports shipped cost of goods at ASIN level on a daily basis and presents summary and detailed comparative views over time, so it's the standard place to go looking for a sales opportunity or a drop worth chasing.
GET_VENDOR_SALES_REPORT covers the same territory programmatically, returning ordered and shipped revenue and units, both aggregated and at ASIN level, at DAY, WEEK, MONTH, QUARTER, or YEAR granularity. Daily requests are capped at 15-day spans, annual requests can span up to two years, and YEAR-period data reaches back as far as three years. Because both an ordered measure and a shipped measure live in the same export, say which one you mean whenever the number leaves your desk.
Traffic Diagnostic reads glance views and conversion against industry benchmarks, which is how you separate a traffic problem from a conversion problem when sales move. GET_VENDOR_TRAFFIC_REPORT is the export in the same territory, carrying glance views (detail page views) aggregated and at ASIN level, on the same granularities and lookback as the sales report.
One detail catches teams outside the US: every vendor analytics report uses Pacific Standard Time regardless of where you sit. A "day" in this data is a Pacific day, so a daily comparison against a system running on local time will drift by a few hours of orders. For the mechanics of what a glance view actually counts, our post on glance views as a vendor KPI goes through it.
Two hourly reports sit alongside the period-based ones:
GET_VENDOR_REAL_TIME_SALES_REPORT returns ordered units and revenue per ASIN by hour. You can request it five minutes after each hour closes, with a 30-day lookback and a 14-day maximum span per request. Negative unit values represent cancellations, so an individual hour can read below zero.GET_VENDOR_REAL_TIME_TRAFFIC_REPORT returns glance views per ASIN by hour, for the hours where you held the featured offer. It becomes available roughly 65 to 115 minutes after the hour closes, with the same 30-day lookback and 14-day maximum span.The 30-day lookback is the part to plan around, because hourly history older than that stops being requestable. If you'll want an hour-by-hour record of this month's stockout next spring, something on your side has to capture it while the window is open.
Inventory Health tracks stock position on a weekly update cycle, covering on-hand inventory, sell-through rate, current stock levels, and lead time adherence.
GET_VENDOR_INVENTORY_REPORT is the documented export in the same territory, returning sellable on-hand units, inventory cost, open purchase orders, and vendor confirmation rate. Three parameters are mandatory: reportPeriod, distributorView (MANUFACTURING or SOURCING), and sellingProgram. The distributorView choice matters more than it looks, because it decides which slice of your catalog the report describes, and the same distinction governs the dataset covered further down. Refreshed data lands 72 hours after the reporting period closes, so a period that closes Monday isn't fully readable until Thursday.
GET_VENDOR_REAL_TIME_INVENTORY_REPORT returns highly available inventory per ASIN by hour, and it reflects orders, cancellations, and add-to-cart activity as they land. You can request it five minutes after the hour closes, with a 30-day lookback and a maximum span of seven days per request, which is half the window the other two real-time reports allow.
The planning screen gives four forecast types: Mean, P70, P80, and P90. GET_VENDOR_FORECASTING_REPORT returns the same four as weekly customer demand forecasts at ASIN level, one marketplace per request.
The constraint worth flagging to whoever does your planning is that only the most recent forecast is available, because Amazon keeps no historical forecast data for retrieval. Forecast-versus-actual analysis, and any read on how the forecast has been moving week to week, depends entirely on you saving each week's file when it publishes, and a week nobody saved is gone.
Net PPM is the margin screen: pure product margin after cost of goods and services are deducted, shown as a percentage of the total, against the prior period, and year over year.
GET_VENDOR_NET_PURE_PRODUCT_MARGIN_REPORT returns margin at aggregate and ASIN level on the same granularities as the sales report, and its data lands sooner than the inventory report's. Weekly periods are available by the end of the day Monday, 48 hours after the period closes, while the 72-hour wait applies to daily periods other than Saturday.
Read it knowing what sits outside it: chargebacks, freight costs, and recovery amounts are absent from Amazon's native vendor reporting, which is built around what went out the door. Net PPM will read better than your landed margin in any period where deductions are running against you, so treat it as one input to profitability and let your own deduction and freight records supply the rest. Our piece on the Amazon vendor experience goes further into how chargebacks and deductions work.
These three are UI reports as far as public documentation goes. Amazon's published analytics report-type list doesn't include a programmatic export for any of them, so plan on reading or downloading them by hand instead of pulling them on a schedule.
Geographic Sales Insights breaks sales down by the state, city, and ZIP code where products shipped, which answers regional questions nothing else here can: which markets a new item is actually landing in, or whether a regional push moved anything.
The programmatic route to the same territory is the Vendor Analytics Dataset below, which supports grouping by country, state, city, and ZIP.
Several report names that come up in vendor conversations every week belong to Brand Analytics, not to Retail Analytics. The distinction is practical: access depends on Brand Registry enrollment, and the data describes shopper behavior across the marketplace instead of your own shipments. Amazon documents these report types:
GET_BRAND_ANALYTICS_SEARCH_CATALOG_PERFORMANCE_REPORT: search impressions, clicks, cart adds, and purchases for your catalog.GET_BRAND_ANALYTICS_SEARCH_QUERY_PERFORMANCE_REPORT: performance by search query across the ASINs you name in the request.GET_BRAND_ANALYTICS_MARKET_BASKET_REPORT: the items customers commonly purchase together with yours.GET_BRAND_ANALYTICS_SEARCH_TERMS_REPORT: the most-clicked ASINs for a given search keyword, by department.GET_BRAND_ANALYTICS_REPEAT_PURCHASE_REPORT: the quantity of repeat purchases over the period.If your brand isn't enrolled in Brand Registry, expect these to be missing from the account entirely, which is worth confirming before you promise anyone a search-term analysis.
Every report above answers one question at a time, which is why so much vendor reporting ends up as a folder of exports and a spreadsheet that stitches them together. Amazon's Data Kiosk offers the other approach: the Vendor Analytics Dataset is a GraphQL dataset where a single query spans domains that used to require separate reports.
You can group results by ASIN, brand, parent ASIN, product group, geography (country, state, city, ZIP), or vendor code, at daily, weekly, or monthly granularity. Inventory carries its own limits inside the dataset: weekly inventory covers eight weeks including the current week, monthly inventory reaches 24 months back, and daily inventory is available for the current date only.
Access splits the way the inventory report's distributorView parameter does. Sourcing View, for a distributor role, is limited to the ASINs Amazon sources directly from you and excludes traffic, while Manufacturing View covers the ASINs you manufacture and includes traffic, forecasting, and orders. Which view you hold determines which of the fields above you can query at all, so confirm it before you design a report around glance views you can't reach.
Querying Data Kiosk is a development project, which is why plenty of teams stay on manual exports. If you want the consolidated view without owning the pipeline, that's the job InsightLeap does: it ingests Vendor Central, Amazon Advertising, and Amazon.com data across your brands and products into one place, so sales, traffic, inventory, and margin land in the same report instead of in six downloads.
Vendor Central is behind a login, so the exact set of screens you see depends on your account: your selling programs, your vendor codes, and whether you're looking at the business as a manufacturer or as a sourcing partner. Access to the Brand Analytics reports depends on Brand Registry enrollment on top of that. Check both of those before you assume a report was retired.
Retail Analytics describes your first-party business with Amazon: what was ordered and shipped, what inventory exists, what it cost, what margin came out, what the forecast says. Brand Analytics describes the marketplace around your products: how shoppers search, what they click, what they buy alongside your items, whether they come back. The two carry different access requirements and different refresh cadences, and they answer different questions, so a number from one won't reconcile against a number from the other.
Yes. Amazon's documentation lists Brand Registry as a requirement for the Brand Analytics report types, so a vendor account on its own doesn't open them. If your brand registration sits with another team or another legal entity, sort that out first, because no report request will work around it.
Three of them: real-time sales (requestable five minutes after each hour closes), real-time traffic (roughly 65 to 115 minutes after the hour), and real-time inventory (five minutes after the hour, capped at a seven-day span per request). Everything else is period-based. Inventory data becomes available 72 hours after the period closes, a weekly Net PPM figure lands 48 hours after its period closes, and the forecast publishes weekly with no history kept behind it.
Before you act on a figure from any of these, know which system produced it, because that decides how current and how granular it can be. A same-day sales question belongs to real-time sales, and the answer won't match the period reports for days. Inventory has a 72-hour floor on how fresh the answer can be, and a weekly margin figure lands 48 hours after its period closes. There is only ever one forecast available, the current one, so if the trend matters, start saving the weekly file now. Anything about search or shopper behavior needs Brand Registry before it needs a report name. Put the report name and the system next to every number you circulate, and you'll spend a lot less time reconciling them later.
Request access today and let InsightLeap help grow your business!