A/B testen: wanneer het loont, wat het kost en wat je vooraf nodig hebt

A/B testen is een gecontroleerde, gerandomiseerde experimenteermethodiek die live websiteverkeer gelijkmatig verdeelt tussen een originele controlepagina en een behandelvariant met één gewijzigde variabele om een statistisch significante conversiestijging te meten bij een betrouwbaarheidsniveau van 95% en een statistisch onderscheidingsvermogen van 80% voordat wijzigingen definitief live gaan.

De mechaniek is eenvoudig en overal uitgelegd. Wat bepaalt of experimenteren rendeert voor je bedrijf is niet de mechaniek, maar of je trechter genoeg sessies en conversies oplevert om het statistische signaal los te maken van dagelijkse toevalsschommelingen.

De meeste stukken hierover worden geschreven door de bedrijven die de testsoftware verkopen, en die slaan de vraag over of je überhaupt zou moeten testen. Deze gids begint daar, want voor een groot deel van de B2B-sites is het eerlijke antwoord: nog niet.

De drempel wordt bepaald door rekenwerk, niet door enthousiasme. Om een realistische verbetering te zien, zeg 20% relatieve stijging in conversies, heb je ongeveer 100 conversies per variant nodig voordat het resultaat zich van toeval losmaakt. Dat zijn 200 conversies per test, en bij een basisratio van 2% betekent het zo'n 10.000 sessies op de geteste pagina.

Daaronder mislukken tests niet luidruchtig. Ze leveren een winnaar op die statistische ruis is, je zet hem live in productie, en het beloofde effect duikt nooit op in de maandcijfers. Twee rondes met schijnwinnaars en het team concludeert dat testen niet werkt, terwijl het testen onder de vereiste steekproefomvang het probleem was.

Elke betrouwbare steekproefberekening weegt drie statistische grootheden tegen elkaar af: je huidige basislijn nadat je eerst je conversieratio berekenen hebt uitgevoerd, het minimaal detecteerbare effect (MDE) waarop je zou handelen, en je foutmarges. De standaard begrenst de Type I-fout (alpha = 0.05, oftewel 95% betrouwbaarheid en maximaal 5% kans op een fout-positieve winnaar) samen met de Type II-fout (beta = 0.20, oftewel 80% statistisch onderscheidingsvermogen en maximaal 20% kans om een echte verbetering te missen). Als je pagina op 2,0% converteert en je wilt een relatief MDE van 15% aantonen (van 2,0% naar 2,3%), dan heb je ongeveer 17.000 sessies per variant nodig. De steekproefcalculator van Evan Miller berekent vooraf exact hoeveel bezoekers per tak nodig zijn.

Drie dingen, elk een kwestie van uren in plaats van weken. Ontbreekt er één, dan krijg je resultaten waar je niets mee kunt, en dat is duurder dan niet testen, omdat de conclusies daarna een jaar worden aangehaald. Het vaste MDE-getal in de hypothese is wat voorkomt dat een vlak resultaat later als kleine winst wordt herlezen.

Conversiemeting die één keer vuurt vanaf elk pad, met de hand gecontroleerd op desktop en mobiel. Een basislijn van minstens acht weken zodat je weet hoe normale wekelijkse variatie eruitziet. En een opgeschreven hypothese met een concreet MDE-doel erin: niet «een korter formulier zal beter werken» maar «het formulier van negen naar vier velden brengen verhoogt het aantal gekwalificeerde inzendingen met minstens 15% bij 95% betrouwbaarheid».

Niemand heeft het verkeer om alles te testen, dus de volgorde telt zwaarder dan de lijst. De tabel hieronder laat zien waar wij per type pagina beginnen, uit audits en niet uit theorie, met het verkeer dat ruwweg nodig is voor een schoon antwoord binnen een maand. De aantallen gelden bij een ratio rond 2%: bij 5% reken je bijna de helft. Nog iets over de volgorde: begin bij de pagina met de meeste sessies, niet bij de pagina die je het meest stoort. Dat zijn zelden dezelfde, en de tweede kost een maand voor een uitkomst die niemand opmerkt.

Het patroon erachter: de eerste test op een pagina hoort een weglating te zijn, geen toevoeging. Weglatingen zijn sneller gebouwd, makkelijker te lezen en winnen vaker, want de meeste pagina's dragen meer dan ze nodig hebben.

