Onze methodiek — statistiek achter elk getal.

Waarom een kwantitatieve methode

Mijn naam is Lars Jansen en ik ben sinds 2024 hoofdredacteur bij Wild Robin Casino. Ik woon in Utrecht-Oost, rijd drie dagen per week op en neer naar het hoofdkantoor aan de Prinsengracht 412 in Amsterdam, en de overige twee dagen werk ik vanuit een co-working aan de Maliebaan in Utrecht. Daar zit ook het data-team waar deze pagina over gaat. De fysieke afstand tussen marketing in Amsterdam en cijferwerk in Utrecht is bewust — afstand dwingt langzaamheid in de oordeelsvorming, en cijferwerk verdraagt geen impulsdruk.

Wild Robin Casino is een KSA-vergund Nederlands casino. Wat onze redactie beschrijft, zijn metrieken op onze eigen producten: de cashier, de bonusmechaniek, het wagering-proces, de mobiele en desktop-renderingen van onze games, de antwoordtijden van onze chat, de doorlooptijden van onze KYC-flows. Geen vergelijking met concurrenten, geen oordeel over een andere markt — gewoon: hoe presteren onze eigen processen op getallen die je kunt narekenen.

De keuze voor een kwantitatieve methode kwam in januari 2025 nadat we een paar maanden hadden gewerkt met losse observaties en gevoelsmatige oordelen. Een speler ervoer onze checkout traag — voelde het traag of was het traag? Een chat-agent leek lang te doen over een vraag — lang vergeleken met wat? Zonder een nul-hypothese en een sample-grootte was het narekenen onmogelijk. Pas toen Mert (bonus-doorrekening) en Joris (data-analyst) systematisch met statistical power gingen werken, kwamen onze antwoorden op orde.

Dit betekent niet dat we kwalitatieve observaties verwerpen. Eric (mobile/desktop QA) doet dagelijks observatie-werk op echte toestellen, en Saskia (verantwoord spel, in dienst bij Jellinek) leest mee op iedere commerciële tekst voordat die online gaat. Hun werk is essentieel en niet meetbaar in een spreadsheet. Wat de kwantitatieve laag eronder doet, is voorkomen dat redactionele intuïtie tot productbeslissingen leidt zonder dat die intuïtie aan een toets is onderworpen.

Het A/B-test-framework

Onze A/B-tests draaien sinds halfweg 2024 op een eigen Python-stack die Joris in Utrecht heeft gebouwd. Geen Optimizely, geen VWO — bewust een eigen implementatie omdat die kant-en-klare tools de tendens hebben de gebruiker een snel-voltooid-rapport te geven dat onder de oppervlakte de statistiek schuwt. Wij willen die statistiek juist kunnen narekenen.

De stack

De technische opbouw is simpel: een nginx-server logt alle sessies in geanonimiseerde vorm naar een Postgres-database. Daarop draait een Python-script dat met scipy.stats en statsmodels de hypothesetoetsen uitvoert. Iedere test krijgt voorafgaand een power-analyse waarin we de minimum detectable effect (MDE) en de gewenste statistical power vastleggen, en daarvan leiden we de benodigde sample-size af. De resultaten komen in een Jupyter-notebook met vaste random seed en commit-hash.

Wanneer we een A/B-test draaien

Niet voor elke productverandering. Een A/B-test kost sample-size, en sample-size kost weken — voor een productpagina met 1.500 sessies per dag duurt 14.000 sessies per arm tien dagen, plus rust-windows. Daarom selecteren we tests op drie criteria. Een: de wijziging raakt een primaire conversiemetric (storting starten, KYC-doorzetten, wagering-completen). Twee: het verwachte effect ligt boven de minimum praktische impact-drempel van 2% absolute verandering. Drie: er is een nul-hypothese die we kunnen formuleren zonder hyperdraad-gewenste-uitkomst.

