In our previous article, we tested how product code search handles different input variations - spaces instead of dashes, missing separators, and lowercase letters. The results on a 40-product dataset looked promising. But, as we noted ourselves:
With only 40 products in the index, a searched code faces minimal competition. With 40,000 products, that same query could match dozens of other codes.
That’s a fair point. So, we took a real-world catalog - 35,000 products from a B2B aviation parts store - and ran the same tests. Not just on a handful of hand-picked codes, but on hundreds randomly selected from across the entire catalog.
How We Ran the Test
We randomly selected 807 product codes and SKUs from the catalog. We made sure to cover all the formats we see in the wild - purely numeric codes, alphanumeric ones with dashes, dots, slashes, brackets, and spaces. For rare formats (like codes with brackets or plus signs), we included every single instance we could find.
For each code, we algorithmically generated query variations simulating typical user behavior - from exact matches to omitting separators to searching by just a fragment of the code. This gave us a total of 6,085 search queries. We fed every query into both versions of our system - Original Search Ready and New Search Ready - and recorded whether the right product surfaced, and at what position.
No query was cherry-picked to "look good." No result was discarded just because it didn't fit the narrative.
Overall Results
Here is how the two versions performed across the entire dataset of 6,085 queries:
- Product found in the 1st position: Original 41% ➔ New 71%
- Product found in the TOP 3: Original 46% ➔ New 76%
- Product found in the TOP 10: Original 51% ➔ New 80%
At first glance, these numbers might seem lower than you’d expect. But that’s the whole point of testing on real-world data - it includes intentionally difficult scenarios, like searching by a tiny fragment or just the numeric part of an SKU. These partial queries naturally drag down the overall success rate, because in a 35,000-product catalog, a short string of characters can easily match dozens of different items simultaneously.
Things get much more interesting when we break the data down by specific scenarios. That’s where you see exactly where orders slip through the cracks.
Exact Matches: The Baseline That Simply Must Work
The customer has the exact code - from a printed catalog, an invoice, or an ERP system. They paste it in and expect an instant result.
- Exact code query: Original 99% ➔ New 100%
- Code typed in lowercase: Original 99% ➔ New 100%
Both versions perform exceptionally well here. However, New Search Ready is slightly more precise in its ranking - the correct product is almost always in the absolute #1 spot, rather than sitting at #2 or #3.
Any decent e-commerce search engine should handle this. The real differences emerge the second a customer tweaks the input.
Where E-Commerce Stores Lose Sales: Customers Tweaking the Code
In reality, customers rarely type a code perfectly. They skip separators, swap them around, or format things their own way. This is exactly where the massive gap between legacy approaches and our specialized algorithm becomes obvious.
The customer skips separators
The system code is 010-01074-00. The customer types 01001107400 - they just ignore the dashes while copying from a piece of paper, a chat pane, or a PDF.
- Success rate: Original 4% ➔ New 89%
Takeaway: From a 96% failure rate to an 89% success rate. Original Search Ready (much like standard e-commerce search engines) practically failed this scenario. While it hit 4% on the real catalog, the conclusion remains: without specialized SKU analysis, this search behavior yields virtually zero results.
The customer swaps separators
The code is 0622.834-923. The customer types 0622-834.923 - swapping the dot and the dash because they can't remember exactly what went where.
- Success rate: Original 33% ➔ New 100%
Takeaway: With the original solution, two out of three customers wouldn't find the product. And all it took was confusing a dot with a dash. New Search Ready tolerates separator swaps and finds the right product every single time.
The customer inserts a dash between letters and numbers
The code is T1210444. The customer intuitively types T-1210444, separating the letter from the numbers. Or they type XC100095 as XC-100-095.
- Success rate: Original 10% ➔ New 89%
Takeaway: With the legacy approach, nine out of ten customers leave empty-handed. Even though they entered the right code - just with one perfectly logical extra dash.
The customer replaces separators with spaces
The code is 010-01074-00. The customer types 010 01074 00.
- Success rate: Original 90% ➔ New 100%
Original Search Ready handled spaces quite well (90%). But for a B2B store with a high average order value, losing those remaining 10% of buyers is an unnecessary financial leak.
The customer adds spaces at letter/number boundaries
The code is W31X2M1G50. The customer types W 31 X 2 M 1 G 50 - intuitively breaking up the letter and number clusters.
- Success rate: Original 10% ➔ New 72%
The Customer Only Has a Fragment of the Code
Customers don't always have the full SKU. Sometimes they only remember the beginning, or just the numbers. We tested these scenarios too, though we naturally expect lower success rates here - in a 35,000-product catalog, a short fragment is inherently ambiguous.
- Start of the code (prefix): Original 46% ➔ New 64%
- Numeric part only: Original 41% ➔ New 55%
- Alphabetic part only: Original 19% ➔ New 20%
For prefixes and numeric segments, New Search Ready offers a visible improvement. Searching only by the letters (e.g., typing just MOT when looking for MOT-51410404) is simply too vague in a catalog this size. Both versions performed similarly, which is the expected behavior.
Did Anything Get Worse? Yes - Here’s Where
Every system upgrade carries the risk of breaking something that used to work. We explicitly tested for this.
Out of 6,085 queries, there were 86 cases (1.4%) where Original Search Ready found the product, but the New version did not. Conversely, New Search Ready successfully found the product in 1,870 cases (31%) where the old algorithm failed.
The ratio of improvements to regressions is a staggering 22 : 1 in favor of New Search Ready.
These regressions occurred almost exclusively on partial queries - where a customer typed only a fragment of the code and the Original algorithm just happened to guess it, placing it lower in the results (positions 7–10). There were zero regressions on exact matches or slightly modified codes. For exact hits, lowercase text, and separator swaps, New Search Ready is as good or better 100% of the time.
Leading Zeros: A Conscious Choice
There was one scenario we intentionally did not test: stripping leading zeros. For example, the code 010-01074-00 searched as 10-1074-0. In technical catalogs, a leading zero is a critical part of the identifier - 010 and 10 can refer to completely different parts. The search engine shouldn't try to guess if the customer forgot the zero or is genuinely looking for another item. This strictness is by design. If, however, a specific catalog requires tolerance for leading zeros, it can easily be adjusted via our configuration.
Where Both Versions Perform Identically
For full transparency, there are code formats where the difference between the Original and New Search Ready is minimal:
- Purely numeric codes (e.g., 76575): Only a 2.5 percentage point improvement. Numbers without separators simply don't leave much room for transformation.
- Codes containing spaces (e.g., 1U149-006-1 PMA): A 2 percentage point improvement. The Original algorithm was already quite adept at handling spaces.
What This Means for Your Conversion Rates
This specific test was run on a single B2B catalog of 35,000 aviation parts. Your products, your SKUs, and your customers might behave slightly differently. But the underlying behavioral patterns - swapping separators, dropping special characters, typing codes from a printed sheet without dashes - are universal. We see the exact same behavior in auto parts, electronics, industrial machinery, and consumer goods.
A customer searching by a product code is your most valuable visitor. They know exactly what they want. They don't need recommendations, filters, or inspiration. They just need to paste the SKU and see the product.
If they don't get a result, they don't try another search. They bounce. And you won't even realize it from your analytics - you'll just see a "zero results search," completely unaware it was a high-intent buyer ready to pull out their credit card.
Test It on Your Own E-Commerce Store
Take five of your best-selling products. Copy their SKUs and paste them into your store’s search bar. Now delete a dash. Replace a dot with a space. Remove all the separators entirely.
Does the right product still pop up in the first position?
If not, you are losing the exact customers who are ready to buy right now - simply because your search engine doesn't understand how humans type.
Want to see how New Search Ready handles your actual data? Book a demo - we’ll show you the results using your own product catalog.
Frequently Asked Questions (FAQ)
Why does a standard search fail when a customer omits a dash?
Standard full-text search treats a product code like a normal sentence, breaking it into smaller "words" wherever there's a separator. When those separators are missing, the search engine sees a completely different "word" and fails to find a match. New Search Ready solves this by processing the SKU in multiple different ways simultaneously during both indexing and searching.
Does this improved code search work on massive catalogs with thousands of products?
Absolutely. We ran this test on a catalog of 35,000 items. In fact, specialized SKU search becomes exponentially more important as your catalog grows, because short fragments of a code are much more likely to erroneously match multiple different products at once.
Will this negatively impact regular text searches (like product names or descriptions)?
No. New Search Ready uses an entirely separate analysis pipeline for product codes, isolated from standard full-text search. Every type of data - name, description, product code, EAN - is processed using the specific logic that suits it best.
What happens if a customer drops a leading zero from a code?
This is an intentional limitation out-of-the-box. For technical identifiers, a zero is part of the code (010 is often a different item than 10). However, if your specific industry or catalog requires tolerance for missing leading zeros, we can easily tweak our configuration to allow it.
