> ## Documentation Index > Fetch the complete documentation index at: https://docs.vortexiq.ai/llms.txt > Use this file to discover all available pages before exploring further. # Revenue at Risk (live), OnBuy > Sum of (suspended_listings x velocity x ASP) + (mis-categorised listings x velocity loss), recoverable. How to read it, why it matters, and how to act on it. **Metrics type:** [Key Metrics](/nerve-centre/overview#metrics-types-explained) • **Category:** [Marketplace](/nerve-centre/connectors#connectors-by-type) > Sum of (suspended\_listings x velocity x ASP) + (mis-categorised listings x velocity loss), recoverable. ## At a glance > Live recoverable revenue locked behind suspended listings, mis-categorised listings, and stale inventory on OnBuy. The number a marketplace ops manager works to drive to zero. This is a derived figure, not a single API field; it sums per-issue revenue exposure in real time. | | | | ---------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **What it counts** | `SUM((suspended_listings.velocity_30d x suspended_listings.asp) + uncategorised_listings.velocity_loss + stale_listings.velocity_decay)` expressed as recoverable GBP per 30-day equivalent. | | **Source data** | Derived. `GET /v2/listings` (status, category\_id, last\_updated\_at) joined with the engine's 30D velocity index built from `GET /v2/orders`. Refreshed every 15 minutes. | | **Currency** | GBP only (OnBuy is UK-domestic). | | **Tax / fees** | Gross of OnBuy commission (consistent with [`onbuy_total_revenue`](/nerve-centre/kpi-cards/onbuy/total-revenue)). | | **Refunds** | Not relevant (forward-looking exposure metric, not a sales metric). | | **Cancellations** | n/a. | | **Channel scope** | OnBuy only. | | **Time window** | `RT` (real-time). The figure is the live exposure, not a trailing window. | | **Alert trigger** | `>$0`. Any non-zero value is actionable. The dollar sign in the registry trigger is artefact; the unit is GBP. | | **What "recoverable" means** | Revenue that would return if the issue is fixed within 7 days. After 7 days OnBuy's algorithm assumes the listing is genuinely cold and recovery rates drop sharply. | | **Roles** | owner, finance. | ## Calculation Calculated automatically from your OnBuy data. See the At a glance summary above for what the metric tracks and the worked example below for a typical reading. ## Worked example **A small UK pet-supplies seller, snapshot at 27 Apr 26 09:00 BST.** The seller has 184 active listings, dispatches in-house, and has been on OnBuy for 11 months. | Component | Listings affected | 30D velocity per listing | ASP | Revenue at Risk | | -------------------------------- | ---------------------- | ------------------------------------- | ------- | --------------- | | Suspended listings | 3 (image-quality flag) | 4 orders / month | £18 avg | £216 | | Uncategorised listings | 6 | 0.5 orders / month (cold) | £22 | £66 | | Stale listings (>180d no update) | 14 | 1.2 orders / month (decayed from 2.8) | £24 | £269 | | **Total Revenue at Risk** | | | | **£551** | ```text theme={null} Suspended: 3 x 4 x £18 = £216 Uncategorised: 6 x 0.5 x £22 = £66 Stale velocity: 14 x 1.6 x £24 = £269 (delta from peer-listing velocity) Total recoverable per 30D £551 ``` **What it means for this seller.** £551 a month is roughly 8% of their current OnBuy revenue (\~£6,800 / month). The cheapest fix is the stale listings, refreshing 14 product descriptions and primary images is a half-day of work and should recover most of the £269 within 4 to 6 weeks. The 3 suspended listings need image-quality fixes (OnBuy requires 1000x1000 minimum, white background); a 1-hour photo-shoot covers them. The 6 uncategorised listings are a 30-minute admin task in the OnBuy Seller Console. If all three issues are cleared this week, the seller should see `onbuy_total_revenue` lift by roughly £550 / month within two months once OnBuy's search algorithm re-warms the listings. That is a very high return on a single afternoon of work, which is why this is a hero card. ## Sibling cards merchants should reference together Revenue at Risk is an aggregator of three different ops issues. To act on it you need the component cards: | Card | Why it matters next to Revenue at Risk | What the combination tells you | | ------------------------------------------------------------------------------------------ | ---------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------- | | [Suspended Listings](/nerve-centre/kpi-cards/onbuy/suspended-listings) | One of the three components, usually the largest. | If 70%+ of risk is suspensions, the priority is image-quality and listing-data fixes. | | [Uncategorised Listings](/nerve-centre/kpi-cards/onbuy/uncategorised-listings) | Listings missing `category_id` are invisible to category browse. | Pure admin fix; should never persist beyond a week. | | [Stale Listings (>180d)](/nerve-centre/kpi-cards/onbuy/stale-listings) | The decay component. | Larger than 50% of risk = cold catalogue, refresh metadata in a single batch. | | [Total Revenue](/nerve-centre/kpi-cards/onbuy/total-revenue) | The size of the impact. | Risk as % of revenue tells you whether to drop everything (>10%) or batch this for next sprint (\<5%). | | [OnBuy Health Score](/nerve-centre/kpi-cards/onbuy/onbuy-health-score) | The composite. | This card moves Health Score by 5 to 15 points depending on size. | | [Listings Suspension Burst (24h)](/nerve-centre/kpi-cards/onbuy/listings-suspension-burst) | New entries to the suspended bucket. | Rising risk + recent suspension burst = a category-wide policy change, not random. | | [Shopify Revenue Trend](/nerve-centre/shopify/revenue_trend) | Shows whether DTC is compensating for OnBuy ops issues. | If OnBuy risk is high and DTC is flat or up, the urgency is lower; if both are bleeding, OnBuy is your highest-leverage fix. | ## Reconciling against the vendor's own dashboard **Where to look in OnBuy's own dashboard:** OnBuy does not natively publish a "Revenue at Risk" figure, this card is genuinely Vortex-IQ-only. The closest views in OnBuy's Seller Console for the underlying components are: > **OnBuy Seller Console (`https://seller.onbuy.com`) -> Listings -> Filter: Status = Suspended** > Lists every suspended listing with the reason code (e.g. "Image quality", "Missing required attribute", "Price-policing flag"). > **OnBuy Seller Console -> Listings -> Filter: Last updated > 180 days ago** > Returns the stale-listing population. > **OnBuy Seller Console -> Listings -> Filter: Category = (none)** > Returns the uncategorised population. You can verify the listing counts match between our cards and OnBuy's filters; the velocity-and-ASP multiplications are our derivation. **Why our number may legitimately differ from a manual estimate:** | Reason | Direction | Why | | ------------------------------- | --------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Velocity calculation window** | Either | We use 30D rolling velocity for the affected listing; if a listing was already in decline before suspension, the figure may overstate the recoverable amount. | | **Recovery assumption** | Ours optimistic | We assume full recovery within 7 days of fix. In reality OnBuy's algorithm takes 7 to 21 days to fully re-warm a previously suspended listing; the actual recovered revenue lands progressively. | | **Category re-classification** | Ours can drift | If OnBuy moves a listing's category, our `last_updated_at` field updates too, which can briefly push a listing out of the "stale" bucket. The next full sync corrects it. | | **Manual seller actions** | Ours can lag | If you have already actioned a fix in the Seller Console, our card may still show the listing as at-risk for up to 15 minutes until the next poll. | | **Multi-component overlap** | Ours can double-count | A suspended-AND-stale listing should only count once; we deduplicate at the listing level, but if OnBuy returns inconsistent metadata across endpoints we may briefly show an inflated total until the next reconciliation pass. | **Internal identity (within OnBuy):** `onbuy_revenue_at_risk = SUM(onbuy_suspended_listings impact) + SUM(onbuy_uncategorised impact) + SUM(onbuy_stale_listings impact)` The three component cards each show the count; this card shows the GBP impact. ***
Documentation cross-reference (for agencies running multiple platforms) The "revenue at risk" concept exists on every commerce platform but with different mechanics. Reference docs for peer platforms: * [`shopify.revenue_at_risk`](/nerve-centre/shopify/revenue_at_risk) * [`bigcommerce.bigcommerce_revenue_at_risk`](/nerve-centre/bigcommerce/bigcommerce_revenue_at_risk) * [`amazon.revenue_at_risk_from_suppressed`](/nerve-centre/amazon/revenue_at_risk_from_suppressed)
## Known limitations / merchant FAQs **Why is my Revenue at Risk number going up even though I am fixing listings?** The card is real-time and additive. Fixing a listing removes its contribution; OnBuy auto-suspending a different listing (e.g. due to a stock-level update or supplier price change) adds a new one. Watch the trend across a week, not the moment-to-moment movement. If you are clearing one listing a day but two new ones suspend, the warehouse data feed is the real problem, fix the inventory feed first. **How is "recoverable" different from "lost"?** Lost revenue is what you have already missed (the orders that did not happen yesterday because the listing was suspended). Recoverable is forward-looking: what will return if you fix the issue this week. We track recoverable because it is actionable; lost is sunk-cost and depressing. The cumulative lost figure is on the backlog as `onbuy_revenue_lost_to_date`. **My number is £550 / month but I do not believe my OnBuy revenue would actually grow by that much.** Three honest reasons that may temper the figure. First, our 30D velocity baseline assumes the listing comes back to its prior demand level; if your category is genuinely declining (e.g. seasonal trail-off), recovery will be lower. Second, OnBuy takes 1 to 3 weeks to re-rank reinstated listings in browse, so the recovery is delayed not instant. Third, if multiple of your SKUs were suspended together, customers may already have rebought from a competitor, and that revenue does not "come back" on a 1-month horizon. As a rule of thumb, expect 60 to 80% of the headline Revenue at Risk to actually materialise within 60 days of fixing. **Should I prioritise this above DTC issues?** For most small UK brands, yes, OnBuy Revenue at Risk has a higher £-per-hour-of-effort recovery rate than equivalent Shopify ops issues, because OnBuy's algorithm is more brittle (a single image issue can suspend a listing that would never get auto-rejected on Shopify). The exception is when DTC is much larger; if Shopify is 80% of revenue, a 5% Shopify issue is bigger in absolute terms than a 30% OnBuy issue. **Why does the figure include "stale" listings as at-risk?** OnBuy's search algorithm explicitly de-prioritises listings without metadata refresh in 180+ days. The decay is real and measurable: stale listings show \~50% of peer-listing velocity. Refreshing the description, primary image, or price tags is enough to reset the clock, you do not need to make substantive changes. **My OnBuy account was just suspended account-wide, not per-listing. Is that in this number?** No. Account-level suspension would zero `onbuy_total_revenue` until reinstated; this card only models per-listing exposure. If your whole account is suspended, this card will read £0 (because there are no active listings). Use [`onbuy_alert_token_expiry`](/nerve-centre/kpi-cards/onbuy/auth-token-health) and the suspension alert as the canaries. **How does this compare to Amazon's "Buy Box loss" exposure?** Amazon's equivalent is more punishing, losing the Buy Box on a high-velocity ASIN can wipe 80% of that ASIN's revenue overnight, so the at-risk dollar value per issue is much larger. OnBuy does not have the same Buy Box dynamic (single-seller listings dominate), so per-listing exposure is lower but suspensions are more common. **Is there an action playbook?** Yes. Run this in order: 1. **Identify the largest single component.** If suspensions dominate, fix images first (OnBuy requires 1000x1000 minimum, white background, single product per shot). If stale dominates, batch-edit descriptions in Seller Console -> Listings -> bulk update. If uncategorised dominates, set `category_id` on each. 2. **Process oldest first.** Listings stale for 200+ days recover slower than those stale for 181 days. Refresh the longest-stale 20% first. 3. **Cross-check against `onbuy_xc_catalogue_drift`.** If your suspended listings are also drifting against Amazon UK, the price-policing flag is the real cause; fix the price gap, not the listing image. 4. **Schedule a quarterly catalogue refresh.** A blanket re-edit pass every 90 days keeps the stale bucket near zero and avoids the larger fixes. *** ### Tracked live in Vortex IQ Nerve Centre *Revenue at Risk (live)* is one of hundreds of KPI pulses Vortex IQ tracks across OnBuy and 70+ other ecommerce connectors. Nerve Centre runs the detection layer; Vortex Mind investigates the cause when something moves; Ask Viq lets you interrogate any number in plain English. [Start for free](https://app.vortexiq.ai/login) or [book a demo](https://www.vortexiq.ai/contact-us) to see this metric running on your own data.