‘p-Hacking’ (oftewel ‘data fishing’ en ‘data snooping’) is de neiging om patronen in gegevens te ontdekken die statistisch significant lijken, terwijl er feitelijk geen effect is. Het fenomeen bestaat in verschillende vormen en maten, maar veelal zien we het terug als:

• Het continu monitoren van het experiment en deze stoppen zodra de waargenomen p-waarde onder een drempelwaarde (gewoonlijk 0,05) daalt.
• Het testen van vele hypothesen, maar alleen die testen rapporteren die significant zijn.
• Het uitsluiten van bezoekers of het aanpassen van data om toch de p-waarde onder de drempelwaarde te krijgen.

In dit artikel zal ik eerst duidelijk maken hoe groot het probleem van p-hacking is binnen de commerciële sector, waarom p-hacking schadelijk is voor je bedrijfsstrategie en wat je kunt doen om het te voorkomen.

p-Hacking in de commerciële sector

Behalve dat het een erkend probleem is binnen de wetenschap blijkt uit het recente onderzoek van Ron Berman et al. (2018) dat p-hacking, ondanks de groei in volwassenheid van de CRO markt, ook binnen de commerciële sector een veel voorkomend fenomeen is.

De resultaten van een analyse van 2.101 commerciële experimenten uit 2014, uitgevoerd op het A/B testing platform Optimizely lieten zien dat bij ongeveer 57% van de experimenten p-hacking plaatsvindt wanneer het experiment 90% zekerheid bereikt. Daarbij bleek dat van deze 57% ongeveer 70% helemaal geen enkel effect bleek te hebben en het percentage foutief ontdekte effecten (ook wel bekend als False Discovery Rate) bij een betrouwbaarheidsinterval van 90% toeneemt van 33% naar 42% (om zo de mogelijkheden tot p-hacking te verkleinen stapte Optimizely in 2015 daarom over naar sequential testing met een False Discovery Rate Control, zie Pekelis et al. 2015).

Wanneer is het risico op p-hacking het grootst?

Opvallend genoeg werden experimenten met kleine positieve effecten vaker vroegtijdig stopgezet dan experimenten met grote positieve effecten. De precieze reden hiervoor is niet duidelijk, maar een mogelijke verklaring zou kunnen liggen in de wens om kleine, maar toevallige positieve resultaten, te waarborgen door het experiment te stoppen voordat het effect terugvalt naar het gemiddelde.

Aan de andere kant kan het ook zo zijn dat men liever start met een nieuw experiment in plaats van tijd verspillen aan het testen van een klein effect. Of misschien zorgen (te) grote positieve effecten juist voor twijfels over de betrouwbaarheid van het experiment en kiest men er liever voor om langer te wachten tot het effect iets is afgezwakt.

Wat kost p-hacking jouw organisatie?

Op basis van de bevindingen uit het onderzoek zou je kunnen redeneren dat het vinden van een effect, zonder dat deze daadwerkelijk bestaat, ertoe leidt dat men stopt met zoeken naar mogelijke effectievere variaties. Als gevolg hiervan loop je eventuele beter presterende varianten mis of implementeer je variaties die na verloop van tijd misschien zelfs een klein negatief effect laten zien.

Zo werd er in het onderzoek van Ron Berman et al. berekend dat de kosten van een foutieve ontdekking rond de 1,95% van de gewonnen uplift liggen. Bij elkaar opgeteld komt dit overeen met 76% van de totale uplift.

Waarom komt p-hacking zo veel voor?

Het fenomeen p-hacking is al langere tijd bekend binnen de wetenschap doordat vele wetenschappers afhankelijk zijn van het aantal publicaties voor funderingen van hun werk. Maar waarom zouden marketeers en andere commerciële medewerkers zich bezighouden met p-hacking? Het implementeren van variaties die mogelijk eerder schadelijk zijn dan dat ze waarde leveren lijkt mij nou niet de beste bedrijfsstrategie.

Een eerste mogelijke verklaring is een tekort aan statistische vaardigheden. Veel mensen hebben niet de achtergrond of ervaring om de statistische resultaten van een platform goed te interpreteren. Bovendien doen A/B-testplatforms regelmatig aanbevelingen die geen rekening houden met de gevolgen van het herhaaldelijk controleren van de p-waarde tijdens het experiment of voor meerdere hypothesetesten.

Een tweede verklaring kan te vinden zijn in het enthousiasme en de verwachting om regelmatig positief significante resultaten te delen. Werknemers die verantwoordelijk zijn voor het uitvoeren van A/B-testen en zich zorgen maken over het (zichtbare) succes van hun CRO programma hebben op korte termijn baat bij het melden van significante resultaten.

Hoe kun je p-hacking voorkomen?

Op mijn werk zijn we maar al te goed bekend met de menselijke biases en onze neigingen om op zoek te gaan naar informatie die onze eigen aannames of overtuigingen bevestigen (lees meer over deze Conformation Bias in het artikel van Roos van Dam). Gelukkig hebben wij genoeg experts op het gebied van statistiek en psychologie in dienst om de kans op p-hacking zo veel mogelijk te verkleinen. Zo is er een aantal methodes en regels die vast onderdeel zijn geworden van ons CRO programma die p-hacking tegengaan. Ik zal ze één voor één bespreken.

