Wyszukiwarka produktów w sklepie B2B – jak sprawić, żeby klient znalazł towar po indeksie, nazwie i literówce

Wyszukiwarka w sklepie B2B działa dobrze wtedy, gdy klient wpisuje to, co ma pod ręką – indeks producenta, własny kod, fragment nazwy albo numer z literówką – i od razu dostaje właściwy towar w swojej cenie. Żeby to osiągnąć, trzeba osobno obsłużyć dokładne dopasowanie kodów, wyszukiwanie pełnotekstowe po nazwach i opisach, zamienniki oraz tolerancję na błędy, a indeks wyszukiwania karmić danymi z ERP lub PIM bez przerw w działaniu. Poniżej opisujemy, jak takie rozwiązanie zaprojektować krok po kroku.

Czym wyszukiwanie B2B różni się od sklepu dla konsumentów

Klient sklepu detalicznego szuka „butów do biegania” i chętnie przegląda wyniki. Kupiec w firmie instalacyjnej, warsztacie czy dziale zakupów producenta wie, czego potrzebuje, i chce dotrzeć do konkretnej pozycji w kilka sekund. Najczęściej wpisuje:

• indeks producenta, czasem z kreskami, spacjami albo bez wiodących zer,
• kod EAN zeskanowany lub przepisany z opakowania,
• własny indeks z systemu zakupowego swojej firmy,
• skróconą nazwę branżową, np. „kolano 90 fi 50” zamiast pełnej nazwy katalogowej,
• numer starego produktu, który został wycofany i ma następcę.

Do tego dochodzi skala. Katalog hurtowni technicznej czy dystrybutora części potrafi liczyć dziesiątki lub setki tysięcy pozycji z bardzo podobnymi nazwami. Wyszukiwarka, która przy zapytaniu „6205” zwraca pół tysiąca łożysk w przypadkowej kolejności, jest dla kupca bezużyteczna. Dlatego w B2B ważniejsza od „inteligencji” jest przewidywalność: dokładne trafienie w kod zawsze na pierwszym miejscu, potem dopiero dopasowania przybliżone.

Krok 1: uporządkuj dane, zanim wybierzesz silnik

Najlepszy silnik nie naprawi danych, w których ten sam indeks występuje raz jako „AB-120/5”, a raz jako „AB120 5”. Przed wdrożeniem warto przejrzeć, jakie pola faktycznie istnieją w ERP lub PIM i które z nich mają trafić do wyszukiwania. Typowy zestaw to:

• indeks wewnętrzny i indeks producenta,
• kody EAN (często kilka na jeden towar, dla różnych opakowań),
• nazwa handlowa i nazwa skrócona,
• producent, marka, seria,
• kluczowe parametry techniczne (średnica, napięcie, materiał),
• kategoria i ścieżka kategorii,
• zamienniki i następcy,
• indeksy klientów, jeśli prowadzisz mapowanie kodów kontrahentów.

Dla pól z kodami przygotuj wersję znormalizowaną: bez spacji, kresek, kropek i ukośników, wielkimi literami. Zapytanie „ab 120-5” po takiej samej normalizacji trafi wtedy w „AB-120/5” bez żadnej magii. To prosta zmiana, która rozwiązuje dużą część skarg typu „wpisuję indeks i nic nie ma”.

Jeśli dane produktowe są rozproszone między ERP, arkuszami i katalogami producentów, najpierw trzeba ustalić jedno źródło prawdy. O przepływie danych produktowych między API, PIM i sklepem pisaliśmy w artykule o Laravel API dla e-commerce B2B i PIM.

Krok 2: rozdziel dopasowanie dokładne i pełnotekstowe

Dobra wyszukiwarka B2B obsługuje w praktyce dwa różne tryby, nawet jeśli klient widzi jedno pole.

Dopasowanie po kodzie

