Jouw 7-stappenplan voor het opzetten van een A/B-test

Stap 1: Hypothese opstellen

De hypothese is dat wat je gaat onderzoeken. En waarover je achteraf kunt zeggen of hij waar of niet waar is.

Stel je hypothese op in een format als deze:

Als we [dit aanpassen],
dan zullen we [deze gedragsverandering zien]
omdat [dit is gebeurd in de overweging van de bezoeker]

Onder ‘als’ kun je meerdere uitwerkingen formuleren, zodat je met elke uitwerking dichter bij de waarheid komt.

Stap 2: Design

Staat de hypothese? Dan is het tijd om je wijzigingen uit te werken als mock-up, of schets een functioneel ontwerp waar je met je stakeholders over kunt praten. Ontwerp gerust meerdere varianten van hetzelfde idee, maar houd in je achterhoofd dat je het beste kunt testen met een enkele variant ten opzichte van ‘A’. Met elke extra variant moet je steekproefgrootte substantieel stijgen om hetzelfde effect te kunnen meten. Vaak is het sneller (en betrouwbaarder) om A/B testen achter elkaar uit te voeren, dan een enkele A/B/C test uit te voeren.

Stap 3: Development + QA

Zodra je test technisch staat, begint het echte werk pas: ervaren wat je bezoeker ervaart. Wat ziet hij? Hoe voelt de pagina aan? En werkt alles zoals bedoeld? Je eerste instinct is misschien om de ‘preview’-functie van je testtool te gebruiken. Begrijpelijk, maar helaas geeft die je vaak een vertekend beeld. Je ziet dan niet precies wat je bezoekers straks écht te zien krijgen.

Onze tip: zet de A/B-test live, maar zorg ervoor dat alleen jij (of je team) hem kunt bekijken via een extra parameter in de URL. Zo simuleer je de échte gebruikerservaring, zonder dat andere bezoekers de test al te zien krijgen. Bijvoorbeeld zo: https://happyhorizon.com/nl/insights/?experiment_qa=true

Stap 4: Steekproefberekening

Als de test klaar staat, moet je gaan bepalen hoe lang deze actief moet zijn voordat je een betrouwbare conclusie kunt trekken. Want stop je te  vroeg? Dan trek je mogelijk conclusies op basis van toeval.

Om dat te voorkomen, ga je een steekproef berekenen. Dat is het aantal bezoekers dat nodig is per variant in je test om betrouwbaar (en binnen een redelijke termijn van 4 tot 6 weken) te kunnen bepalen of je wijziging effect heeft gehad.

Stap 5: Klaar voor livegang

Als alles is doorgetest, is het tijd voor livegang. Breng iedereen in de organisatie op de hoogte, zoals de klantenservice. Zo weten zij wat er aan de hand is met de website, bijvoorbeeld als je test met bezorgkosten of levertijden.

Let tijdens de test altijd op of de verdeling van de bezoekers over de tests gelijk blijft. De check noemen we een ‘Sample Ratio Mismatch’-controle.

Let op: is de p-waarde kleiner dan 0,01? Dan weet je dat er iets mis is gegaan, al laat de formule je niet zien wat precies. Stop de test meteen en onderzoek waar het fout loopt.

Stap 6: De analyse van resultaten

Is de benodigde steekproefgrootte bereikt? Dan is het tijd voor de belangrijkste vraag van je experiment: “Gedraagt de gebruiker zich écht anders in de variant dan in de huidige situatie?”

Om dat te beoordelen, heb je meer nodig dan alleen een hoger conversiepercentage. Je wilt weten of het verschil betekenisvol is of toeval uitgesloten kan worden. En dat doe je met een statistische toets.

Bij A/B-tests met grote aantallen bezoekers en conversies is de z-toets een betrouwbare methode. Hiermee bepaal je hoe groot het verschil tussen variant en controle is.

Stap 7. Rapporteren voor stakeholders

Al die wiskunde is machtig interessant, maar je manager of directeur valt er waarschijnlijk door in slaap. Zij willen waarschijnlijk maar één ding weten: Moeten we de wijziging implementeren, of niet?

Daarom is storytelling erg belangrijk. Je bouwt namelijk aan je merk, niet aan cijfers. Om iedereen te overtuigen van het wel of niet doorvoeren van je geteste wijziging, kun je dit in je verhaal opnemen:

1. Probleemstelling – Het absolute begin van je verhaal is natuurlijk waarom iets getest moest worden. Waar liepen bezoekers tegenaan en welke risico’s wilden we vermijden?
2. Designoplossing – Waarom hebben we gekozen voor het geteste design? Welk gebruikersprobleem zou dit opgelost moeten hebben?
3. Grafieken – Een duidelijke afbeelding van een staafdiagram  of kansdichtheid grafiek die de gemeten verandering laat zien komt beter over dan een stortvloed aan getallen.
4. Business case – Laat zien wat voor potentiële invloed de geteste wijziging heeft op de omzet. Zijn investeringen hiervoor gerechtvaardigd? Breng ook de risico’s in kaart, want niets is zwart-wit.
5. Conclusie – Geef met overtuiging aan of de wijziging wel of niet geïmplementeerd moet worden. Presenteer ook een vervolg op het huidige experiment, want van een enkele test kun je nauwelijks zeggen of je de best mogelijke oplossing hebt gevonden.