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). |
| 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 |
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 | 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 | Listings missing category_id are invisible to category browse. | Pure admin fix; should never persist beyond a week. |
| Stale Listings (>180d) | The decay component. | Larger than 50% of risk = cold catalogue, refresh metadata in a single batch. |
| 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 | The composite. | This card moves Health Score by 5 to 15 points depending on size. |
| Listings Suspension Burst (24h) | New entries to the suspended bucket. | Rising risk + recent suspension burst = a category-wide policy change, not random. |
| 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. |
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.
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 asonbuy_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 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:
- 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_idon each. - Process oldest first. Listings stale for 200+ days recover slower than those stale for 181 days. Refresh the longest-stale 20% first.
- 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. - Schedule a quarterly catalogue refresh. A blanket re-edit pass every 90 days keeps the stale bucket near zero and avoids the larger fixes.