Gdy zapytanie wygląda jak kod (cyfry, litery i separatory bez spacji między słowami), system najpierw sprawdza dokładne trafienie w znormalizowane pola indeksów i EAN. Jeśli jest jeden wynik, można od razu pokazać produkt albo – w szybkim zamawianiu – dodać go do listy. Dopasowanie po prefiksie („AB-12” podpowiada wszystkie „AB-12…”) bardzo pomaga przy długich kodach.

Wyszukiwanie po nazwie i parametrach

Dla zapytań słownych potrzebny jest silnik pełnotekstowy z wagami pól. Trafienie w nazwę i producenta powinno ważyć więcej niż trafienie w opis, a parametry techniczne warto indeksować jako osobne pola, które mogą też służyć do filtrów. Kolejność wyników ustawia się regułami: najpierw dopasowania dokładne, potem towary dostępne, potem pozostałe. Sortowanie według popularności sprzedaży ma sens, ale dopiero jako jeden z czynników, nie jedyny.

Krok 3: literówki, synonimy i zamienniki

Tolerancja na literówki to standard w silnikach takich jak Typesense, Meilisearch czy Elasticsearch/OpenSearch. W B2B trzeba ją jednak ograniczyć. Dla nazw „przewod” zamiast „przewód” albo „zawur” zamiast „zawór” poprawianie błędów pomaga. Dla kodów potrafi szkodzić: „6205” i „6206” to różne łożyska, a podpowiedź „czy chodziło Ci o 6206” jest dla klienta mylącą informacją. Rozsądna reguła to brak tolerancji na błędy w polach kodowych i umiarkowana tolerancja w nazwach, zwykle dopiero od pewnej długości słowa.

Synonimy warto zbierać z prawdziwych zapytań, a nie wymyślać przy biurku. Branża ma swój język: „kolano” i „łuk”, „fi” i „średnica”, skróty producentów, nazwy potoczne. Lista synonimów powinna być edytowalna przez dział handlowy w panelu administracyjnym, bez wdrożenia nowej wersji systemu.

Zamienniki i następcy to osobny temat. Gdy klient wpisuje indeks wycofanego produktu, wyszukiwarka powinna pokazać następcę z wyraźną informacją, że to inny towar. Gdy produkt jest niedostępny, pomocna jest sekcja z zamiennikami. Oba powiązania muszą pochodzić z danych (ERP, PIM lub ręcznej listy prowadzonej przez dział zakupów), a nie z „podobieństwa” wyliczonego przez silnik.

Krok 4: wiele języków i wiele katalogów

Jeśli sprzedajesz w kilku krajach, nie wrzucaj wszystkich języków do jednego pola. Lepiej utrzymywać osobne indeksy (lub kolekcje) dla każdego języka, z właściwymi ustawieniami tokenizacji i listami synonimów. Polskie odmiany („zaworu”, „zaworów”) i niemieckie złożenia wyrazów zachowują się inaczej, a jeden wspólny indeks zwykle pogarsza wyniki w każdym z języków. Pola kodowe mogą być wspólne, bo indeks producenta jest taki sam niezależnie od języka.

Druga sprawa to widoczność asortymentu. W wielu platformach B2B różni klienci widzą różne katalogi: część towarów jest dostępna tylko dla dealerów, część tylko w określonym kraju. Filtrowanie tego powinno odbywać się w samym zapytaniu do silnika (np. przez pole z identyfikatorami grup klientów), a nie dopiero po pobraniu wyników. Inaczej pojawiają się puste strony wyników i błędne liczniki w filtrach.

Ceny indywidualne zazwyczaj nie trafiają do indeksu wyszukiwania. Silnik zwraca listę produktów, a cenę dla zalogowanego klienta pobiera się z modułu cenowego platformy lub z ERP. Wyjątkiem jest sytuacja, gdy klient musi filtrować lub sortować po cenie – wtedy trzeba świadomie zaprojektować, które ceny i dla których grup klientów są indeksowane.

Krok 5: indeksowanie i przebudowa bez przerwy

