What is the catalog revenue-at-risk framework?
The catalog revenue-at-risk framework is a way of ordering product-data fixes by the revenue each gap exposes rather than by how many SKUs share it. It exists because a catalog audit produces hundreds of failures that look equal in a list but are not equal in the business: a missing feed identifier on a top seller removes real money from Shopping today, while a missing alt text on a slow SKU removes almost nothing.
The Product Catalog FTE on ftes.ai applies the framework in its audit, shows the arithmetic per SKU, and proposes its work in that order. The owner can override the order, but the default is the one that protects revenue first.
What are the three inputs?
The framework needs three inputs, all of which a store already has. First, recent revenue per SKU, usually the last ninety days from the store's own orders. Second, the share of each SKU's revenue by channel: organic search, Shopping, marketplaces, direct, email. Third, the audit's list of gaps per SKU, with each gap mapped to the channel it blocks: a feed disapproval blocks Shopping, a missing attribute blocks filtered search, duplicated copy weakens organic search.
No estimate is needed. Where a store cannot attribute revenue by channel, the framework degrades gracefully: it uses total SKU revenue and a flat channel weight the owner sets, and it labels the ranking as approximate.
How is revenue at risk calculated?
Revenue at risk for one gap is the SKU's recent revenue multiplied by the share of that revenue that arrives through the channel the gap blocks. For a gap that weakens a channel rather than removing the product from it, such as a thin title in organic search, a weight below one is applied, and the weight is stated so it can be challenged.
A labelled worked example, illustrative only: a SKU earned four thousand in the last ninety days, sixty percent of it through Shopping, and its feed record is disapproved for a missing identifier. Revenue at risk is four thousand multiplied by zero point six, which is two thousand four hundred. A second SKU earned six hundred with a missing alt text, weighted at one tenth for image search: sixty. The first fix is worth forty times the second, and the ranking says so.
Why rank by revenue rather than by count of failures?
Ranking by revenue rather than by count matters because the two orderings disagree constantly, and the count ordering wastes the first weeks of catalog work. A collection of two hundred low-revenue SKUs with a shared alt-text gap tops a count-based list; fixing it changes almost nothing the business can feel. Ten disapproved top sellers sit near the bottom of that list; fixing them restores Shopping revenue this week.
The framework does not ignore the count. Once revenue-ranked gaps are cleared, shared gaps across a collection are cheap to fix in one batch and the framework surfaces them as the next tier. The point is sequence, not exclusion.
How should a store apply it month to month?
A store should apply the framework at the start of each month using the previous ninety days' revenue, because seasonality moves which SKUs carry the store. A product that ranked low in spring may top the list before a peak season. The Product Catalog FTE re-runs the ranking monthly and shows what moved and why, so the owner sees the plan change before the season, not after.
The monthly view also exposes collections that keep re-breaking: a supplier feed that reintroduces the same missing attribute every import, or a theme that strips alt text on update. Those are upstream fixes, and the framework names them because the same gap keeps reappearing at the top of the ranking.
What are the framework's limits?
The framework's limit is that it orders work; it does not predict outcomes. Revenue at risk says how much revenue currently flows through a channel a gap blocks, not how much will return when the gap is fixed. Some of that revenue was already finding the product another way. The Product Catalog FTE therefore reports revenue at risk as an ordering number and reports actual movement separately, from Search Console and Merchant Center, after the fix.
A second limit is attribution quality. Where channel shares come from a store's analytics, they inherit that tool's attribution model, and the framework says so in the report. The ranking is still useful with imperfect shares because the differences between gaps are usually large.
How does it fit with the other e-commerce roles?
The catalog revenue-at-risk framework fits beside the other e-commerce Digital FTEs on ftes.ai because they read the same revenue data. The Marketplace FTE applies a version of it to listing-quality gaps on Amazon, where a suppressed listing removes a SKU from the channel entirely. The Conversion FTE uses the same SKU revenue to rank funnel leaks. A store that runs several roles gets one consistent answer to the question of what is worth fixing first.