Když zákazník hledá 503 28 32-08, nesmí dostat „podobné“

Vyhledávání s tolerancí překlepů je pro lidský jazyk výborné. U katalogových čísel náhradních dílů je ale „podobné číslo“ prostě jiný díl. Na 180 skutečných číslech ze tří značek jsme změřili, jak fuzzy hledání na kódech selhává, a vyhledávání jsme kvůli tomu upravili ve dvou krocích. Tady jsou čísla i to, co z nich plyne pro každý e-shop s díly, součástkami nebo spotřebním materiálem.

Kde to začalo

Prodejce náhradních dílů na zahradní techniku provozuje vedle e-shopu katalog rozkresů: 1 083 výkresů výrobců a přes 21 000 katalogových čísel dílů značek STIHL, Husqvarna a Oleo-Mac. Zákazník si otevře PDF, najde ve výkresu díl, opíše číslo a chce vědět, jestli ho e-shop má. Katalog se na to ptá vyhledávacího API e-shopu a buď ukáže kartu produktu s cenou, nebo rovnou předvyplní poptávku. Jak celé napojení vzniklo, popisuje sesterská případová studie o napojení katalogu přes API.

Jediný tvrdý požadavek zněl: nikdy neukázat jiný díl jako „skladem“. Tím se tenhle typ dotazu liší od všeho, na co je hledání v e-shopu obvykle stavěné.

Co jsme změřili

Vzali jsme 180 náhodných čísel z katalogu, 60 na značku, každé z jiného rozkresu, a poslali je do API v několika zápisech. Shodu jsme uznali jen tehdy, když se normalizované číslo (bez mezer a pomlček, velká písmena) objevilo v kódu, názvu, EAN, popisu nebo v kódu varianty vráceného produktu.

Jedno číslo Husqvarna, tři zápisy, tři různé výsledky (před úpravou):

Zápis rozhodoval, a u každé značky opačně

Na kontrolní sadě dílů, které v e-shopu prokazatelně jsou, měl původní zápis u Husqvarny úspěšnost 61 %, bez oddělovačů 100 %. U STIHL přesně naopak: 96 % s mezerami, 52 % bez nich.

Fuzzy výsledky na dotaz, který nic nemá najít

Dotaz nesmysl-xyz-000 vrátil 200 produktů. Dotaz 6350 704 1000 (STIHL, v e-shopu není) vrátil 207 produktů v čele se vzduchovým filtrem jiné značky a dárkovým poukazem na 1 000 Kč, protože se v názvu shodoval token „1000“. V odpovědi přitom nebylo nic, podle čeho by šla přesná shoda odlišit od podobnosti.

Tři menší poznatky

• Náhradní čísla jsou jen text. „Nahrazuje originál 503283208“ je v názvu nebo v perexu, ne v žádném kódovém poli. Dvě z 24 shod v testu existovaly jen v perexu.
• Limit výsledků nic nezachrání. 12, 30 i 100 produktů dalo stejné shody; každá správná byla do desáté pozice.
• Většina čísel v e-shopu opravdu není. U 87 % katalogových čísel produkt neexistuje. Poznali jsme to podle „skoro shod“: na 66070095R přijde jen 66071059R, na 3912009 jen 3918006. Přesné porovnání je správně odmítlo. Tolerantní porovnání by zákazníkovi nabídlo špatný díl.

Co jsme s tím udělali

Katalog nejdřív dostal obranu na své straně: dotaz ve dvou zápisech podle značky a přísné porovnání kódu v polích produktu. Husqvarna tím skočila z 18 % na 30 % nalezených dílů. Skutečná oprava ale patřila do vyhledávání, ve dvou krocích.

Den 2: Čísla z názvu a perexu do vlastního pole

Příčina nebyla v řazení. Katalogové číslo výrobce nebylo u těchto dílů v žádném kódovém poli, jen ve volném textu, a ten prohledává analyzer, který seká na mezerách. Proto Husqvarna (čísla slepená) a STIHL (čísla po skupinách) fungovaly každá na jiný zápis.

Revelor teď čísla z názvu a perexu vytahuje do samostatného pole a normalizuje je stejně jako dotaz. Když dotaz vypadá jako kód, výsledky se ořežou na produkty, které to číslo skutečně nesou, a odpověď dostane nové pole code_match. Z dotazu 503 28 32-08 se stalo 4 výsledky místo tisíce, se správným dílem na prvním místě.

Den 3: „Přesná shoda“ musí být přesná

Přeměření na stejných 180 číslech odhalilo 4 falešně pozitivní případy, všechny u Oleo-Macu. Když dotaz nic nenašel, API zkusilo tichou opravu překlepu a code_match se spočítal z opraveného dotazu. 66060381BR tak hlásilo přesnou shodu na díl 66060131, který s ním nemá nic společného.

Oprava: exact je pravda jen při rovnosti normalizovaného dotazu s číslem nalezeným v produktu, u kódů bez jakékoli tolerance. Opravený kód přijde zvlášť v poli suggested, aby se web rozhodl sám, jestli ho nabídne.

GET /api/public/suggestions?q=66060381BR&projectId=…

"code_match": {
  "query_is_code": true,
  "normalized": "66060381br",
  "exact": false,
  "matches": 0,
  "suggested": "66060131",
  "suggested_matches": 2
}

Výsledek

U STIHL a Oleo-Macu zůstává podíl nalezených dílů kolem 5 %, a to je správně: ta čísla v e-shopu nejsou. Rozdíl je, že vyhledávání to teď říká jasně, místo aby vracelo stovky nesouvisejících položek. Pro obchod je to zároveň nový signál: každé „nenalezeno“ se v katalogu loguje, takže je vidět, které díly zákazníci chtějí a e-shop je nenabízí.

Na straně katalogu mohla po opravě zmizet vlastní obrana. Místo dvou dotazů a lokálního porovnávání kódů stačí jeden dotaz a čtení code_match.exact. Méně kódu, méně volání, stejná jistota.

Co si z toho odnést

• Kód není slovo. Tokenizace na mezerách je pro věty správně a pro katalogová čísla zhoubná. Čísla patří do vlastního pole, normalizovaná na obou stranách.
• Přesné musí znamenat přesné. Tolerance překlepů nesmí prosáknout do příznaku, na který se klient spoléhá. Opravu vracejte zvlášť a pojmenovanou.
• Dejte odpovědi příznak, ne jen seznam. Pro člověka je 200 podobných produktů nabídka. Pro program je to bez exact nerozhodnutelná situace.
• Měřte na skutečných datech a s kontrolní sadou. Náhodný vzorek ukáže pokrytí, sada prokazatelně existujících dílů ukáže recall. Bez té druhé by „5 % nalezeno“ vypadalo jako chyba hledání.
• Vyšší limit není odpověď. Když je řazení správné, správná shoda je v první desítce. Když není, limit 100 jen přidá šum.

Měření proběhlo 5. až 7. září 2026 na produkčním API e-shopu na Shoptet Premium v segmentu náhradních dílů na zahradní techniku. Kompletní metodiku a skripty rádi ukážeme.

Prodáváte na Shoptet Premium díly, součástky nebo spotřební materiál a zákazníci u vás hledají podle katalogových čísel? Přesně na tenhle typ dotazu je vyhledávání Reveloru stavěné. Ozvěte se nám — v preview režimu ho pustíme na vašich datech dřív, než ho uvidí zákazníci.