How to estimate revenue at risk caused by your website

Executive brief

Key takeaways

• Slowness translates to a linear loss of engagement, leading to an exponential loss of revenue.
• Group your analytical data by performance tiers to see the true risk.
• Revenue at risk calculations convince boards more effectively than Lighthouse reports.

Trying to justify an expensive refactor by citing performance scores causes friction. Boards deal with financial risks, not milliseconds.

This framework helps engineering teams build a direct financial model, answering the most critical question: how much money is our own code leaving on the table?

The lost opportunity formula

The essential observation is that not all slow traffic results in abandonment, but the probability of conversion always drops. The inference, therefore, is that there is a "baseline conversion rate" and a "friction discount."

The basic equation for revenue at risk is: (Slow Visitors * (Fast Conversion Rate - Slow Conversion Rate)) * Average Order Value

If you have 10,000 monthly slow visitors, where fast conversion is 3% and slow conversion is 1%, you are losing about 200 purchases. At a ticket of $500, the risk caused by slowness is $100,000 per month.

Gathering the necessary data

For this hypothesis to hold weight in a business meeting, use solid sources.

1. Categorized Traffic Volume: Extract the number of monthly sessions classified by response time or LCP (e.g., < 2s, 2 to 4s, > 4s).
2. Conversion by Category: Collect the final conversion rate for each of the groupings.
3. Average Order Value (AOV): Identify the average value of completed transactions.

Limitation: Users on 3G networks tend to have slightly different demographic profiles (and purchasing power). Perfect extrapolation requires isolating device type and geographic location so as not to improperly inflate the estimate.

Recommended action: Create the revenue baseline

Before promising a full recovery of "$100,000", assume that a technical improvement will reduce, but perhaps not entirely eliminate, the friction. Be conservative. Present a scenario where engineering recovers only 30% to 50% of the identified risk through optimizations.

Action Plan

1. Connect the performance data (RUM) of your application to the conversion events in your analytics provider.
2. Create a matrix isolating fast sessions from slow ones, ensuring the device and traffic source are the same (to control for variables).
3. Insert the volume, distinct conversion rates, and AOV into the formula.
4. Present the model to leadership as a project proposal focused on invisible cost reduction.
5. Re-verify the business indicators and recalculate the risk after every major deploy to validate the real return on technical effort.

Direct answers

Frequently asked questions

Do I need RUM data to use this framework?

Ideally, yes. Using Real User Monitoring data coupled with business analytics is the most accurate way to link speed and purchases.