Wyszukiwarka, która podpowiada zanim serwer zdąży odpowiedzieć - historia jednego modułu

Pole wyszukiwania to najmniejszy element sklepu, który robi najwięcej. Klient, który z niego korzysta, zwykle wie, czego chce - jest bliżej zakupu niż ktoś, kto dopiero przegląda kategorie. Jeśli wyszukiwarka mu pomoże, kupi. Jeśli go zmęczy, wyjdzie. I rzadko ktoś to zgłosi, bo nikt nie pisze maila „wasza wyszukiwarka jest wolna” - po prostu nie wraca.

Dlatego gdy pracowałem nad headerem sklepu na Shoper Storefront, wyszukiwarka dostała własny, osobny projekt. Nie restyling gotowego pola, tylko moduł zbudowany od zera, z własnym silnikiem. Opiszę, co w nim siedzi, dlaczego sprawia wrażenie natychmiastowej i czym różni się od tego, co sklep dostaje w standardzie.

Problem z domyślnym szukaniem w sklepie

Standardowa wyszukiwarka sklepowa działa według prostego schematu: wpisujesz znak, skrypt pyta serwer, serwer odpowiada, lista się odświeża. Przy każdej zmianie w polu. Dopóki łącze i serwer są szybkie, a katalog mały, jest znośnie. Problem w tym, że to „znośnie” rozjeżdża się dokładnie wtedy, gdy najbardziej zależy nam na konwersji: na telefonie, na słabszym zasięgu, na dużym katalogu.

Do tego dochodzi druga rzecz, mniej oczywista niż prędkość: trafność. Domyślne szukanie zwykle jest dosłowne. Literówka, polska odmiana, inna kolejność słów albo opisowe zapytanie zamiast nazwy produktu - i wyniki robią się puste albo przypadkowe. Klient widzi „brak wyników” mimo że produkt jest w katalogu, tylko nazwał go inaczej niż sklep.

Klient nie szuka tak, jak nazywacie produkty w bazie. Szuka tak, jak o nich myśli.

To dwa różne problemy - prędkość i trafność - i wymagają dwóch różnych rozwiązań. Stąd architektura, którą wybrałem.

Pomysł: dwa poziomy, które się nie blokują

Moduł działa na dwóch poziomach, które uruchamiają się równolegle i nie czekają na siebie nawzajem.

Poziom 1 to błyskawiczne podpowiedzi liczone w przeglądarce. Po wejściu na stronę moduł raz pobiera lekki indeks katalogu i od tego momentu liczy wszystko lokalnie. Nie ma round-tripu do serwera na każdy wciśnięty klawisz - podpowiedzi pojawiają się praktycznie w trakcie pisania.

Poziom 2 to warstwa semantyczna AI. Osobny, rzadszy strzał do dedykowanego backendu, który rozumie intencję zapytania, a nie tylko dopasowuje litery. Ta warstwa dochodzi „na wierzch” wyników wtedy, gdy jest gotowa - i co najważniejsze, nigdy nie blokuje Poziomu 1.

Klucz jest w tym „nie blokuje”. Klient zawsze najpierw dostaje natychmiastową odpowiedź lokalną. AI to bonus, który dokłada trafności, jeśli zdąży - a jeśli backend akurat zwolni albo nie odpowie, użytkownik nawet tego nie zauważy, bo lokalna lista już jest na ekranie.

Poziom 1: dlaczego to sprawia wrażenie natychmiastowego

Cała sztuczka prędkości polega na tym, że na czas pisania serwer w ogóle nie bierze udziału w grze. Indeks produktów i kategorii ląduje w przeglądarce raz, a potem każde zapytanie jest liczone na miejscu, na gotowej strukturze w pamięci.

Żeby to było szybkie i odporne, indeks budowany jest pod wyszukiwanie, a nie pod wyświetlanie:

• Normalizacja zapytania - tekst jest sprowadzany do małych liter, polskie znaki są zwijane (ł → l, ó → o i tak dalej), a wszystko poza literami i cyframi wycinane. Dzięki temu „Ładowarka”, „ladowarka” i „LADOWARKA” trafiają w to samo.
• Indeks trigramów - nazwy produktów rozbijane są na trójki znaków. To pozwala znaleźć kandydatów nawet wtedy, gdy zapytanie ma literówkę, bo większość trójek i tak się zgadza.
• Ograniczony dystans Levenshteina - dla dopasowania tokenów liczona jest „odległość edycyjna”, czyli ile poprawek dzieli wpisane słowo od słowa z katalogu. Krótkie zapytania dostają mniejszą tolerancję, dłuższe większą. Wersja jest celowo ograniczona: gdy tylko widać, że słowa są za daleko od siebie, liczenie się przerywa, żeby nie marnować czasu.

