In dit artikel laat ik je zien wanneer A/B-testen zinvol is,
|wanneer het vooral tijdverspilling is, en hoe je dat vooraf checkt met je cijfers.
Wanneer je denkt dat alles klopt… maar er tóch niemand koopt
Stel je voor. Je hebt een goed product. Echt goed. Je hebt een strakke landingspagina.
Je funnel staat. Je mails lopen. Alles netjes gekoppeld. Het systeem doet precies wat het moet doen.
En toch… Er komt geen betalende klant uit. Geen drama. Geen paniek. Maar wel dat irritante gevoel van:
“Oké… maar wat is er dan aan de hand?"
Dus je duikt erin. Je maakt een dashboard. Je kijkt naar de cijfers. Je analyseert waar mensen afhaken. En je ziet het: De landingspagina krijgt verkeer, maar de conversie blijft achter.
Mensen kijken wel. Ze scrollen misschien. Ze verdwijnen ook weer.
En dan kom je op het punt waar bijna iedereen dezelfde fout maakt:
Dan ga je “even wat proberen”.
"Als je alles tegelijk verandert en het werkt beter,
weet je precies niks."
Knopje aanpassen. Titel herschrijven. Nieuwe foto. Extra bulletpoints. Nog een testimonial.
Nog een alinea. Nog een “gratis” erbij. En dan hopen dat het ineens wel werkt. Super menselijk. Maar ook super onhandig.
Je wil niet gokken. Je wil bewijs.
Want jij bent niet op zoek naar “mooier”. Je bent op zoek naar:
wat werkt beter in het hoofd van je klant?
Je wil niet hopen dat iets helpt. Je wil snappen:
wat iemand ziet
wat iemand denkt
waar iemand twijfelt
en wat er nodig is om die twijfel te doorbreken
En dan het liefst niet met meningen, maar met gedrag.
Want gedrag liegt minder.
En dan kom je uit bij A/B-testen
Een A/B-test is eigenlijk niets meer dan dit:
Je maakt twee versies van dezelfde pagina.
Versie A = de originele versie (zoals hij nu is)
Versie B = dezelfde pagina, maar met één gerichte verandering
En dan ga je meten:
levert versie B meer resultaat op dan versie A?
Niet omdat het spannend is. Niet omdat het “wetenschappelijk” klinkt. Maar omdat je wil stoppen met gokken.
Waarom je maar één ding tegelijk verandert
Dit is het punt dat veel mensen overslaan.
Als jij tegelijk:
de titel aanpast
de call to action verandert
de knop verplaatst
de layout omgooit
en er 3 testimonials bij zet
…en het resultaat gaat omhoog…
Dan heb je één conclusie:
“Oké. Iets werkte.”
Fantastisch. Maar wát dan? Daarom test je één ding tegelijk. Zodat je weet wat het effect veroorzaakt.
Concreet voorbeeld: knop verplaatsen
Versie A (origineel):
de call-to-action knop staat lager op de pagina, je moet scrollen om hem te zien
Versie B (nieuwe versie):
diezelfde call-to-action knop staat meteen in beeld, bovenaan de pagina, zichtbaar zodra je de pagina opent
Verder blijft alles hetzelfde. En dan laat je dit twee tot vier weken lopen. Niet drie dagen “even kijken”. Maar lang genoeg om het serieus te nemen.
En daarna kijk je:
klikken mensen vaker?
melden ze zich vaker aan?
kopen ze vaker?
Als B wint, weet je: die verandering doet iets. Dat is een A/B-test. Niet meer. Niet minder.
A/B-test in 1 zin: twee versies, één verschil, lang genoeg meten.
Waarom testen vaak niet werkt (probleem)
A/B-testen klinkt volwassen. Alsof je ineens niet meer “loopt te rommelen”, maar écht met conversie bezig bent. En dat snap ik. Want als je landingspagina niet levert, wil je houvast. Iets dat niet op gevoel is.
Alleen… in de praktijk wordt A/B-testen vaak ingezet op het moment dat het eigenlijk nog helemaal niet kan.
En dan krijg je dit:
je draait een test
je kijkt drie dagen naar de grafiek
je ziet een verschil
je voelt hoop
en daarna… gebeurt er niks
Niet omdat A/B-testen onzin is. Maar omdat je het te vroeg probeert.
De conclusie is simpel:
A/B-testen wordt te vroeg ingezet omdat mensen denken: testen = zekerheid.
Maar testen is pas zekerheid als je genoeg verkeer hebt, iets relevants test, weet waar het lekt, en lang genoeg meet om toeval uit te sluiten. En anders is A/B-testen gewoon… een hobby met grafieken.
Een bottleneck vertelt waar het misgaat. Niet waarom.
Wat je eerst moet doen (audit)
Voordat ik ook maar één A/B-test voorstel, wil ik één ding zeker weten:
Waar lekt het systeem nou echt?
Want als je niet weet waar het stokt, ga je testen op de verkeerde plek. En dan krijg je die typische CRO-frustratie: je verandert van alles, je meet van alles… en toch beweegt er niks.
Daarom start ik niet met knoppen, teksten of varianten.
Ik start met een audit.
Een landingspagina is zelden het échte probleem. Het probleem zit meestal in het systeem eromheen: het verkeer dat niet past, een belofte die niet matcht, frictie in een stap, te weinig vertrouwen, of simpelweg te weinig volume. En dat zie je niet door naar één pagina te staren. Dat zie je pas als je de hele klantreis in kaart brengt.
Dus we combineren twee dingen:
context en gedrag.
We praten met de mensen die met de funnel werken (wat is het plan, wat is er al geprobeerd?), en we duiken in de data: analytics, e-mail, social en klantgegevens. Niet om “cijfertjes te hebben”, maar om één ding helder te krijgen:
waar valt de meeste waarde weg?
Als je die route eenmaal ziet, van eerste klik tot betalende klant, wordt het ineens simpel. Dan zie je meestal binnen no-time de 4 of 5 grootste bottlenecks. En dán pas ga je kiezen: testen, iets groters aanpassen, eerst instroom fixen, of frictie uit een stap slopen.
A/B-testen is dus geen startpunt.
Het is iets wat je inzet als je al weet:
welke stap het probleem is, wat je wilt verbeteren, en wat je wilt bewijzen.
benieuwd naar de audit?
Hoe je van inzicht naar test komt (hypothese)
Je audit heeft z’n werk gedaan. Je weet nu waar het lekt. Je ziet waar mensen afhaken. Je ziet waar het systeem “dichtknijpt”.
En dan gebeurt er iets gevaarlijks. Dan wil je fixen. Meteen. Knop aanpassen. Titel herschrijven. Pagina omgooien. Want je voelt:
hier zit het.
Maar hier zit de truc:
Een bottleneck vertelt je waar het misgaat
Niet waarom.
En als je die “waarom” overslaat, test je alsnog blind. Alleen dan met een hip tooltje erbij.
Bottleneck = symptoom
Stel: je ziet dat er genoeg mensen op je landingspagina komen…
maar bijna niemand klikt door naar de volgende stap.
Dat is de bottleneck.
Maar dat betekent niet automatisch:
de knop moet omhoog.
Dat kan ook betekenen:
ze snappen de belofte niet
ze vertrouwen het niet
ze voelen te weinig urgentie
ze raken overweldigd
of ze denken: “mooi verhaal, maar niks voor mij”
Zelfde bottleneck. Vijf totaal verschillende oorzaken.
Dus als jij nu “gewoon wat gaat testen”, is dat geen CRO.
Dat is roulette met grafieken.
Hypothese = jouw beste verklaring
Een hypothese is eigenlijk heel simpel:
Dit gedrag gebeurt waarschijnlijk om deze reden.
Dus niet:
“Ik denk dat dit mooier is.”
Maar:
“Ik denk dat mensen niet doorklikken omdat ze bij binnenkomst nog niet snappen wat het oplevert.”
Of:
“Ik denk dat mensen afhaken omdat de vervolgstap te veel commitment vraagt op dat moment.”
Dat is een hypothese: een verklaring die je kunt toetsen.
En ja, je kunt het fout hebben.
Sterker nog: dat is precies de bedoeling.
Van verklaring naar één gerichte test
Als je hypothese helder is, wordt testen ineens makkelijk. Je verandert één ding dat logisch aansluit op die verklaring.
Voorbeeld:
Bottleneck: weinig mensen klikken door.
Hypothese: de waarde is te laat duidelijk, dus mensen haken af.
Test: zet het belangrijkste voordeel + bewijs direct bovenaan, en kijk of doorklik stijgt.
Niet tien veranderingen tegelijk.
Niet “even een nieuwe layout proberen”.
Gewoon één gerichte ingreep die antwoord geeft op één vraag.
Waarom dit je A/B-test volwassen maakt
Zonder hypothese ben je aan het zoeken naar een winnaar. Met een hypothese ben je aan het zoeken naar de waarheid achter het gedrag. Dan is een A/B-test geen “wedstrijdje tussen twee varianten”, maar een check:
Klopt mijn verklaring, ja of nee?
En als het antwoord nee is?
Mooi. Dan heb je geleerd. Dan ben je dichterbij.
Want conversie-optimalisatie is niet: snel scoren.
Het is: steeds beter snappen wat er in het hoofd van je klant gebeurt.
Wanneer is een A/B-test haalbaar?
Als iemand mij vraagt:
“Wanneer is een A/B-test haalbaar?”
dan ga ik niet praten over “gevoel”, “best practices” of “gewoon proberen”.
Ik zeg maar één ding:
Een A/B-test is haalbaar als je genoeg bezoekers hebt om een verschil te kunnen bewijzen.
Niet: “ik zie iets gebeuren.”
Maar: “ik kan met vertrouwen zeggen dat B beter is dan A.”
En dat kun je vooraf uitrekenen.
Een A/B-test is eigenlijk een eerlijk duel:
Variant A = wat je nu hebt
Variant B = één verandering
Maar als je te weinig bezoekers hebt, dan wint niet de beste variant…
Dan wint toeval.
Daarom moet je eerst weten:
hoeveel bezoekers heb ik nodig om een echte winnaar te kunnen zien?
Je rekent het benodigde bezoekersaantal uit met vier simpele inputs:
Voorbeeld: Pro-Wall Systems
Op de website van Pro-Wall systems, een bedrijf die in ophang- en presentatiesystemen handelt, kun je een demo aanvragen. Ze willen het aantal mensen dat daadwerkelijk een demo aanvraagt verhogen van 1,5% naar 2%.
We doen dus één A/B-test op deze landingspagina:
Variant A = huidige pagina.
Variant B = dezelfde pagina, maar met één wijziging (bijv. alleen de CTA-tekst).
Huidige conversie naar demo-aanvraag is 1,5%.
Het doel is 2,0%.
We willen weten:
hoeveel bezoekers per variant zijn nodig om 1,5% naar 2,0% betrouwbaar te kunnen meten?
Je gebruikt hiervoor een
A/B test sample size calculator
(die bestaan overal).
Wat je invult is basically dit:
P1 = huidige conversie = 1,5% (0,015)
P2 = gewenste conversie = 2,0% (0,020)
Confidence = 95% (standaard)
Power = 80% (standaard)
En dan klik je op “calculate”.
De calculator geeft je dit terug:
± 10.800 bezoekers per variant
dus ± 21.600 bezoekers totaal (A + B)
Is het haalbaar?
Volgens mijn analyse heeft Pro-Wall 390 demo’s nodig om de omzetdoelstelling te halen. De demo-pagina converteert nu 1,5%. Dat betekent dat je op jaarbasis ongeveer 26.000 bezoekers nodig hebt om aan die 390 demo’s te komen.
Als je een A/B-test doet, split je het verkeer 50/50:
13.000 bezoekers per jaar per variant (A en B)
We willen aantonen dat één wijziging de conversie verhoogt van 1,5% naar 2,0%. Met een A/B-test calculator (95% betrouwbaarheid, 80% power) kom je dan uit op:
10.800 bezoekers per variant
21.600 bezoekers totaal
Hoe lang duurt het voordat je genoeg data hebt?
Je hebt 10.800 bezoekers per variant nodig en je krijgt 13.000 per variant per jaar, dus:
10.800 / 13.000 = 0,83 jaar ≈ 10 maanden
Conclusie
Ja, het is haalbaar in de zin dat je de aantallen binnen een jaar kunt halen.
Maar het is niet “lekker” haalbaar als je hoopt op een snelle test van 2–6 weken. Je bent namelijk ongeveer 10 maanden bezig voordat je betrouwbaar kunt zeggen of B écht beter is dan A.
Om het haalbaar te maken is het volgende nodig:
Wat dit betekent in de praktijk
Dit is de reden dat veel A/B-tests nooit iets opleveren.
Niet omdat testen niet werkt, maar omdat er getest wordt zonder eerst te rekenen.
Dan wordt testen geen optimalisatie, maar gokken met grafiekjes.
Een A/B-test is dus alleen haalbaar als het verschil dat je wil meten past bij het aantal bezoekers dat je nodig hebt.
En dát moet je eerst weten, vóór je ook maar één variant bouwt.
De haalbaarheidscheck in je dashboard
Dit is waarom ik die audit altijd koppel aan een dashboard.
De audit is het denkwerk.
Het dashboard is het bewijs.
Want na die audit heb je niet alleen “inzichten”, maar een overzicht waar je echt mee kunt sturen:
we zien de klantreis,
we zien de conversies per stap,
we zien waar het stokt
en daar komen die bottlenecks uit.
Vanuit die bottlenecks formuleren we hypotheses.
En pas daarna denken we:
oké, gaan we testen?
Maar… in datzelfde dashboard zit nog één check die veel mensen overslaan.
De haalbaarheidscheck.
Niet alleen:
wat testen
maar ook:
kan testen?
Je kunt de mooiste hypothese hebben.
Je kunt precies weten wat je wil verbeteren.
Maar als er te weinig mensen door die stap gaan, dan is een A/B-test vooral… een hobbyproject met grafieken.
Daarom zet ik in het dashboard ook grafiekjes die één ding laten zien:
Actual: hoeveel bezoekers/gebruikers er nu door die stap gaan (per week/maand)
Target: hoeveel bezoekers/gebruikers je nodig hebt om een A/B-test zinvol te kunnen draaien
En die twee leg je letterlijk naast elkaar.
Wat je daaruit haalt (in 5 seconden)
Dit is precies het voordeel van werken vanuit audit + dashboard:
je kiest niet op basis van “zin hebben in testen”, maar op basis van haalbaarheid.
En dat voorkomt dat je weken lang naar een grafiek staart die niks mag zeggen.
Test uitvoeren, monitoren en besluiten
Oké. Je hebt je bottleneck. Je hebt een hypothese. Je hebt gecheckt dat er genoeg volume is.
Nu pas ga je testen.
En hier gaat het bij veel A/B-tests mis:
mensen behandelen een test alsof het een mening is.
“B staat hoger. Dus B wint.”
Nee.
Dat is geen conclusie. Dat is enthousiasme.
Uitvoeren = één verschil, eerlijk verdelen, lang genoeg laten lopen
Een A/B-test is alleen een test als je ‘m eerlijk uitvoert:
versie A = controle (origineel)
versie B = variant (één verandering)
verkeer wordt willekeurig verdeeld
je laat ‘m lang genoeg lopen (minimaal één volledige week, liever twee)
En ondertussen: niet elke dag zitten friemelen.
Geen extra wijzigingen. Geen nieuwe campagnes. Geen “we gooien er even iets bij”.
Want dan test je weer geen A vs B.
Dan test je chaos.
Besluiten = pas kiezen als het verschil “echt” is
En dan komt het begrip waar HubSpot (en elke degelijke testtool) altijd mee zwaait:
statistical significance.
In normale mensentaal betekent dat:
Hoe zeker weten we dat het verschil niet gewoon toeval is?
Dus niet:
“B staat hoger”
maar:
“B staat hoger én we hebben genoeg data om te geloven dat dit echt zo is.”
Zolang die zekerheid er niet is, is er geen winnaar.
Dan is er alleen ruis.
Wat je dan wél doet
Is het verschil statistisch significant?
Dan kun je besluiten: doorvoeren (of juist niet).
Is het verschil niet significant?
Dan besluit je óók iets:
je hypothese klopt waarschijnlijk niet,
of het effect is te klein,
of je had te weinig volume.
En dat is prima.
Want een A/B-test is geen gokautomaat.
Het is een leerinstrument.
Conclusie: A/B-testen is een middel, geen doel
Als jij A/B-testen inzet omdat je eindelijk zeker wilt weten wat werkt, dan snap ik je.
Maar dan zit je ook precies in de valkuil waar bijna iedereen in stapt:
Je gebruikt testen als geruststelling.
Niet als strategie.
En dat is cognitieve dissonantie in het wild.
Je zegt:
“Ik wil datagedreven werken.”
Maar wat je eigenlijk wil is:
niet hoeven kiezen.
Je zegt:
“Ik wil bewijs.”
Maar je hoopt vooral dat de grafiek je redt van verantwoordelijkheid.
Je zegt:
“Ik ga het serieus aanpakken.”
En ondertussen test je een knopkleur met 80 bezoekers per week.
Snap je?
Dat voelt volwassen… maar het is gewoon uitstel in een nette verpakking.
A/B-testen is geen doel.
Het is een middel. Een meetlat. Een reality check.
Het werkt alleen als je eerst het echte werk doet:
weten waar het systeem lekt
begrijpen waarom mensen afhaken
een hypothese formuleren die ergens op slaat
en pas dan testen of je verklaring klopt
En ja, soms is de conclusie dan:
We gaan níét testen.
Omdat je eerst instroom mist.
Of omdat je aanbod niet helder genoeg is.
Of omdat je klantreis frictie heeft waar je geen test voor nodig hebt, maar een schop tegen de deur.
Dus als je dit artikel meeneemt, onthoud dan dit:
A/B-testen is niet je plan.
Het is wat je inzet nadat je plan klopt.
En als jij eerlijk durft te kijken naar je cijfers, dan voel je het meteen:
ben je aan het optimaliseren… of ben je jezelf vooral bezig aan het houden?
Dat verschil bepaalt of je straks een “winner” hebt,
of gewoon weer een hobby met grafieken.
0 comments