Valse positieve resultaten bij A/B-testen: de oorzaken die we niet zien.

Bijgewerkt op 25 september 2026 — Begrijp de oorzaken van valse positieven bij A/B-testen voordat ze uw beslissingen vertekenen.

Samenvatting

• Een vals positief resultaat, buiten de puur statistische definitie.
• Steekproefverhouding mismatch: de vals-positieve uitslag die zijn naam niet durft uit te spreken
• Bot-verontreiniging: een onderschat probleem
• Kalendereffecten: dag van de week, seizoensinvloeden, aanbiedingen
• Een korte herinnering over spieken.
• Hoe kun je achteraf vals-positieve resultaten in A/B-testen opsporen?
• Checklist om valse positieven in A/B-testen te voorkomen voordat je gaat generaliseren.
• Veelgestelde vragen
• Belangrijkste conclusies

Valse positieve resultaten bij A/B-testen komen niet altijd van de verwachte plek: een onevenwicht van 1% in de verdeling van je verkeer tussen de twee geteste versies kan al genoeg zijn om een ​​variatie van 2% in je statistieken te veroorzaken. de cijfers gepubliceerd door het DoorDash-engineeringteamGeen verschil van 1% in het eindresultaat, maar een variatie van 2% die simpelweg ontstaat doordat de twee groepen niet langer echt vergelijkbaar zijn. En toch controleren de meeste teams dit punt nooit voordat ze hun conversieratio bekijken.

Deze handleiding gaat verder dan de klassiek vals positief — dat wil zeggen, dat het voortkomt uit een verkeerd geïnterpreteerde betrouwbaarheidsdrempel of herhaaldelijk de resultaten bekijken. Hij onderzoekt met name drie technische oorzaken van valse positieven bij A/B-testen. Deze oorzaken maken een test ongeldig nog voordat statistiek een rol speelt: onevenwichtige steekproef, botcontaminatie en timingseffecten.

Een vals positief resultaat, buiten de puur statistische definitie.

Een vals positief resultaat treedt op wanneer een variant als winnaar wordt aangewezen, terwijl dit in werkelijkheid niet het geval is. De meest genoemde oorzaak is statistisch van aard: een betrouwbaarheidsniveau dat per toeval is bereikt, een te kleine steekproefomvang of een test die te vroeg is gestopt. Maar dat is slechts een deel van het probleem.

Een andere reeks oorzaken, die technischer en moeilijker te detecteren zijn, produceert precies hetzelfde symptoom: een resultaat dat duidelijk lijkt, maar gebaseerd is op gegevens die al vóór de statistische berekening gebrekkig waren. Zelfs een perfect ontworpen test die gedurende de aanbevolen tijd wordt uitgevoerd, kan nog steeds een vals positief resultaat opleveren. De oorzaak: verkeer dat nooit vergelijkbaar is geweest tussen de twee groepen.

Steekproefverhouding mismatch: de vals-positieve uitslag die zijn naam niet durft uit te spreken

Het concept dat in Franstalige handleidingen over dit onderwerp vrijwel ontbreekt, terwijl het toch een van de standaardcontroles is van de grootste experimentele platforms, is de Sample Ratio Mismatch, oftewel SRM.

Het principe is eenvoudig te begrijpen. Een A/B-test die is geconfigureerd om het verkeer gelijk te verdelen (50/50) zou, bij een voldoende grote steekproef, een verdeling moeten opleveren die dicht bij deze verhouding ligt. Wanneer de daadwerkelijk waargenomen verdeling significant afwijkt van de verwachte verdeling – bijvoorbeeld 55/45 in plaats van 50/50 – duidt dit erop dat een technisch probleem een ​​van de twee groepen treft, ongeacht eventuele conversieresultaten.

DoorDash beschrijft verschillende veelvoorkomende oorzaken van SRM (Site Recognition Mapping) in hun eigen systeem: medewerkers die standaard in een groep zijn opgenomen via vroege toegang tot een functie, bugfixes die tijdens het testen zijn doorgevoerd maar de geschiedenis van reeds blootgestelde gebruikers niet "resetten", of simpelweg verkeerd geconfigureerde datafiltering. In elk van deze gevallen meet het testresultaat – zelfs als het statistisch significant is – niet langer wat het zou moeten meten.

