Analytics

Last updated: October 6, 2026

This page documents what SellerCopilot computes, which Amazon data it reads, and what it gives back. It is written to be checked rather than skimmed, so every report and metric below is named the way Amazon names it.

What the product does

SellerCopilot is a subscription analytics application for Amazon selling partners. It connects to a seller's own selling account through Amazon's Selling Partner API, ingests that account's sales, traffic, advertising, inventory, order and financial data once a day, and produces a daily brief: a short written account of what changed in the business and what to do about it, with the figures that produced each recommendation attached.

The product covers Amazon Seller Central accounts. A seller authorizes the application to their own selling account and sees only their own data. Nothing is pooled, benchmarked or compared across customers.

SellerCopilot reads. It does not create, edit, pause or bid on advertising campaigns, and it does not change prices, listings or inventory. Recommendations are for the seller to act on.

The daily brief

Amazon's reports settle one to two days behind the calendar, so the brief is anchored to the most recent date the seller's account actually has data for, not to today. The page states that date, so a reader always knows how fresh the analysis is.

Each morning the brief contains four things:

Portfolio pulse. Revenue, net profit, ad spend and TACOS for the period, against the preceding one.
What's new. Every finding classified against the previous fourteen days: flagged for the first time, resolved since yesterday, persistent for seven days or more with no response, or improving because the metric behind it is moving the right way.
Today's actions. The recommendations themselves, ordered by estimated impact, each with an evidence panel holding the readings it was computed from.
Recent outcomes. What happened after the seller acted, measured against what was predicted.

A Daily Brief recommendation with its evidence panel open: the estimated two-week impact, fourteen-day sessions, conversion and click-through against target, and the written insight naming the listing as the lever with three specific fixes — Daily Brief: one recommendation with its evidence panelProduct screenshot, sample data

How recommendations are generated

Recommendations come from a rule engine, not from a model guessing. Each account is provisioned with nineteen pre-configured rules. Every rule is a stated condition over the account's own metrics, evaluated for each ASIN once a day, against the seller's targets for TACOS, click-through rate, conversion rate and days of stock. Those targets can be overridden per product, and the rules themselves can be edited, disabled or added to.

The engine produces six kinds of action: stop ads, reduce ads, scale ads, order inventory, fix listing, and win the Buy Box. Real examples of the shipped rules, named as they appear in the product:

Stop ads: severe loss and extreme TACOS. The ASIN is losing money per unit and advertising spend is far above its target share of sales.
Fix listing: low conversion despite good click-through. Shoppers are clicking at or above target and buying below it, which points at the detail page rather than at the campaign.
Scale ads: efficient with room to grow. Spend is converting inside target and stock supports more volume.
Order inventory: high demand stockout risk. Days of supply at the measured velocity fall short of the reorder lead time.
Listing suppressed by Amazon. The listing is not buyable at all, which no amount of repricing fixes.
Nobody holds the Buy Box. No seller owns it, which usually means the price sits above Amazon's threshold.

Each finding is written up with the readings behind it, the estimated impact of acting over the next two weeks, and the contributing factors the rule weighed. A recommendation the seller marks as done, deferred or skipped stops being raised for a set period, so the brief does not repeat itself. Once acted on, the outcome is computed over the following seven days (fourteen for ads being scaled) and compared with the estimate.

Written reports and an assistant that answers questions about the account's own figures are generated with Anthropic's Claude models. Product names are replaced with neutral placeholders before any request leaves, and restored in the response. How that works is set out on the security page.

Amazon data sources, and what each one is used for

The table below is the complete set of Amazon data the application reads. Report names are Amazon's report type identifiers, and metric names are the field names Amazon returns.

Amazon data source Metrics used What the product does with it

GET_SALES_AND_TRAFFIC_REPORT
Reports API, by ASIN and day

sessions, browserSessions, mobileAppSessions, pageViews, pageViewsPercentage, unitSessionPercentage, unitsOrdered, orderedProductSales, totalOrderItems, buyBoxPercentage, unitsRefunded, refundRate, and the B2B variant of each

Traffic and conversion analysis per ASIN. Conversion rate comes from unitSessionPercentage, click-through from sessions against advertising impressions, and the comparison of both against the seller's targets is what triggers the listing and advertising rules. Refunds and returns correct the revenue figure.

/finances/v0/financialEvents
Finances API, settlement detail

ShipmentEvent, RefundEvent, ServiceFeeEvent, AdjustmentEvent and ProductAdsPaymentEvent, including their fee and charge components: FBA fulfilment fees, referral fees, promotion rebates, refund commissions and storage fees

Profitability. Amazon's own settlement records are the only accurate source of what a sale actually earned after fees, so net profit per ASIN is built from these rather than estimated from price. They also reconcile each payout.

GET_LEDGER_SUMMARY_VIEW_DATA
GET_LEDGER_DETAIL_VIEW_DATA
Reports API, FBA inventory ledger

Ending balance per FNSKU and MSKU, with receipts, found, lost, damaged and disposed movements, by disposition and location

