Switchback experimenten: een uitgebreide gids

Met andere woorden: je lost één probleem op (het waterbed-effect), maar krijgt er een ander probleem voor terug (het nasleep-effect). Maar dat tweede probleem is vaak beter te managen. Daar kom ik zo op terug.

Waarom dit zo interessant is voor Shopify checkouts

Hier komt het deel waar veel van jullie op zitten te wachten: Shopify checkouts.

Als je een Shopify Plus merchant bent, weet je het al: Shopify ondersteunt geen A/B testing op checkouts. Technisch zou je je traffic kunnen splitsen - dat is niet het probleem. Het probleem is dat Shopify gewoon geen tooling heeft om dit te ondersteunen. Geen ingebouwde A/B test functionaliteit, geen mogelijkheid om twee checkout-versies tegelijk te draaien.

En dat terwijl de checkout juist het deel is waar je conversie écht wordt bepaald.

Met switchback experimenten kun je dit wél testen. Je schakelt om tussen twee checkout-versies op verschillende momenten.

Hoe zou dit praktisch werken?

Optie 1 - Hourly switching (agressief):

• Uur 1: versie A
• Uur 2: versie B
• Uur 3: versie A
• etc.

Dit werkt goed voor duidelijke UI-aanpassingen waar je geen langdurige effecten verwacht. Denk aan: button kleuren, copy aanpassingen, herordenen van formuliervelden.

Optie 2 - Daily switching (conservatiever):

• Dag 1: versie A
• Dag 2: versie B
• Dag 3: versie A
• etc.

Dit is beter voor tests waar je vermoedt dat returning visitors binnen dezelfde dag kunnen terugkomen met een "herinnering" van hun eerdere checkout ervaring.

De drie belangrijkste beslissingen bij het opzetten

Als je een switchback experiment wilt opzetten, moet je drie dingen bepalen:

1. Hoe lang duurt elke periode?

Dit is een afweging tussen "lang genoeg om een effect te meten" en "kort genoeg om veel te kunnen switchen".

Waarom kort beter is (als het kan):

• Je kunt vaker switchen = meer data points = betrouwbaarder resultaat
• Je kunt dag-effecten beter scheiden (maandag vs vrijdag, ochtend vs avond)
• Je leert sneller of je test werkt

Waarom soms langer moet:

• Het effect moet de tijd hebben om zich te manifesteren
• Returning visitors binnen één periode zou verwarrend zijn
• Je verwacht dat mensen tijd nodig hebben om te "wennen" aan een verandering

In de praktijk zie je:

Marktplaatsen (Uber, Deliveroo): Elk uur switchen

• Waarom? Vraag en aanbod veranderen snel
• Effecten zijn direct zichtbaar (mensen boeken een rit of niet)
• Je wilt ochtend/avond en doordeweeks/weekend kunnen scheiden
• Bojinov gebruikt letterlijk "hourly switching" in zijn Uber-voorbeeld¹

Checkout-optimalisaties (Shopify, webshops): Elke dag of uur switchen

• Waarom? Returning visitors kunnen binnen dezelfde dag terugkomen
• Je wilt dat mensen een "schone" ervaring hebben (niet twee keer een andere checkout zien)
• Buffer-tijd van enkele uren voorkomt overlap
• Nog steeds genoeg switches voor goede analyse (28 switches in 4 weken bij 2-day periodes)

Grote strategische veranderingen: Elke week switchen

• Denk aan: complete nieuwe categoriestructuur, nieuwe pricing strategie, nieuw loyaliteitsprogramma
• Waarom? Mensen hebben tijd nodig om te wennen aan grote veranderingen
• Maar: je hebt wel minimaal 6-8 weken nodig voor genoeg switches

De vuistregel: Hoe sneller je effect zich manifesteert én verdwijnt, hoe korter je periodes kunnen zijn. En korter is meestal beter (meer data points).

