Amazon Glance Views and Conversion Rate Explained

Use the Amazon Vendor Central MCP to read Amazon glance views and conversion rate alongside matching Sales and Inventory reports in Amazon Retail Analytics (ARA), then separate fewer Retail sales opportunities from weaker units per view and worsening availability. That's the first useful answer to “traffic is up, so why are sales flat?”

The result is an Amazon Standard Identification Number (ASIN) diagnostic report with a next check for each finding. It gives your team a defensible investigation before anyone changes a bid or rewrites a page. The Vendor Central MCP is built on the vendor side of the Selling Partner API; a brand that also sells on Amazon connects the Selling Partner MCP beside it.

Start with this diagnostic matrix. OOS means out of stock, and the Inventory report states its Procurable OOS rate for the whole catalog in scope, not per ASIN. These are investigation rules, not causal findings from Amazon:

“Steady” means within your team's existing tolerance. Without one, show the changes and leave the classification provisional. PO means purchase order.

ChatGPT, Claude, and Perplexity know nothing about your business out of the box. Your competitors use the same tools. Kuudo gives those tools your data, your rules, and your way of working: your account as it is right now through MCP connections, your judgment running every time through Skills, and your call before anything changes through approval controls. Amazon Agent Atlas grounds the Amazon rules. Your ASIN priorities, comparison tolerances, and decisions belong to you.

A matched reporting scope comes before diagnosis

A missing row is an unresolved comparison, not a zero. Check that both periods contain the same marketplace, ASIN cohort, and dates before explaining any movement.

The Amazon Retail Analytics playbook distinguishes two views of your catalog:

• Sourcing covers products Amazon sources from your vendor group.
• Manufacturing covers the manufacturer's products, regardless of who supplied them to Amazon.

Traffic, Net Pure Product Margin (PPM), and Forecasting dashboards are only displayed to manufacturers. If an eligible account lacks Traffic access, contact your retail partner or Vendor Central's Contact Us route. An MCP connection does not change that entitlement.

The Vendor Central MCP's Reports_createReport, Reports_getReport, and Reports_getReportDocument request each report, check completion, and retrieve its contents. Amazon lists these reports under the Brand Analytics role, so the authorization behind the connection needs that role. The Amazon Retail Analytics EDI/API integration playbook maps these report types to their EDI and API fields. Amazon's Analytics Reports documentation for the Selling Partner API sets the options and the data availability for each:

Compare two complete Sunday–Saturday weeks. This workflow needs Inventory, so all three reports for a week are due by the end of Tuesday. Those times are service levels, not guarantees. Vendor Central's ARA help says reports may take up to a week to populate after a period closes, and that Amazon aims to update weekly reports within 72 hours.

A Sales or Traffic request for a period that is not yet available returns FATAL, so “the week has ended” is not sufficient evidence that its reports are ready. Inspect report completion and lastUpdatedDate.

Keep missing ASINs visible: they can reflect no data for the period, a view mismatch, or vendor hierarchy and mapping issues. Resolve the scope or mark that comparison unavailable.

Amazon glance views measure Retail sales opportunities

Amazon glance views in ARA count ASIN detail-page views when Amazon Retail is the featured seller, meaning it holds the featured offer. They are neither unique shoppers nor advertising clicks.

That restriction changes the diagnosis. A drop in glance views could reflect less demand or fewer opportunities with Retail as the featured seller. The Traffic series alone cannot separate them. The dashboard is a useful starting point because it makes traffic changes visible; that does not establish an earlier refresh than other dashboards.

Keep Advertising reports beside this analysis as context. They measure ad impressions and clicks using different inputs and filters. There is no reason to require their totals to equal ARA glance views, and ad clicks do not belong in the denominator of an ARA units-per-view calculation.

If your Amazon Ads MCP connection is available, ask for a separate campaign context section. A change in ad engagement can suggest where to investigate the traffic mix. It does not turn the ARA comparison into advertising attribution.

Units per view and revenue per view answer different questions

Ordered units divided by glance views is a unit-based conversion proxy. Ordered revenue divided by glance views is currency per view. Amazon's Traffic help calls conversion “the percentage of times a glance view was converted into a sale.” Units are not unique buyers, so treat the unit ratio as a proxy for that, not a count of converted views.

Amazon's own Amazon Retail Analytics playbook uses conflicting numerator wording: its general dashboard section describes conversion with ordered units, while its Traffic subsection describes it with ordered revenue. Preserve that conflict in the report's metric notes. Explicit column names are more useful than choosing one formula and calling it “conversion.”

The unit-based ratio is not bounded like a purchase probability: units are not unique buyers. The revenue ratio is not a percentage. Label its currency, and retain the ordered basis throughout. Mixing shipped units with ordered revenue answers a different question. The ARA Sales dashboard guide explains those sales bases.

If units increase while revenue stays flat, examine derived ordered revenue per unit and the product mix. Don't call that calculation Amazon's shipped average selling price (ASP) metric.

For a group of ASINs, sum the included numerators and denominators first, then divide. Averaging individual ASIN ratios gives a small ASIN the same weight as a large one. Use the same included cohort in both periods, and return unavailable when the denominator is zero or a required input is absent.

