Site Search ROI: How to Build the Business Case From Your Own Search Logs
Failed searches cost you sales. This guide shows how to work out roughly how much, using your own search data, with a simple calculator and an example.
A search that returns nothing is a customer telling you what they wanted to buy, and your site telling them you do not sell it. Most businesses never see the conversation, so they cannot price it.
The short answer: site search ROI is the margin from orders that failed searches would have produced, limited to failures where the item existed, set against the cost of fixing search. You can estimate it from data you already hold: search sessions, the share that failed, a hand-checked sample of those failures, the conversion gap between successful and failed searchers, average order value and gross margin. Present it as a range under stated assumptions, then prove it with a holdout after the change.
This article is about how to quantify the problem. For why it matters in the first place, see why enterprise search is important. It includes a fill-in calculator, a worked example using hypothetical numbers, and the list of things to measure in the first week.
Why do most site search business cases get rejected?
They borrow someone else's numbers. A slide that says "searchers convert several times better" or "zero results cost retailers billions" invites the obvious question: is that true here? The case collapses because nobody can answer it with the business's own data.
The other failures are arithmetic:
- Counting searches instead of sessions. One person retyping a query four times is one failed visit, not four. Counting keystrokes or every Enter inflates both the denominator and the failures.
- Counting robots. Automated traffic searches and never buys. It lowers conversion rates and raises zero-result rates at the same time.
- Assuming every failure was a lost sale. Some zero results are honest: you do not sell the thing. Those cannot be recovered by better search, only by stocking it.
- Using revenue instead of margin. Finance will convert it. A case that shrinks to its gross margin in the first meeting, often a third of the revenue figure or less, has lost its credibility with it.
- Presenting one figure. A single number invites a single objection. A range with named assumptions invites a discussion about the assumptions, which is the discussion you want.
The method below avoids all five. The counting traps are covered in more detail in how to measure enterprise search success.
Why the usual comparison makes site search look better than it is
The most common shortcut is to compare the conversion rate of visitors who searched with visitors who did not, and treat the gap as the value of search. It is the wrong comparison.
- Searchers vs non-searchers compares two different populations. People who type a product name into the box usually arrived knowing what they wanted. Part of their higher conversion is intent they brought with them, and better search cannot create more of it.
- Successful vs failed searchers compares people with similar intent whose experience differed in one respect: whether search found something. The gap here is much closer to what search itself is worth.
- A holdout compares the same population with and without the change, at random. It is the only one of the three that measures cause rather than association, which is why it is the proof step at the end, not the estimate at the start.
Use the second comparison to build the case and the third to prove it. Treat the first as context only.
Even the successful-vs-failed gap is an upper bound. A failed searcher may also have been looking for something harder to find or less likely to be stocked. That is why the calculator applies a recovery factor rather than assuming the whole gap closes.
The site search ROI calculator
Fill in the right-hand column with your own data. Every input has a source in the next section.
| Row | Input or step | Formula | Your value |
|---|---|---|---|
| A | Sessions per month (humans only) | From analytics | |
| B | Share of sessions that use search | From analytics | |
| C | Search sessions per month | A × B | |
| D | Share of search sessions that failed | From search logs | |
| E | Failed search sessions per month | C × D | |
| F | Recoverable share (the item existed) | Replay a sample of 100 | |
| G | Recoverable failed sessions per month | E × F | |
| H | Conversion rate, successful search sessions | From analytics | |
| I | Conversion rate, failed search sessions | From analytics | |
| J | Conversion gap | H − I | |
| K | Average order value | From finance | |
| L | Revenue at stake per month (ceiling) | G × J × K | |
| M | Recovery factor (share of the gap you expect to close) | Assumption: state it | |
| N | Gross margin | From finance | |
| O | Expected margin per month | L × M × N | |
| P | Expected margin per year | O × 12 |
Row L is the honest answer to "what do zero-result searches cost us?": the most that failed search is costing in revenue each month. Row P is the number for the business case. Only two rows, F and M, need judgement, and F is measured rather than assumed.
Where do you find each number?
Sessions and search sessions (A, B, C)
Your web analytics. In Google Analytics 4, enhanced measurement records a view_search_results event with the search_term when a results page URL carries one of the default query parameters (q, s, search, query or keyword); others can be added in its settings (Google Analytics Help). Filter out known automated traffic before you count. Count sessions that contain at least one search, not searches.
Failed search sessions (D, E)
A failed search session is one in which every search returned nothing. That definition is unambiguous, and it is the one the conversion segments below use. Track sessions where results were shown and nothing was clicked separately, because results nobody clicks often mean the right item was not near the top.
Most analytics tools cannot tell a results page from a no-results page unless you tell them. Send the result count with the search event, or give the no-results page its own event. If your search tool reports a zero-result rate per search, use it as a first pass and say so: it overstates failed sessions, because retries inside a session are counted again.
Recoverable share (F)
This is the step most business cases skip, and the one that makes yours credible. Take 100 failed search sessions at random (not the 100 most frequent failed queries) and, for each, take its last search. For each, look for the item in your catalogue by hand. Count how many you find.
If you find most of them, failures are retrieval problems: misspellings, word order, abbreviations, words the engine treated as mandatory. Those are what better search fixes, and the reasons search misses content that already exists are usually small and specific. If you find few, your zero results are honest demand for things you do not stock, and the business case is a buying decision, not a search one. Both are useful answers. For what a well-tuned zero-result rate looks like once search is live, see how to measure enterprise search success.
Two outside data points suggest retrieval failures are common, as context rather than evidence for your site. In Baymard Institute's e-commerce benchmarks, 69% of sites did not offer autocomplete suggestions for slightly misspelt queries (Baymard Institute, 2021), and nearly half did not give users an effective way to recover from a search with no results (Baymard Institute, updated 2025). Neither figure tells you your own share. Only the replay does.
Conversion of successful and failed search sessions (H, I)
Build two segments in your analytics: search sessions where at least one search returned results, and search sessions where none did. Take the purchase conversion rate of each over the same period. Use at least a month if your order volume is low, so the failed segment holds enough orders to be more than noise.
Order value and margin (K, N)
From finance, not from analytics, so the figures match the ones the reviewer already trusts. Use average order value for orders that followed a search if you can get it; the site-wide average is an acceptable substitute if you say so.
Recovery factor (M)
The share of the conversion gap you expect better search to close for recoverable failures. It is the one true assumption in the model. Do not argue for a single value; show the sensitivity table below with a low, middle and high case and let the reviewer pick.
An example with made-up numbers
Example scenario, not a customer case study. Every number in this section is invented to show the arithmetic. None of it is a benchmark, an industry average or a result from any deployment.
A catalogue business with these inputs:
| Row | Input or step | Hypothetical value |
|---|---|---|
| A | Sessions per month | 200,000 |
| B | Share of sessions that use search | 12% |
| C | Search sessions per month | 24,000 |
| D | Share of search sessions that failed | 18% |
| E | Failed search sessions per month | 4,320 |
| F | Recoverable share (replay found 60 of 100) | 60% |
| G | Recoverable failed sessions per month | 2,592 |
| H | Conversion, successful search sessions | 4.0% |
| I | Conversion, failed search sessions | 1.0% |
| J | Conversion gap | 3.0 points |
| K | Average order value | ₹2,500 |
| L | Revenue at stake per month (ceiling) | ₹1,94,400 |
| M | Recovery factor | 50% |
| N | Gross margin | 35% |
| O | Expected margin per month | ₹34,020 |
| P | Expected margin per year | ₹4,08,240 |
Read it in one line: about 2,600 visits a month end in a failed search for something the business sells; if better search closes half the conversion gap on those visits, that is roughly 39 extra orders and ₹34,000 of gross margin a month.
Notice what the example does not claim. It does not count the visitors who found the item by browsing instead, the support enquiries a failed search generates, or the value of knowing what people asked for that you do not stock. Those are real, but they are hard to price, and a case that leaves them out as upside is stronger than one that guesses at them.
What if your guesses are off?
The two judgement inputs are the recoverable share (F) and the recovery factor (M). Holding every other hypothetical input fixed, expected margin per year moves like this:
| Recoverable share (F) \ Recovery factor (M) | 25% | 50% | 75% |
|---|---|---|---|
| 40% | ₹1,36,080 | ₹2,72,160 | ₹4,08,240 |
| 60% | ₹2,04,120 | ₹4,08,240 | ₹6,12,360 |
| 80% | ₹2,72,160 | ₹5,44,320 | ₹8,16,480 |
The pessimistic corner is a sixth of the optimistic one. That spread is the honest state of knowledge before a change, and presenting it openly is what makes the middle cell believable. If the case only works in the top-right corner, it is not a case yet.
You can narrow the spread before deciding. F narrows with a larger replay sample. M narrows only with evidence from your own site, which is what the holdout produces.
What will fixing search cost?
Return needs a cost. Include everything the change actually takes, not only the licence or the build:
- One-off: software or build, catalogue clean-up, integration on the site, and the internal time to test it.
- Running: subscription or hosting, and the hours each month someone spends reading the search reports and acting on them. Search that nobody reviews drifts.
Then two figures:
- Payback months = one-off cost ÷ (expected margin per month − running cost per month)
- First-year ROI = (expected margin per year − first-year cost) ÷ first-year cost, where first-year cost = one-off + 12 × running
Continuing the hypothetical example, with an invented one-off cost of ₹1,00,000 and running cost of ₹5,000 a month: payback is about 3.4 months and first-year ROI about 155% in the middle cell. In the pessimistic corner, ₹1,36,080 a year against ₹1,60,000 of first-year cost, the change does not pay back in year one. Show that cell too. A reviewer who sees you have looked for the case against yourself is more likely to approve the case for.
Whether to build the search or buy it changes the cost lines, not the method.
What should you measure in the first week?
If you cannot fill the calculator today, this is the week's list, in order:
- Confirm searches are recorded at all, with the query text. If they are not, that is the first finding and the first fix.
- Confirm the result count is recorded, so a no-results page is distinguishable from a results page.
- Exclude automated traffic from search counts before computing any rate.
- Count search sessions and failed search sessions, not raw searches.
- List the top 50 zero-result queries by distinct visitors, not by raw count, so one person retrying does not top the list.
- Replay 100 random failed sessions by hand and record found / not stocked / unclear for each. This gives F.
- Build the two conversion segments, successful and failed search sessions, and note the order counts behind each rate.
- Get average order value and gross margin from finance, for the same period.
Item 5 is useful even before the business case is done. The queries at the top of that list are either fixes for search or a list of things customers asked for that you do not sell.
How do you check the result after the change?
The estimate gets the change approved. A holdout proves it. Send a small random share of search traffic to the old search for a few weeks and compare purchase conversion of search sessions between the two groups. Size the period to your order volume: a low-traffic catalogue needs longer to see a difference above the noise.
Track the inputs, not just the outcome: failed-session rate, recoverable share on a fresh replay, and the conversion gap. If conversion rose but failed sessions did not fall, something else changed and search should not take the credit. The ongoing measures for a live search are in how to measure enterprise search success.
For a sense of how far the failure rate can move: on one live catalogue, the search engine behind ITMTB's enterprise search and Tomorrow Central's Search cut zero-result searches roughly tenfold (measured differently before and after; see the case study). Your number will be your own, which is the point of the method.
How to get these numbers quickly
The hardest inputs to obtain are usually D and F: a failure rate you can trust and a record of what failed. Not every site search setup reports either, and a business case cannot start without them.
Tomorrow Central's Search records every search and whether it returned anything, and reports the zero-result rate, the searches that most often returned nothing, clicks and click-through rate for your own catalogue. Its zero-result rate is per search, not per session: take session-level failure (D) from your own analytics, and use the per-search figure only as a labelled first pass. Treat the top no-result searches as a starting point for reading, not as the replay sample; draw the 100 failed sessions for F at random, as described above. It also forgives misspellings using your catalogue's own vocabulary. It runs self-serve on a free plan. Conversion and order value still come from your own analytics and finance, as above. For how site search fits a catalogue business end to end, see site search for a catalogue.
If you would rather have the numbers worked out for you, or need search to run inside your own infrastructure, ITMTB runs the replay on a sample of your real queries before scoping any work, and the engine is available on-premises. See enterprise search or contact us.
Questions people ask about site search ROI
How do you calculate site search ROI?
Count failed search sessions, find the share whose answer existed by replaying a sample by hand, and multiply by the conversion gap between successful and failed search sessions, average order value and gross margin. Apply a recovery factor, then compare the annual margin with the cost of the change.
What do zero-result searches cost?
It depends on your traffic, conversion and order value, which is why industry figures are a poor substitute. The cost is the orders failed search sessions would have produced, limited to failures where the item existed. Your logs and a replay of 100 failed sessions give it as a range.
Do site searchers convert better than other visitors?
Often, but that comparison overstates what better search is worth, because searchers usually arrive with a purchase in mind. Compare searchers whose search succeeded with searchers whose search failed instead.
Should the business case use revenue or margin?
Margin. Finance will convert revenue to margin anyway, and a case presented in revenue looks inflated once they do. Show revenue alongside for context.
How long does it take to measure site search ROI?
The inputs take about a week if searches and orders are already recorded. Proving the result takes a holdout of a few weeks, sized to your order volume.
Can I calculate it without search analytics?
Not reliably. If your site does not record searches and whether they returned anything, recording them is the first week's work. Until then any figure rests on assumptions, not your data.
Key takeaways
- Site search ROI is the margin from failed search sessions that would have converted, limited to failures where the item existed, set against the cost of the fix.
- Compare successful with failed searchers, not searchers with non-searchers. The second comparison mostly measures intent people brought with them.
- Replay 100 random failed sessions by hand. The share you find is the recoverable share, and it is what makes the case credible.
- Present margin, not revenue, and a range across the two assumptions, not one figure. Show the cell where it does not pay.
- Count sessions, exclude robots, and record the result count with every search before computing anything.
- The estimate gets approval; a holdout after the change is the proof.
Sources
- Baymard Institute, Offer autocomplete suggestions for misspellings, 31 August 2021: in its e-commerce benchmark, 69% of sites did not support autocomplete suggestions for slightly misspelt queries.
- Baymard Institute, Search UX: 5 Proven Strategies for Improving "No Results" Pages, published 4 February 2019, updated 18 February 2025: in its e-commerce benchmark, nearly 50% of sites fail to provide effective ways to recover from a search with no results.
- Google Analytics Help, Enhanced measurement events: the
view_search_resultsevent and its default query parameters. - ITMTB, enterprise search case study.
All figures in the worked example, the sensitivity table and the cost example are hypothetical.
Need the number for your own catalogue?
ITMTB replays a random sample of your failed search sessions against your catalogue, measures how many were recoverable, and fills in the calculator with your own figures before anything is scoped.
