Je hoort het steeds vaker, organisaties die server-side A/B-testen in plaats van client-side. Wat houdt dit in? Waarom zou je server-side testen? Wat zijn de uitdagingen? En welke verschillende oplossingen en tools zijn er? In dit artikel proberen we deze vragen zo goed mogelijk voor je te beantwoorden.

Client-side A/B-testen betekent dat wijzigingen van je A/B-test plaatsvinden in de browser van de bezoeker. Middels een client-side A/B-testtool is het opzetten van een eenvoudige test niet heel ingewikkeld (al is bekendheid met HTML, CSS en JS nuttig). Het relatieve gebruiksgemak van client-side heeft echter ook nadelen. De mogelijkheden qua testen blijven voornamelijk beperkt tot het design. Denk aan: kleuren, teksten, lay-out en elementen. Voor sommige organisaties is dit prima. Er zijn talloze testideeën die je aan client-side kunt uitvoeren, maar op een gegeven moment wil je meer mogelijkheden. Dit is waar server-side A/B-testen om de hoek komt kijken.

Wat is server-side testen?

A/B-testen aan de server-side is een vorm van experimenteren waarbij de variatie van een test rechtstreeks op de webserver wordt weergegeven in plaats van in de browser van de gebruiker. Bij server-side testen kunnen developers, met behulp van code, rechtstreeks op de servers de A/B-testen live zetten. Omdat de implementatie bij server-side directer is, maakt het veel geavanceerdere A/B-testen mogelijk. Dit betekent echter wel dat degene die de testopzet ervaren moet zijn in back-end codeertalen, zoals PHP of Node.js.

Wat zijn de voordelen van server-side testen?

Bij server-side testen is het mogelijk om gecompliceerde A/B-testen uit te voeren. Denk aan product(features), algoritmes en volgorde stappen in de checkout. Andere redenen om voor een server-side oplossing te kiezen zijn:

• A/B-testen zijn van hogere kwaliteit omdat je flickering voorkomt (wanneer een originele pagina kort wordt weergegeven voordat de B-variant verschijnt), geen WYSIWYG editor gebruikt (dit leidt vaak tot slechte code) en winnaars direct kan implementeren omdat die al klaar staan op de server.
• Heeft vaak de voorkeur van development omdat server-side A/B-testen beter passen binnen de websitecode en de developers hebben het zelf meer in de hand.
• Meer teams kunnen zelfstandig testen. Product teams kunnen bijvoorbeeld zelf hun nieuwe ontwikkelingen eerst valideren voordat ze live gezet worden.
• Het voldoet aan de security en privacy eisen. Met client-side testen heeft een extern script van je tool toegang tot je website en data, dit brengt risico’s met zich mee. Zeker als deze geplaatst wordt achter een login of op plekken waar klantdata beschikbaar is. 
• Door ITP van Safari worden je first-party cookies versneld verwijderd (1-7 dagen). Dit heeft effect op de kwaliteit van je data en kan ervoor zorgen dat bezoekers in verschillende sessies een andere variant van je test te zien krijgen. Komt een bezoeker terug op je website nadat zijn cookie is verwijderd, dan wordt deze bezoeker gezien als nieuw. Hierdoor wordt een nieuwe verdeling gemaakt in je A/B-test, waardoor je dus niet zeker weet of de gebruiker steeds dezelfde variant heeft gezien. En omdat de gebruiker als nieuw wordt gezien, stijgt het aantal unieke gebruikers aanzienlijk. Afhankelijk van je bezoekers en duur van je test kan dit een flinke impact hebben op je data en je resultaten. First-party cookies kunnen zowel vanuit de server als vanuit de client (door middel van javascript) gezet worden. ITP richt zich specifiek op het gebruik van client-side cookies. A/B-testen en analytics tools maken gebruik van deze client-side first-party cookies, omdat ze ervoor zorgen dat een gebruiker over sessies heen wordt herkend en dat een gebruiker steeds dezelfde variant van een A/B-test blijft zien. Door cookies server-side te plaatsen kan je voorkomen dat je cookies worden verwijderd en met oog op de toekomst is dit een goede reden om over te stappen. De volgende ITP update zorgt er voor dat dit gaat gelden voor alle browsers op een iOS apparaat en dat dus cookies gewist worden na zeven dagen (en met een ‘decorated link’ al na een dag).
• Het laatste voordeel is kostenbesparing, indien je de server-side oplossing zelf maakt en geen externe tool hiervoor gebruik (hierover straks meer). De jaarlijkse kosten voor een client-side tool kunnen hoog oplopen, met name op websites met veel bezoek. Waar server-side testen soms de perceptie heeft om duur te zijn (want de oplossing moet gebouwd en onderhouden worden) blijkt dit in de praktijk niet altijd het geval te zijn. Dit is wel afhankelijk van het type oplossing dat je kiest (zowel client- als server-side), maar het betekent niet automatisch dat een server-side oplossing duurder is.

Wat zijn de uitdagingen van server-side A/B-testen?

