Naar de inhoud

A/B-testen met weinig verkeer

Met het verkeer van een start-up hebben de meeste A/B-tests te weinig statistische power: kleine effecten kun je niet betrouwbaar meten. De eerlijke keuze is dus alleen grote stappen testen, methoden gebruiken die minder data nodig hebben, of de test helemaal overslaan. Deze gids laat zien hoe je herkent in welke situatie je zit – en wat je dan wel doet.

Bijgewerkt op 8 min. leestijdDoor fromHello

In het kort

  1. Statistische power is de kans dat een test een echt effect ziet. Weinig verkeer levert weinig power op, dus alleen grote verschillen zijn meetbaar.

  2. Het minimum detectable effect (MDE) stijgt naarmate je steekproef kleiner wordt – voor een start-up betekent dat vaak verschillen van 20% of meer, niet 2%.

  3. Sequentiële en bayesiaanse methoden verkleinen het probleem van de steekproefgrootte. Ze nemen het niet weg.

  4. Vaak is de juiste keuze om niet te A/B-testen: lanceer met een guardrailmetric, doe een grotere gok of kies voor kwalitatief onderzoek.

Waarom de meeste A/B-tests stuklopen op weinig verkeer

Een A/B-test vergelijkt twee versies en vraagt of het verschil echt is of ruis. Om dat te beantwoorden, heeft hij genoeg waarnemingen nodig om signaal van toeval te scheiden, en die hebben start-ups zelden. Met een paar honderd conversies per maand zegt de rekensom dat je alleen grote verschillen kunt zien – dus het populaire advies om alles te testen, laat je tests draaien die nooit tot een conclusie hadden kunnen komen. De paar tests kiezen die het waard zijn, is precies waar een experimentenroadmap voor dient.

Statistische power en MDE in gewone woorden

Statistische power is de kans dat een test een echt effect ziet als dat er is – 80% is het gebruikelijke doel. Het minimum detectable effect (MDE) is de kleinste verbetering die een test bij die power kan oppikken, gegeven je basisconversie en je steekproefgrootte. De twee bewegen samen: minder bezoekers duwen het MDE omhoog. Voor een start-up is het MDE vaak een relatief verschil van 20% tot 50%, niet de 2% die een knopkleur zou kunnen opleveren. Is je wijziging kleiner dan je MDE, dan kan de test haar binnen geen enkele realistische termijn zien.

Met het verkeer van een start-up zijn alleen grote effecten meetbaar – het gemarkeerde kwadrant is waar A/B-testen met weinig verkeer echt werkt. Kleine effecten vragen een schaal die je nog niet hebt.

Waarom alleen grote effecten meetbaar zijn

De benodigde steekproef schaalt ruwweg met het omgekeerde kwadraat van het effect dat je wilt meten, dus een half zo groot MDE vraagt ongeveer vier keer zoveel bezoekers. Het eigen rekenvoorbeeld van Optimizely maakt het concreet: bij een basisconversie van 10% heb je voor een stijging van 3% ongeveer vijftien keer zoveel bezoekers nodig als voor een stijging van 10%. De effecten die een klein team eerlijk kan meten, zijn dus de grove: een nieuwe prijspagina, een herziene onboardingflow, een ander kernaanbod – geen microcopy. Een CRO Specialist besteedt het grootste deel van de tijd aan bepalen welke wijzigingen groot genoeg zijn om een test waard te zijn.

Sequentieel en bayesiaans testen helpen, een beetje

Met sequentiële methoden mag je vroeg stoppen als een resultaat beslissend is, met een rekenmodel dat bestand is tegen herhaald kijken. Het sequentiële ontwerp van Evan Miller kan het aantal waarnemingen met 25% tot 50% verminderen als het echte effect groot is – en het bestaat juist zodat je niet tussentijds gaat gluren bij een test met een vaste steekproef. Bayesiaanse methoden geven de kans dat de ene variant de andere verslaat in plaats van een p-waarde, en daar valt halverwege makkelijker mee te redeneren. Beide verkleinen het probleem van de steekproefgrootte. Geen van beide neemt het weg: is het echte effect klein, dan heeft elke methode nog steeds meer data nodig dan je hebt.

Test grotere wijzigingen en pas op voor gluren

Twee regels houden testen met weinig verkeer eerlijk. Ten eerste: test grotere wijzigingen. Kies stappen die groot genoeg zijn om boven je MDE uit te komen, en draai één zuivere A/B-test in plaats van een multivariaat raster dat je verkeer nog verder opsplitst. Ten tweede: leg de steekproefgrootte en de stopregel vast voordat je begint, en roep geen winnaar uit op de eerste dag dat het significant lijkt – door vroeg te gluren bij een test met een vaste steekproef gaat ruis als winst live. Gebruik je geautomatiseerde splitstappen in een journey, dan geldt dezelfde discipline: leg de metric en de horizon vooraf vast. Een holdoutgroep – een deel dat je bewust op de oude ervaring houdt – is een eenvoudige manier om te controleren of een effect echt is. Kleine teams draaien weinig tests, dus kies de tests die het waard zijn en voer ze goed uit.

FAQ

Veelgestelde vragen

  • Hoeveel verkeer heb ik nodig om te A/B-testen?

    Dat hangt af van je basisconversie en van het effect dat je wilt meten, niet van een vast aantal bezoekers. Als ruwe referentie noemt de gids van VWO grove benchmarks van minder dan ca. 1.000 bezoekers of 5–10 conversies per week. Zit je daaronder, test dan alleen grote wijzigingen of sla formeel testen over.

  • Lossen sequentieel of bayesiaans testen het probleem van weinig verkeer op?

    Ze helpen, ze lossen het niet op. Beide kunnen een test eerder beëindigen als het effect groot is, maar is het echte verschil klein, dan heeft elke methode nog steeds data nodig die je niet hebt. Ze verkleinen het probleem van de steekproefgrootte in plaats van het weg te nemen.

  • Moet een start-up überhaupt A/B-testen?

    Soms. Bewaar tests voor wijzigingen die groot genoeg zijn om boven je minimum detectable effect uit te komen. Voor al het andere: lanceer met een guardrailmetric, bundel kleine wijzigingen of gebruik kwalitatief onderzoek. Tests zonder genoeg power kosten weken en geven vals vertrouwen.

  • Wat is gluren en waarom is het een probleem?

    Gluren (peeking) is een test met een vaste steekproef steeds opnieuw bekijken en stoppen zodra hij significant lijkt. Dat blaast het aantal fout-positieven op, omdat ruis bij toeval de drempel overschrijdt als je maar vaak genoeg kijkt. Leg de steekproefgrootte en de stopregel vooraf vast, of gebruik een methode die gemaakt is om tussentijds te kijken.

fromHello is open source marketing automation: berichten die worden getriggerd door wat mensen doen.

fromHello Cloud is in early access via de wachtlijst.

Early access

fromHello Cloud

Je bent niet begonnen om klein te blijven.

Early access tot fromHello Cloud gaat gefaseerd open. De onboarding is persoonlijk: we helpen je met de inrichting en met het overzetten van je contacten.

We mailen je zodra je plek vrijkomt. Geen spam.

Nog niet zover? Bekijk op GitHub