Deel de benodigde sessies door je wekelijkse sessies op die pagina en rond af op hele weken. Op weken, omdat verkeer doordeweeks anders loopt dan in het weekend, en midden in de week stoppen het resultaat kantelt naar de dagen die toevallig meededen. Leg ook de einddatum vast vóór de start: een test zonder vast einde loopt tot iemand een resultaat wil zien.

Twee regels houden een lopende test eerlijk. Kijk niet tussentijds om een vroege winnaar uit te roepen voordat de geplande steekproef compleet is, want tussentijds spieken (peeking) jaagt je fout-positieve kans van 5% naar ruim boven de 25%. En laat geen twee tests tegelijk op dezelfde flow lopen als je tool de wisselwerking niet isoleert.

De keuze tussen een frequentistische en een bayesiaanse statistische motor bepaalt hoe je ondernemersrisico weegt, terwijl de technische split-architectuur bepaalt of de verzamelde data überhaupt betrouwbaar is. Frequentistisch testen met een vaste horizon dwingt strikte grenzen af voor de Type I-fout (alpha = 0.05) en de Type II-fout (beta = 0.20) over een vooraf vastgelegde steekproefomvang, en vormt daarmee de standaard voor trechters met veel verkeer.

Bayesiaans testen berekent doorlopend de a-posteriorikans dat Variant B het origineel verslaat, gecombineerd met een verwacht-verliesmetriek (Expected Loss). Die flexibiliteit maakt bayesiaanse evaluatie aantrekkelijk voor middelgrote B2B-sites, mits het team conservatieve priors gebruikt en minimaal twee volledige weekcycli afwacht. Geen enkel statistisch model redt echter een test met Sample Ratio Mismatch (SRM). Als een 50/50-verdeling 5.250 sessies in Controle en 4.710 in de Variant telt, bewijst een chi-kwadraattoets met p < 0.001 dat client-side redirects, trage scripts of adblockers bezoekers asymmetrisch laten wegvallen. Zodra SRM optreedt, moet het testresultaat direct worden afgekeurd.

De technische uitvoering bepaalt daarnaast of je experiment de gebruikerservaring schaadt. Klassieke client-side testscripts passen het DOM pas aan nadat de browser de originele pagina heeft geladen, wat een zichtbare flikkering veroorzaakt (Flash of Original Content, FOOC), Interaction to Next Paint (INP) boven de 200 milliseconden duwt en Cumulative Layout Shift (CLS) verslechtert. Moderne ontwikkelteams voeren de verkeerssplitsing aan de netwerkrand uit via Vercel Edge Middleware of server-side feature flags. Door het variantcookie direct op de CDN-edge toe te wijzen wordt de definitieve HTML vanaf de eerste byte zonder flikkering geleverd, wat de snelheid en conversie van je landingspagina's beschermt.

SEO-split testen beantwoordt een andere vraag en werkt anders. In plaats van gebruikers te splitsen splits je pagina's: de helft van een set vergelijkbare templates krijgt de wijziging en de andere helft niet, en je vergelijkt het organische verkeer tussen de groepen over meerdere weken. In de praktijk betekent dat ook dat de twee testsoorten niet tegelijk op hetzelfde template mogen lopen.

De reden is dat een zoekmachine één versie van een URL ziet en niet twee, dus splitsen op gebruikersniveau kan geen positie-effect meten. Dat ontkracht meteen de gebruikelijke zorg. De documentatie van Google over website-tests zegt expliciet dat een normaal geïmplementeerde A/B-test geen positiestraf oplevert.

SEO-tests vragen meer geduld: minimaal vier tot zes weken en ten minste twintig vergelijkbare pagina's.

De voorbeelden die het hardst rondgaan zijn de fotogenieke, en knopkleur is daarvan de ergste. Hij overleeft dankzij een beroemde casestudy uit 2009 en omdat het het makkelijkst te veranderen is. In onze audits is het nooit de grootste hefboom van een pagina geweest.

De regel die de meeste tijd bespaart: test niets wat je toch wel zou uitrollen. Is de huidige versie stuk, onleesbaar of spreekt hij de advertentie tegen die de bezoeker bracht, herstel hem dan direct. Een test op een kapotte pagina meet welke kapotte versie minder slecht is.

