Steekproefgrootte bepalen vóórdat je begint: de berekening die de meeste A/B-tests overslaan.

Steekproefgrootte bepalen vóórdat je begint: de berekening die de meeste A/B-tests overslaan.

De meeste A/B-tests mislukken nog voordat één bezoeker ze heeft gezien. Niet omdat de hypothese zwak was of het ontwerp slecht, maar omdat niemand had uitgezocht of de test überhaupt een antwoord zou kunnen opleveren.

Het patroon is bekend. Een team brengt een variant uit, bekijkt het dashboard en ziet na tien dagen dat de uitdager 6% hoger staat met een p-waarde van 0.14. Iemand zegt: "Het gaat de goede kant op, laten we het nog een week aankijken." Weer een week later staat de stijging 4%, p = 0.09. De test wordt als een "richtinggevende winst" bestempeld en uitgebracht, of wordt stopgezet omdat de resultaten onduidelijk zijn. Hoe dan ook, drie weken verkeer heeft geen nieuwe inzichten opgeleverd – en die uitkomst was al vóór de lancering volledig bepaald door vier cijfers die niemand had gecontroleerd.

Dit artikel gaat over die vier getallen.

De vier ingangen

De steekproefgrootte is geen kwestie van inschatting. Deze wordt bepaald door vier parameters, en elk serieus experimenteel programma stelt deze parameters vast vóór de lancering, in plaats van erna.

InvoerWat het betekentTypische waarde
BasisconversiepercentageDe huidige waarde van de te testen metriek, gemeten op de exacte pagina en voor de doelgroep waarop de test wordt uitgevoerd.Wat uw gegevens ook zeggen
Minimaal detecteerbaar effect (MDE)De kleinste verandering die de test moet kunnen detecteren.5–20% relatief, afhankelijk van het verkeer.
Significantieniveau (α)Je tolerantie voor het uitroepen van een winnaar die niet echt is.0.05
Statistische power (1−β)Uw kans om een ​​effect te detecteren dat is vast0.80

Geef een rekenmachine die vier gegevens en hij geeft het aantal benodigde bezoekers terug. per variant. Onze gratis A/B-testcalculator Dat doet precies wat nodig is, en het duurt ongeveer dertig seconden – en dat is precies de bedoeling. De reden dat teams deze stap overslaan, is niet dat het moeilijk is. Het is dat het antwoord vaak niet welkom is.

MDE is de invoer die iedereen verkeerd gebruikt.

Het minimaal detecteerbare effect is de parameter die de meeste schade veroorzaakt, omdat de naam iets suggereert wat het niet is.

MDE is niet De verwachte verbetering. Het is geen voorspelling, geen doel en geen prognose. Het is een ondergrens voor detecteerbaarheid: het kleinste werkelijke effect dat uw test met 80% kans kan detecteren. Stel de MDE in op 5% en u zegt eigenlijk: "Als de werkelijke verbetering kleiner is dan 5%, accepteer ik dat deze test die waarschijnlijk zal missen."

Hieruit volgen twee gevolgen, en beide zijn van belang.

Een test kan alleen de vraag beantwoorden waarvoor je hem hebt ontworpen. Als je een minimale effectgrootte van 20% berekent en het werkelijke effect 7% is, zal de test hoogstwaarschijnlijk "geen significant verschil" als resultaat geven. Dat is geen bewijs dat de variant niets doet. Het is bewijs dat je test geen effecten van die omvang kon detecteren – een totaal andere uitspraak, die teams vaak verkeerd interpreteren als "we hebben het getest, het werkte niet".

Relatieve en absolute MDE zijn niet uitwisselbaar. Een basislijn van 2.5% met een 10% relatief MDE betekent het detecteren van een beweging naar 2.75% — een absoluut Een verschil van 0.25 procentpunt. Voer 10 in een rekenveld in waar een absoluut percentage wordt verwacht, en u vraagt ​​eigenlijk om een ​​verandering van 2.5% naar 12.5% te detecteren. De tool zal u dan vrolijk vertellen dat 400 bezoekers voldoende zijn. Controleer welke conventie uw rekenmachine gebruikt. Deze ene verwarring maakt meer testplannen ongeldig dan welke andere fout we ook tegenkomen.

Een uitgewerkt voorbeeld

Een e-commerceklant wil een nieuwe lay-out voor een productdetailpagina testen. De basisconversie op die pagina is 2.5%. Ze willen een relatieve verbetering van 10% detecteren, oftewel een stijging naar 2.75%.

Bij α = 0.05 en een vermogen van 80% is de vereiste ongeveer 64,000 bezoekers per variant, ofwel ongeveer 128,000 in totaal.

