Complete opzet voor een wekelijkse Google Sheet + Claude project die per EAN je bol-conversie vergelijkt met het categorie-benchmark en koppelt aan je eigen listing-wijzigingen. Werkt handmatig tot 50 EANs, daarboven wil je automatiseren.
8 hoofdstukken, setup in 3 tot 4 uur · 13 min lezen · voor bol-verkopers met 50+ actieve EANs en een marketplace- of contentmanager
Je marketplacemanager kijkt nu ad-hoc naar bol-dashboards. Een conversie-dip zie je pas als de omzet 2 tot 3 weken zakt. Dan is de oorzaak (een titel-wijziging van 4 weken terug, een prijsdaling van een concurrent, een cluster negatieve reviews) al weggezakt in de tijdlijn en niet meer te reconstrueren.
Dit document geeft je de exacte opzet die ik voor drie bol-klanten heb neergezet. Bij één daarvan (huishoudelijk, 340 EANs) ving hij in kwartaal 2 een dip op van 4,1% naar 2,7% conversie op een EAN die 18% van de weekomzet draait. Oorzaak: een titel-verkorting die bol zelf doorvoerde na een categoriewissel. Binnen 48 uur teruggezet, dip binnen een week hersteld.
Je hebt drie dingen nodig. Een Google Sheet. Een Claude project (gratis versie is voldoende tot 50 EANs). En toegang tot de assortiment-analyse in je bol-dashboard. Geen API-koppeling, geen scraper.
Tot ongeveer 50 EANs is dit prima handmatig te draaien. Vanaf 50 EANs moet je het automatiseren, anders slaan mensen weken over. Daar kom ik in hoofdstuk 8 op terug.
Bol geeft je de conversie per EAN al kant en klaar in de assortiment-analyse. Je hoeft dus niet zelf orders door bezoekers te delen. Wat je wel zelf moet doen: dit percentage naast twee andere dingen leggen.
Ten eerste naast de conversie-benchmark van bol zelf. Dat cijfer krijg je in dezelfde export mee en is het gemiddelde van de categorie waar jouw EAN in valt. Dat is de eerlijkste vergelijking, want die corrigeert voor seizoen en categorie-drukte.
Ten tweede naast je eigen listing-wijzigingen. Elke keer dat jij of je team een titel, prijs of foto aanpast, log je dat. Zo kun je 3 weken later in dezelfde Sheet zien of de conversie is gestegen of gedaald sinds die wijziging. Dat is het verschil tussen "we passen wat aan en hopen" en "we weten wat werkt".
Niet doen: kijken naar het shopgemiddelde. Dat cijfer verbergt precies de dips die je wil zien. Een EAN kan van 5% naar 2% zakken terwijl je shopgemiddelde stabiel op 3,4% blijft, omdat een andere EAN toevallig omhoog gaat.
Waarom wekelijks en niet dagelijks: bol-bezoekers per EAN zijn onder de 200 per dag vaak te ruisig. Onder de 50 bezoekers per week negeer je de EAN sowieso in de monitor. Boven de 200 bezoekers per week is de conversie statistisch bruikbaar, met een marge van ongeveer plus of min 1 procentpunt.
Voorbeeld uit mijn eigen dashboard (EAN 8710103952565, week 22):
In je bol-verkoopaccount ga je naar Analyse, dan Assortiment-analyse. Kies periode: laatste week (maandag tot en met zondag).
Zet in de kolomkiezer aan:
Download als CSV. Sla het bestand op als bol_export_week[nummer].csv. Bijvoorbeeld bol_export_week22.csv.
Nu de Claude-stap, en hier is het belangrijk dat je dit in een Claude project doet, niet in een losse chat. Waarom: een project onthoudt de instructies en de historische snapshots tussen weken door. Je hoeft dus niet elke maandag opnieuw uit te leggen wat je wilt.
Zo zet je het project op:
Bol Conversie Monitor.Ik lever wekelijks een CSV uit de bol assortiment-analyse.
Kolommen: EAN, bezoekers, orders, omzet, conversie_pct,
conversie_benchmark_pct, periode.
Jij:
1. Normaliseert EANs naar 13-cijferige tekst (leading zeros behouden)
2. Sluit EANs met minder dan 50 bezoekers uit en zet ze in een aparte lijst
3. Berekent per EAN: verschil_vs_benchmark_pp = conversie_pct
minus conversie_benchmark_pct
4. Vergelijkt met de vorige week (uit de bijgevoegde 'ruwe_data' file)
en flagt EANs met een daling van 20% of meer
5. Geeft output als tab-separated tabel, klaar om in Sheets te plakken
ruwe_data tab (zie hoofdstuk 5). Ververs dit bestand elke week na je update.Nieuwe week, hier is de CSV: en plak de CSV.De output plak je in je Sheet, tabblad ruwe_data. Duurt maximaal 4 minuten per week.
Waarom Claude en niet een formule in de Sheet: je bol-export heeft irritante inconsistenties (EAN soms als tekst, soms als getal, soms met een leading zero die eruit valt, benchmark-kolom leeg bij nieuwe EANs). Claude normaliseert dat in één keer. Dit heb ik met een IMPORTDATA-formule geprobeerd en na 3 weken gaf ik het op door parsing-fouten.
Elke maandag leg je per EAN 6 velden vast. Meer wordt te veel handmatig werk, minder is te weinig om de oorzaak van een dip te vinden.
De 6 velden:
Voor de image hash: je hoeft geen echte hash uit te rekenen. Werkbaar alternatief: kopieer de image-URL uit de bol-productpagina (rechtermuisknop, kopieer afbeeldingsadres). Bol gebruikt in de URL een tekenreeks die verandert zodra de main image verandert.
https://media.s-bol.com/wZ4gPjMKpVAB/x8L1qWv/544x680.jpg
^^^^^^^^^^^^^ deze verandert bij nieuwe image
Sla dat middenstuk op. Dat is je "hash".
Voor 50 EANs kost het snapshotten ongeveer 25 minuten als je een tweede persoon hebt en de productpagina-tabbladen naast elkaar zet. Automatiseren met een scraper werkt niet betrouwbaar: bol blokkeert die na ongeveer 8 sessies per week.
Los van de snapshot houd je bij wat jullie zélf aanpassen. Dit is het onderdeel dat mensen overslaan en het is precies waar het rendement zit.
Elke keer dat iemand uit je team een veld wijzigt (titel herschreven, prijs verlaagd, nieuwe hoofdfoto), zet je dat in een aparte tab wijzigingen_log. Kolommen:
datum | EAN | veld | oude_waarde | nieuwe_waarde | reden | doorgevoerd_door
Waarom apart en niet uit de snapshot afleiden: de snapshot ziet wél dát een veld veranderde, maar niet of jij het was of bol. Bol wijzigt zelf titels bij categoriewissels en verhoogt prijzen automatisch bij bepaalde promotie-instellingen. Zonder je eigen log zoek je bij elke afwijking opnieuw uit wie de wijziging deed.
En hier ontstaat de leercurve: 3 weken na een titelwijziging kun je in dezelfde Sheet direct zien of de conversie is gestegen of gedaald ten opzichte van het benchmark. Doe dit een half jaar consequent en je hebt een lijstje eigen bewijzen: welke soort titels werken voor jouw categorie, welke prijs-tweaks landen, welke image-stijl beter presteert.
Zonder deze log is elke wijziging een gok. Met deze log is elke wijziging een A/B-test die zichzelf terugverdient.
Belangrijk: maak het loggen onderdeel van het wijzigingsproces zelf. Wie de wijziging in bol doet, logt hem direct in de Sheet. Niet achteraf. Dit is de grootste sluipmoordenaar: als de marketplacemanager op donderdag snel een prijs aanpast en dat niet logt, staat er de maandag erop een oranje alarm dat niemand kan verklaren.
De grootste valkuil is dat je op alle veranderingen alarm slaat. Je krijgt dan zoveel meldingen dat je ze binnen 3 weken negeert. Dit is mijn regel per veld:
Titel: verandering telt als 3 of meer woorden verschillen, of als het eerste woord verandert. Een komma verplaatsen is geen verandering. Een woordvolgorde-wissel in de eerste 5 woorden telt wel (bol weegt de titelstart zwaarder in zoekresultaten).
Beschrijving: verandering telt als 20% of meer van de tekens verschilt. Laat dit door je Claude project doen met een vaste vervolgvraag:
Vergelijk deze twee beschrijvingen en geef alleen: verschil_pct: X
Beschrijving A: [oude tekst]
Beschrijving B: [nieuwe tekst]
Prijs: verandering telt vanaf 2% verschil, of vanaf 1 euro absoluut, waarbij de laagste van de twee geldt. Dus €12,00 naar €12,20 is geen alarm. €50,00 naar €51,50 is wél een alarm (3%).
Image hash: elke wijziging is een verandering. Punt.
Aantal reviews: geen alarm op groei alleen. Wel alarm als er in één week 3 of meer reviews bijkomen én de gemiddelde ster daalt met 0,2 of meer. Dat betekent een cluster negatieve reviews.
Gemiddelde ster: daling van 0,2 of meer is een alarm, ongeacht het aantal.
Één Sheet, vier tabbladtypes:
Tab ruwe_data: één regel per EAN per week. Kolommen: week, EAN, bezoekers, orders, omzet, conversie_pct, benchmark_pct, verschil_pp, titel, beschrijving, prijs, image_hash, reviews_aantal, sterren_gem.
Deze tab groeit met 50 tot 200 regels per week. Na een jaar heb je 2600 tot 10.400 regels, dat werkt nog prima in Sheets.
Tab wijzigingen_log: zoals in hoofdstuk 4 beschreven.
Tab per_ean (alleen voor je top 20 EANs): pakt met FILTER de historie:
=FILTER(ruwe_data!A:N, ruwe_data!B:B="8710103952565")
Voeg drie kolommen toe: verschil_vs_benchmark_pp, wijziging_in_periode (koppeling naar de log), en alarm_kleur (rood, oranje, groen, met voorwaardelijke opmaak).
Tab samenvatting: één regel per EAN, meest recente week. Kolommen: EAN, conversie_deze_week, benchmark, verschil_pp, eigen_wijziging_laatste_3wk, listing_veranderd_ja_nee, welke_velden, alarm_kleur.
De alarm-formule (D2 is het percentuele verschil tussen jouw conversie en het bol-benchmark):
=IF(D2<=-20,"ROOD",IF(D2<=-10,"ORANJE","GROEN"))
Vergelijken met het benchmark filtert seizoen en categorie-drukte automatisch weg. Vergelijk je met je eigen vorige week, dan reageer je op ruis.
Rood alarm: jouw conversie zit 20% of meer onder het bol-benchmark, en de EAN heeft 100 of meer bezoekers deze week. Onder 100 bezoekers is 20% verschil vaak toeval.
Oranje alarm: conversie 10 tot 20% onder benchmark, of listing veranderd zonder conversie-effect (dit wil je zien om de effecten van je eigen wijzigingen te leren).
Groen: alles anders.
De 20%-drempel komt uit mijn eigen data over 8 maanden en 3 klanten. Onder 20% verschil bleek 70% van de gevallen ruis (herstelde zichzelf in 1 tot 2 weken). Boven 20% was het in 65% van de gevallen een echte oorzaak die actie vroeg.
Bij elk rood alarm doe je binnen 24 uur deze 3 checks. In deze volgorde, want de kans dat de oorzaak hier zit is aflopend.
Check 1: staat er een eigen wijziging in de log in de laatste 2 tot 3 weken?
Kijk eerst in je wijzigingen_log. Titel-wijzigingen en image-wijzigingen leveren in mijn data de meeste conversie-impact op (samen ongeveer 60% van de verklaarde dips). Overweeg de oude versie terug te zetten en 1 week later opnieuw meten. Doe dit alleen bij dips van 25% of meer, anders is de A/B-conclusie te ruisig.
Staat er geen eigen wijziging in de log, maar zag de snapshot wél een veldverandering? Dan heeft bol zelf iets aangepast.
Check 2: zijn er nieuwe reviews met lage sterren?
Ga naar de productpagina en filter op recente reviews. Zit er een cluster negatieve reviews (2 of meer 1- of 2-sterrenreviews in de laatste 2 weken)? Reageer als verkoper binnen 48 uur en los, als het gaat om een productdefect, het onderliggende probleem op.
Check 3: is er een nieuwe concurrent op dezelfde EAN of vergelijkbaar product?
Zoek de EAN op bol en check of je nog de buy-box hebt. Als een concurrent goedkoper is gaan zitten, verlies je conversie. Bij een prijsverschil van meer dan 8% verlies je bijna zeker de buy-box. Prijsverlaging is niet altijd het antwoord, maar bundels of een net iets ander aanbod voorkomen de directe vergelijking.
Als geen van deze 3 checks iets oplevert, is de dip in 80% van de gevallen tijdelijk. Meet de week erna opnieuw. Staat de dip 2 weken achter elkaar rood zonder aanwijsbare oorzaak, escaleer dan naar accountmanagement bij bol.
Tot ongeveer 50 EANs werkt dit draaiboek. Reken op 30 tot 45 minuten per week: CSV downloaden, Claude project runnen, snapshot maken, wijzigingen loggen, samenvatting doorlopen.
Vanaf 50 EANs is dit niet meer handmatig vol te houden. Bij 100 EANs zit je op 90 minuten per week. Bij 200 EANs op 3 uur. En dat is precies waar het misgaat: mensen gaan weken overslaan, snapshots vergeten, of de wijzigingen-log niet meer bijhouden. Ik heb het bij twee klanten zien gebeuren binnen 6 weken na de start.
Vanaf dat aantal moet je het volledig automatiseren. Dat betekent:
Dit is de laag waar het draaiboek stopt en de automatisering begint. Bij ons zit deze monitor standaard in het automation-ecosysteem, gekoppeld aan bol en aan de content-workflow.
De CSV-export van bol wisselt af en toe van kolomvolgorde. Als dat gebeurt, klopt je Sheet-import niet meer. Check elke maandag of de eerste 3 EANs plausibele bezoekersaantallen hebben.
De benchmark-kolom is soms leeg bij nieuwe EANs. Bol vult die pas na 4 tot 6 weken data. Voor die EANs val je terug op je eigen 8-weeks gemiddelde tot het benchmark beschikbaar is.
Bol telt bezoekers per sessie, niet per unieke persoon. Iemand die 3 keer terugkomt telt als 3 bezoekers. Voor trends maakt dat niet uit, maar verwar bol-bezoekers niet met Google Analytics-users.
Reviews-aantal daalt soms. Bol verwijdert reviews die niet aan hun beleid voldoen. Bij een daling van 5 of meer in één week is er iets vreemds, daaronder is het normaal.
Image hash blijft soms gelijk terwijl de foto verandert. Bol hergebruikt af en toe URLs bij minor edits. Los dit op door 1 keer per maand handmatig de top 20 images visueel te vergelijken.
Hij vertelt je niet waarom de conversie zakt, alleen dat het zakt en welke velden zijn veranderd. De diagnose blijft menselijk werk.
Hij meet geen impressies of zoekpositie.
Hij werkt niet voor multi-marketplace (bol plus Amazon plus je eigen shop). Voor die opzet moet je de bezoekers-bron per EAN uitsplitsen en dat vraagt een andere structuur.
Hij vervangt je marketplacemanager niet. Hij maakt hem 3 tot 5 uur per week efficiënter door hem te vertellen waar hij moet kijken. Bij mijn klanten met 200 tot 400 EANs betekent dat: van 8 uur ad-hoc dashboard-werk naar 3 uur gerichte actie per week, mits de automatisering eronder ligt.
← Terug naar de kennisbank
In een vrijblijvend gesprek brengen we in kaart welke systemen jouw business nodig heeft.
Gratis 1-op-1 call met Job Lenselink