Quality Assurance Doen Voor een A/B Test

A/B testen zijn een belangrijk onderdeel van het conversie optimalisatie proces. Hiermee kan namelijk worden getoetst in hoeverre een beoogde wijziging aan de webshop of webshop een positief, negatief, of neutraal effect heeft op de doelen.

Introductie

Bij het opzetten van een A/B test komt een boel kijken. Zo dient een test bijvoorbeeld vlekkeloos te werken op een brede range aan browsers, apparaten, en schermformaten. Het is dan ook belangrijk om te controleren of er geen foutjes in een test geslopen zijn. Dit proces wel ook wel quality assurance (of kwaliteitsverzekering) genoemd.

Relevantie

Helaas is quality assurance echter een onderdeel waar vaak maar weinig aandacht aan wordt besteed, of regelmatig zelfs wordt overgeslagen. Het lijkt immers een boel tijd te kosten en weinig op te leveren. De gedachtegang hierbij is dan bijvoorbeeld dat er slechts kleine wijzigingen worden getest en "wat kan daar nou mis mee gaan?". Verder wil ook een krappe planning er nog wel eens voor zorgen dat quality assurance erbij inschiet.

Het overslaan van quality assurance kan er echter voor zorgen dat er testen live gaan die niet (voor iedere bezoeker) goed functioneren. Hierom is het dan ook van belang dat A/B testen wel goed worden gecontroleerd voordat ze live gaan. Dit kan de volgende voordelen opleveren.

Minder gefrustreerde bezoekers

Bijna niets is zo frustrerend voor een bezoeker als een website of webshop die het simpelweg niet goed doet. Denk hierbij aan knoppen die niet werken, formulieren met onzichtbare foutmeldingen, of elementen die over elkaar heen staan. Al dit soort punten kunnen het gevolg zijn van A/B testen die niet goed zijn doorgetest.

Minder testen moeten herstarten

In sommige gevallen komen teams er later toch achter dat er iets mis gaat met een test. Dit kan bijvoorbeeld zo zijn nadat er klachten van bezoekers zijn binnengekomen bij de support afdeling, of medewerkers zelf aan de bel trekken. In deze gevallen dient de test te worden stopgezet, gekloond, gerepareerd, nagekeken, en opnieuw live gezet te worden. Dit herstarten vraagt tijd en aandacht van het (vaak al erg drukke) CRO team. Ook zorgt het er echter voor dat er op deze manier minder testen per jaar gedraaid kunnen worden. Terwijl de stopgezette test live stond (waarvan de data nu wordt weggegooid) had er immers ook een andere test gedraaid kunnen worden die mogelijk tot waardevolle inzichten had geleid.

Meer betrouwbare en valide testen

In andere gevallen komen organisaties er echter nooit achter dat er een kapotte test live heeft gestaan. Wanneer er echter wel beslissingen op basis van deze test gemaakt worden, dan kan dit tot problemen leiden. Doordat de test niet (geheel) correct heeft gefunctioneerd, zal de data die hieruit voortkomt namelijk niet zeer betrouwbaar en valide zijn.

Minder omzet verlies

Tenslotte kosten kapotte testen simpelweg omzet. Wanneer een bezoeker immers niet (eenvoudig) zijn of haar doelen kan bereiken op de website, dan worden er minder producten of diensten afgenomen. Op deze manier wordt A/B testen een onnodig dure bezigheid, omdat er niet alleen op de kosten van het testen zelf gelet moet worden, maar ook op het verlies in omzet dat kapotte A/B testen in sommige gevallen kunnen veroorzaken.

Aandachtspunten

Onderstaande punten zijn geen complete lijst, maar geven slechts een overzicht van belangrijke punten. Elke organisatie zal immers haar eigen unieke aandachtspunten hebben, haar eigen accenten willen leggen, beschikking hebben over een verschillende mix aan medewerkers, budgetten, tools, etc. Voorgaande punten zullen dan ook hun uitwerking hebben in hoe quality assurance precies ingericht zal worden voor een maximaal rendement.

Naamgeving