Inventory forecasting. Stock on hand is compared with sales velocity derived from units ordered to produce days of supply, stockout dates and recommended reorder quantities. Ledger movements explain a balance change that sales alone do not account for.

/inventory/v1/summaries
FBA Inventory API

fulfillableQuantity, plus inbound and reserved quantities per SKU

Current sellable stock, refreshed through the day. The ledger settles too slowly to tell a seller they are out of stock right now, which is the one case where the advice has to change today.

/pricing/v0/itemOffers
Product Pricing API

IsBuyBoxWinner, LandedPrice, IsFulfilledByAmazon and the offering seller id

Buy Box ownership. Whether nobody holds it, a third party holds it, or Amazon Retail holds it leads to a different recommendation, because the remedy differs in each case. The seller's own share over time comes from buyBoxPercentage above.

GET_MERCHANT_LISTINGS_ALL_DATA
Reports API, catalog

Listing status per SKU, with price, quantity, ASIN and SKU

Listing health, and the catalog itself. A suppressed or incomplete listing cannot win the Buy Box or convert traffic, so it is reported as its own finding instead of being diagnosed as a conversion problem. This report is also how new ASINs and SKUs enter the account.

GET_FLAT_FILE_ALL_ORDERS_DATA_BY_ORDER_DATE_GENERAL
Reports API, order history

Order id, purchase date, ASIN, SKU, quantity, item price, and ship-to city, state, postal code and country

Repeat purchase and customer value analysis: repeat rate, median days to a second order, lifetime value by entry product, monthly cohorts and cross-product purchase paths. This needs to tell whether two orders came from the same customer, and nothing more than that. What is and is not retained is set out on the privacy policy.

spAdvertisedProduct
Amazon Ads API v3, Sponsored Products

impressions, clicks, cost, sales7d, purchases7d, unitsSoldClicks7d, unitsSoldSameSku7d, unitsSoldOtherSku7d, by advertised ASIN and campaign

Advertising efficiency joined to profit. Ad spend is subtracted from the settlement-based net profit for the same ASIN, which is what makes a recommendation to stop or scale a campaign defensible. The same-SKU and other-SKU splits separate direct sales from halo sales, so a campaign that looks unprofitable on its own advertised ASIN is not stopped when it is selling the rest of the catalog.

Ingestion runs once a day on a schedule the seller sets, in their own time zone, with a rolling window per source: ten days for sales and traffic, eight for advertising, seven for orders. Amazon restates recent figures as they settle, and a rolling window is how the application picks up those corrections instead of keeping the first number it saw.

Profitability and the per-SKU P&L

Seller Central reports revenue well and profit poorly. It will tell a seller what an ASIN sold. It will not tell them what that ASIN earned after every fee, refund, promotion and advertising cost that attached to it.

Net profit per ASIN is built by taking ordered product sales and deducting:

FBA fulfilment and referral fees, taken per unit from Amazon's settlement records and stamped onto each day's sales as they were at the time, so a fee change does not silently rewrite last quarter's margin.
Cost of goods, entered by the seller per product.
Refunds and refund commissions.
Promotion rebates and other transaction-level charges.
Sponsored Products spend for the same ASIN over the same period.

The result is a per-SKU profit and loss the seller can read down to the transaction, plus TACOS and ACOS measured against their own target rather than a generic benchmark. It is presented daily, weekly and monthly, with period-over-period and year-over-year comparison, and it is the figure every advertising recommendation is computed against. This is the deliberate difference from a dashboard that reports revenue: an ASIN with growing sales and a negative margin is a problem, and it only looks like one once the fees are in.

Fee estimates are held per marketplace, so an account selling in more than one country does not have one country's fees applied to another's sales.

How access and data handling work

A seller authorizes SellerCopilot through Amazon's standard Selling Partner authorization flow. No credentials are typed into SellerCopilot.
The application reads only the data of the account that authorized it.
Authorization can be revoked by the seller at any time from Seller Central. Revocation stops all further collection immediately.
No buyer contact details are requested, stored or processed. No email addresses, no names, no street addresses. The repeat-purchase and customer-value analytics need to tell whether two orders came from the same customer, so the identity on an order is a one-way digest, not a person. Alongside it the product keeps coarse location only: city, state or province, postal code and country, used for aggregate geographic analysis.
All traffic is served over HTTPS/TLS. The Amazon credentials that authorize access are encrypted with AES-256-GCM before they are written, with the key held separately from the database. The database is a managed PostgreSQL service that encrypts data at rest, including backups.
Data is retained while the account is active and for 30 days after cancellation or after access is revoked, after which it is deleted. A seller may request deletion at any time before that.

The security overview sets this out in more detail, including what SellerCopilot does not claim, and the privacy policy covers the rights a seller has over their data.

Pricing

US$79 per month, with a 14-day free trial. The trial needs no payment to start and gives access to the full application. See pricing for what is included.

Questions

For anything this page does not answer, including from a security or compliance reviewer: [email protected]. See also the security overview and the privacy policy.