Search is a real engineering problem, and a vendor checkbox will not solve it

The Problem

Search is the second-most-used feature on most e-commerce sites and the second-most-neglected. The product team ships a category tree and a “search bar” that calls Elasticsearch with the default query parameters, and then everyone assumes it works. It usually does not. The data shows it: zero-result rates climb, and customers bail out at the search-result page. Conversion data tells you which queries are losing money, but only if you look.

Default search fails because real search is research, and configuration alone does not get you there. A customer who types “condensd milk” should still find “condensed milk”. A customer who types “shoot” usually wanted “shorts”. And “iphone 15 pro 128” needs to behave differently from “iphone 15 pro 128 case”. Every catalogue has its own quirks. Every customer base has its own typing patterns. The default vendor configuration matches none of them precisely.

Good search runs as a metrics-driven loop: define what “relevant” means for your catalogue, measure how often you get there, fix the worst-performing query patterns, then repeat. The engine itself (Elasticsearch, OpenSearch, Meilisearch) is the substrate. The engineering work is the indexing schema, the query parsing, and the tuning loop on top of it.

What the Solution Does

A search service tuned to your catalogue and your customer queries, with the engineering infrastructure for ongoing iterative improvement.

1. Master data ingestion, connect to your CMS (for static fields, descriptions, attributes) and ERP (for dynamic fields: stock, region-specific pricing).
2. Index design, what gets indexed, how it’s structured, what synonyms and synthetic fields enrich it.
3. Query parsing, translate user input into a weighted EQL query that handles strict matches, fuzzy matches, brand recognition, category recognition.
4. Tuning loop, define test queries with expected results, measure relevance, iterate.
5. Production deployment, full-text search, autocomplete suggestions, quick results panel, listing-page integration.

Where It Fits

This makes sense if you…

• Run an e-commerce catalogue with 5k+ SKUs
• See real conversion-loss at the search step (high zero-result rate, high search-page bounce, low search-to-purchase conversion)
• Want a search infrastructure you can iterate on with measurable metrics, with the vendor black box out of the way
• Have structured catalogue data with attributes (or can build it)
• Are ready to treat search as a continuous-improvement function that you keep tuning over time

This is probably not the right time if you…

• Have a small catalogue where the default Elasticsearch / vendor configuration is acceptable
• Want conversational AI search, that’s the product assistant use case
• Want visual search, that’s the visual-search use case
• Need search across non-text data (PDF catalogues, images), that’s an extraction problem upstream

Business Value

Zero-result-page reduction. Default search returns zero results for queries that should have matched (typos, synonyms, partial brand mentions). Proper indexing and synthetic-field enrichment typically drop the zero-result rate by 30-60%, depending on how rough the baseline was.

Conversion lift on search-driven sessions. When search returns more relevant results, more sessions convert. Typical lift is 5-15% on search-completed sessions, with the range depending heavily on your baseline.

Speed. A well-indexed catalogue returns results in sub-100ms, fast enough that the search UX feels instant.

Tunability. Search is never a “set and forget” feature. Customer query patterns shift, catalogue assortment changes, new categories emerge. Our deployments include the tuning infrastructure: golden test queries, metrics dashboards, and hypothesis-driven query-pattern improvements.

How It Works

The architecture below is our canonical pattern for e-commerce search, refined across multiple production deployments.

1. Master data sources

• CMS for static fields: product names, descriptions, attribute values, filters.
• ERP for dynamic fields: stock, price (sometimes global, sometimes per delivery zone).

2. Data update service

Two modes:

• Full reindex, for major catalogue changes or schema migrations.
• Incremental update, for typical day-to-day catalogue changes. The service detects what changed in source data and pushes only the deltas to the search index.

3. Search service

Implements one or more business tasks:

• Find products matching a query, with region filters, price filters, attribute filters, etc.
• Autocomplete suggestions, for partial queries.
• Quick-results panel, top N most-likely matches for partial queries.
• Listing pages, (optional integration) the category listing can be generated by this one search engine too.

4. Indexing and query schema

The hard work is here. For each business task we design:

• One or more indices with primary and supplementary data.
• The method for populating them from the data-update service.
• The method for constructing an EQL query from API parameters.

These three components are tightly coupled, designed and modified together.

5. Query construction patterns

Typical practices in EQL query design:

• Mixing strict and fuzzy queries with different weights (strict matches weight 100, fuzzy weight 50).
• Multiple fields with different weights, match in title weighted higher than match in description.
• Sequential queries, if the query found an exact match in the SKU article, no fuzzy search needed.
• Synthetic fields, enriched fields with tags, synonyms, category names, used in compound queries.
• Query decomposition, if the user typed a brand name, search the brand field; if a category, search the category field.