Een goede naamgeving is belangrijk om de communicatie over A/B testen soepel te laten verlopen. Zonder goede naamgeving komen er namelijk gegarandeerd meetings over "dat experiment op de homepage" of "die ene met de aangepaste tekst". Persoonlijk ben ik voorstander van een constructie waarbij ieder experiment een ID krijgt. Denk hierbij aan bijvoorbeeld EXA-0001, EXA-0002, EXA-0003, etc. voor een bedrijf genaamd Example Inc. Zoals je ziet is er hierbij gekozen om niet alleen te werken met een nummer, maar ook met letters ervoor. Op die manier kan een CRO freelancer of CRO bureau ook eenvoudig de experimenten voor verschillende klanten uit elkaar halen. Tevens is er gekozen voor een aantal voorloopnullen om problemen met sortering te voorkomen die je bijvoorbeeld bij EXA-8 en EXA-10 zou hebben op sommige systemen. Bij voorkeur wordt dit ID overigens zo vroeg mogelijk aan een experiment toegewezen. Een goed moment hiervoor kan bijvoorbeeld het moment zijn waarop een experiment aan de roadmap wordt toegevoegd.

Ook voor varianten kan het verstandig zijn om een duidelijke structuur in de naamgeving te hanteren. Persoonlijk kies ik er meestal voor om het origineel 'Control' te te noemen en de variant met twee of drie woorden een naam te geven. Bijvoorbeeld 'With banner' of 'No reviews'. Mijn advies zou zijn om zelfs op een volledig Nederlandse website alsnog te werken met Engelse namen, je weet immers nooit of er in de toekomst nog eens niet-Nederlandse teamleden aangehaakt zullen worden.

Planning

Hierbij wordt er gecontroleerd of er meerdere experimenten tegelijk gaan draaien. Zijn deze vanuit een technisch perspectief compatibel met elkaar? Is er nagedacht over eventuele statistische interacties die er tussen de varianten op zouden kunnen gaan treden? Ook dient er te worden bepaald of er bijvoorbeeld campagnes of promoties zijn die invloed kunnen hebben op de experimenten. Komt er bijvoorbeeld een enorme sale aan in de geplande looptijd van het experiment, dan kan dit mogelijk een effect hebben op de resultaten. Of wordt er in een experiment melding gemaakt van een bepaalde vouchercode, is er dan vastgesteld of deze gedurende de hele looptijd van het experiment geldig is?

Zorg er in ieder geval voor dat geplande experimenten afgestemd zijn met de betreffende stakeholders. Dit zorgt er namelijk voor dat zij geen onverwachte 'vreemde zaken' op de pagina's onder hun beheer zien. Overigens kan ook een korte email bij het lanceren van een experiment goed helpen. Wanneer je daarin kort zaken uitlegt als de hypothese, varianten, looptijd, pagina's, etc. dan is dit een handig naslagwerk voor een stakeholder wanneer er vragen zouden ontstaan.

Verkeer

Experimenten hebben voldoende verkeer nodig om tot statistisch valide en betrouwbare resultaten te komen. Hierbij moet je niet alleen denken aan voldoende bezoekers op de betreffende pagina's, maar ook aan voldoende conversies op de KPI's waar het experiment zich op richt. Het kan namelijk een enorm verschil maken in de looptijd of een experiment zich richt op de doorklik van een productpagina (PDP) naar een winkelwagen, of op een daadwerkelijke aankoop.

Let er bij het nakijken van het verkeer ook op of de traffic allocation goed staat ingesteld. Dit is de verdeling van het verkeer tussen de verschillende varianten van het experiment. In de meeste gevallen is het raadzaam om het verkeer gelijk te verdelen over de varianten (dus 50% naar control en 50% naar de variant wanneer er met één variant wordt gewerkt).

Targeting

Op welke pagina's, apparaten, en browsers dient dit experiment te gaan draaien? Daarbij dient er bijvoorbeeld ook rekening gehouden te worden met zaken als URL parameters (zoals ?gclid of ?page). Zijn alle benodigde pagina's überhaupt wel met simpele targeting te vangen, of dient hier mogelijk gewerkt te worden met reguliere expressies of zelfs aanvullende tagging op de pagina's zelf? Dan zijn er ook nog uitzondering als problemen met trailing slashes of websites die zowel op www als op non-www werken waar natuurlijk ook nog op gelet dient te worden.

