Forecasting Annual Revenue From An RPV Lift
Turn a winning A/B test's RPV delta into a defensible annual revenue projection — with the haircuts, seasonality adjustments, and sensitivity range that survive finance scrutiny.
Quick answer
Annualized revenue impact = annual sessions × tested RPV lift (in €) × adjustment factor. The adjustment factor (typically 0.5–0.8) bundles holdout shrinkage, seasonality, and lift decay. Present it as a range, not a single number — a 70% mid-case with a 50%/85% floor and ceiling is the format finance will actually sign off on.
Forecasting Annual Revenue From An RPV Lift
Projecting the 12-month revenue impact of a winning A/B test by scaling its tested RPV delta across annual traffic, with haircuts for seasonality and decay.
Forecasting annual revenue from an RPV lift is the step that happens after a test wins: you take the revenue-per-visitor delta measured during the experiment and extrapolate it into a defensible 12-month projection. The naive version is just annual sessions × RPV lift. The defensible version layers in three corrections — a holdout-validated lift (not the inflated test-period number), a seasonality index that respects when in the year your traffic actually lands, and a decay curve for novelty effects. The output is a sensitivity range with a mid-case, not a single point estimate.
You ran a test on your product page. The variant won at 95% confidence with a €0.42 RPV lift on a €18.60 baseline. Now your Head of E-commerce asks what that's worth annually — and the answer needs to survive a CFO's red pen.
The number you give them shouldn't be "€0.42 × annual sessions." That overstates the win by 30–50% in most cases. This page walks through the adjusted version: which haircuts to apply, in what order, and how to wrap them in a range.
The base formula and why it's wrong on its own
The textbook formula is straightforward: Annual Impact = Annual Sessions × ΔRPV. If your store does 4.8M sessions a year and the test showed a €0.42 lift, the naive projection is €2.02M. Clean math, wrong number.
It's wrong because the tested RPV lift is the peak signal under ideal conditions: full attention from the variant, no seasonality drag, no novelty wear-off, and a confidence interval that's wider than the point estimate suggests. The job of the forecast is to deflate that peak into something that holds across 12 months of mixed traffic.
The 30% rule of thumb
Holdout-validated RPV lifts typically come in 25–35% lower than the test-period lift. If your test reported +€0.42, plan the forecast around €0.27–€0.32. Skipping this step is the single most common reason post-launch revenue "underdelivers" against the forecast.
The three corrections that make the forecast defensible
First, the holdout haircut. The lift you measured during the test is inflated by selection effects and the optimistic tail of the confidence interval. A 5% holdout group run for 30 days post-launch is the gold standard — see why holdout-validated RPV lifts forecast 30% lower than test-period lifts for the mechanism. If you don't have a holdout, apply a flat 0.70 multiplier.
Second, seasonality. A test run in August on a store that does 40% of its revenue in November–December cannot be linearly annualized. You need a seasonality index — monthly traffic and AOV weights — applied to the lift. Applying a seasonality index to annualize a Q3-tested RPV win covers the exact mechanics for stores with peak-heavy calendars.
Third, decay. Novelty effects fade. A UI change that wins +3% in week one often settles at +1.5–2% by month three as repeat visitors habituate. Modeling lift decay when forecasting annual revenue from an A/B win shows the half-life curves you can use as defaults when you don't have a long enough post-launch window to measure decay directly.
Typical adjustment factors by test type
Combined haircut factors (holdout × seasonality × decay) by test type
| Test type | Holdout factor | Decay factor (12mo avg) | Combined mid-case |
|---|---|---|---|
| Checkout / cart UX (apparel) | 0.75 | 0.95 | 0.71 |
| Product page layout (beauty) | 0.70 | 0.85 | 0.60 |
| Pricing / discount display | 0.65 | 0.80 | 0.52 |
| PDP imagery / video | 0.75 | 0.90 | 0.68 |
| Navigation / category UX | 0.70 | 0.92 | 0.64 |
| Urgency / scarcity messaging | 0.60 | 0.70 | 0.42 |
| Free shipping threshold | 0.80 | 0.98 | 0.78 |
Urgency and scarcity tests are the cautionary tale: they post big test-period lifts and decay hard once repeat visitors stop reacting to the same countdown timer. Free shipping threshold changes are the opposite — structural, low decay, the lift sticks. The combined mid-case column is what you'd use as a default multiplier on the tested ΔRPV if you have no other data.
Wrapping the point estimate in a sensitivity range
A single annualized number gets challenged. A range survives. The standard format is a low/mid/high band, where low uses the lower bound of your test's confidence interval and the heaviest haircuts, and high uses the upper bound with lighter haircuts. Building a sensitivity range around a forecasted RPV lift walks through the exact construction.
For the €0.42 lift example on 4.8M annual sessions, the band typically lands around €1.05M (low) / €1.42M (mid) / €1.78M (high) — versus the naive €2.02M. Present the mid-case as the forecast and the floor as the commitment. That's the version finance signs off on, and the version you can ship in presenting an RPV-lift revenue forecast to a skeptical CFO.
Edge cases that change the math
If the lift only showed up on mobile, don't annualize against all-device sessions. Use segment-weighted RPV forecasts when the lift only hit mobile — you scale only against mobile traffic, then add a small assumed-zero impact for desktop. Same logic for tests that won only on new visitors, or only on one Shopify market.
If finance needs margin, not revenue: convert before annualizing, not after. Forecasting annual contribution margin (not revenue) from an RPV win avoids the mistake of multiplying revenue by a blended margin that's wrong for incremental orders. And if you're stacking multiple wins across the year, forecasting annual revenue from a stacked series of small RPV wins covers the compounding logic so you don't double-count overlapping traffic.
Frequently asked questions
Because the tested lift is a peak signal — it includes confidence-interval optimism, novelty, and the conditions of the test window. Naive multiplication overshoots actual realized revenue by 30–50% in most post-launch validations. The haircuts exist because real-world performance regresses toward a lower, sustained number.
Trailing twelve months from GA4, not last year's calendar number. If traffic is trending up or down materially, use a forward-looking projection: TTM × (1 + YoY growth rate). For seasonal stores, make sure the traffic projection itself is built monthly, not flat — otherwise the seasonality correction double-counts.
Thirty days minimum with a 5% holdout group, sixty days ideal. The first two weeks post-launch often show inflated lift because the variant is still novel to repeat visitors. By day 30 the novelty effect is largely settled and the holdout RPV gives you a clean realized lift to compare against the forecast.
Order doesn't matter mathematically since both are multiplicative factors, but apply holdout first conceptually — it adjusts the lift itself to a defensible number, then seasonality and decay apply against that corrected lift. This makes the audit trail cleaner when you walk a CFO through the math.
Don't extrapolate a Black Friday-period lift to annual revenue using normal seasonality — the behavior of peak shoppers is structurally different. See forecasting Black Friday revenue from a pre-peak RPV test for how to project peak-period revenue specifically, and use only the non-peak portion of the lift for the annual baseline.
Two-week tests are forecastable but the confidence interval will be wide. Use the lower bound of the 95% CI as your low-case, the point estimate × 0.7 as mid-case, and skip the high-case — there's not enough data to credibly project an upside. Plan to revalidate at 30 and 60 days post-launch.
Both, but lead with margin if you're presenting to finance. Revenue is easier to model but margin is what funds the next test cycle. Convert at the incremental-order margin (not blended), since the win typically pulls in orders at a slightly different AOV and product mix than your baseline.
Annualize only against the segment that won. If mobile is 60% of sessions and the lift was mobile-only at €0.50 RPV, your forecast multiplies €0.50 × (annual sessions × 0.60), not €0.50 × all sessions. Assume zero impact on the non-winning segment unless you have evidence otherwise.
For structural UX changes (checkout, free-shipping thresholds, navigation): 5–10% decay over 12 months. For visual or persuasion changes (PDP layout, badges): 15–25% decay. For pure novelty plays (countdown timers, new badges): 30–50%. The benchmark table on this page gives defaults by test type.
At day 30 with holdout data, day 90 with realized revenue, and at the end of the seasonal cycle the test was launched into. Each revision should narrow the sensitivity range. By the 12-month mark, the forecast becomes the realized number — and your haircut factors become priors for the next forecast.
Test ideas before you ship them
Run unlimited A/B tests, attach hypotheses to outcomes, and build a searchable archive of what works — and what doesn't.