2. Hoe vaak ga je switchen?

Simpel gezegd: hoe vaker je switcht, hoe beter. Maar er is een trade-off.

Voordeel van veel switchen:

• Meer data points = betrouwbaarder statistiek
• Je kunt dag-effecten beter scheiden (zijn maandagen altijd drukker? Dan moet je maandag-A kunnen vergelijken met maandag-B)
• Je kunt seizoenseffecten wegfilteren (kerst, vakantie, etc.)

Nadeel van veel switchen:

• Elk switch-moment geeft risico op het nasleep-effect
• Je gebruikt buffer-tijd, dus je verliest data
• Technisch complexer (meer kans op fouten)

3. In welke volgorde switch je? (Geen patronen, wél random!)

Dit is cruciaal, en hier gaat het vaak mis.

Wat je NIET moet doen:

• Netjes om en om: ABABABABAB - Probleem: Als er een geleidelijke trend is (steeds drukker worden), dan krijgt B gemiddeld de drukke dagen
• Groepjes maken: AABBAABBAABB - Probleem: Als week 1 en 2 toevallig rustig zijn (vakantie), krijgt A alle rustige periodes
• Alle doordeweekse dagen A, alle weekenden B - Probleem: Weekenden gedragen zich anders. Je meet nu "doordeweeks vs weekend" in plaats van "A vs B"

Wat je WEL moet doen: Echt randomiseren

Gebruik een echte random generator (geen patroon dat jij bedenkt).

Denk eraan als een goede beurtrol bij een potje Mens-Erger-Je-Niet. Je wilt niet dat iemand altijd eerst mag. Je gooit een dobbelsteen - puur willekeurig.

Hoe doe je dit praktisch?

• Je tool (zoals Statsig) kan dit voor je
• Of Python/R (zoals in de praktische tips)
• Of zelfs Excel's RAND() functie

Belangrijk: Doe dit VOORAF, niet tijdens het experiment. Bepaal de hele volgorde voor je start, en volg die precies.

Gratis CRO-tips in je inbox. Meld je aan!

Aanmelden

5.000+ mensen ontvangen mijn CRO tips
Max één e-mail per maand

Het andere probleem: het nasleep-effect

Nu komen we bij het lastigste deel van switchback experimenten. Even een stapje terug om het verschil tussen twee begrippen duidelijk te maken:

Het waterbed-effect (interferentie) = de ene groep bezoekers beïnvloedt de andere groep (op hetzelfde moment)
Het nasleep-effect (carryover) = gisteren beïnvloedt vandaag (over tijd)

Bij switchback experimenten heb je geen waterbed-effect meer (want er is maar één groep). Maar je krijgt wel te maken met het nasleep-effect.

Wat is het nasleep-effect? (De simpele uitleg)

Stel je voor: je test twee verschillende kleuren voor je "Koop nu" button. Maandag is hij groen, dinsdag is hij blauw, woensdag weer groen.

Als de kleur van de button geen blijvend effect heeft op mensen, is er geen nasleep. Mensen zien op maandag een groene button, klikken of klikken niet, en zijn het dinsdag weer vergeten. Prima.

Maar stel dat je iets anders test: een nieuwe functie waarbij mensen een account aanmaken tijdens checkout.

Maandag (versie B): mensen maken een account aan
Dinsdag (versie A): geen verplicht account meer

Het probleem: al die mensen die maandag een account hebben aangemaakt, hebben dinsdag een voordeel. Ze kunnen nu sneller uitchecken dan ooit tevoren. Het effect van gisteren "sleept door" naar vandaag.

Dat is het nasleep-effect: wat je gisteren deed, beïnvloedt wat je vandaag meet.

Waarom is dit zo lastig? (Voor wie het wil begrijpen)

Laten we het simpel houden. Als je conversie meet, wil je weten: "Wat is het effect van versie B?"

