ARA Glossary: Sourceable Product OOS, ROOS, Glance

Amazon Retail Analytics (ARA) has five dashboards that each have a matching SP-API (Selling Partner API) report type: Sales, Inventory, Traffic, Net PPM, and Forecasting. An agent on the Amazon Vendor Central MCP, grounded by Amazon Agent Atlas, resolves a vendor's question to the dashboard, the report type, and Amazon's cited metric definition.

Vendor Central hands you a dashboard tab. A raw SP-API report hands you a payload of fields, not which field you needed or what its number means. Someone on my team asks why sell-through dropped, or what "Conversion" means in an export, and the honest answer depends on which report, which account view, and which section of Amazon's help you read.

ChatGPT, Claude, Perplexity, and Copilot know nothing about your business out of the box, and your competitors use them too. Kuudo gives those same tools your account as it is right now, your judgment running every time, and your call before anything changes. The Vendor Central MCP pulls the retail analytics reports, a Skill your team writes keeps the definitions you report against, Atlas supplies Amazon's cited guidance, and approval controls keep downstream decisions with you.

Five ARA dashboards have a matching SP-API report type, so naming the dashboard is only half the job

Knowing the dashboard name gets you nowhere near an API call, and a report type string with no dashboard context doesn't tell you which metric definition governs it. An agent on the Amazon Vendor Central MCP resolves both in one lookup, then requests the report it needs. The Vendor Central MCP is built on the vendor side of Amazon's Selling Partner API; a brand that also sells as a third-party seller connects the Amazon Selling Partner MCP beside it.

When I asked our agent why sell-through dropped on a set of ASINs, it didn't guess. It resolved the question to the Inventory dashboard, the GET_VENDOR_INVENTORY_REPORT report type, and the sellThroughRate field inside it, then pulled the report. Some questions need two reports: Conversion divides by glance views, which sit in GET_VENDOR_TRAFFIC_REPORT, while ordered revenue and ordered units sit in GET_VENDOR_SALES_REPORT.

Amazon stopped publishing the Sales and Inventory EDI transactions and the Forecast EDI transaction after June 30, 2022. Traffic and Net PPM never had an EDI transaction; outside the dashboards, the API is the only way to pull them. If a question resolves to Net PPM, the margin-leakage guide picks up where this one stops. Here is what the agent returns for a margin question:

{
  "operator_question": "Which report do I pull to find products dragging my margin?",
  "resolution": {
    "dashboard": "Net PPM",
    "sp_api_report_type": "GET_VENDOR_NET_PURE_PRODUCT_MARGIN_REPORT",
    "view_required": "manufacturing",
    "metric": {
      "name": "Net pure product margin (Net PPM)",
      "definitions": [
        { "formula": "(shipped revenue - shipped PCOGS + CCOGS - sales discounts) / shipped revenue", "cited_section": "Net PPM dashboard" },
        { "formula": "(shipped revenue - shipped CCOGS + CCOGS - sales discount) / shipped revenue", "cited_section": "Metric glossary" }
      ],
      "conflicting_definition": true,
      "resolution_note": "The glossary's 'shipped CCOGS' reads as a typo for shipped PCOGS. Confirm which formula your internal reporting uses."
    }
  },
  "caveat_flags": ["excludes_warehouse_deals", "manufacturer_dashboard"]
}

ARA and ABA are different products gated by different rules, so "I can't find my dashboard" means two different problems

Every vendor has access to ARA, with no Brand Registry requirement. ABA, Amazon Brand Analytics, is a different product: it requires Brand Registry enrollment and being the brand-selling party on the ASINs in question. Before the agent routes a question to a dashboard, it checks the question against those access rules from Atlas, so it doesn't send you looking for a dashboard your account cannot have.

The two products also measure different things. These ABA features have no counterpart in ARA:

• Search: search popularity, click share, and conversion share for a search term.
• Market basket analysis: the products bought together with yours.
• Repeat purchase behavior: order counts and unique customers over time.

ARA is built around sales and operational dashboards. Confusing the two doesn't just point you at the wrong tab; it points you at a feature set the product you're looking at doesn't have.

