Van 2.863 producten naar 326 klantroutes: zo bouw je een product finder die verkoopt

Ik heb onlangs een product finder opgeleverd voor een Nederlandse premium grooming- en scheerwinkel. Toen ik met hun catalogus aan de slag ging, bleek die 2.863 producten te tellen, verspreid over 142 vendors en 165 producttypes. Wie wilde beginnen met klassiek nat scheren, kwam terecht op één collectiepagina met vijftig safety razors en geen enkele context: nergens stond welk scheermes mild was, welk geschikt voor een beginner en welk strikt bedoeld was voor ervaren gebruikers. Zo'n pagina is een ongesorteerde muur van producten en valt niet te navigeren. Hieronder staat hoe we die muur binnen een paar dagen omzetten in 326 vooraf uitgewerkte klantroutes, met 99,5% productdekking en 0 lege bladeren.

Het startpunt: 2.863 producten en 0 navigatie

Bij e-commerce shops boven de 500 SKU's zie je steeds hetzelfde patroon. De categorieën groeien, de filters groeien mee, maar het gemak voor de bezoeker niet. Een nieuwe bezoeker gaat echt niet 50 scheermesjes doorklikken. Die wil weten welk scheermes bij zijn huid en zijn ervaringsniveau past, en wil dat antwoord in twee of drie klikken. De shop had alle data om dat antwoord te geven, maar die zat in metafields: eigen productvelden die de winkel zelf invult en die pas op de site verschijnen als het thema ze uitleest. Dat deed het thema hier niet, dus voor de bezoeker bestonden ze niet.

In die 40 metafields zat alle data die de finder nodig had. Bij scheerkwasten waren de specs voor haartype, kleur en knoopdikte ingevuld. Bij geuren geurtype, seizoen en gelegenheid. Bij shampoos haartype met 14 verschillende waarden. Allemaal aanwezig in Shopify, niets ervan zichtbaar voor de bezoeker.

De aanpak: een beslisboom die elk product een plek geeft

De oplossing die we kozen is een klassieke beslisboom, alleen zorgvuldig opgebouwd. Vector search of een LLM die zelf productadvies samenstelt kwam er niet aan te pas. De bezoeker krijgt een vraag, kiest een antwoord en krijgt vervolgens een vervolgvraag of een resultaatpagina met de top drie producten. Elke uitkomst komt uit de eigen catalogus, dus er zitten geen verzonnen producten tussen en de pagina laadt gewoon snel. Het werk zit in de aanloop: een geautomatiseerde workflow die de boom bouwt en aan de live catalogus koppelt.

Het verschil met de oude situatie laat zich het makkelijkst naast elkaar zetten:

De boom heeft 9 hoofdtakken, één per categorie waar de shop sterk in is.

Branch                          Sub-questions     Leaves
--------------------------------------------------------
Shaving                              7              52
Beard care                           5              38
Hair styling                         6              44
Skin care                            8              71
Fragrances                           5              48
Oral care                            3              22
Grooming tools                       4              18
Lifestyle                            3              15
Gifts                                4              18
--------------------------------------------------------
Total                               45             326

Per subvraag zijn er tussen de 4 en 15 antwoorden mogelijk. Antwoorden zijn óf een volgende vraag óf een leaf node, het eindpunt van de boom waar producten direct via filters aan hangen. Dat levert 326 unieke paden op, en dus 326 unieke combinaties van klantintentie om te bedienen.

De uitvoering in 7 stappen

De volgorde was doordacht. Eerst data, dan structuur, dan filters, dan matching, dan gaten dichten, dan output. Sla een stap over en je krijgt een prachtig diagram zonder echte producten erachter.

1. Bouw de kennisbank

We haalden de hele Shopify-catalogus op via de GraphQL Admin API. Per product namen we alle metadata mee: titel, type, vendor, prijs, varianten, afbeeldingen, metafields en SEO-velden, allemaal in een lokale kennisbank. Eenmalig werk van een halve dag. Daarna staat alle productdata op één plek waar elke volgende stap op kan leunen.

2. Dimensieanalyse

Per producttype keken we welke metafields bestaan en welke daarvan relevant zijn voor de klant. Bij scheerkwasten was dat specs.type_haar, specs.kleur en specs.knoopdikte. Bij geuren custom.geurtype, custom.seizoen, custom.gelegenheid. Bij shampoos vooral custom.haartype. Niet elk veld komt in de boom terecht: alleen de velden waar een klant daadwerkelijk een vraag over zou stellen.

3. Ontwerp de boomstructuur

We stelden de hoofdtakken vast op basis van het zwaartepunt van de catalogus en het bezoekersgedrag. Per tak hanteren we een vraagvolgorde die van breed naar smal loopt: eerst "welk producttype", dan "voor welk type gebruiker", dan "in welk prijssegment". De leaf is altijd een filter dat een handvol producten teruggeeft.

4. Bouw filters die daadwerkelijk werken