Availability starts at the catalog level, then moves to ASIN proxies

GET_VENDOR_INVENTORY_REPORT returns procurableProductOutOfStockRate only in its aggregate block, InventoryAggregate, which covers all ASINs in the report's scope. The per-ASIN block, InventoryByAsin, has no out-of-stock rate. Read the reported rate as a cohort availability signal, not as a finding about any one ASIN.

The Amazon Retail Analytics metric glossary defines Procurable Product OOS as out-of-stock glance views on procurable ASINs divided by total glance views. Procurability considers whether Amazon can source the product without a purchase-order delay, including known vendor supply and the customer promise. Sourceable Product OOS uses sourceable ASINs instead, and the report has no field by that name.

For ASIN-level availability, the Inventory report's per-ASIN fields serve as proxies. Label them that way in the report:

• sellableOnHandInventoryUnits: units in sellable condition in Amazon fulfillment centers on the last day of the period. Sellable stock describes physical condition; it does not guarantee a buyable offer.
• openPurchaseOrderUnits: units on Amazon's confirmed purchase orders not yet received.
• unfilledCustomerOrderedUnits: units ordered or pre-ordered that have not yet shipped.

Preserve the reported rate and its exact name. If you supply Sourceable Product OOS from an eligible dashboard or export, retain it as a separate field with its source and cohort. Don't reconstruct any OOS rate, per ASIN or in aggregate, from Traffic glance views.

A blank OOS metric is unknown, and Sourcing view can omit metrics available in Manufacturing. A steady weekly rate leaves room for stockouts within the week, and an end-of-period on-hand count can miss them too. Neither proves how many sales were lost.

Request the diagnostic report

Copy this prompt into your connected AI client. The requested artifact is an analysis report, with one reviewable finding per ASIN:

Using my authorized Amazon Vendor Central MCP, produce an ARA traffic-and-sales
diagnostic report for the ASINs and marketplace in this conversation.
Ask for any missing inputs before requesting reports.

Compare the latest two complete, available Sunday–Saturday weeks using
GET_VENDOR_TRAFFIC_REPORT, GET_VENDOR_SALES_REPORT, and
GET_VENDOR_INVENTORY_REPORT. Set reportPeriod=WEEK on all three.
Traffic has no distributorView or sellingProgram option. For Sales and
Inventory, set distributorView=MANUFACTURING and sellingProgram=RETAIL.
Inventory data for a week is due 72 hours after close, so confirm dates,
marketplace, cohort, report completion, and lastUpdatedDate.
Ground definitions in Amazon Agent Atlas's Amazon
Retail Analytics, Amazon Retail Analytics metric glossary, and Amazon
Retail Analytics EDI/API integration playbooks.

For each ASIN, show both periods and changes for glance views, ordered
units, ordered revenue with currency, ordered units per glance view,
ordered revenue per glance view, sellableOnHandInventoryUnits,
openPurchaseOrderUnits, and unfilledCustomerOrderedUnits. Label the
three inventory fields as availability proxies, not OOS rates.
Mark missing rows, zero denominators, and incomplete comparisons
unavailable. Aggregate ordered-units/view and ordered-revenue/view by
dividing summed numerators by summed denominators for the same cohort.

In a separate catalog-level section, show procurableProductOutOfStockRate
from InventoryAggregate for both weeks. It is not reported per ASIN, so
do not assign it to ASINs, average it, or rebuild it from Traffic views.
Confirm its scale, then show its change in percentage points.
Preserve any supplied Sourceable Product OOS separately.
Label count and currency changes as absolute and relative percent.
Label ratio-change units explicitly. Leave relative change unavailable
when its base is zero. Note Amazon's conversion wording conflict.

Triage incomplete comparisons first. Falling views with steady units/view
nominate demand and featured-offer checks. Rising views with falling
units/view nominate availability checks if aggregate OOS rises or the
ASIN's inventory proxies weaken; otherwise, check offer, price, page,
and traffic mix. Units up with revenue flat nominates price and product
mix. Treat these as candidate explanations.

Include the next check, missing evidence, owner, and approval state.
Use my materiality thresholds if supplied; otherwise show deltas without
inventing cutoffs. Put Advertising context in a separate section if my
Amazon Ads MCP connection is available.
Produce the report for review. Hold commercial changes for my approval.

What happens next: review availability before recommending more traffic

Review availability deterioration before recommending more traffic. When aggregate OOS and an ASIN's inventory proxies hold steady while its units per view fall, assign the offer, price, detail-page, and traffic-mix checks. A weaker ratio does not establish that page copy caused the decline. Each finding should end with an owner and the evidence that would change the decision.

Once your team accepts the comparison rules, save them in a user-owned Skill. A weekly run should wait for complete, available reports before comparing them. Amazon Agent Flow lands your vendor data in a lake you own, so a weekly run can compare periods without re-requesting every report. Your team's tribal knowledge becomes part of the next report instead of another correction in a chat.

Next, use the ARA inventory health guide to examine the inventory position behind an availability finding.