Maar als er een nasleep-effect is, dan meet je eigenlijk: "Effect van B + restje effect van A dat ervoor draaide"

Je telt dus dingen dubbel. En dat maakt je conclusies onbetrouwbaar.

Dit is precies waarom je een expert nodig hebt voor de analyse. Die kan dit eruit filteren met speciale statistische methoden (daar kom ik zo op terug). Jij hoeft vooral te weten: het bestaat, en je moet er rekening mee houden in je test-ontwerp.

Hoe ga je om met het nasleep-effect?

Er zijn twee hoofdstrategieën:

Strategie 1: Buffer-tijd inbouwen (de praktische oplossing)

Een buffer-tijd (in vakjargon: "washout periode") is een stukje tijd tussen je periodes waarin je geen data meetelt in je analyse. Het is alsof je een pauze inlast om het nasleep-effect te laten uitdoven.

Een simpel voorbeeld:

Je schakelt om van A naar B om 12:00 uur. Dan zeg je: "Het eerste uur na de switch (12:00-13:00) tel ik niet mee." Dat eerste uur is je buffer-tijd - de tijd waarin het effect van versie A kan "wegspoelen".

Tools zoals Statsig³ noemen dit "burn-in/burn-out periods" en je kunt het instellen in minuten.

Het voordeel: Simpel en effectief voor kortdurende nasleep-effecten.

Het nadeel: Je gooit data weg. En data kosten geld en tijd.

De praktische vraag: hoe lang moet je buffer-tijd zijn?

Dit hangt af van wat je test:

Korte/geen buffer (0-30 minuten):

• Button-kleuren die mensen direct zien en vergeten
• Prijsweergave (mensen maken een beslissing en gaan door)
• Simpele UI-aanpassingen

Middellange buffer (1-6 uur):

• Checkout-aanpassingen waar mensen over nadenken
• Tests met returning visitors die binnen dezelfde dag terugkomen
• Nieuwe features die lichte gewenning vereisen

Lange buffer (1+ dag):

• Account-aanmaak (mensen hebben nu permanent een account)
• Loyaliteitsprogramma's (mensen onthouden hun punten)
• Tests waarbij je verwacht dat mensen het effect "onthouden"

Praktisch advies: Begin conservatief met langere buffer-tijden. Je kunt altijd een volgende test doen met kortere buffers als je ziet dat het niet nodig was.

Strategie 2: Laat een expert het eruit filteren (de geavanceerde oplossing)

De andere oplossing is om het nasleep-effect niet weg te gooien, maar eruit te rekenen met statistische methoden.

Dit is echter expert-territorium. Als je geen ervaren data-analist hebt, of geen tool zoals Statsig gebruikt, dan kun je dit niet zelf doen. Het vereist geavanceerde kennis van time series analyse.

Wanneer is dit relevant?

• Als je heel veel switches hebt en veel data zou verliezen met buffer-tijden
• Als je vermoedt dat het nasleep-effect complex is (niet lineair)
• Als je tools gebruikt die dit automatisch doen (zoals Statsig)

Praktisch advies: Voor je eerste switchback experimenten: gewoon buffer-tijd gebruiken. Simpeler en veiliger.

Hoe analyseer je de resultaten? (Waarom je dit niet zelf doet)

Hier komt het deel waar ik eerlijk moet zijn: de analyse van switchback experimenten is te complex om zelf te doen, tenzij je een statistisch geschoolde data-analist bent.

De fout die iedereen wil maken (maar niet moet maken)

Je zou denken: "Ik tel gewoon het gemiddelde van alle A-periodes en alle B-periodes bij elkaar op, dan doe ik een t-test in Excel, en klaar!"

Dit is bijna altijd fout.

Waarom? Drie redenen:

1. Tijdstrends die je negeert: Misschien stijgt je conversie sowieso over tijd (seizoen, meer bekendheid, betere SEO). Als versie B toevallig vaker in de latere periodes draaide, lijkt het alsof B beter is, maar het is gewoon tijd.
2. Het nasleep-effect dat je negeert: Zoals we net zagen, kan het effect van gisteren doorwerken in vandaag. Je telt dingen dubbel.
3. Tijdsafhankelijkheid (autocorrelatie): Je conversie om 13:00 uur hangt samen met je conversie om 12:00 uur (mensen zijn nog aan het browsen). Een normale t-test gaat ervan uit dat alle metingen onafhankelijk zijn. Dat klopt niet bij tijd-data.

Wat je WEL moet doen: gebruik de juiste tools of experts

Er zijn twee routes:

Route 1: Gebruik een tool die het automatisch doet (aanbevolen)

Tools zoals Statsig hebben switchback experimenten ingebouwd. Je configureert je test, de tool doet alle switches automatisch, en aan het einde krijg je betrouwbare resultaten met de juiste statistische methoden.

Dit is verreweg de makkelijkste route. De tool zorgt ervoor dat:

• Het nasleep-effect correct wordt behandeld
• Tijdstrends eruit worden gefilterd
• Je een betrouwbaar betrouwbaarheidsinterval krijgt
• Je niet per ongeluk de verkeerde conclusies trekt

Route 2: Huur een ervaren data-analist in

Als je geen tool kunt gebruiken (bijvoorbeeld omdat je een custom Shopify checkout test), dan heb je iemand nodig die ervaring heeft met:

• Time series analyse
• Randomization inference methoden
• Bootstrapping technieken voor experiment-analyse

Deze persoon kan de analyse in R of Python doen met de juiste statistische methoden.

Bottom line: Laat de analyse over aan tools of experts. Focus jij op het goed ontwerpen van de test.

Praktische tips voor je eerste switchback experiment

Voordat ik in de praktische tips duik, nog één keer het belangrijkste: je hebt een expert nodig voor de analyse. Of dat nou een tool is zoals Statsig, of een data-analist met ervaring in time series experimenten.

Jouw rol als marketeer/productmanager: de test goed ontwerpen en uitvoeren. Hun rol: de data correct analyseren.

Met dat in gedachten, hier zijn de praktische tips:

1. Start met korte periodes en frequente switches

Begin niet met switches per week. Begin met switches per uur of per dag. Waarom?

• Je leert sneller of je setup werkt
• Je kunt dag-van-de-week effecten beter scheiden (maandag vs vrijdag)
• Je hebt meer data points voor je analyse (30 dagelijkse switches is beter dan 4 wekelijkse)

Het Uber-voorbeeld uit de literatuur gebruikt letterlijk hourly switching. Dat is een goede start voor veel situaties.

2. Bereken vooraf hoeveel switches je nodig hebt

Net als bij A/B tests moet je vooraf weten of je genoeg data gaat hebben. Maar bij switchback experimenten heb je niet zoveel individuele gebruikers nodig – je hebt voldoende periodes nodig.

Hoeveel switches heb je nodig?

Bojinov et al. zeggen: "causal estimators from switchback experiments have large variances as the precision is a function of the total number of assignments."²

Met andere woorden: hoe meer switches, hoe betrouwbaarder je resultaat. Maar er is geen vast minimum dat voor alle situaties geldt.

Wat bepaalt hoeveel je nodig hebt:

• Hoe groot het verschil is dat je wilt kunnen detecteren
• Hoeveel variatie er normaal in je data zit
• Hoe zeker je wilt zijn van je conclusie (statistical power)
• Welke statistische methode je gebruikt

Als je met een tool werkt, check hun documentatie. Statsig heeft bijvoorbeeld een minimum aantal buckets nodig (~10-15 per variant).

3. Randomiseer je volgorde echt (geen patroon!)

Dit is cruciaal. Gebruik GEEN voorspelbaar patroon zoals:

• ABABAB (te voorspelbaar)
• AABBAABB (groepjes maken)
• Alle doordeweekse dagen A, alle weekenden B

