Wyszukiwarka Magento nie znajduje produktu po SKU ani części nazwy

The problem

Standardowa wyszukiwarka Magento 2 w wielu sklepach realnie działa tylko na pełne dopasowanie do nazwy produktu. Klient wpisuje „sv01”, „lakier hybrydowy 01” albo „różowy lakier hybrydowy” — i dostaje „brak wyników”, choć pozycja jest w katalogu i na stanie. Ten sam efekt daje każdy drobiazg: myślnik zamiast spacji, pisownia łączna, brak polskich znaków („zel” zamiast „żel”), literówka, przypadkowy układ klawiatury. Dla człowieka to jeden i ten sam produkt, dla systemu — różne zapytania donikąd.

Najdroższe jest to, że tracony jest najgorętszy ruch. Do pola wyszukiwania idzie osoba, która już wie, co chce kupić: przyszła z katalogu, z newslettera, z Instagrama, gdzie zobaczyła SKU. Pusta lista wyników odsyła ją do konkurencji z gotowym zamiarem zakupu. Przy katalogu 1500–3000 pozycji udział sesji z wyszukiwaniem to zwykle 10–30%, a konwersja takich sesji bywa 2–3 razy wyższa niż średnia na serwisie — mówimy więc o odczuwalnej części przychodu. Dodatkowy minus: nieudane zapytania nigdzie się nie zapisują, więc właściciel sklepu nawet nie widzi, czego ludziom brakuje w katalogu.

What makes it hard

Zrobienia tego „na wprost” nie da się z kilku powodów. Sklep zwykle już działa produkcyjnie, opiekuje się nim zewnętrzny wykonawca, a dostępy do repozytorium i środowiska testowego idą przez niego — to osobny krok i osobny termin. Nie wolno ruszać szablonów katalogu ani skonfigurowanych już filtrów: działają i klient jest z nich zadowolony, a każda ingerencja w widok wyników pociąga za sobą ponowne testy całego katalogu.

Drugie ograniczenie to dane. SKU, kolor, nazwa w zapisie łacińskim, linia produktowa często są już uzupełnione w kartach jako atrybuty, ale nie trafiają do indeksu wyszukiwania albo trafiają bez wagi, więc trafienie w opisie przebija trafienie w SKU. Jeśli atrybuty są wypełnione częściowo albo w różnych formatach, najpierw trzeba je sprowadzić do jednej postaci — inaczej konfiguracja wyszukiwarki utrwali bałagan. I trzecie: rozwiązanie musi być zestawem reguł, a nie ręczną listą, bo nowe produkty dochodzą codziennie i nikt nie będzie przestawiał wyszukiwarki pod każdą pozycję.

How we solve it

Po pierwsze — indeksacja atrybutów z wagami. SKU, kolor, linia i nazwa w zapisie łacińskim stają się pełnoprawnymi polami wyszukiwania, przy czym trafienie w SKU waży więcej niż trafienie wewnątrz opisu. Zapytanie „01” pokazuje wszystkie pozycje z taką numeracją, „sv01” — konkretną kartę, nawet jeśli w nazwie tego kodu nie ma. Dokładamy dopasowania częściowe: szukanie po fragmentach słowa i po kilku słowach w dowolnej kolejności, więc „lakier hybrydowy 01” i „lakierhybrydowy 01” dają ten sam wynik.

Po drugie — normalizacja zapytania, zanim trafi do indeksu. Poprawianie układu klawiatury, zapis z polskimi znakami i bez nich w obie strony („zel” → „żel”, „samer vajb” → Summer Vibe), pisownia łączna i rozdzielna, typowe literówki. Na to nakłada się słownik synonimów pod tematykę sklepu: warianty zapisu kategorii, nazwy kolorów i linii po polsku i po angielsku, potoczne określenia, których używają klienci.

Po trzecie — praca z wynikami. Podpowiedzi od trzeciego wpisanego znaku: zdjęcie, nazwa, cena, przejście od razu do karty. Zamiast ślepej uliczki „brak wyników” — podobne pozycje z tej samej kategorii i najpopularniejsze produkty. Osobno zbierany jest raport zapytań: czego ludzie szukają i czego nie znajdują — to gotowa lista luk w katalogu i w synonimach. Wszystko testujemy na realnym katalogu według listy zapytań od klienta plus własnego zestawu przypadków; prace idą na środowisku testowym, na żywy sklep zmiany wychodzą jednym krokiem po weryfikacji. Wariant rozszerzony dodaje edycję synonimów z panelu administracyjnego bez programisty, ręczne podbijanie wybranych pozycji na górę wyników dla danego zapytania, reguły pod zapytania sezonowe i promocje — oraz, w razie potrzeby, feed do marketplace'ów opartý na tych samych znormalizowanych atrybutach.

What drives the price and timeline

Rynkowe widełki dla Magento 2 przy katalogu do ok. 3000 pozycji: bazowa przebudowa wyszukiwania (atrybuty w indeksie, normalizacja zapytania, dopasowania częściowe, synonimy, podpowiedzi) — około 3 500–6 000 zł i 3–5 dni roboczych. Wariant ze sterowaniem wynikami, raportem zapytań, samodzielną edycją synonimów i wsparciem po wdrożeniu — 5 000–9 000 zł, 5–7 dni. Jeśli tym samym etapem robiony jest feed do Allegro/Ceneo z mapowaniem kategorii oraz automatyczną aktualizacją stanów i cen — 9 000–13 000 zł i 10–12 dni.

Główny czynnik ceny to nie liczba produktów, tylko stan atrybutów. Jeśli SKU, kolor i linia są już wypełnione jednolicie we wszystkich kartach, pracy jest dokładnie tyle, ile w zakresie. Jeśli trzeba je znormalizować albo wyciągać z opisów — dochodzi osobny etap przygotowania danych, a budżet rośnie półtora–dwa razy. Drugi czynnik to tempo przekazania dostępów przez zewnętrznego wykonawcę: termin liczy się poprawnie od dnia, w którym są środowisko testowe i repozytorium, a nie od dnia podpisania umowy.