1. Wordt alles goed gemeten?

Allereerst controleren we altijd voorafgaand aan een experiment of nieuw traject zorgvuldig of de A/B test-tool en de webanalytics-tool goed geïmplementeerd zijn. Op het moment dat een A/B test live gaat wordt meteen gecheckt of alle data goed binnenkomt, of de verdeling tussen A en B ook echt 50/50 is en of de targeting goed gaat. Daarnaast zorgen we ervoor dat alle noodzakelijke metingen goed zijn ingesteld (meet je alles wat je wilt meten?) en verzamelen we zoveel mogelijk informatie over het gedrag van de bezoeker.

Op deze manier kun je naast de informatie of je A/B testresultaten significant zijn (of niet) achterhalen of er andere inzichten zijn die je helpen het effect op gedrag te doorgronden. Op basis van deze aanvullende kennis kun je niet alleen op een later moment betere experimenten bedenken, maar blijf je ook kritisch kijken naar het daadwerkelijke effect dat jouw variant teweeg heeft gebracht. Let hier wel op dat je altijd een Overall Evaluation Criteria (OEC) vaststelt, zodat je niet verdwaald raakt in al je analyses en altijd voor ogen houdt wat voor jouw organisatie de belangrijkste meeting is.

2. Bayesiaans hypothese testen

We doen de analyse van onze A/B testen (in de meeste gevallen) aan de hand van Bayesiaanse statistiek (lees hier meer over onze keuze voor Bayesiaanse statistiek). Binnen de Bayesiaanse methode liggen de resultaten een stuk genuanceerder: op basis van een testuitslag wordt bepaald hoe groot de kans is dat de variant beter presteert dan de huidige situatie. Een testuitslag heeft daardoor geen binaire uitslag (winnaar of geen winnaar, zoals bij frequentistische statistiek), maar een kans van 0% tot 100%.

In tegenstelling tot frequentistische statistiek, vertelt de Bayesiaanse methode je dus niets over de beslissing die je moet nemen. Er wordt nergens geïnsinueerd of je de hypothese zou moeten accepteren of verwerpen. Hierdoor wordt je gedwongen om zelf verder uit te zoeken of de resultaten van je A/B test daadwerkelijk een positief effect hebben en ook na de implementatie je conversies zullen doen toenemen.

De keuze voor Bayesiaanse statistiek betekent echter niet dat je geen risico meer loopt om bijvoorbeeld vroegtijdig een experiment te stoppen (lees in punt drie en vier hoe je dit probleem kunt oplossen). De manier van rapporteren zorgt er alleen voor dat het advies op basis van je analyse minder stellig is en dus minder bepalend voor de mogelijke gevolgen van je experiment (implementatie of geen implementatie).

3. Start met een Bandbreedte Calculatie

Je bandbreedte is de hoeveelheid A/B-testen per jaar die je als bedrijf statistisch gezien kunt uitvoeren. Een bandbreedte berekening leert je welke pagina’s (templates) de meeste waarde toevoegen, waar de grootste optimalisatiekansen liggen, op welke pagina’s (templates) A/B-testen kunnen worden uitgevoerd en hoe lang deze A/B testen zouden moeten duren.

Doordat je met deze berekening van tevoren vaststelt welk effect er per pagina behaald moet worden (je power) en hoe lang een test aan moet staan, voorkom je dat je hier tijdens het experiment, of na afloop, bij de analyse dingen gaat aanpassen en risico loopt op p-hacking.

4. Gewoon niet spieken

Naast het feit dat wij op basis van de bandbreedte berekening vaststellen hoe lang een A/B test aan moet staan en hoe hoog het behaalde effect moet zijn is spieken bij lopende testen bij ons op kantoor simpel weg verboden. Los van een aantal berekeningen die we uitvoeren om te controleren of er niets helemaal mis gaat, mag niemand tussendoor het verloop van een experiment in de gaten houden.

En afgezien van een enkel zwak moment van sommige (veelal enthousiaste) collega’s, lijken we deze regel (redelijk) goed te volgen en acteren we niet op deze spiekmomenten.

Ga het gevecht aan met p-hacking

Hopelijk heeft dit artikel je duidelijk gemaakt waarom het van belang is dat je je als CRO specialist of data analist (maar ook de rest van het CRO team) bewust bent van de gevaren, maar vooral ook de kosten van p-hacking. Het komt, jammer genoeg, nog steeds vaak voor. En ondanks dat het in de meeste gevallen gebeurt met de beste bedoelingen (heel veel enthousiasme voor A/B testen) is het op de korte, maar vooral ook lange termijn, schadelijk voor de organisatie.

Ik heb in dit artikel een aantal manieren omschreven die voor ons helpen bij het voorkomen van p-hacking, maar er zijn er vast nog veel meer. Deel ze dus vooral, want ook dit soort kennis zal de markt alleen maar doen groeien in volwassenheid.