Hoe een onjuiste monsterverhouding te detecteren en te corrigeren

Detectie wordt meestal gedaan met een chi-kwadraat toets toegepast op de waargenomen verdeling tussen de groepenDit is een controle die DoorDash systematisch uitvoert, zelfs voordat er naar conversiestatistieken wordt gekeken. Het bedrijf meldt dat het aantal incidenten met betrekking tot SRM (Sales Relationship Management) met 70% is gedaald in zes maanden na de automatisering van deze controle. Dit bewijst dat het probleem, zodra het actief wordt gemonitord, grotendeels wordt opgelost voordat het productbeslissingen beïnvloedt.

In de praktijk: voordat je een winnend resultaat viert, controleer dan of het aantal bezoekers in elke groep overeenkomt met de oorspronkelijke verdeling. Een ogenschijnlijk kleine afwijking – een paar procentpunten – kan al genoeg zijn om de hele analyse ongeldig te maken.

Deze verificatie is niet alleen van toepassing op platforms die tientallen miljarden gebeurtenissen per dag verwerken, zoals DoorDash. Het principe geldt evenzeer voor kleinere e-commercewebsites: het enige verschil is het verkeersvolume dat nodig is om de chi-kwadraattoets de afwijking betrouwbaar te laten detecteren. Bij een klein volume kan een onevenwichtigheid statistisch onzichtbaar blijven, terwijl het resultaat toch vertekend raakt. Des te meer reden om de verdeling visueel te controleren voordat u volledig vertrouwt op geautomatiseerde berekeningen.

Bot-verontreiniging: een onderschat probleem

Een tweede, vaak over het hoofd geziene technische reden is dat een aanzienlijk deel van het geteste verkeer soms niet door mensen wordt gegenereerd. analyse gepubliceerd door PeakhourEen specialist op het gebied van webbeveiliging noemt het voorbeeld van een klant die ontdekte dat 40% van hun testverkeer afkomstig was van bots – een cijfer waar je duizelig van wordt als je bedenkt dat dit verkeer in de meeste A/B-testtools exact als menselijk verkeer wordt geteld.

Het probleem wordt verergerd door de democratisering van residentiële proxy's, waardoor geautomatiseerd verkeer zich kan voordoen als individuele bezoekers verspreid over miljoenen verschillende IP-adressen, waardoor traditionele detectiemethoden (IP-blokkering, bandbreedtebeperking) grotendeels ineffectief worden.

Een bot gedraagt ​​zich uiteraard niet als een menselijke bezoeker: hij converteert niet op dezelfde manier, blijft niet even lang op de pagina en kan zelfs asymmetrisch verdeeld zijn over uw twee versies als zijn surfgedrag verschilt (bijvoorbeeld een bot die systematisch de eerste link op een pagina volgt). Het resultaat: een gemeten conversieratio die niet langer het werkelijke gedrag van uw publiek weerspiegelt, zonder dat er waarschuwingen worden geactiveerd als u dit verkeer niet specifiek filtert.

Dit risico treft met name e-commercewebsites met veel advertentieverkeer, waar het grote aantal klikken ook meer geautomatiseerd verkeer aantrekt voor prijsvergelijkingen of het verzamelen van concurrentiegegevens. Voor dit type profiel is het filteren van niet-menselijk verkeer vóór de analyse niet langer een secundaire optie, maar een even essentiële stap als de significantieberekening zelf – een punt dat we verder toelichten in onze handleiding over...A/B-testen voor e-commerce.

Kalendereffecten: dag van de week, seizoensinvloeden, aanbiedingen

Een derde, bekendere maar in de praktijk nog steeds onderschatte oorzaak is dat koopgedrag sterk varieert afhankelijk van de dag van de week, de tijd van de maand en lopende aanbiedingen. Een test die op maandag wordt gestart en op woensdag wordt stopgezet omdat het "al significant lijkt", legt in werkelijkheid slechts een zeer specifiek segment van het gedrag vast, en niet een representatieve trend.

