De methode voor A/B-testen is eenvoudig uit te leggen: verdeel het verkeer, vergelijk de resultaten en wacht op statistische significantie. Het is echter makkelijk om de methode verkeerd toe te passen, en een aantal fouten komen regelmatig terug, zelfs bij ervaren teams. Dit artikel bespreekt de meest voorkomende fouten bij A/B-testen, waarom ze de resultaten vertekenen en hoe je ze het beste kunt vermijden.
Fout nr. 1: Testen zonder een duidelijke hypothese
Een test starten omdat een concurrent een vergelijkbare verandering heeft doorgevoerd, of omdat een designtrend online circuleert, levert zelden bruikbare resultaten op. Zonder een duidelijke hypothese die een observatie, een verandering en een verwachte meetwaarde met elkaar verbindt, wordt het lastig om het resultaat te interpreteren: een succesvolle test onthult niets over het 'waarom', en een mislukte test leert niets dat overdraagbaar is naar de volgende test.
De correctie is eenvoudig toe te passen: formuleer vóór elke test de hypothese in de vorm "omdat [observatie], geloven we dat [verandering] [effect] zal veroorzaken, gemeten met [maatstaf]". Als deze zin niet duidelijk kan worden afgemaakt, is de test waarschijnlijk nog niet klaar om te worden uitgevoerd.
Fout nr. 2: De test stoppen zodra een resultaat significant lijkt.
Dit is waarschijnlijk de meest voorkomende fout, zelfs bij teams die bekend zijn met statistische theorie. De meeste tools tonen een realtime betrouwbaarheidsniveau, dat bij elk nieuw bezoek opnieuw wordt berekend. Door dit cijfer dagelijks te controleren en de test te stoppen zodra het boven de 95% komt – soms al na twee of drie dagen – vergroot je de kans op een willekeurige fluctuatie die op een bepaald moment op een reëel effect lijkt.
Dit fenomeen, in de literatuur over gecontroleerde tests beschreven als "peeking", kan het aantal vals-positieve resultaten aanzienlijk verhogen ten opzichte van het opgegeven betrouwbaarheidsniveau. De oplossing is om een minimale steekproefomvang en -duur vast te stellen voordat de test wordt uitgevoerd (zie het artikel op deze blog over het berekenen van de steekproefomvang), en het resultaat pas als definitief te beschouwen wanneer aan beide voorwaarden is voldaan – nooit eerder, zelfs niet als het dashboard er al veelbelovend uitziet.
Fout nr. 3: Te veel wijzigingen tegelijk testen
Het tegelijkertijd wijzigen van de titel, afbeelding, knop en lay-out van een pagina in één enkele variant lijkt misschien efficiënt – één test in plaats van vier. Het probleem is echter dat een positief resultaat niet onthult welke van de vier wijzigingen het effect teweegbracht, noch of sommige ervan een resultaat belemmerden dat zonder die wijzigingen nog beter had kunnen zijn.
Door per test een variabele te isoleren, kunt u het resultaat duidelijk toeschrijven aan een specifieke wijziging en deze inzichten vervolgens gebruiken voor volgende tests. Dit betekent niet dat u zich moet beperken tot micro-aanpassingen: een complete pagina-herontwerp kan absoluut als één enkele "herontwerp"-variant worden getest ten opzichte van de controlevariant, zolang het doel van de test maar is om het herontwerp als geheel te valideren in plaats van het effect van elk afzonderlijk onderdeel te isoleren.
Fout #4: De vereiste steekproefgrootte wordt genegeerd.
Het starten van een test zonder eerst het benodigde aantal bezoekers in te schatten, leidt vaak tot een van de volgende twee problematische situaties: ofwel wordt de test te vroeg gestopt door gebrek aan geduld, wat vergelijkbaar is met de 'peeking error', ofwel blijft de test oneindig lang draaien zonder dat er ooit een duidelijke beslissing wordt genomen, waardoor een deel van het verkeer op een niet-gevalideerde variant maandenlang vastloopt.
Door de steekproefomvang vóór de lancering te berekenen, gebaseerd op het huidige conversiepercentage en het minimale effect dat we willen detecteren, weten we van meet af aan of de test haalbaar is binnen een redelijke termijn en kunnen we onze ambities daarop afstemmen in plaats van dit achteraf te ontdekken.
Fout #5: Verschillen tussen segmenten worden genegeerd
Een geaggregeerd resultaat kan zeer uiteenlopende gedragingen in verschillende verkeerssegmenten maskeren. Een wijziging kan de conversie op mobiele apparaten verbeteren, terwijl deze op desktops licht daalt, of kan gunstig zijn voor nieuwe bezoekers zonder dat dit gevolgen heeft voor terugkerende bezoekers. Door uitsluitend naar het totale cijfer te kijken, bestaat het risico dat een resultaat wordt gegeneraliseerd dat in werkelijkheid slechts een deel van het publiek ten goede komt – of dat een wijziging met een algeheel positief effect een daling in een strategisch segment maskeert.
Het is niet nodig om elk denkbaar segment voor elke test te analyseren, maar het controleren van de consistentie van het resultaat op de assen die het meest relevant zijn voor uw bedrijf (type apparaat, nieuwe bezoekers versus terugkerende bezoekers, belangrijkste verkeersbronnen) voordat u een conclusie trekt, blijft een eenvoudige controle die onaangename verrassingen na de implementatie voorkomt.
Fout nr. 6: Correlatie, causaliteit en het nieuwigheidseffect door elkaar halen.
Een goed uitgevoerde A/B-test met een willekeurige verkeersverdeling legt doorgaans een redelijk betrouwbaar causaal verband vast tussen de geteste verandering en het gemeten effect. Er blijft echter een mogelijke vertekening bestaan: het nieuwigheidseffect. Een nieuwe lay-out kan meer aandacht trekken simpelweg omdat deze anders is, een effect dat verdwijnt zodra terugkerende bezoekers eraan gewend zijn. Dit fenomeen is met name belangrijk om in de gaten te houden bij zeer zichtbare veranderingen die worden getest bij een publiek met een hoog percentage terugkerende bezoekers.
De eenvoudigste aanpak is om de duur van de test te verlengen tot voorbij het strikte statistische minimum wanneer een nieuwigheidseffect wordt vermoed, en, indien het volume dit toelaat, de ontwikkeling van het conversiepercentage van de variant te vergelijken tussen de eerste en de laatste dag van de test: een effect dat duidelijk afneemt in de loop van de tijd is een teken van een nieuwigheidseffect in plaats van een blijvende verbetering.
Fout nr. 7: Het nalaten om de resultaten te documenteren
Een test waarvan de resultaten niet op een gestructureerde manier worden vastgelegd – hypothese, bijgehouden meetwaarden, duur, steekproefgrootte en uitkomst – verliest veel van zijn waarde op de lange termijn. Zonder deze vastlegging wordt hetzelfde idee soms een jaar later opnieuw getest vanwege een gebrek aan collectief geheugen, en individuele inzichten leiden nooit tot een genuanceerder en cumulatief begrip van bezoekersgedrag.
Het bijhouden van een gestructureerde testgeschiedenis, zelfs in een eenvoudige vorm, is een van de minst kostbare en meest lonende investeringen die een team kan doen in zijn experimenteerprogramma. Het stelt je bovendien in staat om na verloop van tijd terugkerende thema's te identificeren (wijzigingen die een gebruikerservaring vereenvoudigen werken bijvoorbeeld bijna altijd beter dan wijzigingen die deze verrijken), specifiek voor je doelgroep.
Fout nr. 8: Een resultaat generaliseren buiten de context.
Een test die uitsluitend tijdens een atypische verkoopperiode wordt uitgevoerd (uitverkoop, piekseizoensdrukte, eenmalige reclamecampagne) kan een resultaat opleveren dat niet gedurende de rest van het jaar wordt herhaald, omdat het bezoekersprofiel in die periode verschilt van het gebruikelijke profiel. Evenzo is een resultaat verkregen uit één verkeersbron (bijvoorbeeld een specifieke reclamecampagne) niet noodzakelijkerwijs generaliseerbaar naar al het websiteverkeer.
Door aandacht te besteden aan de context waarin een test is uitgevoerd – de periode, de belangrijkste verkeersbronnen, uitzonderlijke gebeurtenissen tijdens de testperiode – kan de werkelijke reikwijdte van een resultaat nauwkeuriger worden ingeschat voordat het op grote schaal wordt geïmplementeerd, of voordat wordt besloten om het opnieuw te testen in een meer representatieve context als er twijfel bestaat.
Fout #9: De technische controle vóór de lancering wordt overgeslagen.
Een test kan methodologisch deugdelijk zijn — goede hypothese, goede steekproef, slechts één variabele getest — en toch een onbruikbaar resultaat opleveren als een technisch probleem bij de lancering onopgemerkt blijft: een slecht geconfigureerde conversietracker die bepaalde gebeurtenissen niet meetelt, een variant die slecht wordt weergegeven in een specifieke browser of op een bepaald schermformaat, of een element van de variant dat een ander onderdeel van de pagina verstoort zonder dat dit direct opvalt.
Een systematische controle vóór de start van een test voorkomt deze valkuilen: visualiseer de variant op de belangrijkste browsers en schermformaten die door uw doelgroep worden gebruikt, activeer handmatig de geregistreerde conversiegebeurtenis om te bevestigen dat deze wordt vastgelegd, en laat de test een paar uur draaien met een lagere verkeersbelasting voordat u overschakelt naar de uiteindelijke belasting. Zo kunt u eventuele afwijkingen opsporen voordat ze een grotere steekproef beïnvloeden. Deze controle duurt zelden langer dan tien minuten en voorkomt dat u na enkele dagen dataverzameling ontdekt dat een deel van de resultaten onbruikbaar is.
Een korte checklist voordat je een test start.
Om al deze fouten in een direct bruikbare vorm samen te vatten, volgen hier de punten die u moet controleren voordat u een A/B-test uitvoert:
- De hypothese is helder geformuleerd, met één observatie, één verandering en één succesindicator.
- Per variant wordt slechts één variabele aangepast, tenzij dit bewust gebeurt om een algehele herziening als een samenhangend geheel te testen.
- De benodigde steekproefomvang werd berekend op basis van het huidige conversiepercentage en het minimaal gewenste effect.
- Er wordt vooraf een minimale duur vastgesteld (minimaal één tot twee weken), die wordt gerespecteerd, zelfs als na enkele dagen al een resultaat duidelijk lijkt.
- De conversietracking werd handmatig getest vóór de definitieve lancering.
- De variant werd visueel geverifieerd op de belangrijkste apparaten en browsers van het publiek.
- Er is een plan opgesteld om het eindresultaat te documenteren, wat dat ook moge zijn.
Het kost slechts een paar minuten om deze lijst vóór elke lancering door te nemen, en hij dekt de overgrote meerderheid van de fouten die een test achteraf ongeldig maken. Deze verificatietijd wordt ruimschoots gecompenseerd door de betrouwbaarheid die de uiteindelijke beslissing oplevert.
Belangrijkste conclusies
Geen van deze fouten vereist geavanceerde hulpmiddelen om te voorkomen; ze worden gecorrigeerd door methode en discipline: een hypothese formuleren vóór elke test, slechts één variabele tegelijk testen, een vooraf berekende steekproefomvang, een constante testduur, aandacht voor verschillen tussen segmenten en systematische documentatie van de resultaten. Het zijn deze gewoonten, meer dan de keuze voor het ene of het andere hulpmiddel, die bepalen of een A/B-testprogramma op de lange termijn betrouwbare beslissingen oplevert.
BlastOptimize is ontworpen om de technische belemmeringen in dit proces weg te nemen – het creëren van varianten zonder code, een geïntegreerde berekening van de steekproefomvang en realtime monitoring van de statistische significantie – zodat het team zich kan blijven richten op wat er echt toe doet: de kwaliteit van de hypothese en de nauwkeurigheid van de methode. Als u een van deze fouten in uw eerdere tests herkent, is dit een goede gelegenheid om het onderwerp in uw volgende test opnieuw te bekijken met een robuustere methode.
Reacties zijn uitgeschakeld.