Concreet: in maart 2026 hebben we een A/B-test gedraaid op de cashier-pagina waarbij we de plek van de iDEAL-knop ten opzichte van de creditcard-knop wisselden. MDE 3%, statistical power 80%, alpha 0,05. Sample-size: 14.000 sessies per arm, in totaal 28.000 sessies. Doorlooptijd: 11 dagen. Uitkomst: iDEAL-eerst-positie verhoogde de cashier-conversie met 3,4%, p = 0,022. Significant, boven MPI, gepubliceerd in onze interne Q1-rapportage en doorgevoerd in het nieuwe ontwerp.

Wat we niet doen

• Geen peeking. Een A/B-test wordt op een vooraf vastgelegde datum afgesloten, niet op het moment dat de p-waarde toevallig onder 0,05 zakt. Vroege beslissingen op tussenstanden inflateren type-I errors; dat is een rookie-fout die we vermijden.
• Geen post-hoc cherry-picking van metrieken. De primaire metric staat in het pre-registration-document voor de test live gaat. Secundaire metrieken worden separaat geanalyseerd, met multiple-comparison-correctie.
• Geen significantie zonder MPI. Een statistisch significante toename van 0,3% wordt niet als product-update doorgevoerd — geen speler ervaart dat verschil, en de operationele kost van wijzigen is hoger dan de marginale winst.

Completion rates op zes flows

Naast A/B-tests zijn completion rates onze tweede statistische werkpaard. Een completion rate is het percentage spelers dat een proces dat ze begonnen, ook afmaakt — en daarmee een directe indicator van hoe goed of slecht een UX-stroom werkt. Sinds eerste kwartaal 2025 meten we maandelijks zes flows op completion rate.

De zes flows

De drempels zijn niet geplukt uit de lucht maar afgeleid uit historische rangen plus een buffer van 3 procentpunt. Zakt een completion rate twee maanden achter elkaar onder de drempel, dan triggert dat een UX-onderzoek — Eric kijkt op echte toestellen, Saskia checkt of er taal-issues spelen, Mert rekent door of er iets schuift in de bonusmechaniek. Pas als we de oorzaak hebben, gaat er een fix in de pijplijn. Niet andersom.

De wagering-completion van 62,1% verdient een toelichting omdat hij op het eerste gezicht laag oogt. Wagering is bewust het inspannendste proces van een bonus — spelers stoppen als ze er geen plezier in hebben, en dat is een keuze die we respecteren. We mikken niet op 90%+ completion daar; dat zou betekenen dat spelers wagering doorzetten ook als ze plezier verloren hebben. 60% rond de drempel is een gezond getal voor een Nederlandse markt waar de KSA strikt is op verantwoord spel.

Sample-size en power-analyse

Een A/B-test draaien zonder vooraf de sample-size te berekenen is, in academische termen, «underpowered» lopen. In productie-termen is het tijdverspilling. Joris draait standaard een power-analyse voordat een test live gaat — in Python met statsmodels.stats.power.

Hoe we de sample-size bepalen

Vier inputvariabelen: minimum detectable effect (MDE), basisrate van de primaire metric, gewenste statistical power, en alpha-niveau. Standaardinstelling: MDE 3% relatief, basisrate uit voorgaande maand, power 80%, alpha 0,05. Met die parameters komt voor een conversiemetric op 70% basisrate de benodigde sample-size uit op ongeveer 14.000 sessies per arm. Voor minder dramatische verschillen schaalt het op — MDE 1% vraagt 110.000 sessies per arm.

Een tabel ter illustratie:

Bij 80% statistical power en alpha 0,05. De kolom basisrate 90% maakt zichtbaar waarom we voor extreme conversies (uitbetaling-completion bijvoorbeeld) met minder spelers tot significante uitspraken kunnen komen — de variantie is daar gewoon kleiner. Voor de wagering-completion van 62,1% staan we op het zwaarste punt op de tabel; dat is de reden waarom we daar tests pas overwegen als we de doorlooptijd van zes weken kunnen accepteren.

Wat we ook hebben geleerd: een test éérder afsluiten dan gepland heeft een statistische prijs. Vroege significantie kan optisch overtuigend zijn, maar reflecteert vaak ruis. Sinds Q3 2025 sluiten we tests strikt op de afgesproken einddatum — niet op het moment dat een tussenstand er goed uitziet.

Multiple comparisons en correctie

