“No results found.” You had eleven of them in stock.
The shopper described exactly what they wanted. You stocked it, priced it, and had it sitting in a warehouse. Your search returned nothing, because nobody ever wrote down the one attribute they filtered on.
This is the only failure in commerce that generates no error, no ticket and no complaint. The shopper simply leaves, and your analytics records it as a bounce.
Down from a 9–14% industry baseline.
On sessions that use at least one filter.
Generated per category, not hand-tagged.
Enriched index, p95, at 12,400 SKUs.
Nobody files a ticket for a search that found nothing.
When your checkout breaks, someone gets paged within four minutes. When your search returns nothing for a product you have in stock, absolutely nothing happens. No alert fires. No customer emails you. Nobody on the team finds out.
The shopper types their query once, reads the empty state, and goes to a competitor — or to a model, which will answer them. In your dashboard this appears as a short session with a high bounce rate, filed under “traffic quality” and blamed on the ad campaign.
Which is why the on-site search log is the most valuable under-read document in most commerce businesses. It is a list, written by customers in their own words, of things they wanted to buy from you that day.
The zero-result section of that log is better still. Every line is a purchase that failed for a reason you control — and in our audits, roughly two-thirds of those queries could have been satisfied from stock the retailer already held.
Zero-result queries matching stock the retailer already held.
Median share of search sessions hitting an empty result set.
The failure mode is total silence. That is what makes it expensive.
Filters don’t hide products that fail. They hide products you never described.
All three machines below are dual-boiler, rotary-pump espresso machines. Every one genuinely satisfies the query. Run the panel against your feed as it arrives, then against the same catalog enriched — and click any filter.
espresso machine dual boiler 15 bar rotary pump plumbable
ApexBrew Espresso Maker - Silver
$1,8991 of 4 filterable attributes recorded
BaristaMaster Coffee Unit
$1,2500 of 4 filterable attributes recorded
Torino Espresso Maker 1G
$2,4500 of 4 filterable attributes recorded
Raw feed · 1 of 16 possible attribute values present across the sample
The machine has a rotary pump whether or not anyone recorded it. Your search engine does not get to know that.
Shoppers don’t use your manufacturer’s vocabulary.
Nobody has ever typed “direct water line plumbable” into a search box. They type what they mean. Both columns below have to resolve to the same attribute or the search fails.
“one that plumbs into the wall”
Direct water line plumbable · boolean
“the quiet one”
Operating noise ≤ 62 dB(A)
“won't trip my kitchen breaker”
Peak draw 1450 W · 13 A on a 120 V circuit
“steams milk properly”
Dedicated steam boiler · 1.8 bar saturated
“fits under my cabinets”
Height 385 mm incl. raised hopper clearance
“not the plastic kind”
Housing material · 304 stainless, not ABS
These mappings are not hand-written by a merchandiser guessing at phrasing. They are mined from your own zero-result queries, your review and Q&A text, and your return reasons — the three places where customers describe products in the words they actually use.
We are not trying to replace your search engine.
Your search engine is almost certainly fine. Algolia, Elastic, Typesense and Coveo are all extremely good at ranking, typo tolerance and relevance tuning across the fields they are handed.
None of them can filter on an attribute that is not in the index. Give a world-class engine nine fields per SKU and it will index nine fields per SKU, beautifully, in eighteen milliseconds.
Aonex sits upstream. Enriched, normalised, fully-populated records are streamed into whatever cluster you already run, through the connector you already have. Nothing about your front end, your ranking configuration or your analytics has to change.
If you later switch engines, the enrichment layer is unaffected — the attributes belong to your catalog, not to the search vendor.
Plus any engine reachable by webhook, S3 drop or direct index write
The questions you’re about to ask.
We already pay for a good search engine. Why would this change anything?
Because your search engine is almost certainly not the problem. Algolia, Elastic and Coveo are all excellent at ranking, typo tolerance and relevance tuning over the fields they are given. None of them can filter on an attribute that does not exist in the index. If your feed carries nine fields per SKU, a world-class engine will index nine fields per SKU very quickly. We do not replace it — we change what it receives.
Can't we just add the facets we care about manually?
You can, and for a few hundred SKUs in one category you probably should. The arithmetic stops working at scale: facet sets are category-specific, so a catalog spanning espresso machines, cookware and small appliances needs three different attribute schemas, each with its own controlled vocabulary, each maintained as suppliers change their formats. That is a permanent staffing commitment, not a project. Aonex generates the facet tree per category and keeps it populated as the feed changes.
How do you handle shopper language that doesn't match our data at all?
Synonym expansion is built from three sources rather than a hand-written list: your own on-site search logs including the queries that returned nothing, review and Q&A text where customers describe products in their own words, and return-reason data which is unusually honest about what people thought they were buying. "Plumbs into the wall" becomes a boolean attribute because real shoppers typed it, not because a merchandiser guessed they might.
Won't more facets just overwhelm the shopper?
Only if you show all of them. Facet trees are generated per category and ranked by how much each one actually narrows the result set for real queries in that category — a filter that never changes the results is noise, and it gets suppressed. The goal is not forty visible filters. It is that the four which matter are populated on every SKU instead of sixty percent of them.
What does a zero-result audit involve on our side?
Export your on-site search log for the last ninety days — query string and result count is enough, no customer data. We identify which zero-result queries you could have answered from stock you already hold, and which attributes were missing to answer them. It requires no integration and tells you the size of the problem before you commit to anything.
Read the searches that found nothing.
Send us ninety days of on-site search logs — query string and result count, nothing about your customers. We will tell you which of those failed searches you could have answered from stock you already own, and exactly which attributes were missing.
No integration · No customer data · Findings in five working days