Die pagina trekt 40,000 bezoekers per maand. De test heeft dus iets meer dan drie maanden nodig om de beoogde steekproefomvang te bereiken.

Dit getal verandert de hele discussie. Niet omdat drie maanden onmogelijk is, maar omdat het nu een openlijk genomen besluit is – vóór de lancering, met de afwegingen duidelijk zichtbaar – in plaats van een langzame teleurstelling die pas op dag 21 aan het licht komt.

Wijzig nu één invoerwaarde. Houd dezelfde basiswaarde aan, maar pas de grootte aan voor een relatieve verbetering van 20% in plaats van 10%:

MDE (relatief)Absoluut verschilBezoekers per variantTijd tegen 40 km/maand
5%0.125 pagina's~ 256,000~13 maanden
10%0.25 pagina's~ 64,000~3.2 maanden
20%0.5 pagina's~ 16,800~ 25 dagen
30%0.75 pagina's~ 7,700~ 12 dagen

Het halveren van de MDE verviervoudigt ruwweg de steekproefomvang. Die relatie is geen toeval van deze getallen – de steekproefomvang schaalt omgekeerd evenredig met het kwadraat van de effectgrootte. Het is het allerbelangrijkste om te begrijpen over experimenteel ontwerp, omdat het je laat zien waar de hefboomwerking zit: Het is veel goedkoper om de verandering groter te maken dan om meer verkeer te genereren.

Een voorzichtige variant die een knop twee pixels verplaatst, vereist een steekproefomvang die geen enkele middelgrote website kan leveren. Een variant die de pagina herstructureert, heeft wel een kans. Daarom lopen voorzichtige testprogramma's vast – niet omdat de ideeën verkeerd zijn, maar omdat ze te klein zijn om te meten.

Waar het verkeer zich daadwerkelijk bevindt

Een andere factor die in de berekeningen een rol speelt, is het basispercentage. De benodigde steekproefomvang neemt sterk af naarmate het basispercentage stijgt.

Neem dezelfde relatieve MDE van 10%, maar pas deze toe op de verzendstap van het afrekenproces, waar 40% van de bestellingen doorgaat naar de betaalfase:

  • Basislijn 2.5% → ~64,000 per variant
  • Basislijn 40% → ~2,400 per variant

Dezelfde MDE, hetzelfde vertrouwen, hetzelfde vermogen. Zesentwintig keer minder verkeer.

Die pagina trekt natuurlijk veel minder bezoekers dan de productpagina. Maar de behoefte aan een bepaalde pagina neemt sneller af dan het verkeer, waardoor diepgaande funnel-tests vaak de enige tests zijn die een website met gemiddeld verkeer daadwerkelijk kan uitvoeren. Als je conversieratio 2% is, is het testen van de homepage een investering van een jaar en het testen van de checkout een investering van twee weken.

Praktisch advies: als de rekenmachine een onmogelijk getal retourneert, controleer dan, voordat je de MDE verbreedt, of er een stap verderop in de trechter is waar dezelfde hypothese kan worden getest tegen een hogere basislijn.

Wat gaat er eigenlijk mis als je het overslaat?

Er zijn hier twee mogelijke oorzaken voor het mislukken van een systeem, en de tweede is veel minder bekend dan de eerste.

Je mist daardoor echte verbeteringen. Een test met onvoldoende statistische power levert "geen significant verschil" op voor een verandering die wél werkt. Het team concludeert dat het idee slecht was en laat een richting varen die winstgevend had kunnen zijn. Dit is de mislukking waar iedereen van weet, en het is de minst kostbare van de twee.

Uw winstcijfers zijn te hoog. Dit is de factor die de resultaten van een programma stilletjes verstoort. Bij een test met onvoldoende statistische power kan een resultaat alleen de significantiedrempel halen als willekeurige ruis het resultaat ver genoeg duwt – wat betekent dat de effecten die je do De als significant beschouwde waarden zijn systematisch groter dan de werkelijkheid. Hoe lager de macht, hoe groter de overdrijving.

Een ondermaats programma mist dus niet alleen dingen. Het produceert een testlogboek vol winnaars met overdreven hoge winsten, die vervolgens worden vermenigvuldigd met het verkeer om een ​​omzet te voorspellen die nooit gerealiseerd wordt. Zes maanden later vraagt ​​iemand waarom de som van de winsten niet terug te vinden is in de omzetcijfers. Dit is meestal het antwoord.

Dit kun je niet oplossen tijdens de analyse. Het moet al tijdens het ontwerp worden voorkomen.

Per variant, niet totaal