Een A/B-test op één metric is statistisch overzichtelijk. Een A/B-test op twintig metrieken parallel is een mijnenveld — bij alpha 0,05 zonder correctie verwacht je statistisch één vals positief op alleen ruis. Onaanvaardbaar als je productbeleid op de uitkomsten gaat baseren.

Welke correctie wij gebruiken

Tot half 2025 gebruikten we Bonferroni-correctie — de eenvoudigste, conservatiefste methode die alpha deelt door het aantal tests. Bij twintig tests betekent dat alpha 0,0025 per test, wat in de praktijk veel echte effecten over het hoofd liet zien (verhoogt type-II errors). Sinds half 2025 zijn we overgestapt op Benjamini-Hochberg-procedure als we false discovery rate willen controleren in plaats van familywise error.

Het verschil is praktisch: Benjamini-Hochberg accepteert dat een klein percentage van de geclaimde significantes vals positief is, in ruil voor minder gemiste effecten. Voor onze toepassing — we willen UX-issues opsporen, niet medische beslissingen baseren — is dat een acceptabele afweging. Bij elke A/B-test boven drie metrieken ligt nu een lijst met gecorrigeerde p-waarden in het rapport.

Concreet voorbeeld

In februari 2026 testten we een nieuwe layout voor de bonus-claimpagina, met twaalf secundaire metrieken naast de primaire (claim-completion). Twee secundaire metrieken kwamen uit op p < 0,05 zonder correctie. Met Benjamini-Hochberg op false discovery rate 0,1 bleef één metric significant; de andere viel weg als waarschijnlijk vals positief. We publiceerden de bevinding op de één significante metric en lieten de andere zien als «na correctie niet significant, mogelijk aanleiding voor vervolgtest». Die nuance kost leeswerk; ze voorkomt dat we een tussentijdse ruis als product-aanpassing doorvoeren.

Reproduceerbaarheid via Jupyter

Een statistische analyse die niet reproduceerbaar is, is geen statistische analyse. Mert heeft op de TU Delft kennisgemaakt met reproducible research-praktijken in academische context, en die discipline hebben we tot redactionele norm verheven.

Wat reproduceerbaarheid bij ons inhoudt

• Vaste random seed. Iedere notebook begint met np.random.seed(42) of vergelijkbaar — geen wisselende seeds tussen runs, geen gevoelige reservaties op random toeval.
• Commit-hash op de pagina. Iedere gepubliceerde statistische uitspraak verwijst onderhuids naar de Git-commit waarop de analyse rust. Een onderzoeker die over zes maanden wil narekenen, ziet welke staat van de code de uitkomst heeft geproduceerd.
• Dataset-snapshot. De ruwe data van de analyse wordt geanonimiseerd opgeslagen in een Parquet-file met datum-stempel. Ook al verandert de productiedata, de analyse blijft nareken-baar op de oorspronkelijke snapshot.
• Notebook-export naar HTML. Bij elke kwartaalrapportage exporteren we de notebooks als statisch HTML-rapport, zodat ze leesbaar blijven ook als Jupyter zelf in versie verschuift.

Op gemotiveerde aanvraag delen we via een gesloten link de notebooks met journalisten, academici of de KSA. In 2025 ontvingen we zes zulke aanvragen, alle zes binnen vijf werkdagen behandeld. We delen geen open API — niet uit gehei mzucht, maar omdat de drempel van «wie wil deze data en waarvoor?» bij beide kanten zorgvuldigheid afdwingt.

Donderdag in Utrecht — stat-review

Iedere donderdag van 10:00 tot 13:00 zit ik in een vergaderkamer van de co-working space aan de Maliebaan met Joris voor wat we intern de stat-review noemen. Drie uur, vaste agenda, koffie en een whiteboard. Ergens tussen 11:30 en 12:00 schuift Mert via Zoom in vanuit Amsterdam — hij heeft niet altijd tijd om te reizen, en de bonusdoorrekeningen leveren de meeste data voor onze maandrapportages.

De vaste agenda

