A/B-testen: de voor- en nadelen van ‘client-side’ versus ‘server-side’

A/B-testen kan op twee manieren: ‘client-side’ en ‘server-side’. Wat de beste keus is hangt af van de vereisten en het gebruik binnen je organisatie. Een overzicht van de voor- en nadelen van beide methodes.

In januari 2023 maakte Google bekend te stoppen met de ondersteuning van Optimize per september 2023: een goede gelegenheid om opnieuw te kijken naar de voordelen en nadelen van verschillende testmethodes, zoals client-side versus server-side A/B-testen.

De meeste organisaties testen client-side, maar er is ook de mogelijkheid om alleen server-side te testen. Het verschil zit hem in waar de test wordt uitgeserveerd en hoe de aanpassingen op de website worden geplaatst en gemeten. Bij het testen aan de client-side deel je de gebruiker bij een variant in vanaf de browser, terwijl server-side de gebruiker gelijk indeelt vanaf het contact met de server. Een server-side A/B-testoplossing kun je zelf bouwen of je kunt een oplossing van bijvoorbeeld VWO of Optimizely gebruiken.

Het is belangrijk bij het uitvoeren van A/B-testen om zeker te zijn dat de variant (A of B) op een willekeurige manier wordt getoond en dat de prestaties van beide varianten accuraat worden gemeten. In dit artikel staat variant A steeds gelijk aan de oude situatie en is variant B de versie met de aanpassing die we willen testen. Met A/B-testen is de betrouwbaarheid van data cruciaal. De populaire data-uitspraak is ‘garbage in = garbage out’ gaat ook hier op: zonder een sterk datafundament kunnen we de data niet interpreteren en geen uitspraak doen. Daar ga ik straks nog verder op in.

‘Client-side’

Bij client-side A/B-testen wordt de aanpassing van de test geplaatst in de browser van de gebruiker. Wanneer een gebruiker de website bezoekt, wordt met een stukje code een verzoek gestuurd naar de tooling, die er vervolgens voor zorgt dat de gebruiker variant A of B te zien krijgt. Client-side tests zijn meestal sneller en makkelijker om op te zetten door drag-&-drop-editors voor het testen van specifieke elementen op de pagina. Dit heeft echter een behoorlijke negatieve impact op laadsneldheid van de website en kan tevens leiden tot flickering, wanneer de A-variant nog even kort in beeld flitst voordat de B-variant laadt.

Flickering (bron: kameloon)

Naast deze voor- en nadelen betaal je per sessie of gebruiker in een A/B-test. Zeker voor grote organisaties die frequent willen A/B-testen kunnen de kosten daarmee behoorlijk oplopen.

‘Server-side’

Met server-side A/B-testen wordt de aanpassing van de test uitgevoerd op de server. Wanneer de bezoeker de website bezoekt, stuurt de server de gebruiker direct variant A of B van de pagina. Dat betekent dat de gebruiker meteen wordt ingedeeld bij variant A of B van de test en er geen aanvraag meer wordt gedaan naar externe tooling om de variant in te laden. Flickering bestaat daarmee dus niet meer. Tevens zijn de data betrouwbaarder, omdat de gebruiker vanaf het eerste contact wordt ingedeeld in variant A of B.

Server-side A/B-tests hebben over het algemeen meer middelen en developmentcapaciteit nodig om op te zetten, maar het voordeel is dat testen via de serverkant meer controle kan bieden, dat je niet betaalt per sessie en dat het een minimaal effect heeft op laadsnelheid van de website. Server-side heeft dus verschillende voor- en nadelen ten opzichte van client-side.

Voordelen:

• Databetrouwbaarheid – Server-side is betrouwbaarder, aangezien de variant wordt bepaald door de server.
• Laadsnelheid – Server-side heeft een minimale impact op laadsnelheid
• Gebruikerservaring – Vermijden van flickering door via de server de variant te bepalen
• Flexibiliteit – Meer flexibiliteit bij het testen van grote en kleine veranderingen
• Schaalbaarheid – Ongelimiteerd het aantal gebruikers in A/B-tests meenemen

