The ARA Report and Metric Glossary for Vendors

The ARA report router Skill, grounded by Amazon Agent Atlas, is what actually answers which ARA report answers a given question, and what the metric inside it actually measures. Amazon's Vendor Central UI doesn't do that: it hands you a dashboard tab. Raw SP-API (Selling Partner API) reports don't do it either: they hand you a payload full of fields, not an interpretation of which field you needed or what its number means. I run into this constantly. Someone on my team asks why sell-through dropped, or what "Conversion" means in the export we're staring at, and the honest answer depends on which report, which account view, and which section of Amazon's own help docs you're reading, not on which tab happened to be open when you logged in.

Why not just ask ChatGPT or Claude the same question? A plain chat hits the same three walls on any Amazon job. It has no access to your data, so neither knows if your login has Sourcing or Manufacturing view, or whether you're Brand Registry enrolled, and can't name your dashboard. It has no way to take action, so neither can call SP-API to verify a report type actually exists. And it runs on generic knowledge, not Amazon's, so the answer is uncited and primed to ship a silent mistake. What you get is disconnected, generic, manual work. MCP is your data and the tools to act, Atlas is the cited rule book, the Skill is the safe workflow.

Every ARA dashboard has a mirrored SP-API report type, so naming the dashboard is only half the job

Sales maps to GET_VENDOR_SALES_REPORT. Inventory maps to GET_VENDOR_INVENTORY_REPORT. Forecasting maps to GET_VENDOR_FORECASTING_REPORT. Traffic maps to GET_VENDOR_TRAFFIC_REPORT. Net PPM maps to GET_VENDOR_NET_PURE_PRODUCT_MARGIN_REPORT. Knowing the dashboard name gets you nowhere near an API call, and knowing a report type string with no dashboard context doesn't tell you which metric definition governs it. The ARA report router Skill resolves both in a single lookup, calling through Selling Partner MCP to fetch the report once it knows which one you actually need.

When I asked our agent why sell-through dropped on a set of ASINs, the Skill 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 through the same call path. It's also the reason the Skill catches a retirement most operators don't think to check: the Sales and Inventory EDI transactions (X12 852, EDIFACT SLSRPT) and the Forecast EDI transaction (X12 830, EDIFACT DELFOR) were retired after June 30, 2022, so API is now required to pull them. Traffic and Net PPM never had an EDI form at all; they've been API-only from day one. If the question resolves to Net PPM specifically, that's where the margin-leakage guide picks up. This guide is upstream of it: once the router names the dashboard and the report type, that guide is where you go hunting for the actual leak.

{
  "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" }
      ],
      "conflicting_definition": false
    }
  },
  "caveat_flags": ["excludes_warehouse_deals", "manufacturer_only_dashboard"]
}

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

Every vendor gets ARA. No Brand Registry requirement, no enrollment gate, it's part of the vendor relationship. ABA, Amazon Brand Analytics, is a different product entirely: it requires Brand Registry enrollment and being the brand-selling party on the ASINs in question. Before the Skill routes an operator's question to a dashboard, it classifies the question against those access rules first, so it doesn't send you looking for a dashboard your account structurally cannot have.

Beyond the access gate, the two products measure different things entirely. ABA's Search feature covers search popularity, click share, and conversion share for a search term. Its market basket analysis shows co-purchased products. Its repeat purchase behavior tracks order counts and unique customers over time. None of that lives in ARA, which is built around sales and operational dashboards, not search or purchase-pattern analytics. Conflating the two doesn't just point you at the wrong tab, it points you at a feature set that doesn't exist in the product you're looking at.

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

This is the one that made me stop trusting my own memory of ARA definitions. 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 overview page, defines Conversion as ordered units divided by glance views. Not a typo in one section and a fix in the other, both are live, current documentation. Amazon's own help content disagrees with itself two sections apart, and neither section says so.

