W większości sklepów PrestaShop z paska wyszukiwania korzysta od 15 do 30 % odwiedzających. I to właśnie ten segment trzeba obserwować: odwiedzający, który wpisuje zapytanie w wyszukiwarkę, ma intencję zakupową od 2 do 5 razy silniejszą niż odwiedzający w biernej nawigacji. Badania Baymarda i Forrestera zbiegają się w tym punkcie od dziesięciu lat, bo wyszukiwanie wewnętrzne konwertuje lepiej niż reszta ruchu.
Problem w tym, że natywne wyszukiwanie PrestaShop jest technicznie słabe. Brak podpowiedzi w czasie rzeczywistym, brak tolerancji dla literówek, brak ważenia sortowania, brak analityki. W tym wyjątkowo rentownym segmencie sklep oferuje odpowiednik pliku tekstowego przeszukiwanego poleceniem grep. I nikt nie mierzy kosztu.
Ten artykuł rozkłada na części to, dlaczego wyszukiwanie wewnętrzne jest często pomijaną dźwignią konwersji, jak policzyć, ile Cię dziś kosztuje, i co zmienia dobrze zrobione wyszukiwanie na żywo.
Profil odwiedzającego, który korzysta z wyszukiwarki
Zrozumienie stawki zaczyna się od zrozumienia, kto szuka. Analizy behawioralne pokazują trzy dominujące profile:
1. Odwiedzający transakcyjny
Wie, czego chce. „Czerwona sukienka rozmiar 38”, „iPhone 17 Pro 256 GB”, „Słuchawki Bose”. Jego intencja zakupowa jest wysoka, a tarcia znosi źle. Jeśli wyszukiwarka nie da mu tego, czego szuka, w 2 do 3 sekund, opuszcza sklep i wpisuje zapytanie w Google.
2. Odwiedzający eksplorujący
Ma mgliste wyobrażenie. „Prezent dla mężczyzny”, „Buty na lato”, „Wygodne spodnie”. Jego intencja jest mniej natychmiastowa, ale jest otwarty. Wyszukiwarka proponująca trafne podpowiedzi ukierunkowuje jego decyzję.
3. Odwiedzający powracający
Zna sklep, widział produkt przy poprzedniej wizycie i szuka go po częściowej albo przybliżonej nazwie. Tolerancja dla literówek i pamięć kontekstowa robią różnicę.
Wszystkie trzy profile konwertują od 2 do 5 razy lepiej niż średnia witryny, jeśli wyszukiwarka poprawnie ich obsłuży. I wszystkie trzy wychodzą na tym źle, gdy zawiedzie.
Czego nie robi natywne wyszukiwanie PrestaShop
Natywny silnik PrestaShop 8 (i 9) opiera się na pełnotekstowym indeksie MySQL albo opcjonalnym Elasticsearchu. Działa, ale ma strukturalne braki:
Brak tolerancji dla literówek
„Sambba” nie zwróci Adidas Samba. „Iphon” nie zwróci iPhone’a. Odwiedzający widzi „Brak wyników” i wychodzi. W sklepie modowym od 8 do 15 % wyszukiwań zawiera co najmniej jedną literówkę. Wszyscy ci odwiedzający są straceni.
Brak podpowiedzi w czasie rzeczywistym
Odwiedzający musi zatwierdzić wyszukiwanie (klawiszem Enter albo kliknięciem w lupę), a potem czekać na załadowanie strony wyników. W tym czasie uwaga spada. Konkurencja (Amazon, Allegro, marketplace’y) oferuje podpowiedzi natychmiastowe. Porównanie wypada okrutnie.
Brak ważenia produktów
Wyszukanie „sukienka” zwraca wszystkie produkty zawierające to słowo, bez inteligentnego sortowania: bestsellery, nowości i produkty dostępne na stanie nie są faworyzowane. Odwiedzający trafia na produkt niedostępny, przestarzały albo poza sezonem. Konwersja przepada.
Brak analityki
Ile wyszukiwań dziennie? Które zapytania nie dają żadnego wyniku? Które mają niski współczynnik kliknięć? Bez tych danych nie da się zoptymalizować katalogu ani wykryć okazji produktowych.
Ograniczona wydajność
Przy katalogu powyżej 10 000 produktów pełnotekstowe wyszukiwanie MySQL staje się wolne (od 200 do 500 ms). Przy poprawnie skonfigurowanym indeksie Elasticsearch schodzimy poniżej 50 ms, ale instalacja i utrzymanie Elasticsearcha rzadko bywają udźwignięte.
Realny koszt źle zrobionej wyszukiwarki: jak go zmierzyć
Większość sprzedawców nie ma pojęcia o koszcie swojej obecnej wyszukiwarki, bo jej nie mierzy. Oto trzy minimalne wskaźniki do oprzyrządowania, nawet bez dedykowanego modułu:
Wskaźnik wyszukiwań bez wyników
Ile zapytań zwraca zero produktów? Jeśli jesteś powyżej 8 do 10 %, masz problem z katalogiem albo z tolerancją dla literówek. Każdy brak wyników to sfrustrowany odwiedzający.
Współczynnik kliknięć w wyniki wyszukiwania
Odwiedzający wpisał zapytanie i zobaczył wyniki. Ilu klika w produkt? Jeśli CTR jest poniżej 40 %, winne jest sortowanie albo trafność.
Współczynnik konwersji po wyszukiwaniu
Jaki jest współczynnik konwersji w sesjach przechodzących przez wyszukiwarkę? W porównaniu ze wskaźnikiem globalnym powinieneś obserwować od 1,5 do 3 razy więcej. Jeśli jesteś poniżej, Twoja wyszukiwarka źle obsługuje swój najbardziej rentowny segment.
W sklepie generującym 400 tys. zł miesięcznego obrotu, w którym 25 % odwiedzających korzysta z wyszukiwarki, wyszukiwarka osiągająca o 30 % mniej, niż mogłaby, oznacza od 20 do 32 tys. zł utraconego obrotu miesięcznie. W skali roku od 240 do 380 tys. zł. I jest to niewidoczne, bo nikt tego nie mierzy.
Co zmienia dobrze zrobione wyszukiwanie na żywo
Natychmiastowe podpowiedzi w trakcie pisania
Już od drugiego albo trzeciego znaku pod paskiem otwiera się okno z pasującymi produktami, ze zdjęciem, ceną i bezpośrednim odnośnikiem do karty. Odwiedzający klika od razu, bez przechodzenia przez stronę wyników. Liczba odsłon na jedno wyszukiwanie spada dwu- do trzykrotnie, a zysk konwersyjny jest znaczący.
Tolerancja dla literówek
Algorytm odległości Levenshteina albo równoważny: „Sambba” znajduje „Samba”, „Iphon” znajduje „iPhone”. W sklepie modowym sama ta korekta odzyskuje od 8 do 15 % wcześniej traconych wyszukiwań.
Inteligentne sortowanie
Wyniki uwzględniają kilka kryteriów: trafność tekstową, popularność (bestsellery), dostępność (najpierw na stanie), świeżość, cenę. Konfigurowalne zależnie od strategii handlowej (sklep premium kontra wyprzedaż zapasów).
Podpowiedzi uzupełniające
„Szukasz hasła sukienka?”, a dalej sugerowane kategorie (sukienki długie, sukienki krótkie, sukienki wieczorowe). Odwiedzający eksplorujący zostaje przekierowany do trafnych kategorii. Rośnie liczba kwalifikowanych odsłon.
Wbudowana analityka
Pulpit z top 20 wyszukiwań, zapytaniami bez wyników (czyli okazjami produktowymi do stworzenia), CTR per zapytanie, współczynnikiem konwersji po wyszukiwaniu i zmianą w czasie. Dane, na których da się działać, a nie kosmetyczne raportowanie.
Wydajność
Zoptymalizowane indeksowanie, zapytania poniżej 50 ms nawet przy ponad 100 000 produktów, leniwe ładowanie wyników, inteligentny cache. Płynność doświadczenia jest równie ważna co trafność wyników.
Nasz moduł dflivesearch: wyszukiwanie, które konwertuje
Wdrożenie tego stacku ręcznie wymaga od 15 do 25 dni pracy deweloperskiej: zoptymalizowany indeks, algorytm dopasowania z tolerancją dla literówek, interaktywny front, analityka. Nasz moduł dflivesearch dla PrestaShop 8 i 9 pakuje całość:
- Podpowiedzi w czasie rzeczywistym od drugiego znaku, ze zdjęciem produktu, ceną i stanem magazynowym.
- Tolerancja dla literówek konfigurowalna (akceptowana różnica 1 do 2 znaków).
- Inteligentne sortowanie według ważonej trafności (tekst plus popularność plus stan plus cena).
- Podpowiedzi kategorii i tagów obok samych produktów.
- Kompletna analityka: top zapytań, brak wyników, CTR, konwersja, zmiana w czasie.
- Zoptymalizowana wydajność: zapytania poniżej 50 ms do 100 000 produktów.
- Wielojęzyczność z obsługą per sklep w trybie multisklep.
- Zgodność z RODO: brak cookie śledzącego bez zgody.
- Bez wymaganego Elasticsearcha: działa na standardowym MySQL-u dla sklepów do 50 000 produktów.
Za 89 € zamieniasz najbardziej rentowny segment swojego ruchu w maszynę konwersji.
Trzy szybkie optymalizacje do zrobienia nawet bez modułu
Jeśli nie jesteś gotów instalować dedykowanego modułu, trzy darmowe optymalizacje pozwalają już odzyskać część potencjału:
- Oprzyrząduj wyszukiwania bez wyników. Włącz natywny log PrestaShop albo własny skrypt zapisujący zapytania bez dopasowania. Zidentyfikuj 20 najczęstszych zapytań bez wyników i albo utwórz odpowiadające produkty, albo dodaj synonimy i aliasy w module wyszukiwania.
- Skonfiguruj tagi i aliasy produktów. Natywny silnik PrestaShop obsługuje tagi. Staranne uzupełnienie tagów produktów (synonimy, warianty pisowni, skróty) poprawia trafność bez zmiany silnika.
- Wyeksponuj pasek wyszukiwania. W 30 % motywów pasek jest ukryty albo słabo widoczny. Uczynienie go wyraźnym, zwłaszcza na urządzeniach mobilnych, zwiększa jego użycie, a więc i konwertujący segment.
Te trzy działania są opłacalne nawet bez modułu. Nie zastąpią pełnego wyszukiwania na żywo, ale przygotowują grunt.
FAQ
Czy do dobrego wyszukiwania potrzebny jest Elasticsearch?
Nie, nie zawsze. Dla sklepów poniżej 50 000 produktów dobrze skonfigurowany indeks MySQL z inteligentnym modułem w zupełności wystarcza i daje wydajność poniżej 50 ms. Powyżej 100 000 produktów albo przy zaawansowanych potrzebach (dynamiczne filtry w czasie rzeczywistym) Elasticsearch staje się zasadny. Złożoność instalacji i utrzymania pozostaje kosztem do uwzględnienia.
Czy wyszukiwarka wpływa na SEO?
Pośrednio tak. Wyszukiwarka, która konwertuje, poprawia zaangażowanie (czas na stronie, liczba odsłon), co Google interpretuje jako sygnał jakości. A przechwycone zapytania wewnętrzne to kopalnia złota przy ustalaniu, które zapytania Google warto opracować: jeśli Twoi odwiedzający często wpisują „skórzane buty męskie”, to prawdopodobnie także zapytanie do celowania w SEO.
Jaka jest różnica między wyszukiwaniem na żywo a ulepszonym paskiem wyszukiwania?
„Wyszukiwanie na żywo” oznacza konkretnie natychmiastowe wyświetlanie wyników w trakcie pisania. „Ulepszony pasek wyszukiwania” może mieć samo autouzupełnianie, bez pokazywania wyników. Zysk konwersyjny bierze się głównie z wyświetlania wyników w czasie rzeczywistym, a nie z samych podpowiedzi tekstowych.
Jak obsłużyć zapytania wielowyrazowe?
Pułapka: „czerwona jedwabna sukienka” wymaga elastycznego łączenia. System ścisły (AND na wszystkich trzech słowach) często zwraca zero wyników. System luźny (OR) zwraca zbyt dużo szumu. Dobra praktyka: priorytetowe dopasowanie AND z awaryjnym OR o obniżonej punktacji. dflivesearch obsługuje tę logikę domyślnie.
Czy analityka wyszukiwarki stwarza problemy z RODO?
Nie, jeśli pozostaje zagregowana (ile razy wpisano zapytanie X, bez wiązania z możliwym do zidentyfikowania użytkownikiem). Jeśli krzyżujesz wyszukiwanie z identyfikatorem zalogowanego użytkownika, staje się to daną osobową wymagającą przetwarzania zgodnego z RODO. dflivesearch pozostaje domyślnie na poziomie zagregowanym.
Aby pójść dalej
Wyszukiwanie wewnętrzne to jedna z najsłabiej wykorzystywanych dźwigni lejka e-commerce. Zobacz także nasz materiał o anatomii karty produktu o wysokiej konwersji (gdzie wyszukiwarka jest głównym punktem wejścia segmentu transakcyjnego) oraz przewodnik po 12 dźwigniach konwersji w e-commerce. Trzy uzupełniające się ujęcia: przechwycić (wyszukiwarka), przekonać (karta produktu), domknąć (koszyk i checkout).
Aby przejść do działania: nasz wybór modułów do wyszukiwania i nawigacji.