1. Lopende A/B-tests. Hoeveel sessies binnen, blijft de power-analyse op koers, zijn er signalen van peeking-druk vanuit andere afdelingen. Beslissingen aan tafel: doorgaan tot afgesproken einddatum, vroegtijdig afbreken bij operationele blocker, of pre-registreerde wijziging in de protocol.
2. Completion rates van afgelopen week. Joris draait de freshly-gerunde queries, ik kijk mee, we noteren significante verschuivingen ten opzichte van het maand-mediaan. Drempel-onderschrijdingen krijgen een tussennotitie naar Eric voor UX-onderzoek.
3. Multiple-comparison-checks op lopende analyses. Iedere analyse boven drie metrieken loopt door Joris’ statsmodels.stats.multitest-script. Bevindingen die alleen ongecorrigeerd significant zijn worden niet gepubliceerd; bevindingen die na BH-correctie blijven staan gaan door naar de redactionele schrijfronde.
4. Reproducibility-cleanup. Notebooks van de afgelopen week worden gecheckt op random seed, commit-hash en dataset-snapshot. Eentje die niet voldoet wordt teruggestuurd naar de auteur voor aanpassing. Dat overkomt ons gemiddeld eens per maand.
5. Publicatie-besluit. Wat van deze week mag in de openbare changelog, wat in een Q-rapportage, wat blijft binnen de redactie omdat de basis te dun is. Niet alles wat we statistisch significant vinden gaat publiek — sommige bevindingen vragen herhaling voordat we ze als «onze cijfers» vermelden.

Drie uur per week. Twee mensen plus Mert via Zoom. Geen scrum-board, geen Jira-tickets, geen project-management-trucs — gewoon donderdag, gewoon de cijfers, gewoon beslissen. Dat is genoeg structuur voor een team van vijf.

Bonus-doorrekening met scipy

Mert kwam in september 2024 fulltime bij ons werken na zijn afstuderen in econometrie aan de Utrecht University. Sinds dag één doet hij één ding: elke promotie die wij overwegen op de site te plaatsen, draait door zijn rekenmodule voor de tekst geschreven kan worden. Pas als zijn cijfers groen geven, schrijven we de begeleidende uitleg.

Mert’s rekenmodule draait in Python met scipy.stats voor de waarschijnlijkheidsverdelingen en pandas voor de invoer-uitvoer. De parameters die hij eet: nominale bonusgrootte, vereiste doorspeel-factor, maximumcap per ronde, beschikbare termijn in dagen, weegfactor per spelcategorie, eventueel een winsthoogte-plafond, eventueel een opname-grens. De drie cijfers die hij teruggeeft: een te verwachten netto-stand op een doorsnee speel-RTP van 96 procent, een schatting van actieve speeltijd in uren bij € 1 inzet per spin, en een interne speelbaarheids-index op een nul-tot-honderd-schaal.

De bruikbaarheidsindex is geen sterrenoordeel maar een samengestelde meting uit zes componenten met openlijke weging: doorspeel-kost (30%), tijdsdruk (20%), helderheid van spelbijdrage (15%), redelijkheid van max-inzet (15%), impact van winsthoogte-plafond (10%), product-restricties (10%). Een score onder 45 betekent: niet als hoofd-promotie. De welkomstbonus die nu in onze etalage staat — honderd procent tot vijfhonderd euro plus tweehonderd gratis spins, dertig dagen om af te ronden, doorspeel-factor 35× en cap op vijf euro per ronde — landt op 72. De doorlooptijd-schatting komt uit op iets meer dan acht uur € 1-spins, met een gemiddelde nettostand rond drieenzestig euro op een dubbele inzet van honderd plus honderd bonus. De gedetailleerde berekening leeft in onze welkomstbonus-doorrekening.

Mert publiceert in zijn interne logbook elk kwartaal de afgewezen voorstellen — promo-ideeen die de drempel niet haalden — zodat het bestuur kan zien dat het filter actief blijft. In Q1 2026: 14 voorgelegde concepten, waarvan 9 doorgekomen, 5 afgewezen op bruikbaarheidsindex onder 45. Drie van de vijf afgewezen scoorden negatief op de wagering-component, twee op de tijdsdruk.

Publicatieprincipes met cijferdiscipline