De uitvoer van de rekenmachine is de vereiste. voor elke arm van de test. Twee varianten betekent het dubbele aantal. Dit klinkt vanzelfsprekend, maar wordt voortdurend verkeerd geïnterpreteerd, meestal in de te optimistische richting.

Meerdere varianten verergeren het probleem nog eens. Een A/B/C/D-test vereist vier keer zoveel steekproeven als de test met één arm. en Drie gelijktijdige vergelijkingen met de controlegroep verhogen de kans op ten minste één vals positief resultaat aanzienlijk, tot ver boven de nominale 5%. Correctie hiervoor verhoogt de vereiste waarde nog verder.

Voor de meeste websites geldt in de praktijk: tenzij je verkeer in overvloed hebt, voer twee tests uit. Een vierwegtest op een pagina die nauwelijks een tweewegtest aankan, levert niet vier keer zoveel leerwinst op. Het levert nul leerwinst op, en die leerwinst wordt bovendien langzamer behaald.

De duur is een aparte beperking.

Het behalen van de gewenste steekproefgrootte is noodzakelijk, maar niet voldoende.

Een test die zijn doel na vier dagen bereikt, heeft het gedrag van vier dagen geanalyseerd. Verkeer op weekdagen en in het weekend converteert anders. Betaaldagen spelen een belangrijke rol in e-commerce. Betaalde campagnes die midden in een test worden gelanceerd, veranderen de samenstelling van het publiek. Nieuwe ontwerpen hebben bovendien een nieuwigheidseffect dat afneemt – de eerste interactie met een onbekende lay-out is geen stabiele indicator voor de prestaties op de lange termijn.

Voer de meting minimaal een volledige week uit, en bij voorkeur twee, ongeacht wat de steekproefomvangberekening toelaat. De langste beperking – de steekproefomvang of de conjunctuurcyclus – is bepalend. Stel de einddatum van tevoren vast in plaats van elke ochtend te controleren en te stoppen wanneer de cijfers er goed uitzien, wat een aparte en zeer effectieve manier is om valse winnaars te creëren.

Wanneer het getal onmogelijk is

Soms is het eerlijke antwoord dat de test niet kan worden uitgevoerd. Dat is nuttige informatie, en er zijn vijf redelijke reacties mogelijk.

Test een grotere verandering. De kwadratische relatie maakt dit verreweg de meest effectieve optie. Herontwerp de workflow in plaats van de knop.

Ga over naar een hogere basiswaarde. Test het effect op basis van het toevoegen aan het winkelmandje of het afrekenproces, in plaats van de daadwerkelijke aankoop. De effectgrootte wordt gemeten ten opzichte van een grotere basis en de steekproefvereiste vervalt. Accepteer dat je een indirecte meting uitvoert en valideer de link met de omzet afzonderlijk.

Test verderop in de trechter., zoals hierboven.

Groepeer vergelijkbare pagina's. Door één test uit te voeren op alle categoriepagina's in plaats van slechts één categorie, wordt het beschikbare verkeer aanzienlijk vergroot, mits de pagina's qua gedrag voldoende op elkaar lijken om het samenvoegen van gegevens te rechtvaardigen.

Stop met testen en begin met onderzoeken. Als een website geen experiment kan uitvoeren, is A/B-testen niet de juiste methode. Gebruiksvriendelijkheidstesten, sessieopnames en heuristische evaluatie vinden sneller en goedkoper de problemen. Kwantitatieve validatie volgt later, wanneer de veranderingen groot genoeg zijn om meetbaar te zijn. Daar is niets mis mee – het uitvoeren van tests met onvoldoende statistische power om rigoureus over te komen is erger dan helemaal geen tests uitvoeren.

Checklist voor de vlucht

Vóór elke testlancering:

  • [ ] Basislijn gemeten op de daadwerkelijke pagina en doelgroep waarop de test zal worden uitgevoerd, niet op de hele website.
  • [ ] MDE expliciet schriftelijk vermeld, met relatieve of absolute specificatie
  • [ ] Berekende steekproefomvang per variant en vermenigvuldigd met het aantal armen
  • [ ] Vereiste duur vergeleken met beschikbaar verkeer — en het antwoord geaccepteerd vóór de lancering
  • [ ] Einddatum vooraf vastgesteld
  • [ ] Minimaal één volledige conjunctuurcyclus, ongeacht wat de voorbeeldberekening zegt.
  • [ ] De randomisatie-eenheid komt overeen met de analyse-eenheid (toewijzing op bezoekersniveau, meetwaarden op bezoekersniveau)
  • [ ] Verkeersverdeling geverifieerd in de eerste uren — een 50/50-test die 53/47 oplevert, betekent een probleem met de meetapparatuur, en de resultaten zijn onbruikbaar totdat dit is opgelost.

