Filtry produktów w PrestaShop: dlaczego liczba obok filtra nie zawsze się zgadza

Problem, którego nikt nie zgłasza, ale który zauważają wszyscy

Na stronie kategorii klient zaznacza filtr z napisem „Czerwony (12)”, oczekuje 12 produktów, a lista pokazuje 8 albo 15. Żadnego komunikatu o błędzie, żadnego wyjaśnienia, tylko liczba, która się nie zgadza. To nie jest kosmetyczny drobiazg. To rodzaj niespójności, który w pół sekundy niszczy zaufanie do reszty serwisu: skoro filtr kłamie w małej, dobrze widocznej liczbie, dlaczego miałoby się ufać cenie czy dostępności?

Ten problem jest tak częsty w filtrach fasetowych (tych, które wyświetlają razem kilka kategorii filtrów, każdą z własnym zliczaniem) nie z powodu niedbalstwa. Obliczenie tej liczby tak, by zawsze zgadzała się z kliknięciem, jest trudniejsze, niż się wydaje, i to jeden z punktów, w których wyszukiwarki fasetowe naprawdę różnią się między sobą.

Dlaczego zliczanie może zaprzeczać kliknięciu

Najczęstszą przyczyną jest to, że zliczanie i kliknięcie są obliczane według dwóch różnych logik. Typowy przypadek: właściciel sklepu grupuje kilka zbliżonych wartości pod jedną etykietą (na przykład „Czerwony” dla wariantów Karmazynowy, Szkarłatny i Bordowy z katalogu). Jeśli zliczanie sumuje liczbę wystąpień każdego wariantu, a kliknięcie stosuje warunek „musi mieć wszystkie te warianty naraz” zamiast „musi mieć co najmniej jeden z tych wariantów”, to wyświetlona liczba i liczba uzyskana odpowiadają na dwa różne pytania. Zasada, która zapewnia spójność, jest prosta do sformułowania i łatwa do złamania w kodzie: zliczanie musi odpowiadać dokładnie na to samo pytanie, które zastosuje kliknięcie, a nie na pytanie podobne.

Poprawny sposób rozwiązania, sprawdzony na kilku wyszukiwarkach (natywny sterownik PrestaShop i Elasticsearch), polega na tym, by od początku traktować grupę wartości jako jeden zbiór: zliczanie staje się pojedynczym „policz różne produkty, które mają co najmniej jedną z tych wartości” (COUNT(DISTINCT ...) w bazie danych albo dedykowana agregacja w silniku takim jak Elasticsearch), a kliknięcie stosuje dokładnie ten sam warunek. Wyświetlana liczba przestaje być sumą, która może obiecywać za dużo, i staje się rzeczywistą sumą mnogościową, taką samą, jaką daje kliknięcie.

Warto też znać uczciwy wybór projektowy: w Meilisearch, dla wartości zgrupowanych, liczba obok filtra po prostu nie jest wyświetlana, zamiast ryzykować wyświetlenie błędnej. To decyzja projektowa, zadeklarowana w panelu ustawień właściciela sklepu, a nie ukryte ograniczenie. Jeśli chodzi o zaufanie, filtr bez liczby jest zawsze lepszy niż filtr z błędną liczbą.

Koszt zawsze poprawnej liczby

Nawet gdy logika jest poprawna, obliczanie dokładnego zliczania dla każdej wartości każdego filtra ma realny koszt, który bardzo zależy od używanej wyszukiwarki. W zewnętrznym silniku, takim jak Elasticsearch czy Meilisearch, zliczenia przychodzą z tym samym zapytaniem, które oblicza wyniki, więc dodatkowy koszt jest minimalny. W natywnym silniku PrestaShop, który pracuje w bazie danych sklepu, każda wartość każdego filtra może wymagać własnego zapytania zliczającego.

W katalogu liczącym 200 000 produktów, z około 2 250 grup atrybutów i cech, wyłączenie dokładnego zliczania w filtrach (wyświetlanie listy dostępnych wartości bez liczby obok) skróciło czas strony kategorii z jednym aktywnym filtrem z 43,3 sekundy do 11,9 sekundy, a dla samych faset cech i atrybutów z 6,8 i 5,4 sekundy odpowiednio do 15 i 19 milisekund. Te liczby opowiadają prostą historię: ta mała liczba w nawiasie, w dużym katalogu i przy silniku ograniczonym do bazy danych, może kosztować więcej niż cała reszta strony razem wzięta.

Co robić w praktyce

• W katalogu liczącym kilka tysięcy produktów dokładne zliczanie prawie zawsze jest warte swojego kosztu: warto je zachować.
• W dużym katalogu przy samym natywnym silniku warto zastanowić się, czy nie wyłączyć dokładnego zliczania (wyświetlając tylko listę dostępnych wartości), czy raczej przejść na zewnętrzny silnik, który oblicza je bez dodatkowego kosztu.
• Jeśli używają Państwo filtrów z wartościami zgrupowanymi (kilka wariantów pod jedną etykietą), proszę wyraźnie zapytać, jak są obsługiwane, gdy „wszystkie filtry muszą pasować jednocześnie” (tryb I): to przypadek, w którym suma i suma mnogościowa różnią się najbardziej, i to właśnie ten, który klient zauważa jako pierwszy.
• Zawsze lepiej wybrać filtr, który nie wyświetla żadnej liczby, niż filtr, który wyświetla błędną. Jeśli moduł wyszukiwarki nie może zapewnić dokładnego zliczania w danej sytuacji, właściwym wyborem jest jego ukrycie, a nie zgadywanie.

Podsumowanie

Błędna liczba obok filtra nie jest drobiazgiem graficznym: to znak, że zliczanie i kliknięcie odpowiadają na dwa różne pytania, a w dużym katalogu, przy nieodpowiedniej wyszukiwarce, może to być także najkosztowniejsza część strony. W cll_essearch rozwiązaliśmy ten problem u źródła, jednym wspólnym obliczeniem dla zliczania i dla kliknięcia, w natywnym sterowniku, Elasticsearch, OpenSearch i Meilisearch, oraz z możliwością wyłączenia zliczania, gdy katalog jest zbyt duży, by opłacało się obliczać je na żywo. Jeśli klient kiedykolwiek napisał do Państwa: „filtr mówił jedno, a potem niczego nie znalazłem”, prawdopodobnie jest to właśnie ten problem.

Wyszukiwarka Elasticsearch i nawigacja fasetowaBłyskawiczne wyszukiwanie z tolerancją literówek i nowoczesna nawigacja fasetowa we wbudowanym silniku lub w o…99,99 €Zobacz produkt