Dit is een van de meest gestelde vragen door teams die nieuw zijn met A/B-testen: hoeveel bezoekers, of hoeveel conversies, heb je nodig voordat je de resultaten van een test kunt vertrouwen? Het antwoord is niet eenduidig; het hangt af van je initiële conversieratio, de omvang van de verandering die je wilt detecteren en de mate van zekerheid die je nodig hebt voordat je een conclusie trekt. Dit artikel legt deze factoren één voor één uit, zonder ingewikkelde wiskundige formules, zodat je zelf de benodigde steekproefomvang voor een betrouwbare test kunt inschatten.
Waarom de steekproefomvang de belangrijkste vraag is bij een test.
Een A/B-test vergelijkt het gedrag van twee groepen bezoekers die twee verschillende versies van een pagina te zien krijgen. Menselijk gedrag varieert echter van nature van bezoeker tot bezoeker, ongeacht de bekeken versie: op sommige dagen, op sommige momenten, converteren sommige profielen beter dan andere, om redenen die niets met de test te maken hebben. Bij een kleine steekproefomvang kan deze natuurlijke variatie – statistische 'ruis' – gemakkelijk een verschil tussen de twee groepen creëren dat op een reëel effect lijkt, terwijl het in werkelijkheid slechts een willekeurige fluctuatie is.
De steekproefomvang is de belangrijkste factor bij het onderscheiden van een echt signaal van ruis. Hoe groter de steekproef, hoe meer willekeurige fluctuaties elkaar opheffen en hoe groter de kans dat een gemeten verschil tussen twee groepen een reëel effect van de geteste verandering weerspiegelt in plaats van toeval. Een test uitvoeren zonder de benodigde steekproefomvang te hebben geschat, komt neer op het vooraf bepalen of het verkregen resultaat betrouwbaar zal zijn.
De beginwisselkoers
De eerste factor om te weten is het huidige conversiepercentage van de pagina of het gebruikerstraject dat wordt getest, gebaseerd op de meeteenheid die zal worden gebruikt om de test te evalueren. Dit cijfer kan eenvoudig worden verkregen uit de gegevens die al beschikbaar zijn in uw analysetool: het aantal conversies gedeeld door het aantal bezoekers, over een recente en representatieve periode (waarbij, indien mogelijk, perioden met uitzonderlijke promoties of atypische verkeerspieken worden uitgesloten).
Dit startpercentage heeft direct invloed op de benodigde steekproefomvang: voor hetzelfde effect vereist een laag conversiepercentage (bijv. 1%) een grotere steekproef dan een hoog conversiepercentage (bijv. 20%) om hetzelfde relatieve verschil te detecteren. Dit is een van de redenen waarom tests met infrequent voorkomende statistieken (een aankoop, een abonnement) over het algemeen meer verkeer en tijd vergen dan tests met frequent voorkomende statistieken (een klik, een paginascrollen).
De MDE, oftewel de omvang van het effect dat we proberen te detecteren.
Het MDE (Minimum Detectable Effect) verwijst naar het kleinste verschil tussen de controlegroep en de variant dat de test betrouwbaar kan detecteren. Het is een keuze, geen meetbare waarde: u bepaalt zelf welk niveau van verbetering de moeite waard is om te detecteren.
Deze keuze heeft een dramatisch effect op de benodigde steekproefomvang. Het detecteren van een klein effect (bijvoorbeeld een stijging van het conversiepercentage van 5% naar 5,2%, een relatieve verbetering van 4%) vereist aanzienlijk meer verkeer dan het detecteren van een groot effect (een stijging van hetzelfde percentage van 5% naar 6,5%, een relatieve verbetering van 30%). In de praktijk betekent dit dat een kleine wijziging – een knopkleur, een woord in een titel – een aanzienlijk grotere steekproefomvang vereist dan een complete pagina-herontwerp, bij hetzelfde verkeersniveau, simpelweg omdat een bescheidener effect wordt verwacht.
Het praktische gevolg is eenvoudig: op een website met een gemiddeld bezoekersaantal is het beter om de eerste tests te richten op wijzigingen waarvan een duidelijk effect wordt verwacht (herstructurering van een pagina, vereenvoudiging van een navigatiepad) in plaats van op micro-aanpassingen die maanden nodig hebben om een bruikbaar resultaat op te leveren.
Het betrouwbaarheidsniveau en de statistische power
Twee andere, meer technische parameters completeren de berekening. Het betrouwbaarheidsniveau (vaak ingesteld op 95%) geeft de kans aan dat een test ten onrechte als winnaar wordt uitgeroepen, terwijl er in werkelijkheid geen verschil is tussen de twee versies – dit wordt een vals positief resultaat genoemd. De statistische power (vaak ingesteld op 80%) geeft de kans aan dat een reëel effect wordt gedetecteerd, indien aanwezig, in plaats van ten onrechte te concluderen dat er geen verschil is – een vals negatief resultaat.
Deze twee waarden (95% en 80%) zijn gangbare conventies in de A/B-testindustrie, geen absolute regels. Het verhogen ervan (bijvoorbeeld door te streven naar 99% betrouwbaarheid) verkleint het risico op een onjuiste conclusie, maar verhoogt tegelijkertijd de benodigde steekproefomvang; het verlagen ervan versnelt het verkrijgen van een resultaat, ten koste van een groter risico op een onjuiste conclusie. Voor een test met beperkte gevolgen (een gemakkelijk terugdraaibare aanpassing) kunnen flexibelere drempelwaarden gerechtvaardigd zijn; voor een test waarvan het resultaat een kostbare implementatiebeslissing bepaalt, zijn strengere drempelwaarden te verkiezen.
Hoe schat je in de praktijk de benodigde steekproefomvang?
In de praktijk is het zelden nodig om de onderliggende statistische formule zelf te berekenen. De meeste A/B-testplatforms, waaronder BlastOptimize, bevatten een calculator die simpelweg vraagt om het huidige conversiepercentage en het minimale effect dat je wilt kunnen detecteren. De calculator geeft vervolgens direct de benodigde steekproefomvang per variant terug, evenals een schatting van de testduur op basis van het huidige paginaverkeer.
Deze inschatting moet worden gemaakt vóór de start van de test, nooit erna. Het dient om te bepalen of de test haalbaar is binnen een redelijke termijn, rekening houdend met het beschikbare verkeer. Zo niet, dan dient de inschatting te worden aangepast: ofwel de reikwijdte van de te testen wijziging (gericht op een breder effect, dus een hogere MDE), ofwel de reikwijdte van de test (door meerdere pagina's met weinig verkeer te groeperen in plaats van één geïsoleerde pagina te testen), ofwel moeten andere onderzoeksmethoden worden overwogen (kwalitatieve gebruikerstests, enquêtes) wanneer het verkeer het simpelweg niet toelaat om binnen een redelijke termijn een voldoende grote steekproef te bereiken.
De "kijkfout": het resultaat bekijken voordat het af is.
Zodra de steekproefomvang is geschat, is het van cruciaal belang om te wachten tot deze is bereikt voordat er een conclusie wordt getrokken – zelfs als het dashboard na slechts enkele dagen een indrukwekkend verschil laat zien. Dit gedrag, ook wel "peeking" genoemd, is een van de meest voorkomende oorzaken van onjuiste resultaten bij A/B-testen: de statistische significantie-indicatoren die de meeste tools in realtime weergeven, worden continu berekend. Een verschil kan op een bepaald moment significant lijken en vervolgens afnemen, of zelfs omslaan, zodra de volledige steekproefomvang is bereikt.
De eenvoudigste praktische regel om deze valkuil te vermijden, is om vóór de start van de test zowel een minimale steekproefomvang als een minimale duur vast te stellen (doorgaans minstens één tot twee weken, om de variaties tussen weekdagen en weekenden te ondervangen), en het resultaat pas als definitief te beschouwen wanneer aan beide voorwaarden tegelijkertijd is voldaan.
Wat te doen als er te weinig verkeer is voor een standaard test?
Niet alle websites hebben voldoende verkeer om micro-optimalisaties gedurende een paar dagen met een ruime steekproef te testen. Bij beperkt verkeer kunnen verschillende aanpassingen helpen om de prestaties verder te verbeteren:
- Testen van wijzigingen met een grote verwachte impact In plaats van micro-aanpassingen, om de benodigde steekproefomvang te verkleinen.
- Groepeer de meetwaarden door een doel hoger in de funnel na te streven (bijvoorbeeld klikken naar winkelwagen in plaats van de uiteindelijke aankoop), wanneer dit relevant blijft voor de te testen hypothese, aangezien frequentere gebeurtenissen een kleinere steekproef vereisen.
- Verleng de duur van de test. Door de gebruikelijke termijn van twee weken te overschrijden en een langere wachttijd voor de beslissing te accepteren.
- Vul A/B-testen aan met kwalitatieve methoden. (gebruikerstests, sessieopnames, klantinterviews) die geen grote hoeveelheid verkeer vereisen om bruikbare inzichten op te leveren.
Een concreet voorbeeld om de redenering te visualiseren.
Laten we, om deze concepten concreter te maken, een puur illustratief voorbeeld nemen. Stel je een landingspagina voor met een huidig conversiepercentage van 3%, en een team dat een minimaal relatief effect van 15% wil detecteren (d.w.z. een verandering van 3% naar ongeveer 3,45%), met behulp van de gebruikelijke drempelwaarden van 95% betrouwbaarheid en 80% statistische power. Een steekproefgroottecalculator zou in dit scenario aangeven dat er enkele duizenden bezoekers per variant nodig zijn om de test betrouwbaar te laten zijn – de exacte orde van grootte hangt af van de gebruikte formule, maar het principe blijft hetzelfde: hoe kleiner het gewenste effect is ten opzichte van het initiële percentage, hoe sneller de benodigde steekproefgrootte toeneemt.
Als dezelfde pagina slechts een paar honderd bezoekers per week trekt, duurt het enkele maanden voordat de vereiste steekproefomvang is bereikt – een tijdsbestek dat zelden strookt met het tempo van een marketingteam. Er zijn dan twee opties: ofwel de hypothese herzien om een breder effect te bereiken (een meer structurele verandering in plaats van een kleine aanpassing), ofwel een hogere MDE accepteren, wat de gevoeligheid van de test vermindert, maar ook de duur ervan verkort. Deze afweging, bewust gemaakt vóór de lancering, is beter dan een test die zonder zorgvuldige overweging wordt gelanceerd en voortijdig wordt afgebroken vanwege ongeduld.
Veelgestelde vragen
Moet voor zowel de controlegroep als de variant hetzelfde monster worden gebruikt?
In de overgrote meerderheid van de gevallen wel: een gelijke verdeling van het verkeer tussen de twee versies is de meest efficiënte configuratie om zo snel mogelijk statistische significantie te bereiken, bij een gelijk totaal verkeersvolume.
Kunnen we meer dan twee varianten tegelijk testen?
Ja, maar elke extra variant verlaagt het beschikbare verkeer per vestiging en verhoogt de tijd die nodig is om een voldoende grote steekproef voor elke variant te verkrijgen. Een A/B/C/D-test, met hetzelfde totale verkeer, vereist aanzienlijk meer tijd dan een traditionele A/B-test om tot een betrouwbare conclusie te komen over elke variant.
Is een test betrouwbaar bij een kleine website?
Ja, mits de verwachtingen worden bijgesteld: geef prioriteit aan veranderingen met een grote potentiële impact, accepteer langere testduur en aarzel niet om A/B-tests aan te vullen met methoden die niet afhankelijk zijn van verkeersvolume, zoals kwalitatieve gebruikerstests.
Belangrijkste conclusies
De steekproefomvang is geen technisch detail dat alleen voor statistici is weggelegd; het is de parameter die bepaalt of een A/B-test een betrouwbare conclusie oplevert of juist een misleidend resultaat. De steekproefomvang hangt af van het initiële conversiepercentage, de omvang van het effect dat je wilt detecteren en het vereiste betrouwbaarheidsniveau – drie elementen die je beter kunt inschatten vóór de test dan achteraf te ontdekken dat ze de conclusie ongeldig maken. Het goede nieuws is dat een in de testtool geïntegreerde calculator voor de steekproefomvang in de overgrote meerderheid van de gevallen voldoende is om deze berekening voor het marketingteam uit te voeren.
BlastOptimize integreert deze calculator direct in het dashboard en geeft een schatting van de benodigde testduur op basis van het werkelijke verkeer naar de te testen pagina. Dit voorkomt dat er een test wordt uitgevoerd die toch geen doorslaggevende resultaten oplevert. Als je niet zeker weet welke steekproefgrootte je nodig hebt voor je volgende test, is dit een goed uitgangspunt om te bepalen voordat je zelfs maar je variant aanmaakt.
Vergelijkbare publicaties:
- CRO: Definitie, berekening en een handleiding voor beginners (2026)
- Call-to-action die converteert: hoe schrijf je hem en…
- Statistische significantie van een A/B-test: de complete handleiding
- Kameleoon vs no-code-oplossingen: is CRO…
- A/B-testen in e-commerce: 7 baanbrekende ideeën (2026)
- Hoe voer je je eerste A/B-test uit?














Reacties zijn uitgeschakeld.