Bereken de cijfers voordat je de variant bouwt.

De hele berekening duurt een halve minuut en heeft invloed op wat je bouwt. Teams die hun tests eerst op schaal uitvoeren, ontwerpen de meer ambitieuze varianten, omdat ze dan kunnen zien wat de minder ambitieuze varianten zouden kosten.

Voer je basisconversieratio in, het effect dat je wilt kunnen detecteren, en je betrouwbaarheids- en statistiekinstellingen. Als het geretourneerde getal hoger is dan je verkeer, is dat geen reden om de lancering door te zetten; de test geeft aan dat je je plan moet aanpassen.

Veelgestelde vragen

Hoeveel bezoekers heb ik nodig voor een A/B-test? Er is geen universeel getal. Het hangt af van je basisconversiepercentage, het kleinste effect dat je wilt detecteren en de door jou gekozen significantie- en powerniveaus. Een pagina met een conversiepercentage van 2.5% heeft ongeveer 64,000 bezoekers per variant nodig om een ​​relatieve verbetering van 10% te detecteren; een afrekenproces met een conversiepercentage van 40% heeft er ongeveer 2,400 nodig voor hetzelfde relatieve effect.

Wat is een goed minimaal detecteerbaar effect? De laagste waarde die uw verkeer binnen een redelijke termijn aankan. Begin met uw beschikbare verkeer en een streefduur van twee tot vier weken, en bereken vervolgens de MDE (Minimum Delay Effect) die daarbij past. Als die MDE groter is dan de verandering die u test realistisch gezien kan veroorzaken, herontwerp dan de test.

Kan ik een test voortijdig stoppen als deze duidelijk aan de winnende hand is? Niet met een standaard test met een vaste horizon. Door herhaaldelijk te controleren en te stoppen bij het eerste significante resultaat, stijgt het percentage valse positieven tot ver boven de 5%. Als u de mogelijkheid nodig hebt om vroegtijdig te stoppen, gebruik dan een daarvoor ontwikkelde methode – sequentiële testen of een Bayesiaans raamwerk – en neem die beslissing vóór de lancering, niet tijdens de lancering.

Wat als mijn test significantie bereikt voordat de vereiste steekproefomvang is bereikt? Wees er sceptisch over en blijf doorzetten tot het geplande einde. Vroegtijdige significantie in een ondermaatse periode is precies het patroon dat leidt tot opgeblazen, niet-reproduceerbare winnaars.

Is 80% vermogen voldoende? Het is de gebruikelijke standaard en een redelijk uitgangspunt, maar het betekent wel dat je een kans van 20% accepteert om een ​​echt effect te missen. Voor belangrijke beslissingen – een herontwerp van het afrekenproces, een prijswijziging – is een power van 90% de extra steekproef waard. Voor goedkope, omkeerbare veranderingen is 80% prima.

Weet u niet zeker of uw testprogramma wel de juiste antwoorden oplevert?

Als uw testlogboek vol staat met kleine successen die nooit terug te vinden zijn in de uiteindelijke resultaten, ligt het probleem meestal aan de beginfase van de analyse. Wij beoordelen experimentele programma's en vertellen u duidelijk waar het ontwerp tekortschiet.

Wilt u meer weten over de CRO-service? 


Çağdaş Polat
Geschreven door

Çağdaş Polat

Çağdaş Polat is medeoprichter van Switas, waar hij leiding geeft aan technologie- en groeiconsultancy voor merken in de e-commerce, reisbranche, gezondheidszorg en de publieke sector. Hij is afgestudeerd in computerwetenschappen en heeft de afgelopen tien jaar de overstap gemaakt van softwareontwikkeling naar senior marketing-, product- en strategiefuncties. Nu adviseert hij bedrijven over CRO, analyses en het opzetten van groeisystemen die meetbaar zijn.


Gerelateerde artikelen

Switas zoals gezien op

Vergroten: Influencermarketing opschalen met Engin Yurtdakul

Bekijk onze Microsoft Clarity-casestudy.

We hebben Microsoft Clarity benadrukt als een product dat is ontwikkeld met praktische, realistische gebruiksscenario's in gedachten door echte productontwikkelaars die de uitdagingen begrijpen waar bedrijven zoals Switas mee te maken hebben. Functies zoals 'rage clicks' en JavaScript-foutopsporing bleken van onschatbare waarde bij het identificeren van frustraties van gebruikers en technische problemen, waardoor gerichte verbeteringen mogelijk werden die een directe impact hadden op de gebruikerservaring en conversieratio's.