Algeria AgencyArtificial intelligence
Site search: the cost of zero results
The least-opened report in your shop is your best demand signal. What it contains, and how much of it is really an engine problem.
A minority of visitors use a shop’s internal search, and that minority buys far more than the rest. It makes sense: somebody typing a product name knows what they want, they are closer to a purchase than any visitor who landed on the home page, and they have told you exactly what they were looking for.
It follows that a search returning nothing is the most expensive leak a shop has. It is also the least examined: the zero-result query report exists in almost every platform, it is free, and it is opened by practically nobody.
This article describes what that report contains, how to separate what is an engine problem from what is a range problem, and why personalised recommendations are almost always premature. Half of what follows is done without a supplier.
The report nobody opens
The first thing to do is not to change engine, it is to export three months of internal queries and read them. Half an hour is enough to classify them, and the classification is the real deliverable of the project — the one that stays useful whichever tool you choose afterwards.
What you will find falls almost always into the same four families: typos, words in a language other than your catalogue, products you do not sell, and products you sell under a different name. Each calls for a different answer and only one of them is technical.
Read the queries exactly as typed, without normalising them. The way your customers spell a product name is commercial information: it is the word they will also use in a search engine, in a private message, and at the counter.
There is a structural reason for that neglect and it deserves naming: this report does not look like a performance report. It contains no curve, no comparison with last month, no percentage. It is a list of words, and a list of words does not present well in a meeting. It is nonetheless the only place in your tooling where your customers speak to you directly, without an intermediary and without rephrasing.
A typo is an engine problem
An engine demanding exact spelling fails on a substantial share of queries, and it fails silently: the visitor sees an empty page, concludes you do not stock the item, and leaves. Nothing in your statistics distinguishes that case from a genuine absence of stock.
Typo tolerance is the fastest-paying fix in this whole subject. It covers transposed letters, missing accents, doubled characters, singular and plural, and it goes in without touching the rest of the shop.
It has a limit worth knowing: too much tolerance returns wrong results and damages trust in the search. Tuning is done against your own queries, not a default, and it is one of the few things in this field that measures cleanly before and after.
You also have to look at the other end of the problem: queries returning too many results. A customer typing a broad word and receiving two hundred unsorted items is in the same position as one who receives none — they cannot choose, and they leave. That case does not appear in the zero-result report and is spotted through the post-search click rate, which collapses on those queries.
A missing product is a range problem
Part of the zero-result queries concern products you do not sell. No engine will fix that, and it is good news: the list, ranked by volume, is a free, dated demand study of your own audience.
What the shop should do with those queries is a commercial decision, not a technical one. Showing a page that says "we do not carry this item" with real alternatives is enormously better than an empty page, and it also allows offering a restock alert.
We hand that list over at scoping and it belongs to you. It is often the part of the project that pays best, and it is the part where we have nothing to sell.
That list has a value beyond the shop. What your customers look for and you do not carry is also what they ask for at the counter, what they type into a search engine, and what your competitors may notice before you do. Passing it to whoever decides the range is more useful than keeping it in a technical folder where it ends up forgotten.
The same product under another name
The third family is the easiest to fix and the least obvious to spot: your customers search for a product you do have, using the word they use, which is not the one on your listing. The manufacturer’s trade name against the everyday name, the brand against the category, the abbreviation against the full term.
The answer is a synonym list built from your own queries, not from a generic dictionary. It takes an hour and it is specific to your catalogue, your region and your customers.
The synonym list has an agreeable property: it is built once and ages slowly. The words your customers use change more slowly than your catalogue, and a list drawn up this year will still be largely right next year. It is one of the few pieces of work in this field whose result does not degrade on its own.
French, Arabic, and the word written as it sounds
A query is almost never in a single language. The same customer searches a brand in Latin script, a category in French and a qualifier in Arabic, sometimes in one sentence, and writes product names as they hear them rather than as they are spelled.
An engine configured for one language fails on most of those queries, and it fails in the most expensive way: silently. The visitor does not report the failure, does not try again with another word, and leaves.
Handling it properly means indexing the catalogue in both scripts and mapping common transliterations of brand names. That is not an exotic feature here, it is the normal case, and a supplier presenting it as an option has misread the market.
A technical point worth asking for explicitly: search has to ignore diacritics in both directions. A customer typing without accents should find an item whose listing carries them, and the reverse should hold too. It sounds elementary and it is the most frequently forgotten setting, because it does not show while you test with words you spell correctly.
There is an edge case worth handling explicitly: single-character queries and isolated digits. They look absurd in the report and they are not — they are partially typed product references, or sizes. Treating them as noise removes real queries from the report, and it is one of the quietest ways to deprive yourself of half the signal.
Filters cover what decides
After the search comes the sort, and the useful filters are not the ones reproducing the catalogue tree. They are the ones a purchase actually turns on: size, compatibility, and above all availability in the delivery wilaya.
A category filter helps somebody browsing; it does not help somebody who has already typed a product name and wants to know whether they can have it. Those are two different visitors and search serves the second.
Filters have a display constraint people underestimate: on a phone, a filter panel occupying two screens does not get used. Three or four filters visible without scrolling do more work than twelve tucked into a dropdown, and the choice of those three or four comes from the queries, not from the catalogue structure.
Availability outranks relevance
A perfectly relevant but unavailable result is a bad result. That is truer here than elsewhere, because delivery is not uniform: an item available in Algiers and not in Béchar is not available to a customer in Béchar, and telling them at checkout costs more than the item.
The practical consequence is that stock and delivery zone enter the ranking rather than being shown afterwards. An unavailable item can stay visible — it informs — but it must not occupy the first position.
That is a trade-off to set explicitly, because most engines rank by textual relevance by default and know nothing about your logistics.
There is a wording that works better than hiding the item: show it with its availability by zone, plainly, from the results list. ‘Available in Algiers, three days elsewhere’ is information a customer knows how to use. Removing it from the list denies them the choice and leaves them thinking you do not carry it at all, which is false information.
The volume suggestions require
"Customers who bought this also bought that" is a sentence describing a statistical regularity. For a regularity to exist you need enough orders for an association to repeat other than by chance, and that quantity is larger than intuition suggests.
Below it, the system produces associations that are real arithmetically and absurd commercially: two products bought together three times by the same person, a seasonal item linked to everything that sold the same week. The sum is correct and the advice is wrong.
The test to insist on is simple: run the associations against past history and check they beat a selection written by hand by somebody who knows the products. Often they do not, and the manual selection is then the right answer — faster, more explicable, and editable by whoever runs the shop.
There is a middle alternative worth knowing: associations written by category rather than by product. ‘With a printer, offer compatible cartridges’ is a rule that fits on one line, needs no history, and never goes embarrassingly wrong. It covers most of what a statistical system would find, without waiting for its volume.
Never suggest what is not available
This is the commonest and most irritating mistake: a suggestions block offering an out-of-stock item, an item already in the basket, or an item the customer has just bought. Each of those three is fixed by a rule, not a model.
They matter more than they look because they read as inattention on your part. An engine suggesting what was just bought teaches the customer that the block is not worth looking at, and they will not look at it again.
There is a particular case deserving its own rule: products bought rarely and singly, like an appliance or a piece of furniture. Recommending them to somebody who has just bought one is doubly useless, and a simple category exclusion settles it better than a model. Rules of that kind can be counted on one hand and avoid most embarrassing suggestions.
Empty listings cannot be compensated for
A search system and a recommendation system both work on whatever describes your products. If the listing is three words and a photo, there is nothing to work on, and no model will make up for it.
That situation is common and has an unsatisfying answer: fill in the listings. It is manual work, it is long, and it is the highest-return project on this page — it improves site search, organic ranking, recommendations and the listings themselves, all at once.
We say so at scoping when it applies, and we do not take the engine project until it is done. An engine installed on an empty catalogue gives mediocre results that will be blamed on the engine.
There is a way to make that work bearable: do it in the order of the report. Rather than filling listings by category or alphabetically, start with the items actually being searched for. A hundred well-written listings on products that receive queries beat a thousand done in catalogue order, and the report gives you the order for free.
Measure before and after
The zero-result rate is the only figure that says whether this work achieved anything. It is recorded before the intervention and after it, and it needs no comparison with anything external to be useful.
The second indicator is the share of sessions containing a search that end in a purchase. It is almost always markedly higher than sessions without a search, and that gap is the argument for spending time on a report nobody was opening.
A precaution about the measurement itself: record the rate over a comparable period, not over the two weeks following the work. A new arrival attracts unusual searches and a sale period attracts others, and comparing an ordinary month with a peak one produces a gap that owes nothing to the work done. One month before, the same month last year if possible, and one month after.
What we do, and what we will not sell
We export your queries, we classify them into the four families, we replace the engine if that is what the classification indicates, and we measure the zero-result rate before and after. Recommendations come later, if the history supports them.
The zero-result list is handed to you before any engagement, and we know when handing it over that most of what it contains is fixed without us: writing synonyms, correcting listing names, deciding whether to add a product to the range. Those are commercial decisions, taken in one morning by whoever runs the shop, and they often produce more effect than the engine change that would have followed. We would rather hand over that document and lose half the project than sell an engine that masks a range problem.
What we will not sell is a recommendation engine on a thin order history. We know how to build one, it will run, and it will display associations calculated correctly from too few orders — which is to say coincidence with a correct sum behind it. The client would see suggestions, believe them drawn from their own trade, and leave them in place. When the test against history does not beat a hand-written selection, we propose the hand-written selection and say so plainly: a less impressive deliverable, cheaper, and one that stays editable by you without calling us.
A last remark on the order of work, because it decides the budget. If you were to do only one thing from this entire article, it would be typo tolerance: it is the cheapest, the fastest to put in place, and the one whose effect is measured in days rather than months. The rest can wait a quarter without anything degrading, and we say so in that order even when the order covered everything.
Frequently asked questions
How many products make this worthwhile?
Below a few hundred references, clear navigation usually beats an engine. We say so rather than selling the installation.
Do we have to change e-commerce platform?
Not in most cases. Search can be replaced without touching the rest of the shop, and that is how we do it.
How many orders do recommendations need?
Enough for an association to repeat other than by chance. We test against your history and show you the result before you decide.
Does search handle Arabic and French together?
Yes, including within one query and with transliterated brand names. That is the normal case here and it is handled first.
What about searched-for products we do not sell?
Show them as unavailable with real alternatives rather than returning an empty page, and keep the list. That is a range decision.
How do we know it worked?
By the zero-result rate and the share of sessions with a search that convert, recorded before and after. Both are in your own tool.
Where we come in
Your internal searches that return nothing, sorted into four families, name the problem unambiguously. Three of those families are not fixed by an engine.
- We hand you the list of silent queries before any commitment.
- We fix the catalogue first, which settles the majority of cases.
- We replace the engine only last, and only if the fourth family dominates.
We will not sell recommendation on a thin history: without volume it suggests at random, and you would pay for an effect nobody sees.
Read next
RAG without the jargon: what an assistant on your documents still invents
Connecting a model to your documents does not make it honest. It changes what it invents, and moves the problem to what you give it to read.Your engine will never be better than your catalogue
When search finds nothing, the cause is nearly always in the product records. The weekly work that prevents it.The words transcription does not know
The voice agent understands the sentence and gets the name wrong. That is the opposite of what people fear, and it is what makes an appointment unusable.
Let us talk about your project
A free audit, no commitment: we look at your online presence and tell you what is holding it back.