We rebuilt search three times. Autocomplete outperformed the first two combined.

We rebuilt search three times on one project.

First pass: relevance ranking. Field boost across name, SKU, category. Better.

Second pass: Russian morphology and synonyms. 180 synonym pairs, ICU Russian analyzer. Conversion from search went up again.

Then I looked at the event data and noticed something we'd ignored completely: 43% of conversions that started with a search query happened without the user pressing Enter. They clicked a suggestion in the dropdown and went straight to the product page.

Third pass: autocomplete.

How many conversions come from clicks, not Enter

Most ecommerce teams treat autocomplete as a UX nicety. If you look at the path from search box to purchase, it's a separate funnel with its own conversion rate.

On our 28k SKU catalog, we split the analytics: search_submit (user pressed Enter or the search button) and suggestion_click (user clicked a suggestion from the dropdown). Three months of data showed that 41–45% of sessions that started with search and ended in a purchase went through suggestion_click. Those users never pressed Enter at all.

That means nearly half of search conversions were going through an interface we hadn't touched in two years.

Industry benchmarks from Elasticsearch and Algolia put similar numbers in the 35–45% range. But that's an average. If your catalog is narrow and predictable — specific product types, consistent naming — you might see 60% or more.

What most shops actually do with autocomplete

The typical Bitrix shop takes one of two paths.

First: Bitrix's built-in AJAX search, SQL LIKE under the hood. No morphology, no ranking, no stock awareness. Users see whatever happens to match the prefix string. It's random.

Second: Elasticsearch with a basic match_phrase_prefix. Technically better, but default ranking is alphabetical or by _score without business context. What ends up in the top suggestions is whatever has the right text — not what actually sells.

Both treat autocomplete as "help the user type," not "close the sale."

Completion Suggester vs Phrase Suggester

Elasticsearch gives you a few options for autocomplete. The two most common are Completion Suggester and Phrase Suggester.

Completion Suggester works on prefix. User types "card" — it returns everything that starts with "card." It's the fastest option because it runs from a dedicated in-memory data structure, latency around 5–15ms. The downside: no morphology, no typo tolerance. "Crad" or a Cyrillic/Latin keyboard switch returns nothing.

Phrase Suggester works on phrase similarity using term co-occurrence statistics from the index. Slower, but it can suggest corrections. Good for fixing typos, not great for predicting intent from partial input.

In practice, we landed on a hybrid. Completion Suggester for prefix suggestions — fast, from memory. A fallback multi_match with fuzziness: AUTO when prefix returns nothing. Most users get instant suggestions. Unusual input triggers the slower fuzzy path.

One thing that surprised us: Russian morphology in autocomplete needs separate handling. A standard text analyzer works on full tokens, but Completion Suggester stores whatever you give it at index time. We indexed multiple word forms — nominative and genitive — for key vocabulary. It solved a lot of "why doesn't this obvious query work" tickets.

Ranking suggestions by margin, stock, and CTR

The interesting part isn't the technology. It's what ends up at the top of the suggestion list.

By default, Elasticsearch's Completion Suggester ranks by a weight field you control. We made that field a composite score, calculated at index time.

Three factors. Click-through history — how often users clicked that suggestion in the last 30 days — is the strongest. Stock status is second: out-of-stock products got their weight cut in half. No point sending users to an "unavailable" page. Margin is third, and it gets the smallest boost. Aggressive margin weighting breaks relevance fast, and users notice.

We recalculate weights nightly via cron, alongside the main reindex job. Adds about 8 minutes to the process. The suggestion index stays fresh.

What we changed and what we measured

Before: Completion Suggester with weights based only on query popularity. Suggestions were technically accurate but commercially neutral.

After: three-component weight formula, multi-form indexing for Russian vocabulary, suggestion_click tracked as a first-class conversion event.

Results over the first six weeks:

• suggestion_click share of all search sessions: 38% → 52%
• Conversion rate from suggestion_click: +11% relative (users who clicked suggestions used to convert slightly less than users who typed full queries — that gap closed)
• Out-of-stock products in top-5 suggestions: 22% → 4%

One unexpected effect: the number of "dead-end" search sessions dropped. Those are sessions where someone typed a query, found nothing useful, and left. A better suggestion list helped users refine their query before submitting it — they saw working variations while typing.

The one thing that makes autocomplete worse

ML-based suggestions without data. I've heard this from several teams: "Let's train a model on user behavior and predict intent." It sounds good. But if you're doing fewer than a few million search events per month, the model will overfit to rare patterns and break expected behavior in ways that are hard to diagnose.

The rule that's worked for us: collect data first. suggestion_click events, conversion paths from search, zero-results rate. After three months, you'll see what actually matters for your catalog. Then you can talk about more complex approaches.

Until then, Completion Suggester with sensible weights and proper index design solves 80% of the problem. That's not a consolation prize. That's a lot of conversion uplift for a day of work.

Closing

Autocomplete isn't a UX feature. It's a conversion path that runs in parallel with your main search results. And it's often the bigger one.

If you're running Elasticsearch and haven't tracked suggestion_click as its own metric, add that event now. You'll see the size of this channel within a month.

On why we went to Elasticsearch in the first place, and what it actually changed in the catalog experience: Elasticsearch is not a fast database. It's a UX tool. And on turning zero-results queries into a product signal: Zero results as a product backlog.