Wat is server-side A/B testen?

Er zijn verschillende methoden om A/B testen uit te voeren op je website, zowel client-side als server-side. Hoewel de meeste tools gebruiken maken van een client-side aanpak, kan het heel interessant zijn om eens te kijken wat een server-side aanpak kan opleveren. Maar dan is het wel belangrijk om te weten: Wat is server-side testen nu eigenlijk?

Dat is een hele interessante vraag. Onze ervaring is dat op deze vraag verschillende antwoorden worden gegeven, afhankelijk aan wie je de vraag stelt.

 

Er zijn 2 mogelijkheden

In de praktijk komen we voornamelijk de volgende twee antwoorden tegen:

Antwoord 1: Server-side A/B testen zijn experimenten waarbij het gedrag van de website of (web)applicatie wordt getest en waarbij een developer nodig is om de gewenste veranderingen door te voeren.

Antwoord 2: Server-side A/B testen zijn experimenten waarbij geen javascript of tags gebruikt wordt, zodat er geen flicker-effect kan ontstaan.

Hoewel de antwoorden enigszins op elkaar lijken, zijn ze allebei correct. Maar het hangt echt af van je perspectief om te bepalen welk aspect nu belangrijk voor jouw situatie is.

Als snelheid belangrijk is

Als jouw website sterk is geoptimaliseerd voor performance & snelheid, dan klinkt server-side A/B testen waarschijnlijk erg aanlokkelijk. Je wil natuurlijk niet dat jouw bezoeker lang moet wachten tot een pagina met de bijbehorende variant compleet geladen is.

Jouw razendsnelle website kan dan wel eens de oorzaak zijn dat de bezoeker de verandering van de A/B test opmerkt, het flicker-effect ziet. Dat is vanuit het oogpunt van een “zuivere” A/B test natuurlijk niet de bedoeling. Jouw site is dan zo snel klaar met het weergeven van de content, dat de A/B test oplossing het niet kan bijbenen en achter de feiten aan holt. Omdat de code van het experiment niet geoptimaliseerd is, of wellicht wordt de code aan de "andere kant van het internet" gehost. Met als resultaat vertraging en een een "zichtbare" A/B test. 

De “oplossing” van client-side tools

De tools hebben hier een "oplossing" voor in de vorm van een trucje: Ze maken de originele content tijdelijk onzichtbaar (door het 100% transparant te maken), zodat je niet ziet dat de variatie wordt toegepast. Zodra de variatie volledig is geladen zal content weer worden getoond. Dat betekent dat al het harde werk om de website te optimaliseren grotendeels teniet wordt gedaan en dat er eigenlijk toch weer een flicker-effect ontstaat, alleen nu dan met een blanco pagina.

Als alternatief bieden de meeste tools een oplossing aan waarmee jouw developers vanuit de backend (meestal een webserver of applicatieserver) een verzoek aan de tool kunnen doen. De tool vertelt dan welke variant getoond moet worden en welke interactie geregistreerd. De developer (die heb je in dit geval wel voor elk experiment nodig) bouwt de noodzakelijke code in en je experiment zal zonder visuele bijwerkingen worden uitgevoerd.

Een andere aanpak

Een compleet andere, maar minstens zo effectieve oplossing is een tool die gebruik maakt van een "reverse-proxy" aanpak. De tool is dan tussen de browser en de webserver geïnstalleerd en ziet alle verzoeken van de bezoeker en de antwoorden van de webserver langskomen. Dat betekent dat er voor de bezoeker geen tags noodzakelijk zijn en dat er geen aanpassingen in de code van de applicatie gedaan moeten worden. De "reverse proxy" is dan een doorgeefluik met de mogelijkheid om pagina's aan te passen terwijl ze aan de bezoeker worden geserveerd. Ook kan er dan geregistreerd worden wat de bezoeker doet, klikt en invult, zonder daar extra tracking voor te hoeven inrichten. Immers, alle verzoeken van de browser gaan "door" de tool heen en zijn dus eenvoudig te registreren.

De voordelen van deze aanpak zijn dat er vanuit de browser geen wijzigingen meer doorgevoerd moeten worden en de pagina flicker-vrij zal worden geleverd. Aanvullend zou je ook informatie vanuit de tool kunnen doorgeven aan de applicatie of webserver, om het de developer gemakkelijk te maken. Die hoeft dan niet meer te communiceren met een API maar krijgt alle benodigde informatie voor variaties op een presenteerblaadje aangeleverd.

Als nadeel zou je kunnen denken aan de extra netwerk-stap die gemaakt moet worden, maar met een zorgvuldige implementatie zal dat meestal flink meevallen en niet opwegen tegen het nadeel van bijvoorbeeld het flicker-effect.

Samenvattend zijn er dus verschillende mogelijkheden als het gaat om server-side A/B testen en zul je per situatie moeten bekijken welke aspecten het beste passen bij jouw business-doelstelling en hoe je op de lange termijn het meeste rendement uit je tool haalt.

Wil je meer weten over server-side A/B testen? Neem dan eens een kijkje op onze website.