An example. Query: “condensd milk”. EQL: title: "condensed AND milk" weight 100, title: "condensed OR milk" weight 50, description: "condensed AND milk" weight 25. The typo still lands on the right product.

6. Quality measurement and tuning

Search quality is measured the way ML is measured:

• Top-N relevance, for a fixed test set of queries with known expected results, how often is the top result (or top-5) correct?
• Pairwise relevance, for pairs of products, is the ranking correct?
• Result coverage, how many queries return at least one result?

Tuning runs like an ML experimentation loop:

1. Formalize a test query set with expected results.
2. Experiment: change indexing schema, change query construction.
3. Measure relevance on the test set.
4. Analyze errors, generate hypotheses, iterate.

Stack

Elasticsearch, OpenSearch, or Meilisearch, chosen on your infrastructure preference. Datapipe runs the incremental update pipeline. Python and FastAPI form the search service layer. A custom evaluation harness drives the tuning loop.

What You Need to Make This Work

Data. Product catalogue with structured attributes. Historical search query logs if you have them (very useful for the test query set). Click and conversion data tied to search sessions (helpful for relevance signal, not strictly required).

Integrations. Read access to your CMS and ERP. The search service exposes a REST API; your frontend consumes it.

Hardware. Cloud-based search engine. CPU-driven, no GPU required. Sizing depends on catalogue size and query volume.

Team. A product owner who knows what “relevant” means for your catalogue. A data engineer for the indexing pipeline (around 30-50 hours during initial implementation). A frontend developer for the search-UX integration. Ongoing: a search-relevance owner, often the product owner again, who reviews each tuning iteration.

Implementation Roadmap

1. Test / Initial Implementation (4-6 weeks)

Set up the search engine. Design the indexing schema. Implement the data-update service. Build the initial query parser. Define the test query set with expected results. Measure baseline relevance. Output: working search service with documented baseline metrics.

2. Tuning iteration

Search is never “done” after implementation. We typically run 2-4 tuning iterations over the next 3-6 months, each one improving relevance on the worst-performing query patterns. Each iteration is 2-4 weeks: identify the gap, propose an indexing or query change, measure impact, then ship.

3. Ongoing relevance ownership

Your team takes over the tuning loop. We stay engaged for major catalogue migrations and new business tasks. That covers things like adding multi-language support, or moving some queries to vector search.

Keep in Mind

Where it breaks, and what to plan for:

• Search is a continuous-improvement function. Treating it as a one-time configuration is what produces the bad-search problem in the first place. Plan for tuning ownership past the initial implementation.
• The test query set is the operating definition of relevance. Without it, “is search better now?” becomes a subjective debate. Building a good test query set is part of the value of the engagement, and an ongoing task as your catalogue and customers evolve.
• Vector and semantic search fit some queries, and EQL fits others. For long, descriptive, intent-driven queries, embedding-based vector search beats EQL. For specific SKU codes and brand searches, classical EQL is more accurate and much faster. We deploy hybrid approaches where they earn their keep.
• Synonyms and synthetic fields are real work. They are not free wins. They take design effort, and they sometimes hurt as much as they help: over-broad synonyms produce irrelevant matches. Tune carefully.
• Catalogue data quality is the ceiling. Bad attribute data produces bad search results. Sometimes the biggest improvement is upstream catalogue cleanup.
• This is search, not conversational AI. For natural-language understanding of complex catalogue questions, see ecommerce-product-assistant. Search and conversational AI complement each other. Neither one replaces the other.

FAQ

Why not use a SaaS search vendor (Algolia, Coveo, Bloomreach)?

Commercial search vendors are excellent for organizations that want a ready-made product with managed infrastructure. Our approach fits when you need one of these: heavy customization the vendor’s configuration UI cannot reach, integration with non-standard data sources, fully on-prem deployment, or substantially lower per-query cost at very high volume.

Can this work alongside our existing search?

Yes. Some clients keep their existing search as the default and route specific query patterns (high-zero-result, specific categories) to the new engine. Migration can be gradual.

Does this support multilingual catalogues?

Yes. Multilingual indexing requires per-language tuning, but the architecture supports it. We’ve shipped Russian / English / Spanish deployments.

Can the search engine handle attribute filters (price range, brand, etc.)?

Yes, that’s standard. Attribute filters are first-class in the API.

What about voice search?

Voice search is a transcription problem followed by a text-search problem. Transcription is upstream, in your voice infrastructure. The search engine handles the resulting text query.

Ready to Discuss?

If your e-commerce search is the visible weak link in your conversion funnel, and default vendor configuration is not producing acceptable relevance, this is the right conversation. We will look at your catalogue, your search query patterns, and your conversion data. Then we will tell you what an initial implementation and tuning engagement would cost.

Discuss your project