The Business Case: Forecasting What a Faster Currency Converter Is Worth
Objective: Pull a real baseline LCP and organic-traffic number from Wise's currency-converter landing pages, then apply the lesson's own cited case-study multiplier to forecast the traffic upside of fixing LCP, before requesting dev time to actually do it.
Wise's marketing team wants to justify a dev sprint to fix slow-loading currency-converter landing pages, ranked by transactional intent but currently 'Poor' on LCP. Dev leadership wants a projected number before greenlighting the sprint, not just 'it'll help'.
Pull today's real field-data baseline, then apply the lesson's cited Nykaa case (40% LCP cut, 28% organic traffic gain) as a conservative benchmark multiplier to build a defensible forecast.
What is a defensible, dollar-figure forecast for fixing a Poor LCP template, built on real baseline data and a discounted named benchmark?
Before you start
What you'll need
- —Access to Google Search Console field data for the property being forecast
- —Access to Google Analytics 4 conversion data for the same property
- Field data
- real-user Chrome performance data, as opposed to a single lab test run, and what Google actually uses to grade a page.
- Benchmark discount
- deliberately applying a fraction of a cited case study's result to account for differences in market, product, or traffic mix.
Free path (everything below is enough to finish)
Free, and the only source of the field data Google actually grades the page on.
Free, and the only tool that connects the traffic forecast to an actual dollar figure leadership can evaluate.
The process
2 steps
Step 01 of 02
The lesson stresses that ranking is determined by field data, real Chrome users, not lab data from a single test run, and that Search Console's field data is what a forecast should be anchored to.
Before forecasting anything, what is the currency-converter template's actual field-data LCP and its current organic session volume?
Procedure
- Open Core Web Vitals > Mobile, find the currency-converter URL group's field-data LCP value
- Open Performance, filter Pages to the currency-converter path, set date range to last 28 days
- Note total organic clicks for that path over the period
- Record both numbers as the pre-fix baseline (illustrative figures below, not Wise's real production numbers)
Baseline (illustrative, not Wise's actual production data) ------------------------------------------ Currency-converter template: POOR, field-data LCP 4.9s (23 URLs) Organic clicks, past 28 days: 38,400 Organic sessions attributed to these 23 URLs: primary entry point for roughly 12% of all organic sessions site-wide
Healthy
A documented, dated field-data baseline exists before anyone asks for a dev sprint to fix it.
Unhealthy
The sprint request goes to engineering leadership as 'it'll probably help SEO' with no baseline number attached at all.
What this means
A forecast without a real baseline isn't a forecast, it's a guess dressed up as one. Search Console's field data is exactly what Google itself uses to grade the page, which makes it the only credible starting point for a business case.
So what do I do about it?
| Symptom | Action | Effort |
|---|---|---|
| The dev sprint request has no attached baseline metric | Pull the field-data LCP and 28-day organic click baseline before submitting the request | 5 min |
Step 02 of 02
The lesson cites Nykaa's real result: a 40% LCP improvement produced a 28% organic traffic increase, a direct, named, dated benchmark for exactly this kind of fix.
Applying Nykaa's ratio conservatively to Wise's 38,400-click baseline, what's the forecast range worth presenting to leadership?
Procedure
- In GA4, filter Landing pages to the currency-converter URL path
- Pull the current conversion rate and average revenue per session for that path
- Apply Nykaa's cited 28% traffic-increase ratio to the 38,400 monthly organic clicks baseline, conservatively, at half the cited effect (14%) to account for a different market and product
- Translate the resulting traffic range into a revenue range using the GA4 conversion numbers
Forecast memo (illustrative) ------------------------------------------ Baseline: 38,400 organic clicks/month, POOR LCP 4.9s Benchmark: Nykaa, 40% LCP cut -> 28% organic traffic increase (cited in lesson, web.dev case study) Conservative applied ratio: half of Nykaa's, 14% Forecast: +5,376 organic clicks/month if LCP moves from 4.9s to under 2.5s (Good) GA4 conversion rate on this path: 2.1%, avg revenue per conversion: $340 Forecast revenue impact: +5,376 x 2.1% x $340, approximately +$38,400/month
Healthy
Leadership sees a specific, conservatively-discounted, dated-benchmark-backed number before approving the sprint, not an open-ended promise.
Unhealthy
The team promises 'a 28% traffic increase' as if Wise is guaranteed the exact same result Nykaa saw in a completely different market and product category.
What this means
Citing the real Nykaa number by name and then explicitly discounting it is more persuasive than either an unsupported guess or an overclaimed exact match, it shows the team understands the benchmark's limits, which is what makes a forecast credible to a skeptical engineering lead.
So what do I do about it?
| Symptom | Action | Effort |
|---|---|---|
| Leadership is skeptical of an SEO-only justification for a dev sprint | Present the discounted forecast with the GA4 revenue translation attached, framed as a conservative floor, not a promise | 30 min |
Analyze your findings
What to look for
- Baseline recency
- Is the field-data LCP and organic click number dated and pulled from real Search Console data, not estimated?
- Benchmark relevance
- Does the cited case study share a similar mechanism, an LCP fix causing a traffic lift, even if the market differs?
- Discount applied
- Has the cited result been conservatively scaled down rather than promised in full?
- Revenue translation
- Is the traffic forecast converted into a dollar range using real conversion data, not left as a raw click number?
Make the call
Leadership asks why the forecast uses 14% instead of Nykaa's actual 28% traffic lift. What's the right answer?
Recommendation · Priority: Medium
“The currency-converter template's dev sprint request should be submitted with the attached forecast memo: a documented Poor field-data LCP baseline of 4.9s across 23 URLs and 38,400 monthly organic clicks, a conservative 14% traffic-lift projection (half of the cited Nykaa 40% LCP cut to 28% traffic gain benchmark), and a resulting revenue estimate of roughly $38,400/month using GA4's actual conversion rate and revenue-per-session for that path. This gives engineering leadership a specific, discounted, cited number rather than an open-ended SEO promise.”
Common mistakes
What trips people up
Forecasting without a real baseline — a projected lift means nothing without a documented starting LCP and traffic number to lift from.
Applying a cited benchmark at full strength — a different company, market, and product category rarely produces an identical result, so citing the number without discounting it overclaims.
Leaving the forecast in clicks instead of revenue — engineering leadership evaluates a dev sprint against dollar impact, not raw traffic numbers.
Citing a benchmark vaguely instead of by name and number — 'Core Web Vitals fixes help traffic' is not persuasive, 'Nykaa saw a 28% organic lift from a 40% LCP cut' is.
Final deliverable
A one-page forecast memo: current field-data baseline, the cited benchmark, a conservatively discounted projected traffic and revenue range.
See a reference example
Running the same forecast method on Adyen's merchant-onboarding landing pages (illustrative) using the redBus 72% INP improvement to 7% sales benchmark instead produced a smaller but still fundable projected revenue case, since Adyen's conversion value per session was much higher than Wise's.
Success criteria
You're done when you can:
- Pulled a real, dated field-data LCP baseline and a real 28-day organic click number before forecasting anything
- Cited the Nykaa benchmark by its actual numbers (40% LCP cut, 28% traffic gain), not a vague 'CWV helps'
- Applied a conservative discount to the benchmark rather than promising the exact same result
- Translated the traffic forecast into a revenue range using real GA4 conversion data
Key takeaway
A business case for a technical fix needs three things: a real dated baseline, a named benchmark applied at a credible discount, and a translation into the metric leadership actually cares about. Skipping any one of the three turns a forecast back into a guess.