Amazon's own ARA docs define "Conversion" two different ways on the same overview page

The Conversion definition is the one that made me stop trusting my memory of ARA. The Traffic dashboard section of Amazon's ARA overview defines Conversion as ordered revenue divided by glance views. The General dashboard information section, on the same page, defines it as ordered units divided by glance views. Both are live documentation, and neither section mentions the other.

Rather than pick a side, the agent returns both formulas whenever a question resolves to Conversion, cites each one's section, and flags the metric as conflicting. If your internal reporting was built on one formula and a teammate pulled the other, you'd see two Conversion rates and no obvious reason why. A Skill your team writes can record which formula you report against.

Three out-of-stock metrics sound interchangeable and aren't. The agent keeps each as its own glossary entry:

• ROOS (procurable product OOS) considers procurable ASINs, a broader cohort than Rep OOS, so ROOS usually reads as a lower percentage on the same account.
• Rep OOS considers only replenishable ASINs.
• Sourceable Product OOS is OOS glance views on sourceable ASINs divided by total glance views, in the Manufacturing view only.

Sell Through Rate gets its own definition too: shipped units minus customer returns, divided by on-hand units plus received units. Here is what the agent returns for a Conversion question:

{
  "operator_question": "What does Conversion mean in my ARA dashboard, and which report is it in?",
  "resolution": {
    "dashboard": "Traffic",
    "sp_api_report_types": ["GET_VENDOR_TRAFFIC_REPORT", "GET_VENDOR_SALES_REPORT"],
    "view_required": "manufacturing",
    "metric": {
      "name": "Conversion",
      "definitions": [
        { "formula": "ordered revenue / glance views", "cited_section": "Traffic dashboard" },
        { "formula": "ordered units / glance views", "cited_section": "General dashboard information" }
      ],
      "conflicting_definition": true,
      "resolution_note": "Glance views come from the Traffic report; ordered revenue and ordered units come from the Sales report. Both formulas are current on the same page, so confirm which one your internal reporting matches."
    }
  },
  "caveat_flags": ["manufacturer_dashboard", "conflicting_definition"]
}

Four recurring distortions make an ARA number look complete when it isn't

Amazon's help pages name four conditions that change what an ARA number includes. The agent attaches each one to the resolution as a caveat flag, so the caveat travels with the number:

• Warehouse Deals are excluded. ARA leaves Warehouse Deals sales out of its reported metrics, Sales and Net PPM included, because the vendor doesn't collect those proceeds. Your retail partners' internal tools may include them, so a reconciliation that counts them won't match.
• The account view gates metrics. Traffic, Net PPM, Forecasting, Sourceable Product OOS, and ROOS appear in the Manufacturing view only, so a Sourcing-view login won't show them. Amazon shows the Net PPM dashboard to manufacturers.
• Returns restate ordered revenue. Customer returns and cancellations are applied to ordered revenue based on the original date of the sale, so a return processed this month can revise ordered revenue for an earlier month.
• Mapping fixes lag. Once an ASIN mapping is corrected, it may take up to 14 days to reflect in the dashboards, so a fixed product can still look missing.

Net PPM also has two written formulas. Amazon's overview gives shipped revenue minus shipped PCOGS plus CCOGS minus sales discounts, divided by shipped revenue. The metric glossary writes the second term as shipped CCOGS, which reads as a typo for shipped PCOGS. The agent returns both with their sources, as in the margin example above, next to the excludes_warehouse_deals and view_required: manufacturing flags.

What happens next: put the routed report pull on an Agent Flow schedule

A routed answer names the dashboard, the report type, and the caveat flags, which is enough to run the same pull again. Amazon Agent Flow lands your vendor data in a private lake you own, next to the ads data behind the Amazon Ads MCP, and can run report pulls on a schedule. A recurring pull suits anything with a lag attached: an ASIN missing today may appear once its mapping fix propagates.

For questions that resolve to Net PPM, go to the margin-leakage guide. Routing tells you where to look; that guide is where you dig for the leak. The pattern under all four sections is the same: route the question to a cited, current answer before you build anything on top of it.

Next in the series: read glance views in the ARA Traffic dashboard to diagnose flat vendor sales.