Dit risico is des te reëler omdat het koopgedrag in Frankrijk een sterke seizoensinvloed vertoont – uitverkoopperiodes, Black Friday, feestdagen – waardoor het gebruikelijke conversiepercentage aanzienlijk kan afwijken, in beide richtingen. Het uitvoeren van een test tijdens een van deze periodes, zonder dit expliciet in de analyse te vermelden, komt neer op het generaliseren van een resultaat dat de rest van het jaar niet zal worden herhaald.

De eenvoudigste praktische regel blijft om een ​​test altijd uit te voeren over volledige veelvouden van zeven dagen, nooit over een willekeurig aantal dagen. Dit zorgt ervoor dat elke dag van de week even vaak vertegenwoordigd is in de uiteindelijke steekproef, ongeacht de totale duur van de test.

Een test van 10 dagen bevat bijvoorbeeld meer maandagen en dinsdagen dan zaterdagen en zondagen – een onevenwichtigheid die de resultaten kan vertekenen in de richting van winkelgedrag op weekdagen, wat op de meeste gangbare websites verschilt van het gedrag in het weekend. Door de test te verlengen naar 14 of 21 dagen, in plaats van te kiezen voor een rond getal dat geen rekening houdt met deze beperking, wordt deze vertekening gecorrigeerd zonder de complexiteit te vergroten.

Een korte herinnering over spieken.

Een vierde oorzaak, deze keer van statistische aard, verdient een korte vermelding zonder hier verder op in te gaan: "peeking", wat inhoudt dat men de resultaten van een test bekijkt terwijl deze loopt en besluit te stoppen zodra een gunstig signaal verschijnt. We beschrijven dit mechanisme, met de precieze cijfers die hierover zijn gepubliceerd, in ons artikel gewijd aan de statistische significantie — Essentiële aanvullende literatuur om alle oorzaken van vals-positieve resultaten te behandelen, zowel technische als statistische.

Hoe kun je achteraf vals-positieve resultaten in A/B-testen opsporen?

Je kunt een resultaat dat al wijdverspreid is nog steeds achteraf verifiëren. Drie waarschuwingssignalen zouden aanleiding moeten geven tot bezorgdheid:

• De aangekondigde winst is niet terug te vinden in de algemene cijfers van het bedrijf. enkele weken na de generalisatie, toen het op deze schaal zichtbaar had moeten zijn.
• Een A/A-test (Een vergelijking tussen twee strikt identieke versies) uitgevoerd op hetzelfde verkeerssegment onthult een significant verschil waar statistisch gezien geen verschil zou moeten zijn — een teken dat de testinfrastructuur zelf ruis produceert.
• De verdeling van het verkeer tussen de twee groepenDe achteraf geverifieerde configuratie komt niet overeen met de configuratie die aan het begin van de test was ingesteld.

Dit laatste punt is precies wat een geautomatiseerde controle op afwijkingen in de steekproefverhouding kan detecteren, zelfs voordat dit onderzoek achteraf nodig is. Het is een van de meest concrete argumenten voor een tool die dit soort afwijkingen continu in plaats van op aanvraag monitort.

Het is niet alleen een kwestie van gemak: een onderzoek dat wordt uitgevoerd nadat een verandering is doorgevoerd, is altijd duurder dan een onderzoek dat voorafgaat. De tijd die wordt besteed aan het begrijpen waarom een ​​verwachte winst nooit terug te vinden is in de bedrijfsresultaten, had beter gebruikt kunnen worden om de volgende hypothese op de lijst te testen.

Checklist om valse positieven in A/B-testen te voorkomen voordat je gaat generaliseren.

Voordat een succesvolle variant voor 100% van het verkeer wordt ingezet, beperken vier snelle controles het risico op wijdverspreide valse positieven:

• Komt de waargenomen verdeling tussen de groepen overeen met de verwachte configuratie (geen afwijking in de steekproefverhouding)?
• Heeft de test een volledige periode van zeven dagen bestreken, zonder een ongebruikelijke promotieperiode te overlappen?
• Heeft u het verkeer gefilterd om bots en identificeerbaar niet-menselijk verkeer uit te sluiten?
• Heeft de test de geplande duur bereikt, zonder dat u deze voortijdig hebt gestopt op basis van een gunstig signaal dat u onderweg hebt waargenomen?

