Why Your E-Shop is Losing Customers Who Search by Product Code

Why are product codes so tricky?

Product codes aren't "pretty" words. They are combinations of letters, digits, and special characters—dots, slashes, hyphens, hashes, and pipes. Every e-shop, manufacturer, and supplier creates them in their own way. This results in codes such as:

• CAT/SUB/001 — slashes as delimiters
• SKU#2024/REV:2 — hash, slash, and colon in a single code
• PART(X)[L];3 — parentheses, brackets, and a semicolon
• MODEL(V2) — parentheses in the middle of the code

To a human, they are readable. For a search engine, they can be a nightmare. Many search solutions simply discard special characters, break the code into nonsensical parts, or fail to find it altogether. We admit that we also struggled with this type of search while looking for the right solution. Product codes behave completely differently than standard text and require their own approach to indexing and retrieval. It took us time to find the balance between tolerance and precision. Today, however, we are taking a significant step forward.

We conducted a systematic test on synthetically generated query variants

To move beyond "it probably works," we took 40 product codes—18 with special characters and 22 real codes from Czech e-shops—and ran two sets of tests on them.

18 codes with special characters — deliberately exotic combinations of dots, slashes, hashes, parentheses, and semicolons (CAT/SUB/001, SKU#2024/REV:2, PART(X)[L];3). These codes test the limits of search capabilities.

22 real codes from Czech e-shops — gathered from technical goods retailers. They cover the most common formats encountered in practice:

• 15400-PFB-014 — three groups separated by hyphens
• 1WD-E3440-00 — alternating letters and numbers
• S410510394006 — a letter and 12 digits without delimiters
• 8000A9294 — a letter mixed among numbers
• 07703305178 — 11 digits with a leading zero
• 240.347.00.1 — numerical groups separated by dots
• S 274865 — letter, space, number
• MA 29094K-26 — prefix, space, number with a letter in the middle
• BR7ES — spark plug code (letters-numbers-letters)
• X07P1372 — letters and numbers mixed without delimiters

All 295 queries (both sets) were tested against the entire 40-product catalog—both via Search Ready and through the native search of a major e-commerce platform.

Set 1: Five fundamental ways customers enter a code

We simulated the five most common ways a customer types a code:

• Exactly as in the system — PROD.001
• Replacing delimiters with spaces — PROD 001
• Omitting delimiters entirely — PROD001
• Entering only the beginning — PROD
• Typing in lowercase — prod.001

176 queries across all 40 products. Variants were generated algorithmically based on typical user behavior patterns when entering product codes. These were not from real search logs. In practice, most customers enter the code exactly or in lowercase—but it is the outlier cases that determine lost orders.

Set 2: Real-world variants

We added another 119 queries simulating more specific behaviors:

• Space at the boundary of letters and digits — BR 7 ES instead of BR7ES, S 410510394006 instead of S410510394006
• Hyphen at the boundary — T-1210444 instead of T1210444
• Without leading zeros — 7703305178 instead of 07703305178
• Swapping delimiters — 240-347-00-1 instead of 240.347.00.1
• Numbers only — the customer only remembers 51410404 from the code MOT-51410404
• Letters only — PSY from the code PSY-0118

Total 295 queries for 40 products. Each query was sent to the search API, and we recorded whether the correct product appeared and at what position.

How and why was this test created?

We prepared this test as an internal experiment focused purely on search behavior when handling product codes. It is not an academic benchmark study, but a practical test of typical query variants commonly encountered in e-commerce. The goal was to verify the robustness of Search Ready when dealing with different ways of writing a code.

Results: Numbers that speak

Set 1 — Basic variants

• Total queries: 176
• Product found: 176 (100%)
• In the first position: 164 (93%)
• In the top 3: 176 (100%)
• MRR (Mean Reciprocal Rank): 0.96

In this test scenario, we achieved 100% success. Each of the 40 products was found in every variation. An MRR of 0.96 indicates that the correct product appears in the first position in the vast majority of cases.

MRR is a standard metric for search quality—it tells you where the correct result ranks on average. A value of 1.0 would mean it is always in the first place.

Set 2 — Advanced variants

• Total queries: 119
• Product found: 117 (98%)
• In the first position: 108 (92%)
• In the top 3: 115 (97%)
• MRR: 0.94

How to interpret these numbers

The test was conducted on a relatively small catalog (40 products), so competition between results was low. In a real e-shop with thousands of items, ranking short fragments of a code can naturally be more complex. However, exact matches and minor formatting variants should function reliably regardless of the catalog size.

The two unfound queries shared a common pattern—removal of the leading zero: 07703305178 → 7703305178 and 240.347.00.1 → 240.347.0.1. For technical codes, a leading zero is part of the identifier—search shouldn't have to guess whether the customer forgot the zero or is looking for a different part. In technical identification, precision is usually more important than aggressive error tolerance.

Comparison: How does "standard search" perform?

To give the numbers context, we ran the same 295 queries through the native search of a major Czech e-commerce platform.

Set 1 — Basic variants (176 queries):

• Exactly entered code — Standard: 100% / Search Ready: 100%
• Lowercase — Standard: 100% / Search Ready: 100%
• Delimiters replaced by spaces — Standard: 89% / Search Ready: 100%
• Code without delimiters — Standard: 0% / Search Ready: 100%
• Code beginning only — Standard: 100% / Search Ready: 100%
• Total — Standard: 82% / Search Ready: 100%
• MRR — Standard: 0.79 / Search Ready: 0.96

Set 2 — Advanced variants (119 queries):

• Space at letter/digit boundary — Standard: 100% / Search Ready: 100%
• Hyphen at boundary — Standard: 0% / Search Ready: 100%
• No leading zeros — Standard: 20% / Search Ready: 80%
• Number only — Standard: 100% / Search Ready: 100%
• Letters only — Standard: 81% / Search Ready: 100%
• Space removed — Standard: 0% / Search Ready: 100%
• Swapping delimiters — Standard: 72% / Search Ready: 100%
• Total — Standard: 69% / Search Ready: 98%
• MRR — Standard: 0.64 / Search Ready: 0.94

Both solutions perform equally well for exact codes, lowercase, and code beginnings. The difference becomes clear the moment the customer changes the code slightly.

Code without delimiters — the customer types PROD001 instead of PROD.001 or MOT51410404 instead of MOT-51410404. In our test, the standard search failed to find a single product for 29 such queries. Search Ready found them all. This is a common real-world scenario—a customer transcribing a code from a catalog page often skips delimiters.

Hyphen at letter/digit boundary — T-1210444 instead of T1210444 or DCPR-8-EKC instead of DCPR8EKC. Standard search: 0%. Search Ready: 100%.

Swapping delimiters — 240-347-00-1 instead of 240.347.00.1. Standard search handled 72%, Search Ready handled all of them.

What does this mean for your e-shop?

Queries containing a product code are unique in e-commerce: the user usually knows exactly what they want to buy and expects an immediate result. Therefore, even a relatively small improvement in findability in these scenarios can have a disproportionately large impact on both user experience and conversion.

Let’s look at the numbers from the perspective of a customer entering a product code.

In our test, the correct product appeared for 99% of queries. This held true even when the code was entered with different delimiters, in lowercase, or only as a fragment. For standard search, that figure is 77%. That 22-percentage-point difference represents unnecessary obstacles on the path to an order.

A customer searching by product code is in the decision phase. They don't need convincing or inspiration. They just need search not to stand in their way.

Common practical scenarios:

• Wholesale customers entering codes from an order sheet—often manually, with occasional typos.
• Technicians or maintenance staff looking for spare parts based on a code from a label—which might contain slashes, parentheses, or anything else.
• Customers with recommendations who received a code from a friend in a chat—likely without special characters or only as a partial code.
• Repeat purchases — customers searching by a code from a previous invoice, where the code might be truncated or reformatted.

We simulated each of these scenarios within the test, and the search achieved very high success rates.

Why does this actually happen? The answer lies in how search technically handles product codes.

Details matter

When people say "e-shop search," they usually mean searching by product name. But product codes are a discipline of their own. They require the search engine to:

• Understand special characters — treating them as full-fledged parts of the code rather than discarding them.
• Tolerate deviations — different delimiters, missing characters, or changes in casing.
• Find fragments — because customers often have only a snippet of the code, not the whole thing.
• Maintain precision — when a customer enters an exact code, it must be the top result.

This test of 295 queries against 40 product codes confirms these results in a controlled environment. Not because it’s easy—but because we’ve worked on it systematically.

What the tests show—and what they don't

It is only fair to say these tests were conducted in a lab environment—on isolated data specifically designed to test the search engine’s ability to work with product codes. We tested on 40 products. A real e-shop has thousands or tens of thousands. That is a fundamental difference.

With 40 products in the index, a searched code has minimal competition. A query for PFB or 240 easily finds the right product because there is almost no competition. With 40,000 products, the same query could correspond to dozens of other codes, and the correct result might not be in first place.

Exact matches—the full code, the code in lowercase, the code with different delimiters—will work reliably regardless of catalog size. However, vague queries, such as just the numerical part or a short fragment, will naturally be less precise in a full index.

Furthermore, in a real e-shop, multiple attributes are searched simultaneously, results are ranked by complex scoring, and codes compete for position with names, descriptions, and other data. Once we have this new search deployed in live environments, we will conduct tests on live data—and we’ll write about it again.

Why putting the code in the product name isn't enough

One critical technical takeaway: the product code must be stored in your data as a separate attribute. Not as part of the product name, and not hidden in the description.

We often see e-shop operators insert the code directly into the title—e.g., "Oil Filter 15400-PFB-014 Honda." It looks logical; the customer sees the code, so search should find it. But it’s not that simple.

Product code search works differently than standard text search. We use specialized analysis tailored to the structure of product identifiers—the code is decomposed into parts, delimiters and their variations are preserved, and swaps are tolerated. This is exactly why we can find 15400-PFB-014 even if the customer types 15400 PFB 014 or just 15400-014.

However, this analysis cannot be applied to the product name. If we did, the results would be nonsensical. Regular text requires a different approach: stemming, synonym handling, and context-based relevance.

This is why the search works across multiple attributes simultaneously—name, description, parameters, brand, product code—but searches each attribute differently, using different logic and weight. The product code gets specialized analysis; the name gets text analysis. The final score is then combined from all of them.

This is the technology behind our test numbers. It's not just that the search "handles special characters." It's that it processes each type of data in the way that suits it best.

So, if you want your customers to reliably find products by code—ensure you have those codes in a dedicated field. Not just in the title, not just in the description, but specifically in the product code or SKU field.

How to verify if your search handles product codes?

Take five of your most complicated product codes. Enter them into your e-shop's search bar. Then enter them in lowercase. Then without delimiters. Then just the first half. Then just the numerical part.

If the product appears at the top every time—your search works. If not, your search may be creating unnecessary friction for the customers who know exactly what they want to buy.

And those are the most valuable ones.

Consider these results an illustration of the principle—the actual impact always depends on the size of the catalog, the quality of product data, and the search configuration.