Waarom mislukken micro-copytests en knopkleuren op B2B-sites met bescheiden verkeer bijna altijd? Omdat cosmetische aanpassingen de conversieratio doorgaans maar met 1% tot 3% relatief verschuiven, waarvoor bij 95% betrouwbaarheid en 80% onderscheidingsvermogen ruim 40.000 sessies per variant nodig zijn. Wanneer je pagina 6.000 tot 15.000 sessies per maand ontvangt, leveren alleen structurele ingrepen zoals een scherpere waardepropositie, minder formuliervelden of concrete klantcases direct naast de actieknop de relatieve winst van 15% tot 28% op die binnen drie tot vier weken statistisch significant wordt.

Een test heeft drie mogelijke uitkomsten en de meeste teams plannen er maar één. Een duidelijke winnaar is het zeldzame geval. Een duidelijke verliezer is echt nuttig, want die laat zien dat de aanname achter de pagina niet klopt. En een vlak resultaat, het meest voorkomende, betekent dat de wijziging te klein was voor jouw volume, niet dat het idee fout was. Plan die beslissing ook echt in. Een resultaat dat op een volle agenda wacht is in de praktijk hetzelfde als geen resultaat, en het is de meest voorkomende reden dat testprogramma's na een half jaar stilvallen.

Schrijf de interpretatieregel op vóór de start: welk getal telt als winst, welk als vlak, en wat je in elk geval doet. Noteer ook wie beslist: een resultaat zonder aangewezen beslisser blijft liggen.

Het werk van Nielsen Norman Group over kwantitatieve studies behandelt de steekproefvraag uitgebreider.

De fouten die we zien herhalen zich, en geen ervan is statistisch van aard. Ze gaan over proces, en daarom lost een betere tool ze zelden op.

• Vroeg stoppen op een goede dag, waardoor een muntworp een beslissing wordt
• Iets testen dat zo klein is dat zelfs een echt effect bij jouw volume onzichtbaar blijft
• Twee dingen tegelijk veranderen en leren welk paar won in plaats van welke wijziging werkte
• Het verwachte resultaat nooit opschrijven, waardoor elke uitkomst als succes wordt gerapporteerd
• Testen over een seizoenspiek en de conclusie op de rest van het jaar toepassen

"De tests waar we iets van leren zijn de tests waarbij we hadden opgeschreven wat we verwachtten en het mis hadden." - conversieverantwoordelijke bij Vezert

Geen van deze fouten los je op door van tool te wisselen. Je lost ze op door vóór de start drie regels op te schrijven: wat je verwacht, wanneer je stopt en wie beslist.

De tool is de kleinste post. Een bruikbare testtool kost bij de volumes die de meeste B2B-sites hebben €0 tot €200 per maand, en het gratis pakket van meerdere aanbieders volstaat voor één test tegelijk. De echte kosten zitten in de bouw en de analyse. Reken ook de gemiste kans mee: de maand die een test bezet is een maand waarin die pagina geen andere verbetering krijgt. Bij weinig verkeer overtreft die kost vaak de waarde van het antwoord.

Reken op drie tot acht uur per test voor de implementatie op een normale pagina, plus een uur om het resultaat inclusief SRM-controle goed te lezen. Tegen bureautarieven is dat €400 tot €1.200 per test, en een programma met één test per maand ligt rond €1.000 tot €2.500 inclusief tool en rapportage. Je kunt deze doorlopende testbudgetten vergelijken met vaste projecttarieven op onze pagina met prijzen.

Eén post staat nooit in de offerte: de beslistijd. Programma's sterven veel vaker aan ongelezen resultaten dan aan slechte tools.

Haalt je belangrijkste pagina 10.000 sessies per maand, begin dan met de weglaattest uit de tabel en schrijf eerst het verwachte MDE-getal op. Zo niet, besteed hetzelfde budget aan gekwalificeerd verkeer en gebruik een CRO audit om de structurele knelpunten te vinden die geen test nodig hebben om duidelijk te zijn. En houd bij wat je hebt getest, ook de vlakke uitkomsten. Zonder dat logboek test elk nieuw teamlid over twee jaar precies dezelfde dingen opnieuw, met dezelfde uitkomst en dezelfde kosten.

Het meeste wat een eerste audit vindt is toch niet testbaar. Het is stuk, en stukke dingen repareer je in plaats van ze te testen. Ons conversieoptimalisatiewerk scheidt die twee voordat er iets gebouwd wordt.