Productfilters in PrestaShop: waarom het cijfer naast het filter niet altijd klopt

Het probleem dat niemand meldt, maar iedereen opmerkt

Op een categoriepagina vinkt een klant een filter aan met “Rood (12)”, verwacht 12 producten, en de lijst toont er 8, of 15. Geen foutmelding, geen uitleg, alleen een cijfer dat niet klopt. Dat is geen cosmetisch detail. Het is het soort inconsistentie dat in een halve seconde het vertrouwen in de rest van de site vernietigt: als het filter liegt over een klein, goed zichtbaar cijfer, waarom zou de klant dan de prijs of de beschikbaarheid vertrouwen?

Dat dit probleem zo vaak voorkomt bij gefacetteerde filters (die waarbij meerdere filtercategorieën tegelijk worden getoond, elk met een telling), komt niet door nalatigheid. Het komt doordat het lastiger is dan het lijkt om dit cijfer altijd overeen te laten komen met de klik, en dit is een van de punten waarop gefacetteerde zoekmotoren echt van elkaar verschillen.

Waarom een telling de klik kan tegenspreken

De meest voorkomende oorzaak is dat de telling en de klik met twee verschillende logica's worden berekend. Een typisch geval: de webwinkelier voegt meerdere verwante waarden samen onder één label (bijvoorbeeld “Rood” voor de varianten Karmozijn, Scharlaken en Bordeaux uit de catalogus). Als de telling het aantal voorkomens van elke variant optelt, terwijl de klik “moet al deze varianten tegelijk hebben” toepast in plaats van “moet minstens één van deze varianten hebben”, beantwoorden het getoonde cijfer en het verkregen cijfer twee verschillende vragen. De regel die alles consistent houdt, is eenvoudig te formuleren en gemakkelijk te breken in de code: de telling moet precies dezelfde vraag beantwoorden als de klik zal toepassen, niet een verwante vraag.

Een goede manier om dit op te lossen, getest op meerdere zoekmotoren (de eigen driver van PrestaShop en Elasticsearch), is een groep waarden vanaf het begin als één enkele verzameling te behandelen: de telling wordt één enkele opdracht “tel de unieke producten die minstens één van deze waarden hebben” (een COUNT(DISTINCT ...) in de database, of een speciale aggregatie in een zoekmotor zoals Elasticsearch), en de klik past exact dezelfde voorwaarde toe. Het getoonde cijfer is dan geen som meer die te veel kan beloven, maar de werkelijke vereniging, precies die welke de klik oplevert.

Er is ook een eerlijke keuze die goed is om te kennen: bij Meilisearch wordt voor samengevoegde waarden het cijfer naast het filter simpelweg niet getoond, in plaats van het risico te nemen een onjuist cijfer te tonen. Dat is een ontwerpbeslissing die in het instellingenpaneel van de webwinkelier wordt vermeld, geen verborgen beperking. Voor het vertrouwen is een filter zonder cijfer altijd beter dan een filter met een onjuist cijfer.

De kosten van een altijd juist cijfer

Ook als de logica klopt, heeft het berekenen van een exacte telling voor elke waarde van elk filter echte kosten, die sterk afhangen van de gebruikte zoekmotor. Met een externe zoekmotor zoals Elasticsearch of Meilisearch komen de tellingen mee met dezelfde query die de resultaten berekent, dus de extra kosten zijn minimaal. Met de eigen zoekmotor van PrestaShop, die in de database van de webwinkel werkt, kan elke waarde van elk filter een eigen telquery nodig hebben.

Op een catalogus van 200.000 producten met ongeveer 2.250 groepen attributen en kenmerken bracht het uitschakelen van het exacte tellen van de filters (de lijst met beschikbare waarden tonen zonder het cijfer ernaast) een categoriepagina met één actief filter terug van 43,3 seconden naar 11,9 seconden, en alleen voor de facetten van kenmerken en attributen van respectievelijk 6,8 en 5,4 seconden naar 15 en 19 milliseconden. Deze cijfers vertellen een eenvoudig verhaal: dit kleine getal tussen haakjes kan op een grote catalogus met een zoekmotor die beperkt is tot de database meer kosten dan de rest van de pagina bij elkaar.

Wat u concreet kunt doen

• Op een catalogus van enkele duizenden producten zijn exacte tellingen bijna altijd hun kosten waard: houd ze.
• Vraag u op een grote catalogus met alleen de eigen zoekmotor af of u de exacte tellingen moet uitschakelen (door alleen de lijst met beschikbare waarden te tonen) of moet overstappen op een externe zoekmotor die ze zonder extra kosten berekent.
• Gebruikt u filters met samengevoegde waarden (meerdere varianten onder één label), vraag dan expliciet hoe die worden behandeld wanneer “alle filters tegelijk moeten overeenkomen” (EN-modus): dat is het geval waarin som en vereniging het meest uiteenlopen, en het is het geval dat een klant als eerste opmerkt.
• Geef altijd de voorkeur aan een filter dat geen cijfer toont boven een filter dat een onjuist cijfer toont. Als een zoekmodule in een bepaalde situatie geen exacte telling kan leveren, is de juiste keuze die te verbergen, niet te raden.

Samengevat

Een onjuist cijfer naast een filter is geen grafisch detail: het is het teken dat de telling en de klik twee verschillende vragen beantwoorden, en op een grote catalogus met de verkeerde zoekmotor kan het ook het duurste deel van de pagina zijn. In cll_essearch hebben wij dit probleem bij de wortel aangepakt, met één enkele berekening die door de telling en door de klik wordt gedeeld, op de eigen driver, Elasticsearch, OpenSearch en Meilisearch, en met de mogelijkheid de tellingen uit te schakelen wanneer de catalogus te groot is om ze in realtime te berekenen. Heeft een klant u ooit geschreven “het filter zei het ene en daarna vond ik niets”, dan is dit waarschijnlijk het probleem dat u hebt.

Elasticsearch-zoekfunctie & gefacetteerde navigatieRazendsnelle zoekfunctie met typfouttolerantie en moderne gefacetteerde navigatie in een venster, met de…€ 99,99Bekijk product