Amazon Seller Performance Report (Account Health)

The Seller Performance report is Seller Central's Account Health page handed over as JSON. One document is one marketplace, holding a top-level list of account statuses and a list of performance metrics whose entries carry roughly twenty named metric objects of a few recurring shapes. Trellis lands those as three tables mirroring the sections the page itself draws — customer service performance, policy compliance and shipping performance — so a table can be reconciled against the screen it restates.

One row is one metric, for one marketplace, over that metric's own measurement window. The window is in reporting_date_from and reporting_date_to, and it is Amazon's rolling trailing window for that metric, different from row to row in the same file. It is not a range you asked for, and nothing here is safe to partition by day.

The tables are long rather than wide: metric says which metric a row is, and only the columns belonging to that metric's shape carry values. A metric a marketplace does not have simply emits no row — the US and DE documents carry unitOnTimeDeliveryRate and the CA and BR ones do not, and that shows up as absent rows, not as a half-null column. Late shipment rate is the one metric that arrives as a list of windows rather than a single number, so it lands as several rows that differ only in their window; the figure the Account Health page headlines is the 30-day one.

Every rate and every target in the file is a measurement rather than money — rate, target_value and ahr_score are float, the counts are integers, and nothing here is a currency amount. The targets travel with the rows, so a check can compare rate against the target_value in the same row instead of carrying a number of its own around in code.

Through the Selling Partner API, this is the Reports API report type GET_V2_SELLER_PERFORMANCE_REPORT, which answers a JSON document rather than a flat file. You ask for it with a marketplace and nothing else: Trellis requests it bare, with no date range and no report options at all.

That bareness is the trap, and it is one Trellis fell into first. The request used to send ShowSalesChannel — an option that belongs to the order reports — together with a dataStartTime and dataEndTime both set to today. That is a zero-width window asked of a report that measures fixed trailing windows of its own. There is no date range to set here, because every window in the answer is Amazon's choice, not yours.

One document is one marketplace. Every file fawcett has validated carried exactly the requested marketplace's entries in both of its lists, so a multi-marketplace picture is several pulls, not one. The extractors still read each entry's own reported_marketplace_id instead of stamping the requested one on, which means a file that ever did span marketplaces would land visibly rather than quietly mislabelled — and it means your code should read that column too.

In Seller Central, the same numbers are the Account Health page, which sits under the Performance tab — and which the top menu links to directly, since it shows the account health status.

customer_service

policy_compliance

shipping

Reconciling a dashboard against the Account Health screen. The three tables were drawn to mirror the page's own three sections, so a customer service number that does not match the screen is a bug in one row, not a modelling argument. metric, reporting_date_from and reporting_date_to identify exactly which figure on the page a row is restating.

Watching a metric move without a time series. The file has no history in it — each pull is a snapshot. Keeping the snapshots and comparing rate for the same metric across them is the only way to see a trend, and it is worth starting before you need it, because a snapshot you did not keep is gone.

Alerting without hardcoding thresholds. target_value and target_condition ride along with each row, so a check can ask whether rate is on the right side of the target Amazon shipped today rather than the one someone typed into a config last year. status carries Amazon's own verdict on the same comparison.

Splitting late shipment rate by window. Because late shipment rate arrives as a list of windows, the shipping table holds several rows for it. Comparing the shorter window against the 30-day one is how you tell a metric that is recovering from one that is still sliding, before the headline figure catches up.

Comparing marketplaces honestly. Pulls from different marketplaces land in the same tables, each row naming its own reported_marketplace_id. Bear in mind the metric set differs — a marketplace with no unitOnTimeDeliveryRate row does not have a worse delivery record, it has a different metric set.

Separating the invoice metrics from the order ones. invoice_defect_count, missing_invoice_count and late_invoice_count sit beside the order-based components in the same table but answer a different operational question, usually owned by a different team than the one watching shipments.

Nothing here is safe to day-partition on. Every timestamp in the file is a metric's own rolling measurement window, not a requested data range, and the windows differ per metric and per row. Treating reporting_date_to as "the day this data is about" silently invents a time series that does not exist. The report is a snapshot, and the date that identifies a pull is the snapshot date stamped on it.

A missing row is not a zero. Metrics that a marketplace does not carry emit no row at all. Code that reads a metric's rate by looking up a row and defaulting to 0 when it finds none will report a perfect score for a metric that was never measured.

One file is one marketplace. Do not stamp rows with the marketplace you requested — read reported_marketplace_id. That is the column the extractors carry precisely so a file that ever spans marketplaces is visible rather than silently relabelled.

The warning states are not in the tables. The document has a warningStates list that was empty in the production files fawcett has observed, so its element shape has never been seen and it is deliberately not profiled. Because the JSON extractors write only profiled fields, a populated element would be invisible — it would not land anywhere and nothing would complain. If you are looking for a warnings table, that is why there is not one; check a real file before assuming there are no warnings.

Do not sum a column across metrics. The tables are long, and rate, order_count and the count columns mean whatever the row's metric says they mean. Summing order_count over a table adds together denominators from different metrics measured over different windows.

The targets are Amazon's, and the consequences are not in the file. target_value, status and ahr_score say how a metric stands against the threshold Amazon shipped with it. What Amazon does at any given value — and what counts as at risk — is policy, and this file does not carry it. Read the account's own Account Health page and Amazon's policy pages for that.

Do not assume the component counts add up to the headline one. order_with_defects_count counts orders while the claim, chargeback and negative feedback columns count events, and nothing in the evidence settles the arithmetic between them — in Amazon's own schema example those three components together exceed the orders-with-defects count. The invoice columns may run the other way: that schema describes the invoice defect count as the total "due to missing invoice and late invoice", and its example does add up exactly. A document's example is not evidence about a real file, so check one before a report relies on either.

Check the scale before anything compares against a number of its own. Amazon's report schema writes every rate in its examples as a decimal below 1, and then describes the value as a rate "in percentage". The document contradicts itself, so this page does not settle whether rate and target_value arrive as fractions or as percentages. Comparing rate against the target_value in the same row is safe either way, because both come out of the same file; a comparison against a hardcoded figure is not.

The example rows on this page are illustrative. The marketplace ids in them are real, but every number beside them — including target_value — was made up to show the shape of a row. Amazon ships the target with each row for exactly this reason: read it from your own file, never off this page.