Indeks wyszukiwania to kopia danych, więc musi nadążać za zmianami. Zwykle stosuje się dwa mechanizmy jednocześnie:

1. Aktualizacje przyrostowe – każda zmiana produktu, stanu lub widoczności w platformie wysyła zadanie do kolejki, które aktualizuje pojedynczy dokument w indeksie.
2. Pełna przebudowa – okresowo lub po zmianie struktury indeksu (nowe pole, zmiana wag, nowe synonimy) budowany jest cały indeks od zera.

Pełna przebudowa nie powinna wyłączać wyszukiwarki. Sprawdzony wzorzec to budowanie nowej kolekcji obok starej i przełączenie aliasu dopiero wtedy, gdy nowa kolekcja jest kompletna i przeszła kontrolę (liczba dokumentów, kilka zapytań testowych). Typesense i Elasticsearch/OpenSearch obsługują aliasy kolekcji, więc klient nie widzi momentu przełączenia. Starą kolekcję usuwa się po potwierdzeniu, że nowa działa, co daje też prostą ścieżkę wycofania.

W aplikacjach Laravel integrację z silnikiem ułatwia Laravel Scout, który ma sterowniki m.in. dla Typesense, Meilisearch i Algolii. Przy dużych katalogach i złożonych regułach i tak warto mieć własną warstwę, która kontroluje schemat indeksu, normalizację kodów i przebudowę z aliasem, zamiast polegać wyłącznie na domyślnej konfiguracji.

Stany magazynowe zmieniają się często. Jeśli wyszukiwarka ma filtrować „tylko dostępne”, aktualizacje stanów muszą trafiać do indeksu z kolejki, partiami, a nie przez pełną przebudowę co kilka minut.

Jak mierzyć, czy wyszukiwarka działa

Wyszukiwarki nie da się ocenić „na oko” przez kilka testowych zapytań zespołu. Warto od pierwszego dnia zapisywać zapytania i mierzyć:

• odsetek zapytań bez wyników – i przeglądać je co tydzień, bo to gotowa lista brakujących synonimów, kodów i towarów,
• odsetek wyszukiwań, po których klient kliknął produkt lub dodał go do koszyka,
• pozycję klikniętego wyniku – jeśli klienci regularnie klikają piąty wynik, ranking jest źle ustawiony,
• czas odpowiedzi wyszukiwarki, także w podpowiedziach podczas pisania,
• zapytania, po których klient przechodzi do formularza kontaktowego lub dzwoni do handlowca.

Lista zapytań bez wyników jest najcenniejszym źródłem poprawek. Często okazuje się, że klienci szukają po indeksach konkurencji, starych numerach katalogowych albo nazwach potocznych, których nie ma w danych.

Gotowy moduł czy własne rozwiązanie

W wielu gotowych platformach B2B wyszukiwarka jest wbudowana i przy prostym katalogu wystarcza. Granica pojawia się zwykle przy nietypowych kodach, wielu językach, katalogach zależnych od klienta, zamiennikach i potrzebie kontrolowania rankingu. Wtedy lepiej sprawdza się osobny silnik wyszukiwania z warstwą integracyjną zaprojektowaną pod Twoje dane. Jeśli rozważasz budowę lub przebudowę całej platformy, opis zakresu znajdziesz na stronie system B2B dla firmy, a dobre wyszukiwanie warto od początku traktować jako element integracji z ERP, opisanej w artykule o pułapkach integracji ERP z platformą B2B.

Następny krok

Jeśli klienci skarżą się, że „nie mogą znaleźć towaru”, a zapytania bez wyników nie są nigdzie zapisywane, zacznij od krótkiego przeglądu danych produktowych i logów wyszukiwania. Projektujemy i rozwijamy platformy B2B i CRM razem z wyszukiwaniem, integracją z ERP i panelem do zarządzania synonimami. Napisz do nas, opisz swój katalog i źródła danych, a zaproponujemy zakres pierwszego etapu.