Waarom niet? Stel alle drukke dagen zijn toevallig B, en alle rustige dagen zijn A. Dan weet je niet of B beter is, of dat het gewoon de drukke dagen zijn.

Hoe dan wel: Gebruik een echte random generator. Je expert/tool kan dit voor je doen. Als je het zelf moet: gebruik Python, R, of zelfs Excel's RAND() functie.

import random
                    periods = 56  # 4 weken × 2 switches per dag
                    sequence = ['A'] * (periods // 2) + ['B'] * (periods // 2)
                    random.shuffle(sequence)
                    print(sequence)

4. Gebruik buffer-tijd, ook als je denkt dat het niet nodig is

Voor je eerste experimenten: speel het veilig. Gebruik buffer-tijd na elke switch, ook als je vermoedt dat het nasleep-effect klein is.

5. Monitor, maar concludeer niet te vroeg

Let op: je kunt NIET tussendoor kijken hoe het gaat, zoals bij normale A/B tests.

Waarom niet? Bij normale A/B tests zie je meteen beide groepen. Bij switchback zie je eerst alleen A (of alleen B), dan alleen B (of alleen A). Dat geeft geen zinvol beeld.

Wat je WEL moet monitoren:

• Gebeuren de switches op de juiste tijden?
• Komt de data binnen zoals verwacht?
• Zijn er geen technische problemen?
• Zijn er externe events die je moet documenteren? (campagnes, uitval, etc.)

Wat je NIET moet doen:

• Tussentijds kijken of "B beter gaat dan A"
• Vroeg stoppen omdat je "al een verschil ziet"
• De test verlengen omdat je "nog geen verschil ziet"

Wacht tot het einde, laat je expert de analyse doen, en trek dan conclusies.

6. Test je switching-mechanisme eerst (met een dummy test)

Voor je een echt experiment start: doe een technische test met twee identieke versies (A en A').

Schakel een paar keer heen en weer en verifieer:

• De switch gebeurt op het geplande moment
• Alle gebruikers zien de juiste versie
• Je tracking werkt correct
• Er zijn geen caching issues
• Je metrics kloppen (A en A' zouden identiek moeten zijn)

Dit voorkomt vervelende verrassingen tijdens je échte test.

7. Documenteer alles fanatiek

Houd een logboek bij (spreadsheet is prima) met:

• Exacte switch tijden - tot op de minuut
• Je buffer-periodes - wanneer begon/eindigde elke buffer?
• Externe events - marketing campagnes, technische problemen, PR, grote nieuws
• Traffic anomalieën - onverwachte pieken of dips
• Code changes - ook kleine bugfixes tellen
• Weekenden en feestdagen - deze gedragen zich anders

Je expert heeft dit nodig om de analyse te doen. En als er rare resultaten zijn, kun je hiermee verklaren waarom.

8. Communiceer verwachtingen met je team

Switchback experimenten zijn anders dan A/B tests. Zorg dat je team weet:

• Je ziet geen real-time resultaten tijdens de test
• Je kunt niet tussentijds switchen van strategie
• Je kunt niet segmenteren zoals bij normale A/B tests (geen "hoe doen vrouwen vs mannen?")

• Je hebt een expert nodig voor de analyse
• Het duurt langer voor je betrouwbare conclusies hebt
• De setup is complexer, maar dat is oké voor deze situatie

Beter om dit vooraf te bespreken dan achteraf teleurstellingen.

9. Begin met een low-risk test

Je eerste switchback experiment is een leerervaring. Zorg dat de stakes niet te hoog zijn.

Goed eerste experiment:

• Test twee varianten die je beide prima vindt (niet één heel risicovol)
• Test op een niet-kritisch onderdeel eerst
• Kies iets waar je verwacht weinig nasleep-effect te hebben
• Geef jezelf ruim de tijd (geen deadline pressure)

Slechte eerste experiment:

• Test een radicale verandering waar je CEO op wacht
• Test iets met waarschijnlijk grote nasleep-effecten
• Doe het op je checkout tijdens Black Friday
• Probeer 3 varianten tegelijk te testen (houd het bij A/B)

Leer de methode met een veilige test. Dan kun je bij volgende experimenten groter en complexer gaan.

Mijn conclusie: wanneer pak je switchback experimenten?

Laten we het samenvatten met een praktische beslisboom:

1. Ondersteunt je platform A/B testing?
   → Ja, en groepen beïnvloeden elkaar niet: Gebruik gewoon A/B testing. Simpeler en beter.
   → Nee, of groepen beïnvloeden elkaar wel: Ga naar stap 2.
2. Heb je toegang tot de juiste tools of experts?
   → Nee, en ik kan ze ook niet krijgen: Switchback is dan niet haalbaar. Je hebt Statsig, Eppo, of een ervaren data-analist nodig.
   → Ja, ik heb een tool of expert: Ga naar stap 3.
3. Heeft je test snel zichtbare effecten die ook snel verdwijnen?
   → Nee (loyaliteit, account-aanmaak, lange merkherinnering): Switchback is waarschijnlijk niet geschikt. Te veel nasleep-effect.
   → Ja (UI changes, prijzen, checkout-flow): Ga naar stap 4.
4. Heb je genoeg traffic voor voldoende switches binnen je experiment tijd?
   → Nee: Te weinig data. Je hebt een power analyse nodig om te bepalen of switchback haalbaar is met jouw traffic niveau. Vraag je expert om dit uit te rekenen.
   → Ja, naar verwachting wel: Switchback kan een goede optie zijn! Lees verder voor concrete use cases.

Concrete use cases waar switchback echt de oplossing is:

1. Shopify Plus checkouts

• Probleem: Platform ondersteunt geen A/B testing op checkouts
• Oplossing: Switchback met hourly of daily switching
• Let op: Je hebt custom development nodig voor de switching-logica

2. Marktplaatsen met het waterbed-effect:

Uber/Lyft - Pricing tests

• Probleem: Hogere prijzen groep A → minder ritten → meer chauffeurs voor groep B → kortere wachttijden groep B
• Oplossing: Hele stad switcht elk uur van prijs

Deliveroo/UberEats - Commissie tests

• Probleem: Hogere commissie groep A → restaurants verhogen prijzen → klanten kiezen groep B restaurants
• Oplossing: Alle restaurants switchen tegelijk van commissiestructuur

Airbnb - Zoekalgoritme tests

• Probleem: Nieuw algoritme groep A → meer boekingen → minder beschikbaarheid voor groep B
• Oplossing: Hele platform switcht elk uur van algoritme

bol.com marketplace - Verkoper-features

• Probleem: Nieuwe feature groep A verkopers → meer sales → minder voor groep B verkopers
• Oplossing: Alle verkopers krijgen tegelijk feature A of B

3. Eén ondeelbare unit:

Warehouse-tests - Je test een nieuw picking algoritme

• Je kunt niet half het warehouse splitsen
• Je kunt wel per dag of per shift switchen

Stad/regio-tests - Je test een nieuwe marketing strategie in Amsterdam

• Je kunt niet half Amsterdam versie A geven
• Je kunt wel per week switchen tussen strategieën

Platform-wide features - Je test een nieuwe checkout-flow

• Je hebt maar één codebase die live is
• Je kunt wel elke dag de feature aan/uit zetten

4. Enterprise klanten (elk uniek):

• Je hebt 5 grote enterprise klanten
• Ze zijn zo verschillend dat je ze niet met elkaar kunt vergelijken
• Maar je kunt ze wel met zichzelf vergelijken op verschillende momenten
• Elke klant switcht op zijn eigen schedule tussen A en B

Wat je nodig hebt om te starten:

Tools die switchback ondersteunen:

• Statsig - Volledige switchback support, automated analysis
• Eppo - Ook switchback functionaliteit (voor zover ik weet)
• Custom oplossing - Voor Shopify of andere platforms waar je zelf moet bouwen

Of: een data-analist met ervaring in:

• Time series experimenten
• Randomization inference methoden (Fisher tests)
• Bootstrapping voor experiment-analyse
• R of Python voor statistische analyse

Mijn advies voor als je wilt beginnen:

1. Zorg dat je de analyse geregeld hebt
   Eerst een tool of expert regelen. Zonder dat kun je niet beginnen.
2. Start klein en veilig
   • Test twee varianten die je beide oké vindt (niet één heel risicovol)
   • Kies iets met weinig verwacht nasleep-effect
   • Geef jezelf ruim de tijd (4-6 weken)
3. Begin met frequente switches
   • Marktplaats: hourly switching
   • E-commerce checkout: daily switching
   • Grote features: switches elke paar dagen
4. Gebruik buffer-tijd
   Ook als je denkt dat het niet nodig is. Bij je eerste test: speel het veilig.
5. Documenteer alles
   Je expert heeft dit nodig voor de analyse.
6. Wacht op de volledige analyse
   Niet tussentijds concluderen. Wacht tot je expert de correcte statistische analyse heeft gedaan.

Belangrijkste lessen:

• Switchback experimenten lossen echte problemen op waar A/B testing faalt
• Ze zijn complexer, maar dat is oké - sommige problemen vereisen complexere oplossingen
• Je MOET de juiste tools of experts hebben voor de analyse
• Jouw rol: de test goed ontwerpen. Hun rol: de data correct analyseren
• Begin klein, leer de methode, ga dan groter

• Je kunt dit niet zelf in Excel analyseren
• Je kunt niet tussentijds kijken en concluderen
• Je kunt niet zomaar segmenteren zoals bij normale A/B tests

Verder lezen en bronnen

Als je dit artikel interessant vond, zijn dit de bronnen waar ik uit heb geput:

Wetenschappelijke papers (voor als je echt de diepte in wilt):

• Bojinov & Shephard (2019): "Time series experiments and causal estimands: exact randomization tests and trading" - Over de Fisher randomization test methode https://arxiv.org/pdf/1706.07840
• Bojinov et al. (2020): "Design and Analysis of Switchback Experiments" - Het definitieve paper over hoe je switchback experimenten ontwerpt en analyseert https://arxiv.org/pdf/2009.00148

Tools & Praktische documentatie:

• Statsig Switchback Documentation: hoe Statsig switchback experiments implementeert https://docs.statsig.com/experiments/types/switchback-tests

Heb je vragen over switchback experimenten? Of wil je sparren over hoe je dit zou kunnen toepassen voor jouw situatie?

Ik denk graag met je mee over:

• Of switchback de juiste oplossing is voor jouw probleem
• Hoe je een eerste test zou kunnen opzetten
• Welke tools of experts je nodig hebt
• Hoe je je team hierin kunt meenemen

Laat het me weten!

Hulp nodig? Ik help CRO teams als coach of specialist met 'de voeten in de klei'

Gijs heeft meer dan 16 jaar ervaring in het verhogen van conversies als freelance CRO specialist.

Hij combineert zijn expertise in psychologie, statistiek, development, UX design en projectmanagement om alles uit CRO te halen.

Met een track record van meer dan 7.500 uitgevoerde A/B tests is hij een van Nederlands meest ervaren conversie specialisten.

Sinds 2013 is Gijs CXL Certified, een internationaal erkend certificaat voor conversie-optimalisatie.

Gijs is winnaar van de WhichTestWon Award, een internationaal erkend onderscheiding voor conversie-optimalisatie.

Dit is wat zijn klanten over hem zeggen, en dit is het verhaal van Gijs.