De filteroperators die we uiteindelijk gebruikten:

• product_type, basisfilter
• vendor, merkfilter
• price_min en price_max, prijssegment
• title_contains, keyword match in productnaam
• metafield_value_contains, tekstmatch tegen metafield-waarde
• metafield_gid_match, exacte match op een Shopify Metaobject GID

Die laatste is de lastigste. Een metafield van het type metaobject-referentie bewaart geen tekst, maar een verwijzing naar een los metaobject: gid://shopify/Metaobject/307295715714. Het label "Droge huid" staat in dat metaobject en de API geeft standaard alleen de verwijzing terug. Je moet die GID's dus eerst omzetten naar hun labels, anders vergelijkt je filter een stuk tekst met een verwijzing en matcht er niets.

5. Match tegen de catalogus

Elk filter wordt uitgevoerd tegen alle 2.253 actieve producten. Output per leaf node: een lijst met gematchte producten en hun score. De score combineert afbeeldingskwaliteit, lengte van de omschrijving, aanwezigheid van metafields en of de prijs in een logische bandbreedte valt voor die categorie. De top drie op score krijgt de klant te zien op de resultaatpagina.

6. Gap-analyse

De eerste run van de boom leverde 26 lege bladeren op, paden waar 0 producten uitkwamen. Precies wat je in deze fase wilt: elk leeg blad vertelt je iets. De diagnose, uitgesplitst naar oorzaak:

• 11 waren filterbugs: een typefout in een vendornaam (een merk dat in het filter als "Salt and Stone" was opgeslagen, terwijl Shopify "Salt & Stone" had), of een producttype met een spelfout
• 8 waren GID-mappingproblemen: het filter zocht op een label, terwijl Shopify een GID had opgeslagen
• 7 waren echte catalogusgaten: een vendor was uitverkocht, of een subcategorie had geen passend product op voorraad

De 11 en de 8 oplossen kost een middagje werk. De 7 echte gaten gaan terug naar de klant als signaal: "deze intenties zijn de moeite waard om te dekken, hier zit een gat in je assortiment." Dat op zich is al een commercieel inzicht dat uit het project rolt. Na alle fixes: 0 lege bladeren, 99,5% productdekking.

7. Genereer drie outputs

Aan het eind van het proces liggen er drie bestanden klaar, elk met een ander gebruik verderop in de keten.

1. tree.json: 64 nodes, 326 leaves, klaar voor de finder frontend
2. chatbot_qa.json: 326 vraag-antwoordparen, klaar als kennisbasis waar een AI-chatagent zijn antwoorden uit ophaalt (in het vak: een RAG-corpus)
3. seo_landing_pages.json: 326 landingspagina-specificaties, elk met slug, H1, meta description, breadcrumb en top drie producten

Waar we tegenaan liepen: 26 lege bladeren en hoe we ze oplosten

De gap-analysefase bepaalt of een product finder project standhoudt of uit elkaar valt. Iedereen kan een boom schetsen op papier. De vraag is of er bij elk eindpunt echte producten hangen. Een illustratief voorbeeld: het blad "safety_mild", bedoeld voor mensen die beginnen met klassiek nat scheren en een gevoelige huid.

{
  "id": "safety_mild",
  "label": "Mild for sensitive skin",
  "filter": {
    "product_type": ["Safety razor"],
    "title_contains": ["R89", "Mild", "Companion"],
    "exclude_title": ["R41"]
  },
  "product_count": 4,
  "top_3": [
    {"title": "Safety Razor R89", "vendor": "Mühle", "price": 34.95},
    {"title": "Safety Razor AL13 - Mild", "vendor": "Henson Shaving", "price": 89.95},
    {"title": "Safety Razor Companion", "vendor": "Mühle", "price": 38.95}
  ]
}

Niets ingewikkelds. Een filter dat zegt "producttype Safety razor, alleen titels die R89, Mild of Companion bevatten, en sluit expliciet R41 uit want R41 heeft een agressieve bladafstand." De waarde zit in twee dingen: het filter is afgeleid van de daadwerkelijke catalogusstatus van die week, en de uitsluiting (R41) is afgeleid van het gesprek met de klant over wat een beginner echt niet wil. Geen scraping of giswerk: iemand met kennis van de catalogus stelt de regel vast en de boom voert hem uit.

De drie outputs en wat ze opleveren

De klant ziet op de site de interactieve finder-UI: drie klikken naar drie producten. Bij de andere twee outputs zit vaak de echte meerwaarde.

De chatbot-Q&A-paren

Voorbeeld van een Q&A-paar dat we rechtstreeks doorgaven aan een chatagent:

Q: How do you prefer to shave? With a safety razor (DE), Mild for sensitive skin
A: Based on what you said, I recommend:
   1. Safety Razor R89 by Mühle (€34.95)
   2. Safety Razor AL13 - Mild by Henson Shaving (€89.95)
   3. Safety Razor Companion by Mühle (€38.95)