Na tym opiera się ranking, który nie jest „zawiera frazę / nie zawiera”. Wyżej ląduje produkt, którego nazwa zaczyna się od zapytania, niż taki, który ma je gdzieś w środku. Liczy się pokrycie - ile słów z zapytania faktycznie trafiło - a wyniki z pokryciem poniżej połowy są odsiewane, żeby nie zaśmiecać listy. Krótsze, celniejsze nazwy dostają lekką premię nad rozwlekłymi. To wszystko liczy się w ułamku tego, co zająłby jeden round-trip do serwera.

Do tego dochodzi „czy chodziło Ci o”. Jeśli wpisane słowo w ogóle nie istnieje w katalogu, moduł szuka najbliższego częstego słowa ze słownika produktów i proponuje poprawkę. Klient wpisuje „słuchwaki”, dostaje sugestię „słuchawki” i jednym kliknięciem poprawia zapytanie, zamiast patrzeć na pustą listę.

Tolerancja literówek to nie gadżet. To różnica między „brak wyników” a sprzedażą, na telefonie, w biegu, jednym kciukiem.

Poziom 2: AI, które rozumie intencję

Poziom 1 świetnie radzi sobie z literówkami i odmianą, ale ma granicę: operuje na słowach. Nie wie, że „coś do ładowania w samochodzie” to ładowarka samochodowa, jeśli te konkretne słowa nie padły w nazwie produktu.

Tu wchodzi warstwa semantyczna. To osobny mikroserwis, który dopasowuje produkty po znaczeniu zapytania, a nie po dosłownych literach, i zwraca sekcję „Najtrafniejsze” oznaczoną znacznikiem AI na samej górze podpowiedzi.

Ważne są tu trzy decyzje inżynierskie, które sprawiają, że ta warstwa pomaga, a nie przeszkadza:

1. Osobny, dłuższy debounce. Lokalne podpowiedzi odświeżają się niemal z każdym znakiem, ale zapytanie do AI wysyłane jest rzadziej i dopiero gdy użytkownik na moment przestanie pisać. To oszczędza wywołania modelu i nie zasypuje backendu przy każdym klawiszu.
2. Twardy timeout. Jeśli backend nie odpowie w wyznaczonym oknie, żądanie jest przerywane. Użytkownik nie czeka - lokalna lista i tak jest już na ekranie.
3. Cichy fallback. Błąd, timeout albo wyłączony backend nie powodują żadnego komunikatu o awarii. Wyszukiwarka po prostu działa na Poziomie 1. Warstwa AI jest addytywna, nie krytyczna.

Efekt z perspektywy klienta: pisze, od razu widzi sensowne podpowiedzi, a po chwili - jeśli zapytanie było opisowe albo nietypowe - na górze pojawia się jeszcze trafniejszy zestaw. Nic nie miga, nic nie znika, nic nie każe czekać.

Skuteczność wyszukiwania to przychód, nie estetyka

Łatwo myśleć o wyszukiwarce jak o detalu UI. W e-commerce to jeden z najlepiej konwertujących elementów sklepu, więc każdy procent trafności przekłada się na pieniądze.

Złożmy to, co realnie zmienia los zapytania:

• Polska odmiana i znaki diakrytyczne nie wykładają szukania.
• Literówki są tolerowane przez trigramy i dystans edycyjny.
• Nieistniejące słowa dostają propozycję poprawki zamiast pustej listy.
• Opisowe, „ludzkie” zapytania łapie warstwa semantyczna.
• Podpowiadane są i produkty, i kategorie - klient, który wpisał coś szerokiego, dostaje skrót do całej półki, a nie tylko do pojedynczego SKU.

Każdy z tych punktów to klient, który w domyślnej wyszukiwarce zobaczyłby „brak wyników” i wyszedł. To są ciche straty - nie pojawiają się w żadnym raporcie jako „przegrana sprzedaż”, bo nikt nie mierzy zakupów, które się nie wydarzyły. Ten sam typ niewidocznego wycieku opisywałem przy wolnym mega-menu: problem czuć w konwersji, ale trudno go przypisać do przyczyny.

Design: moduł, który nie udaje czegoś innego

Wyszukiwarka jest dominantą headera, więc i wyglądać musi jak dominanta, a nie jak doklejone pole. Cały moduł jest self-contained: ma własne style i własny silnik zamknięte w jednym kawałku, z klasami w osobnej przestrzeni nazw, żeby nie zderzać się z resztą motywu.

Warstwa wizualna trzyma się systemu marki: białe pole z wyraźną ramką i zaokrągleniem, pomarańczowy pierścień skupienia przy aktywności, czytelny przycisk SZUKAJ w kolorze akcentu. Podpowiedzi to panel z miniaturą produktu, nazwą z podświetlonym dopasowaniem, marką i ceną (z przekreśloną ceną poprzednią, gdy jest promocja), a pod nimi kategorie jako klikalne pigułki.

Pod spodem są rzeczy, których nie widać, a robią różnicę:

• Pełna obsługa klawiatury - strzałki przewijają listę, Enter wchodzi w zaznaczony wynik, Escape zamyka. Dla części klientów to podstawowa dostępność, dla części zwykła wygoda.
• Stan ładowania i czyszczenia - delikatny spinner, gdy indeks się dociąga, i przycisk czyszczenia pola.
• Realny adres pełnych wyników - „Pokaż wszystkie wyniki” oraz przycisk SZUKAJ prowadzą do prawdziwej strony wyników sklepu. Podpowiedzi liczą się skryptem, ale samo wyszukanie jest zwykłym przejściem pod adres - działa też wtedy, gdy ktoś po prostu wciśnie Enter, bez czekania na podpowiedzi.

To ta sama filozofia, którą trzymam w całej pracy na zamkniętym froncie Shopera, opisana przy Shoper Storefront: co musi być natychmiastowe i pewne, robimy pewnym, a wszystko inne dokładamy na wierzch, nie kosztem podstawy.

Drugi element tego samego headera: menu

Wyszukiwarka nie powstała w próżni. To część większej przebudowy nagłówka sklepu, w której wcześniej zająłem się nawigacją. O tym, dlaczego duże, wielopoziomowe mega-menu potrafi zamulać przy najechaniu i jak to naprawiłem bez ruszania struktury linków, pisałem osobno: Szybkie mega-menu na Shoper Storefront.

Krótka aktualizacja - bo menu w docelowym headerze robi już więcej niż samą nawigację. Każdy panel kategorii poza listą podkategorii pokazuje też treści redakcji i polecane produkty wprost w menu: kafel poradnika („Czytaj poradnik”) i kartę produktu z poradnika („Zobacz produkt”, z ceną i promocją). Nawigacja przestaje być spisem działów, a staje się miejscem, w którym klient od razu dostaje kontekst i konkretną propozycję.

Na desktopie to pełnoszerokie mega-menu: rząd głównych działów, a pod nim panel z pogrupowanymi podkategoriami (np. „Montaż i ładowanie”, „Ochrona i wygląd”, „Zapachy i ozdoby”), skrótami „Przydatne” i - po prawej - poradnikiem oraz polecanym produktem dopasowanym do otwartej kategorii.

Na telefonie ten sam zestaw działa jako pełnoekranowe menu akordeonowe. Rozwijasz dział, potem podkategorię, a w środku - te same kafle poradnika i produktu co na desktopie. Bez przycięcia, bez gubienia treści po drodze na mały ekran.

To celowy zabieg pod content commerce: poradnik buduje zaufanie i odpowiada na „które wybrać”, a karta produktu daje od razu ścieżkę do zakupu - jedno i drugie w miejscu, gdzie klient i tak już szuka. Przy okazji to mocne linkowanie wewnętrzne, bo poradniki i produkty są w menu jako prawdziwe linki, widoczne dla robotów na każdej podstronie sklepu.

Razem menu i wyszukiwarka tworzą jeden spójny nagłówek: nawigacja z kontekstem dla tych, którzy przeglądają, i błyskawiczne szukanie dla tych, którzy już wiedzą, czego chcą. Oba elementy zbudowane tak, żeby były szybkie w interakcji i nie traciły przy tym widoczności dla robotów wyszukiwarek.

Co z tego ma sklep

Wyszukiwarka i menu to nie kosmetyka headera. To dwie drogi, którymi klient dociera do produktu, i obie zostały zbudowane pod jeden cel: żeby nie tracić ludzi, którzy są już gotowi kupić.

Standardowe pole szukania przegrywa cicho - na każdym round-tripie do serwera i na każdej literówce, której nie wybacza. Tych strat nie widać w raporcie, bo to zakupy, które się nie odbyły. Dwupoziomowa wyszukiwarka odwraca tę logikę: natychmiastowa odpowiedź lokalna jako fundament, AI jako warstwa trafności na wierzchu, i żadna z nich nie blokuje drugiej.

To dokładnie ten rodzaj różnicy, który stoi za specjalizacją w Shoperze: platforma daje ramy, a wynik robi inżynieria w tych ramach. Ta sama staranność, którą wkłada się w pomiar i tagowanie, opłaca się na froncie sklepu - bo najlepszy tracking pokaże tylko, gdzie klienci odpadają, a tu chodzi o to, żeby odpadali rzadziej. Taką wyszukiwarkę i inne elementy headera Storefront buduję na zlecenie - zobacz dodatki i przebudowę frontu Shopera.

Podsumowanie

Dobra wyszukiwarka sklepowa nie musi wybierać między prędkością a trafnością. Poziom 1 - lokalny indeks, trigramy, tolerancja literówek i „czy chodziło Ci o” - daje natychmiastowość bez serwera. Poziom 2 - warstwa semantyczna AI z osobnym debounce, timeoutem i cichym fallbackiem - dokłada zrozumienie intencji, nie blokując podstawy.

Całość zamknięta w jednym module headera, obok przebudowanego mega-menu, w spójnym designie marki i z pełnymi linkami wyników, które działają nawet bez podpowiedzi.

Klient nie pamięta, że wyszukiwarka była szybka. Pamięta, że znalazł to, czego szukał. Twoim zadaniem jest sprawić, żeby jedno wynikało z drugiego.