Hoe je filters en productattributen opzet

Filters zijn het verschil tussen een klant die door je collectiepagina bladert en een klant die een plant vindt die hij ook echt wil kopen. Het is ook een van de meest onderbenutte features in plantenwebshops — de meeste resellers slaan filters oföf helemaal over (waardoor klanten door 60 producten moeten scrollen) óf plakken er een default-filterset op zonder na te denken over wat eronder zit. De filter-UI op de pagina is maar de zichtbare helft. Het echte werk is de data-discipline die het voedt.

Filters en attributen — twee kanten van dezelfde data

Voor alles: snap de relatie. Een attribuut (soms property, spec of metafield genoemd) is een stuk gestructureerde data op een product — lichtbehoefte, potmaat, diervriendelijkheid. Een filter is de UI waarmee een klant een collectiepagina kan versmallen op basis van die attributen.

Dat betekent dat filters en attributen dezelfde data zijn, vanuit twee kanten bekeken:

• Vanuit de back-end (jouw perspectief bij het bouwen van de catalogus) is het een attribuut op een product.

• Vanuit de front-end (het perspectief van de klant op een collectiepagina) is het een filter-checkbox.

Elk filter dat je wilt aanbieden vereist een schoon, gevuld attribuut op elk product in scope. Daarom kan de filterdiscussie niet los gezien worden van de spec-discussie: zie productspecificaties voor de onderliggende spec-template.

Starterset: maximaal 5–7 filters

De meeste plantenwebshops zouden moeten draaien met niet meer dan 5–7 filters per collectiepagina. Daarboven stoppen klanten met scannen en gaan ze het filterpaneel negeren. De starterset die voor bijna elke plantenwebshop werkt:

1. Verzorgingsniveau (Makkelijk / Gemiddeld / Gevorderd) — het meestgebruikte filter. Klanten identificeren zichzelf op ervaring en willen planten die matchen.

2. Lichtbehoefte (Helder direct / Helder indirect / Gemiddeld / Weinig) — op twee na meestgebruikt. Gedreven door de kamer waarvoor ze shoppen.

3. Diervriendelijk (Ja / Nee) — binair. Hoog emotioneel gewicht; kattenbezitters gebruiken het religieus.

4. Potmaat (Ø in cm: 6, 9, 12, 17, 21, 24+) — gedreven door waar de plant heen gaat.

5. Planthoogte bij levering (Tot 30cm / 30–60cm / 60–100cm / 100cm+) — onderscheiden van potmaat; vertelt de klant hoe volgroeid de plant aankomt.

6. Prijsrange (slider of buckets) — elke shop, elke collectie.

7. Optionele 7e: hangt af van de collectie. Op Buitenplanten — Winterhardheid of Volle zon / Schaduw. Op Cadeaus — Gelegenheid of Ontvanger. Op Kamerplanten — Luchtzuiverend.

Alles daarboven is filter-rommel. Weersta de drang om elk attribuut in je database te exposen — de meeste attributen horen op de productpagina (specs), niet in het filterpaneel.

Wanneer iets een attribuut is en wanneer ook een filter

Een nuttige test voor elk kandidaat-filter:

• Zou een klant erop zoeken? "Diervriendelijk" — ja. "Inkoopcode" — nee. Het eerste is een filter; het tweede is interne data.

• Zijn er 3+ producten aan elke kant van het filter? Een filter dat 1 product oplevert is kapot. Matcht "Potmaat 6cm" maar 2 producten, dan is dat een spec voor de PDP, geen filter om te exposen.

• Is de data discreet en consistent? "Licht: helder indirect" werkt als filter (4 discrete buckets). "Dagelijkse wateropname in ml" werkt niet (continu, wisselt per seizoen).

Concrete voorbeelden van plantenattributen die goed filteren:

• Lichtbehoefte (4 discrete buckets)

• Diervriendelijkheid (binair)

• Potdiameter (5–7 standaardmaten)

• Verzorgingsniveau (3 buckets)

• Volgroeide hoogte (4 buckets)

• Luchtzuiverend (binair)

• Nu bloeiend (binair)

En attributen die niet goed filteren — die horen alleen als specs op de PDP:

• Latijnse soortnaam (te fijnmazig, klant filtert er niet op)

• Watergeef-frequentie in dagen (wisselt per seizoen, geen stabiele filterwaarde)

• Land van herkomst (interessant, geen koopbeslissing)

• Botanische familie (relevant voor liefhebbers, niet voor eerste-keer-kopers)

Het empty-state-probleem

Hier vallen filters in productie om. Een klant past drie filters toe — "Diervriendelijk + Weinig licht + Onder €30" — en de pagina geeft nul resultaten. De standaardbehandeling is een platte "Geen resultaten gevonden"-melding, die de klant naar een concurrent stuurt.

Wat je in plaats daarvan doet:

• Stel de dichtstbijzijnde match voor: "0 resultaten voor deze filters. Verwijder 'Onder €30' om 7 planten te zien die aan je andere criteria voldoen."

• Identificeer het meest beperkende filter automatisch en stel voor om dat specifiek te versoepelen. De meeste filter-apps (Shopify Search & Discovery, WooCommerce filter-plugins als FacetWP) ondersteunen dit met configuratie.

• Toon "alternatieve collecties": "Bekijk alle diervriendelijke planten" / "Bekijk weinig-licht-planten" — geef de klant een uitweg, geen doodlopende weg.

Dit is een filterfeature waar de implementatie-inspanning klein is en de conversie-impact groot. Zet geen filters live zonder empty-state-plan.

Single-select vs. multi-select

Beslis per attribuut of de klant één waarde of meerdere kan kiezen:

• Single-select voor hiërarchische of wederzijds uitsluitende attributen. Verzorgingsniveau: je bent beginner of niet. Potmaat: je shopt voor één specifieke maat.

• Multi-select voor parallelle opties. Licht: een klant met meerdere kamers wil planten voor "Helder indirect" ÉN "Gemiddeld". Diervriendelijk: meestal binair, maar als je splitst in Kat-veilig en Hond-veilig, sta beide toe.

Een redelijke default voor een plantenwebshop:

• Multi-select: Licht, Potmaat, Planthoogte, Verzorgingsniveau

• Single-select: Diervriendelijk (binair), Prijsrange

Data-discipline — hier leven of sterven filters

Het lastigste aan filters is niet de UI — het is het schoon houden van de onderliggende attributen over honderden producten. Een paar niet-onderhandelbare regels:

• Elk product in scope moet een waarde hebben voor elk filter-attribuut. Geldt je "Diervriendelijk"-filter voor alle kamerplanten, dan heeft elke kamerplant Ja of Nee nodig — geen ontbrekende waarde. Ontbrekende data sluit producten stilletjes uit van filterresultaten.

• Gebruik dezelfde waarden-vocabulaire over producten. "Helder indirect" en "Indirect helder licht" zijn voor een mens hetzelfde en voor een filter verschillend. Standaardiseer naar één formulering per spec, schrijf het op als je interne taxonomie.

• Normaliseer eenheden. Potmaat komt soms binnen van leveranciers in cm, soms in inches, soms als litervolume. Converteer naar één eenheid (cm diameter) voor filters. Toon de bron-data in de spec-tabel op de PDP als je wilt, maar de filterwaarde is genormaliseerd.

• Audit voor elk seizoen. Als je nieuwe lente- of herfstproducten toevoegt, draai een snelle "missend attribuut"-rapport en vul de gaten voor ze live gaan. De Everspring-catalogus levert je de bron-data; de filter-mapping is van jou.

Waar filters op de pagina staan

Een aparte maar verwante beslissing: waar op de collectiepagina staat de filter-UI?

• Desktop: linker sidebar is de default en werkt. Filters zijn persistent, klant kan aanpassen zonder context te verliezen.

• Desktop: top filter-balk (boven het grid) werkt voor shops met 3–4 filters. Visueel schoner, minder schermruimte, maar valt om zodra je een 5e filter toevoegt.

• Mobile: bottom-sheet drawer. Vastgepinde onder-knop "Filter (3)" opent een drawer over het grid. Probeer geen inline filters boven het grid op mobile — verspilt scroll, klant kan producten niet zien tijdens filteren.

Filters vs. on-site search

Eén laatste ding dat het waard is om te zeggen: filters en zoeken overlappen, maar zijn niet hetzelfde tool. Filters versmallen een collectiepagina waar de klant op is geland; zoeken start vanuit een query. Een klant die weet dat hij "Calathea Orbifolia" wil gebruikt zoeken. Een klant die "een weinig-licht-plant voor de badkamer" wil gebruikt filters op de Kamerplanten-collectie. Allebei moeten werken. Lees hoe je je on-site zoekbalk opzet voor de zoek-kant van deze vergelijking.

Wat je morgen kunt doen

Open de filter-instellingen van je shop (Shopify: Online Store → Navigation → Filters of via Search & Discovery; WooCommerce: native widget of FacetWP / WooCommerce Product Filter-plugin). Lijst elk actief filter. Vraag voor elk: heeft elk product in deze collectie een schone, genormaliseerde waarde voor dit attribuut? Zo ja, behouden. Bij minder dan 95% dekking, vul de data of haal het filter weg. Check daarna je starterset tegen de 5–7 hierboven — voeg toe wat ontbreekt, schrap wat nooit gebruikt wordt (kijk naar filter-analytics als je platform die ontsluit). Test ten slotte het empty-state-gedrag door bewust een 0-resultaat-combinatie te kiezen — geeft je shop een platte "Geen resultaten gevonden", configureer dan een versoepelings-suggestie of een fallback naar een gerelateerde collectie. Ga dan door naar on-site search, die de queries vangt die filters niet kunnen.