Take any furniture store and send three queries into its search box: mattress 140x200, mattress 140 x 200, mattress 140×200. To the shopper, that's one and the same query. To the search engine, it's three different queries with three different result sets.
On one real index we measured, it looked like this: the first spelling returned 17 results, the second returned 207 (and from position seven on, they were sizes the shopper never asked for), and the third variant, with the typographic multiplication sign, found nothing at all.
None of those three answers is correct. And what's worse, not one of them shows up as an error.
Where the problem actually lives
The instinctive reaction is to reach for relevance: add a boost, retune field weights, bolt on semantic search. None of that helps, because the problem happens a layer below, during text analysis. By the time scoring gets a say, the result set is already assembled wrong.
E-commerce search is typically tuned for natural language. It handles inflection and understands synonyms. But 140x200 isn't a word. It's a technical string that follows different rules than a sentence, and standard language analysis treats it like a random cluster of characters and digits.
Concretely, it breaks in three independent places:
Typographic variants never meet. The shopper types a lowercase x, the manufacturer puts × (the multiplication sign) in the product name, and another supplier uses *. One person puts a space between the numbers, another doesn't, and sometimes there's a non-breaking space in there. To a human these are variants of one notation, but to the search engine they're different strings that break apart differently. There's simply nowhere for a match between query and product to occur.
The order of the numbers decides whether anything is found. From the shopper's point of view, order doesn't matter, because 140x200 and 200x140 are the same size. But if the engine compares individual elements strictly by position, it won't find the product with the reversed notation at all. Not ranked lower, missing from the results entirely.
The spaced-out spelling floods the results with noise. When the shopper types 140 x 200, the engine chops the text into three separate tokens. If it's configured with a looser matching rule (something like “it's enough if part of the query matches”), it starts showing products that match just one of them. That's where those 207 results come from; they aren't better results, they're a flooded result set in which the right product drowns.
Fixing this doesn't mean adding one simple rule. It means separating technical notation from ordinary language and processing it so the engine understands its structure, not just its individual characters.
Why almost nobody notices
Because none of it is visible anywhere. It isn't an exception in the log or a 5xx error; the index is green, the product is in the catalog and in stock, and the price is right.
Zero-result reports catch only the crudest half of the problem, the queries that returned nothing. They don't catch the second, more common case: the query returned two hundred items but converted at zero, because what the shopper wanted ended up on page five underneath other sizes. In the stats, that's logged as a successfully served query.
And because this is a long tail of specific spellings, no individual query has the volume to force anyone's attention. In aggregate, though, it's one of the most valuable segments of demand there is. A shopper typing an exact designation knows precisely what they want and is as close to ordering as it gets.
Across industries, the pattern shows up anywhere product names contain unusual characters and codes:
- Furniture and mattresses: dimensions and formats (140x200)
- Automotive: type designations and bolt patterns (5x112, 205/55 R16)
- Tools and electrical: series codes, diameters, compatibility (SDS-Plus, 20V, 125mm)
- Health and beauty: strengths and volumes (500mg, 2x50ml)
- Electronics: model and product designations (MGB-450)
How the fix itself can go wrong
This kind of change has an unpleasant property: it reaches into the foundation of the analysis that every other query on the store uses too. It's easy to retune search so it nails dimensions while quietly breaking ordinary natural-language search - which is to say, the vast majority of traffic. And because the breakage is mild and hits only a portion of queries, average metrics won't catch it.
That's why at Search Ready we built a dedicated evaluation set for this type of query. We measure two groups separately: targeted queries with technical notation, and ordinary natural-language queries. The set is deliberately booby-trapped, containing the same model in a different size, a code shared across categories, and numbers that aren't dimensions at all. Without those traps, a change looks better than it really is.
Two findings from that measurement are worth generalizing:
Don't tune only on the queries you're doing this for. On the targeted dimension queries, a range of parameters looked essentially neutral across a wide span of settings. Anyone tuning on those alone would conclude the configuration doesn't matter. The difference only surfaces on ordinary queries, the ones the change touches indirectly.
Don't tune on the average. The configuration with the highest average score produced twelve times as many serious regressions as a more conservative variant. The average is measuring something other than what matters. What you need to watch is the number of degraded queries and how deep that degradation goes, not an aggregate number.
What it did in practice
To measure result quality precisely, we use nDCG (Normalized Discounted Cumulative Gain). In plain terms it measures two things at once: whether the engine found the right products, and whether it put them in the top spots. A score of 1.0 means a perfect ranking, while a low number says the shopper has to scroll or hack their way through irrelevant merchandise.
On the targeted set of dimension queries, our nDCG moved from 0.623 to 0.931.
The second group is the more interesting one, though. On a set of just under 500 ordinary natural-language queries, every query that used to return zero results stopped doing so. More than a hundred queries improved substantially, and across the rest of the traffic there was no visible regression.
That the dimension queries started working was the expected outcome. The side effect, though, was healing part of the ordinary queries that seemed to have nothing to do with dimensions. It was a good reminder that an “edge case” class of queries is often a symptom of something degrading results across the board.
What to take away from this
If you run search over a catalog with technical notation in product names, it's worth doing a simple test:
Take 10 such queries, write each one in 3 natural variants (closed up, with a space, with a different character), and compare the result sets.
They don't have to match exactly. But if they differ by an order of magnitude in result count, or in the composition of the top ten, you have a silent leak of demand exactly where the shopper is closest to buying.
Want to know how big this problem is in your case? Get in touch. We'll gladly take a look at your search and show you how many shoppers are walking away today because of mishandled dimensions and codes.