Segmenten

Naast pagina's, apparaten, en browsers kan een experiment ook nog richten op specifieke segmenten. Een bekende is dat een experiment alleen getoond dient te worden voor ingelogde bezoekers. Andere mogelijkheden zijn bijvoorbeeld dat een experiment alleen dient te tonen voor bezoekers die vanaf een bepaalde website af komen of die een bepaalde promotie hebben gezien.

Houd er hierbij ook rekening mee dat de preview modus van sommige testing tools beperkt rekening houdt met dergelijke 'audience targeting' criteria.

Doelen

De doelen waarop een A/B test beoordeeld wordt kunnen gemeten worden in de A/B testing tool zelf, of in een losse analysetool zoals Google Analytics of Adobe Analytics. Hoe dan ook dient er voor elk experiment vastgesteld te worden of de betreffende doelen correct worden opgeslagen in de gekozen tool. Wanneer er naast de primaire KPI's (zoals transacties of omzet) ook gewerkt wordt met secundaire KPI's (zoals clicks op een knop) dan dienen deze mogelijk nog los opgeslagen te worden.

Tracking

Een ander belangrijk onderdeel van de quality assurance is om na te kijken of de betreffende tools goed worden ingeladen. Wanneer bijvoorbeeld namelijk de A/B testing tool niet wordt ingeladen op sommige pagina's waarop het experiment zou moeten draaien, dan heeft dit een grote impact op de resultaten van het experiment. Hetzelfde geldt voor het niet (correct) ingeladen van de webanalyse tool en een eventuele bezoekersgedrag analyse tool zoals Hotjar of Clarity.

Compatibiliteit

Dient het experiment nog te werken voor bezoekers die gebruikmaken van Internet Explorer? Hoe zit dat met bezoekers op het schermformaat van een iPhone SE? Op de meeste websites zijn dit relatief kleine groepen bezoekers, die soms echter nog verantwoordelijk zijn voor een significant percentage van de omzet. Houd er bij de quality assurance dan ook rekening mee dat het experiment ook voor deze bezoekers goed werkt of dat zij worden uitgesloten van het experiment.

KPI's

Is er nagedacht op welke KPI's het resultaat van het experiment beoordeeld zal gaan worden? Dit is bijvoorbeeld nodig om een goede inschatting te kunnen maken van de doorlooptijd van het experiment. Ook heb je deze gegevens nodig om achteraf discussies te voorkomen wanneer bijvoorbeeld een bepaalde waarde (zoals de click-through rate) is toegenomen, maar een andere is afgenomen (zoals het aantal transacties).

Functioneel

Werkt alles naar behoren? Zijn er bijvoorbeeld JavaScript foutmeldingen te zien in de browser console? Of zijn er mogelijk onderdelen op de website die niet meer goed werken? Dergelijke problemen kunnen soms moeilijk te achterhalen zijn. Zorg er daarom voor dat je JavaScript foutmeldingen bijvoorbeeld opslaat in Google Analytics (en stel custom alerts in voor wanneer hun aantal zou toenemen). Ook kan het bijzonder lonen om in goed contact met de customer support afdeling te blijven. Zij horen vaak als eerste wanneer er problemen op de website zijn die je mogelijk tijdens de quality assurance over het hoofd hebt gezien.

Conclusie

Het uitvoeren van een goede quality assurance kan het verschil maken tussen een nutteloos experiment en eentje die betrouwbare en valide resultaten oplevert. De voordelen die in dit artikel zijn beschreven geven hierbij aan wat de meerwaarde daarvan voor een organisatie kan zijn. Om jezelf er van te verzekeren dat er zo min mogelijk problemen voortkomen uit A/B testing is het dan ook belangrijk om altijd quality assurance uit te voeren. Hierbij geldt: hoe nauwkeuriger deze wordt uitgevoerd, hoe kleiner de kans op problemen door een experiment is.