Een AI-agent die dit corpus als basis gebruikt, koppelt een vrij geformuleerde vraag aan een leaf node en antwoordt met aanbevelingen die verankerd zijn in echte SKU's tegen echte prijzen. Voorwaarde is wel dat het corpus meeloopt met de catalogus. Ververs je het niet, dan noemt de agent na verloop van tijd producten en prijzen die niet meer kloppen. Dat is de lat die je moet halen voordat je een AI-assistent op een live shop zet.

De SEO-landingspagina's

326 pagina's gericht op long-tail intentie. Slugs zoals /product-finder/shaving-brush-sensitive-skin, /product-finder/anti-aging-cream-oily-skin, /product-finder/fragrance-summer-fresh. Elke pagina toont de top drie producten plus de relevante categoriecollectie als secundaire navigatie. Intern doorgelinkt, zodat linkwaarde die op één pagina landt ook de rest van het netwerk versterkt.

De finder zelf

Inbedbare widget op de site, of een volledige pagina op /finder. De klant kiest. Eén vraag per node, alleen de relevante antwoorden getoond. De resultaatpagina toont de top drie plus een optie "toon alle 12 matches" voor de nieuwsgierigen.

De cijfers en wat ze waard zijn

Eerlijk verhaal over wat dit betekent voor conversie: ik heb geen A/B-test naast de bouw gedraaid, dus ik ga je geen percentage voorschotelen. Het gangbare beeld in e-commerce is dat een korte keuzelijst in de laatste stap beter werkt dan een lange, simpelweg omdat de bezoeker minder hoeft af te wegen. Iemand die in 2 of 3 klikken op drie passende producten uitkomt, haakt minder snel af dan iemand die zelf door 200 SKU's moet ploeteren. Hoe groot dat verschil is, hangt af van het assortiment en is hier niet gemeten.

Voor SEO is het verhaal concreter, al hoort daar een eerlijke kanttekening bij. 326 nieuwe long-tail landingspagina's, elk gericht op een intentie waarvoor de hoofdcategoriepagina niet rankt. Reken er alleen niet op dat alle 326 gaan scoren: Google is streng op dunne, bijna identieke pagina's, dus de winst zit in de paden waar een echte zoekvraag achter zit en die voldoende eigen inhoud meekrijgen. Zo bekeken is het een eenmalige contentinvestering die jaren kan renderen zolang de catalogus actueel blijft. Voor de chatbot geldt dat hij pas bruikbaar wordt als zijn antwoorden uit echte producten en prijzen komen, in plaats van uit een generieke LLM die zelf iets samenstelt.

Er speelt nog iets, en dat wordt voor Nederlandse webshops steeds zichtbaarder. AI Overviews, ChatGPT Search en Perplexity beantwoorden productvragen steeds vaker zonder dat de bezoeker nog doorklikt naar een shop. Minder klikken op de klassieke posities, meer antwoorden die direct in de zoekomgeving verschijnen. Juist dan telt of jouw advieskennis ergens als gestructureerde data klaarstaat. Een corpus van 326 vraag-antwoordparen met echte SKU's en echte prijzen is bruikbaar materiaal voor zulke systemen, maar alleen als het ook echt gepubliceerd staat, als pagina's met leesbare tekst en productgegevens. Een JSON-bestand op je eigen server komt daar nooit terecht. Garanties zijn er niet, maar mijn inschatting is dat shops die hun advieskennis zo vastleggen beter zichtbaar worden in AI-antwoorden dan shops met alleen kale collectiepagina's.

Wat dit zou betekenen voor jouw shop

Dit project werkte omdat de klant al een catalogus had met een solide metafield-structuur. Dat is niet vanzelfsprekend. Het realistische beeld bij veel Nederlandse webshops is dat de productdata het knelpunt is, niet de techniek: metafields zijn leeg, inconsistent ingevuld of bestaan alleen voor de bestsellers. In dat geval kost stap 2 (dimensieanalyse) een week langer, omdat je eerst een metafield-template moet uitrollen en de bestaande producten moet verrijken. Dat is te doen, maar het is werk. Hoe schoner je catalogus, hoe sneller dit gaat.

De realistische eerste stap is dan ook niet "bouw een finder", maar de dimensieanalyse uit stap 2, beperkt tot je twee of drie belangrijkste categorieën. Die analyse vertelt je of je productdata een boom kan dragen, waar de gaten zitten en of het assortiment genoeg te kiezen geeft om vragen zinvol te maken. Pas daarna beslis je of de volledige boom de investering waard is.

Ik doe dit soort werk voor e-commerce klanten van wie de catalogus is gegroeid zonder dat de winkelervaring is meegegroeid. Heb je 500+ producten en loop je tegen conversie- of vindbaarheidsproblemen aan, stuur me een bericht en dan kijken we samen of een product finder voor jouw shop kan doen wat het hier deed. Mail info@jermayads.nl of gebruik jermayads.nl/contact.