Nadelen:

• Opzet is complexer – Server-side kost meer tijd om op te zetten dan client-side.
• Minder flexibel – Developer nodig voor de opzet test en geen drag-&-drop-editor.
• Kennisniveau – Server-side vereist meer technische kennis en ervaring dan client-side.

A/B-tests doormeten in Google Analytics 4

Naast het implementeren van de tooling voor client-side of server-side is het van groot belang om ook het doormeten strak neer te zetten. Het doormeten van een server-side of client-side A/B-test kun je in samenwerking met je developer of developmentpartij opzetten. Het is van belang dat een gebruiker pas wordt ingedeeld in een variant wanneer hij of zij een variant ook daadwerkelijk ziet, niet eerder of later. Wanneer dit niet gebeurt is het onmogelijk om de test te analyseren.

Voor het vervolg van dit artikel gaan we ervan uit dat dit goed gaat: de gebruiker heeft variant A gezien en moet nu ook variant A als waarde krijgen in Google Analytics 4. Hoe doen we dat? In het geval van GA4 kunnen we gebruikmaken van Google Tag Manager (GTM) en een GA4 event tag. Met de GA4 event tag kunnen we de gebruiker in de A/B-test op basis van een ‘dataLayer.push’ indelen in variant A of B. Voor meer informatie over de datalayer kun je dit artikel van Simo Ahava lezen.

Met het event ‘ab_test’ kunnen we vervolgens de gebruiker indelen op basis van ‘test_id’ en ‘test_variant’. Ik raad aan de waarden op gebruikersniveau te binden. Dit maakt de rapportage en de analyse van de test vervolgens namelijk eenvoudiger via BigQuery en de Google Analytics 4 interface. Daarvoor moet je twee custom user-dimensies toe te voegen aan GA4: ‘test_id’ en ‘test_variantì.

Optimizely adviseert de dimensies op gebeurtenisniveau toe te voegen. Zelf vind ik dat onnodig voor één A/B-test. Wanneer meerdere A/B-tests live zijn kan dit wel van meerwaarde zijn. Mijn persoonlijke voorkeur gaat naar gebruikersniveau.

Wat is het meest toekomstbestendig?

In het kort: client-side en server-side kunnen beiden geschikt zijn voor het uitvoeren van A/B-tests. Wat je kiest is afhankelijk van je behoeften. Ga je A/B-testen met 2000 of meer dan 15.000 gebruikers? Hoe groter het aantal gebruikers en je ervaring met A/B-testen, des te belangrijker het is om te starten met server-side A/B-testen. Server-side A/B-testen biedt meer schaalbaarheid, flexibiliteit en betrouwbaarheid, alleen kost het meer developmentcapaciteit en is het niet op te zetten via een drag & drop editor.

Wil je echt impact gaan maken en je website verbeteren op grote schaal? Dan kun je er ook voor kiezen direct te beginnen met server-side A/B-testen en zo het effect op de laadsnelheid van je website te minimaliseren. Tevens kun je op die manier ongelimiteerd A/B-testen met al je gebruikers, zonder te betalen per sessie en behoud je alle controle. Maar let op: wanneer je net begint met A/B-testen is het vrij extreem om inderdaad direct te beginnen met een eigen server-side A/B-testoplossing. Als je net begint raad ik aan te starten met de client-side-oplossing om te zien wat het effect is op je website of app.

Kortom, er is geen absoluut antwoord: het is van belang om zorgvuldig af te wegen welke methode het beste past bij je organisatie.

Over de auteur: Berend Vrakking is Data- en CRO-Consultant bij Reprise Digital.

Op de hoogte blijven van het laatste nieuws binnen je vakgebied? Volg Emerce dan ook op social media: LinkedIn, Twitter en Facebook.