Als server-side A/B-testen alleen maar voordelen heeft dan zou iedereen het doen. Stel je wil overstappen naar server-side, dan zijn er een aantal uitdagingen waarmee je rekening moet houden:

• Er is voldoende development capaciteit nodig in de product teams. Bij server-side testen ligt het ontwikkelen van de experimenten bij de interne teams en niet meer bij een front-end developer die ook in het CRO-team zit. De developers implementeren nu niet alleen de winnende experimenten, maar ze moeten elke test ontwikkelen. Zijn er andere (interne) prioriteiten, dan loopt je testprogramma vertraging op omdat development minder tijd heeft voor het bouwen van A/B-testen.
• De juiste mindset in de product teams. De scrum methode is gefocust op het uitvoeren én afronden van een project. Uiteraard wordt daarbij ook gekeken naar de mogelijke waarde. Als dit project wordt gevalideerd door middel van een experiment kan dit betekenen dat bepaalde opleveringen niet live worden gezet als ze een verliezer zijn, ook al zijn ze al gebouwd. Dit heeft impact op de ‘mindset’ van product teams en kan zorgen voor een lagere motivatie. Iets waar veel tijd en moeite in is gestopt tijdens een sprint gaat toch ineens niet live.
• Development capaciteit voor het maken en doorontwikkelen van je tool. Zelfs als je eerste variant van je zelf ontwikkelde server-side tool live staat, betekent het niet dat die af is. Er is development capaciteit nodig om je tool te blijven ontwikkelen en onderhouden. Hier zitten ook kosten aan verbonden.
• Standaardiseren van het proces. Als je net begint met server-side testen, dan gaat er de nodige tijd en energie inzitten om alle teams op deze manier te laten werken. Natuurlijk hoef je niet in een keer over en kan dit een geleidelijk proces zijn.
• Server-side data is over het algemeen betrouwbaarder dan de data in een platform zoals Google Analytics. Dit moet alleen wel goed gebouwd worden en dat vormt weer een uitdaging. In eerste instantie kunnen de analyses gewoon nog gemaakt worden in de analytics tool, voordat het geïntegreerd wordt in de server-side oplossing.

Oplossingen

Als je server-side wil testen, dan zijn er eigenlijk twee oplossingen:

1. Zelf een server-side oplossing maken.
2. Je kan een externe testtool gebruiken om je testen te implementeren (zoals bij client-side). De meeste testtools (behalve Google) hebben of zijn bezig met het ontwikkelen van een server-side oplossing.

Stel je gaat je eigen server-side oplossing maken, houd dan rekening met de volgende punten:

• Begin klein om complexiteit tegen te gaan (experimenteer met experimenteren).
• Tips om developers mee te krijgen en gemotiveerd te houden:
  • A/B-testen moet een uitgangspunt worden, niet een vraag.
  • Experimenteren moet meegaan in het ritme van scrum teams.
  • Deel onverwachte learnings uit A/B-testen.
  • Teams kunnen een outcome KPI (meer conversie) krijgen, in plaats van alleen een delivery KPI (vijf A/B-testen per maand).
  • Laten zien dat alleen een delivery KPI slechts in een beperkt aantal gevallen tot positieve impact leidt.
• Server-side meten maakt bucketen mogelijk en data betrouwbaarder. Zoals hierboven aangegeven vormt server-side meten wel weer een uitdaging. Het moet namelijk (goed) gebouwd worden. In dit geval kan ook gelden: begin klein. Begin bijvoorbeeld met het meten van alleen het aantal bezoekers en de conversies op de belangrijkste metric.
• De veronderstelling leeft dat het heel lastig is om zelf een server-side oplossing te bouwen en te onderhouden. Naar aanleiding van een meetup met bedrijven die zelf een oplossing gebouwd hebben blijkt dit erg mee te vallen. Zeker de eerste versie waarin bezoekers random verdeeld moeten worden blijkt niet al te ingewikkeld. Een belangrijke learning is vooral: start er gewoon mee en blijf er niet eeuwig over discussiëren.
• Bij verlies van snelheid en controle bij de teams, kan gekozen worden voor een hybride oplossing. Hierbij maak je testen omtrent design via je testtool en laad je die aan de client-side in, en doe je gecompliceerde testen via je server-side oplossing. Dit is ook zeker aan te raden als je net start met server-side A/B-testen.

Voor ons wegen de voordelen zeker op tegen de nadelen om (deels) server-side te testen. Op een gegeven moment loop je toch aan tegen de beperkte mogelijkheden en mindere kwaliteit van client-side testen. Veel succes én blijf vooral testen 🙂 

Want to know more?

We denken graag met je mee! Heb je hulp of advies nodig? Neem dan contact op met Ruben de Boer.

Wil je maandelijks het laatste nieuws en artikelen over ons vakgebied ontvangen? Sign up for our newsletter!

Ruben de Boer en Tom van den Berg gaan in een Engelstalige podcast voor CRO.CAFE ook in op server-side experimenteren. Beluister de podcast here.