{"id":1005534,"date":"2026-04-28T13:43:38","date_gmt":"2026-04-28T11:43:38","guid":{"rendered":"https:\/\/www.iterates.be\/?p=1005534"},"modified":"2026-04-17T14:08:06","modified_gmt":"2026-04-17T12:08:06","slug":"de-7-valkuilen-die-je-a-b-tests-ongeldig-maken-en-hoe-je-ze-kunt-vermijden","status":"publish","type":"post","link":"https:\/\/www.iterates.be\/nl\/de-7-valkuilen-die-je-a-b-tests-ongeldig-maken-en-hoe-je-ze-kunt-vermijden\/","title":{"rendered":"A\/B-testen: de 7 valkuilen die je tests ongeldig maken"},"content":{"rendered":"
\n

L\u2019A\/B-testen<\/strong> is geruststellend. We lanceren twee versies, wachten op de cijfers en kiezen dan de winnaar. Wetenschappelijk. Datagestuurd<\/em>. Objectief. Behalve dat in de praktijk de meeste A\/B-tests ongeldig zijn - niet omdat de teams incompetent zijn, maar omdat er heel specifieke fouten in het proces sluipen. Het resultaat: slechte beslissingen met vals vertrouwen. Hier zijn de zeven meest voorkomende valkuilen en hoe je ze in de praktijk kunt vermijden.<\/p>\n\n\n\n

1. Ontwerpfouten die je resultaten vanaf het begin vertekenen<\/h2>\n\n\n\n

Zelfs voordat je naar je gegevens kijkt, is de schade vaak al aangericht. Twee structurele fouten kunnen een test ongeldig maken zodra deze is opgezet.<\/p>\n\n\n\n

De test te vroeg stoppen (Peek & Stop)<\/h3>\n\n\n\n

Je start je test op maandag. Op woensdag dashboard<\/strong> postte +14 % in conversies met een p-waarde<\/strong> van 0,03. Je stopt en zet in. Klassieke fout.<\/p>\n\n\n\n

Tijdens een test fluctueren de resultaten natuurlijk. Als je vaak controleert en stopt zodra de drempel wordt overschreden, zal je percentage fout-positieve uitslagen<\/strong> (fouten in type I<\/strong>) explodeert. Simulaties tonen aan dat deze snelheid 50 % kan overschrijden - zelfs met een theoretische drempel van 95 %.<\/p>\n\n\n\n

De oplossing: bepaal voordat u de test start de duur van de test en de steekproefomvang<\/strong> houd je er dan aan. Als je onderweg een oogje in het zeil moet houden, gebruik dan geschikte methoden zoals de Sequentieel testen<\/strong> of de\u2019Altijd geldige gevolgtrekking<\/strong>.<\/p>\n\n\n\n

Te veel varianten tegelijk testen<\/h3>\n\n\n\n

Vijf varianten tegelijk testen lijkt effectief. In werkelijkheid cre\u00ebert elke extra vergelijking zijn eigen waarschijnlijkheid van fout-positief<\/strong>. Met vijf vergelijkingen bij p < 0,05 is de kans op ten minste \u00e9\u00e9n fout-positief groter dan 22 %. Dit is het probleem met meervoudige vergelijkingen<\/strong> - ook bekend als Type I foutenpercentage<\/strong>.<\/p>\n\n\n\n

De oplossing: test \u00e9\u00e9n of twee varianten tegelijk als je verkeer beperkt is. Als je er meerdere test, pas dan een statistische correctie toe zoals de Bonferroni-correctie<\/strong> of de Benjamini-Hochberg<\/strong>. En vooral: formuleer een duidelijke hypothese voor<\/em> om te testen. Een test zonder hypothese is onderzoek vermomd als experiment.<\/p>\n\n\n\n

2. Statistische valkuilen die je resultaten opblazen<\/h2>\n\n\n\n

Zelfs met een goed ontworpen test kunnen statistische fouten ertoe leiden dat je gelooft in winsten die er niet zijn - of winsten mist die er wel zijn.<\/p>\n\n\n\n

Een te klein of verkeerd berekend monster<\/h3>\n\n\n\n

La statistische kracht<\/strong> meet de waarschijnlijkheid van het detecteren van een echt effect als het bestaat. Een test met 50 % vermogen mist de helft van de echte effecten - het is een munt opgooien met een extra stap.<\/p>\n\n\n\n

Om de juiste steekproefgrootte te berekenen, heb je drie parameters nodig: de basistarief<\/strong> van je metriek, de Minimaal Detecteerbaar Effect (MDE)<\/strong> en de vermogensniveau<\/strong> (over het algemeen 80 %). Een te kleine test heeft twee perverse effecten: het mist de echte positieve effecten (valse negatieven<\/strong>), en als het iets detecteert, wordt het geschatte effect vaak opgeblazen - dit is de vloek van de winnaar<\/strong>.<\/p>\n\n\n\n

De oplossing: bereken de steekproefgrootte voor<\/em> te starten, met hulpmiddelen zoals Evan Miller's calculator of de Python-bibliotheek statsmodellen<\/code>.<\/p>\n\n\n\n

Statistische significantie verwarren met praktisch belang<\/h3>\n\n\n\n

Een resultaat kan statistisch belangrijke<\/strong> en praktisch nutteloos. p = 0,01 met een winst van +0,3 % in conversiesnelheid: is dit de ontwikkelingskosten en de bijbehorende technische schuld waard? Waarschijnlijk niet.<\/p>\n\n\n\n

La statistische significantie<\/strong> antwoordt : \u201cKomt dit effect door toeval?\u201d Het geeft geen antwoord op de vraag: \u201cIs dit effect groot genoeg om ertoe te doen?\u201d Gebruik hiervoor maatregelen van\u2019effectgrootte<\/strong> - Cohen's d<\/strong>, relatieve lift<\/strong>, De absolute impact geprojecteerd op je gebruikersbestand. Definieer een Minimale bedrijfsimpact<\/strong> Wat is het kleinste resultaat dat het doorvoeren van de verandering rechtvaardigt? Het is deze lat die als leidraad moet dienen voor je beslissingen, niet alleen de p-waarde<\/strong>.<\/p>\n\n\n\n

3. Vertekeningen in gedrag en metingen die leiden tot verkeerde interpretaties<\/h2>\n\n\n\n

Een test kan technisch geldig en statistisch correct zijn en je toch misleiden. Dit is waar gebruikersvooroordelen en statistieken om de hoek komen kijken.<\/p>\n\n\n\n

Het nieuwheidseffect en de verkeerde steekproefratio<\/h3>\n\n\n\n

Twee verschillende fenomenen kunnen je conclusies in dit stadium bederven. Het eerste is de\u2019nieuwheidseffect<\/strong> een variant beter presteert omdat hij gewoon verschillende<\/em>. Gebruikers gaan op onderzoek uit nieuwsgierigheid en klikken meer - maar dit effect is van voorbijgaande aard. Als je te vroeg meet, zal je ogenschijnlijke winst verdwijnen zodra de nieuwigheid wegebt. Omgekeerd\u2019Hawthorne-effect<\/strong> Gebruikers die het gevoel hebben dat ze in de gaten worden gehouden, gaan zich anders gedragen. Om een echte verbetering van een artefact te onderscheiden, moet je de evolutie van de metriek in de tijd opvolgen en minstens twee weken wachten voor je een grote interfacewijziging doorvoert.<\/p>\n\n\n\n

Het tweede fenomeen is de Mismatch monsterverhouding (SRM)<\/strong> De verhouding van gebruikers tussen de varianten komt niet overeen met de verwachte verhouding. Als je test is ontworpen op basis van 50\/50 en je krijgt 52\/48, dan zijn al je conclusies ongeldig. Voer voor elke analyse een chi-kwadraat toets<\/strong> op de grootte van je groep. Veel voorkomende oorzaken zijn volgen<\/strong>, s, verkeerd geconfigureerde omleidingen en bots<\/strong> gefilterd na toewijzing, of een kruisbesmetting<\/strong> tussen groepen.<\/p>\n\n\n\n

Slecht gekozen statistieken<\/h3>\n\n\n\n

Dit is de meest strategische valkuil. Een perfect uitgevoerde test kan tot de verkeerde beslissing leiden als je de verkeerde dingen meet. Klassiek voorbeeld: je optimaliseert de doorklikpercentage<\/strong> op een knop Toevoegen aan winkelwagentje. Hij gaat omhoog. Maar de aankoop voltooiingspercentage<\/strong> val. Je hebt stroomafwaarts wrijving gecre\u00eberd zonder het te beseffen.<\/p>\n\n\n\n

Alle goede tests moeten het volgende bevatten vangrail statistieken<\/strong> - statistieken die je niet probeert te verbeteren, maar ook niet wilt verslechteren: inkomsten per gebruiker, retentiegraad<\/strong>, NPS, laadtijd. Als een vangrailmetriek verslechtert, is de \u201cwinnende\u201d variant op de hoofdmetriek<\/strong> misschien geen winst zijn. Stel jezelf de volgende vraag voordat je van start gaat: \u201cAls deze metriek met X % toeneemt, weet ik dan zeker dat dat goed is voor het bedrijf?\u201d Als het antwoord \u201cniet noodzakelijk\u201d is, zoek dan naar een betere metriek.<\/p>\n\n\n\n

<\/p>\n<\/div>","protected":false},"excerpt":{"rendered":"

A\/B-testen heeft iets geruststellends. Je lanceert twee versies, wacht op de cijfers en kiest dan de winnaar. Wetenschappelijk. Datagestuurd. Objectief. Behalve dat in de praktijk de meeste A\/B-tests ongeldig zijn - niet omdat de teams incompetent zijn, maar omdat er heel specifieke fouten in het proces sluipen. Resultaten<\/p>","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1238,1245,1239],"tags":[],"class_list":["post-1005534","post","type-post","status-publish","format-standard","hentry","category-developpement-dapplication","category-developpement-de-logiciel","category-developpement-web"],"acf":[],"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/www.iterates.be\/nl\/wp-json\/wp\/v2\/posts\/1005534","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.iterates.be\/nl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.iterates.be\/nl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.iterates.be\/nl\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.iterates.be\/nl\/wp-json\/wp\/v2\/comments?post=1005534"}],"version-history":[{"count":1,"href":"https:\/\/www.iterates.be\/nl\/wp-json\/wp\/v2\/posts\/1005534\/revisions"}],"predecessor-version":[{"id":1005558,"href":"https:\/\/www.iterates.be\/nl\/wp-json\/wp\/v2\/posts\/1005534\/revisions\/1005558"}],"wp:attachment":[{"href":"https:\/\/www.iterates.be\/nl\/wp-json\/wp\/v2\/media?parent=1005534"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.iterates.be\/nl\/wp-json\/wp\/v2\/categories?post=1005534"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.iterates.be\/nl\/wp-json\/wp\/v2\/tags?post=1005534"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}