Rather than pick a side, the Skill attaches both formulas to the resolution whenever it resolves a question to Conversion, citing each one's exact source section and flagging the metric as having a conflicting definition instead of silently returning one number as "the" answer. That flag matters more than it sounds: if your internal reporting was built against one formula and a teammate pulled a number using the other, you'd see two different Conversion rates and no obvious reason why, unless something told you to check.

ROOS and Rep OOS get the same treatment, for a related reason: they sound interchangeable and aren't. ROOS, procurable product out-of-stock, considers procurable ASINs, a broader cohort than Rep OOS's replenishable-ASINs-only scope. Because the ROOS cohort is larger, ROOS usually reads as a lower percentage than Rep OOS on the same account, which is exactly the kind of thing that looks like an error until you know it's a definitional difference. Sourceable Product OOS is a third, related but distinct glossary entry, not a synonym for either: OOS glance views on sourceable ASINs divided by total glance views, also Manufacturing view only. The Skill keeps all three as separate glossary entries so it never treats one as a stand-in for another. Sell Through Rate gets its own definition too: shipped units minus customer returns, divided by on-hand units plus received units, a formula with no ambiguity but plenty of adjacent metrics it gets confused with.

{
  "operator_question": "What does Conversion mean in my ARA dashboard, and which report is it in?",
  "resolution": {
    "dashboard": "Traffic",
    "sp_api_report_type": "GET_VENDOR_TRAFFIC_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": "Amazon's ARA overview defines Conversion two different ways in two sections of the same page. Both sections are current, confirm which formula your internal reporting matches before comparing numbers across teams."
    }
  },
  "caveat_flags": ["manufacturer_only_dashboard", "conflicting_definition"]
}

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

Warehouse Deals sales are excluded from the Sales and Net PPM dashboards, so if your internal reporting reconciles against ARA and includes Warehouse Deals in its own totals, the two will never match, by design, not by error. Sourcing view versus Manufacturing view changes which ASINs and even which metrics appear at all: Traffic, Net PPM, Forecasting, Sourceable Product OOS, and ROOS are Manufacturing-view-only, so a Sourcing-view login won't show them regardless of what the operator asked for. Customer returns and cancellations get booked against the original date of the sale, not the date the return happened, which means a return processed this month can quietly revise a number from three months ago. And ASIN mapping issues, once corrected, can take up to fourteen days to actually show up in the dashboards, so a "fixed" product can look missing for two more weeks.

Net PPM itself is (shipped revenue minus shipped PCOGS plus CCOGS minus sales discounts) divided by shipped revenue, and the Warehouse Deals exclusion applies to it the same way it applies to Sales. The decision_plan the Skill produces carries these as caveat flags attached to the resolution itself, not buried in a footnote: excludes_warehouse_deals: true on Sales and Net PPM, view_required: manufacturing on Traffic, Net PPM, Forecasting, Sourceable OOS, and ROOS. The flag travels with the number, so whoever reads the resolution sees the caveat before they build a decision on the metric, not after.

What happens next

A decision_plan isn't a one-off answer, it's structured output the Skill can hand off downstream. Once the Skill has resolved a question to a dashboard, a report type, and a set of caveat flags, that resolution feeds into Amazon Agent Flow, the same data layer that holds Amazon Ads MCP and Selling Partner MCP pulls side by side, so a routed ARA answer sits next to the ad-spend numbers it eventually gets compared against. The Skill can schedule the same lookup as a recurring check instead of a one-time query, useful for anything with a mapping delay attached, since a "missing" ASIN today might just need another look in two weeks. For questions that resolve to Net PPM, the handoff goes straight to the margin-leakage guide, because routing tells you where to look and that guide is where you actually go digging for the leak itself.

The pattern underneath all four sections is the same: get the question routed to a cited, current answer before you build anything on top of it, not after you've already shipped a number that was wrong in a way nobody flagged.

Next in the series: ARA vs. ABA, which dashboard actually answers which question.