Cijferdiscipline werkt alleen als ze gekoppeld is aan publicatiediscipline. Vier principes hangen op de muur van mijn werkkamer in Utrecht. Letterlijk geprint, geen frames.

• Geen significantie zonder MPI. Een statistisch significante bevinding wordt alleen gepubliceerd als hij ook boven onze minimum praktische impact-drempel van 2% absolute verandering ligt. Onder die drempel blijft de bevinding intern. Dat is geen censuur — het is publicatiediscipline. Spelers verdienen geen rapport over een 0,3% verschuiving die ze nooit zullen ervaren.
• Geen post-hoc cherry-picking. De primaire metric staat in het pre-registration-document voordat de test live gaat. Secundaire metrieken worden separaat geanalyseerd met multiple-comparison-correctie. We rapporteren niet alleen wat goed uitkomt; we rapporteren wat het pre-registration heeft voorzien plus de secundaire bevindingen onder correctie.
• Onze eigen minpunten blijven publiek. In maart 2026 documenteerden we een KYC-completion-dip van 78% naar 71% over twee weken — oorzaak: een UI-wijziging die we te haastig hadden uitgerold. Het incident staat nog steeds op de cashier-pagina, en pas als de bijbehorende metingen aantonen dat het probleem structureel verholpen is verhuist de notitie naar de pagina-changelog onderaan.
• Reproduceerbaarheid is een publicatie-eis. Elke statistische uitspraak op deze site verwijst naar een Jupyter-notebook met vaste seed en commit-hash. Op gemotiveerde aanvraag delen we ze. Dat is niet sluikse openheid; het is de minimale standaard die je van een data-gedreven redactie mag verwachten.

Voor vragen over deze principes of over een specifieke meting: mail mij persoonlijk via [email protected] of via mijn directe lijn [email protected]. Reactietermijn: 24 uur op werkdagen, langer in vakantieperiodes.

Team Wild Robin Casino

Vijf vaste mensen, twee locaties.

• Lars Jansen — hoofdredacteur, dat ben ik. Tien jaar ervaring in iGaming-data, drie dagen per week in Amsterdam aan de Prinsengracht 412 en twee dagen vanuit Utrecht. Eindverantwoordelijk voor publicaties, draai de donderdag-stat-review met Joris.
• Mert — bonus-doorrekening, econometrie Utrecht University 2024. Werkt vanuit Amsterdam, sluit donderdag via Zoom aan op de stat-review. Bouwt en onderhoudt de scipy-rekenmodule voor onze bonusanalyses.
• Joris — data-analyst, statistical computing TU Delft 2022. Werkt vanuit de co-working aan de Maliebaan in Utrecht, draait de A/B-tests en completion-rate-queries, beheert het Jupyter-archief.
• Saskia — consultant verantwoord spel, in dienst bij Jellinek (GGZ-instelling die in Nederland de meeste cliënten met gokproblematiek behandelt). Werkt twee dagen per week in Amsterdam, leest mee op iedere commerciële tekst voordat die online gaat. Veto bindend.
• Eric — mobile/desktop QA, sinds begin 2025 bij ons. Doet de UX-tests op echte toestellen wanneer een completion rate onder de drempel zakt. Werkt vanuit Amsterdam.

Geen freelance-pool, geen ghostwriters. Plus één externe data-analist die Joris ondersteunt bij niet-standaard analyses. Op de over-ons-pagina staat uitgeschreven hoe we ontstaan zijn en waarom de splitsing tussen Utrecht en Amsterdam bewust gehouden wordt.

Waarom deze pagina blijft staan

Onze testopstelling laat zich niet aanpassen omdat de cijfers ergens slechter uitvallen dan we hadden gehoopt. Die afspraak hebben we eind 2024 met elkaar gemaakt, en sindsdien houden we hem aan. Wat hierboven staat, vormt de basis onder elke gepubliceerde meting; ieder onderdeel dat we toevoegen of laten vervallen verschijnt als wijzigingsnotitie boven de pagina. Een statistiek zonder transparante onderbouwing is geen statistiek meer — dan ben je gewoon aan het adverteren met getallen.