Deze controles duren slechts een paar minuten en voorkomen dat er wekenlang beslissingen worden genomen op basis van een resultaat dat in de praktijk nooit zal worden gereproduceerd. Een slecht gedistribueerde test kan dit soort vertekening zelfs al introduceren vóór de analysefase – zie onze pagina hierover. Ultrasnelle diffusie Hierin wordt beschreven hoe bijwerkingen als gevolg van een gebrekkige technische implementatie van de test kunnen worden voorkomen. Het beste moment om deze checklist te integreren is tijdens de configuratiefase, zelfs vóór de lancering – dit leggen we uit in onze handleiding over de doelen en het bijhouden van de voortgang van een A/B-test, om te voorkomen dat een probleem achteraf moet worden vastgesteld in plaats van het te voorkomen.

Veelgestelde vragen

Wat is een Sample Ratio Mismatch (SRM)?

Dit is een onverwachte onevenwichtigheid in de verkeersverdeling tussen testgroepen – bijvoorbeeld een gemeten verdeling van 55/45 terwijl 50/50 werd verwacht. Een SRM (Site Redirect Mapping) duidt bijna altijd op een technisch probleem (omleidingsfout, bot, onjuiste filtering) dat het testresultaat ongeldig maakt, ongeacht de ogenschijnlijke statistische significantie ervan.

Hoe detecteer je een mismatch in de monsterverhouding?

Een chi-kwadraat toets, toegepast op de waargenomen verdeling tussen groepen, kan een abnormale onbalans detecteren. Sommige experimentele platforms voeren deze toets automatisch uit voor elke test en geven een waarschuwing nog voordat de conversieresultaten worden weergegeven.

Kunnen bots een A/B-test vertekenen?

Ja, en we onderschatten vaak de omvang van het probleem: sommige websites hebben ontdekt dat tot wel 40% van hun testverkeer afkomstig was van bots, met name via residentiële proxies die moeilijk te onderscheiden zijn van regulier menselijk verkeer.

Geeft een test die op maandag is gestart een betrouwbaar resultaat op vrijdag?

Nee. Koopgedrag verschilt vaak tussen weekdagen en weekenden. Een test die niet minstens een volledige cyclus van zeven dagen omvat, loopt het risico een kalendereffect te meten in plaats van een werkelijk effect van de geteste variant.

Is spieken (te vaak naar de resultaten kijken) de enige oorzaak van vals-positieve resultaten?

Nee. Het is een goed gedocumenteerde statistische oorzaak, maar valse positieven kunnen ook voortkomen uit technische oorzaken die onafhankelijk zijn van de statistische methode: onevenwichtigheid in de steekproef, besmetting door bots of ongecontroleerde timingseffecten.

Belangrijkste conclusies

Het opsporen van valse positieven bij A/B-testen draait niet alleen om statistische significantie – dat is slechts de helft van het werk. De andere helft vindt plaats nog voordat het betrouwbaarheidsniveau wordt berekend: een evenwichtige verkeersverdeling, verkeer vrij van botvervuiling en een testduur die een volledige cyclus bestrijkt in plaats van een momentopname gebaseerd op een bepaalde kalender.

Het cijfer van DoorDash is het onthouden waard: een onevenwichtigheid van 1% kan al genoeg zijn om een ​​variatie van 2% in je statistieken te veroorzaken. Op deze schaal kan een test die "succesvol lijkt" heel goed slechts een technisch artefact meten – en geen echte conversiewinst.

Om dit risico te beperken zonder elke test handmatig te hoeven controleren, hebben we onze oplossing ontwikkeld. visuele editor omvat een distributiecontrole bij elke testlancering, en de CRO-autopilot kan automatisch een afwijking signaleren voordat er een productbeslissing wordt genomen. Hoewel de hier besproken concepten misschien nog onduidelijk zijn, kan onze CRO-woordenlijst legt ze in eenvoudige taal uit — en ons aanbod is toegankelijk via onze instapformules om deze strenge aanpak vanaf de allereerste test toe te passen. Als u momenteel een ander platform evalueert, is onze vergelijking met AB Tasty Het document beschrijft ook hoe elk hulpmiddel dit type kwaliteitscontrole uitvoert – een criterium dat net zo belangrijk is als de prijs die op de pagina wordt weergegeven. receptie van elke oplossing.