Stappenplan: 10 functies bouwen voor je server-side testtool

Experimenteren (A/B-testen) op de server is een onderwerp dat steeds meer gaat spelen. Wanneer je besluit over te schakelen naar server-side testen (in plaats van client-side), sta je voor een belangrijke keuze: bouwen of kopen. Het bouwen van de basisfuncties van je server-side testomgeving is vaak eenvoudiger dan je denkt, en kan ook goedkoper zijn. In dit artikel beschrijf ik de voordelen van server-side experimenten uitvoeren én een chronologisch stappenplan.

Voordat je begint, moet je wel basiskennis hebben over het verschil tussen experimenteren aan de client-side en aan de server-side. Wanneer je een URL in je browser typt, stuurt deze een verzoek naar een server. Deze server stuurt data terug naar je browser, waardoor je de website ziet. Bij experimenten aan de client-side worden de wijzigingen die je aanbrengt in de browser geladen. Met server-side worden de wijzigingen op de server geladen voordat ze naar de browser van je bezoeker worden verzonden. Meer weten over server-side testen? Lees dan deze blog.

Waarom zou je experimenten?

Er zijn verschillende voordelen wanneer je experimenten uitvoert op je server:

• Het is mogelijk om gecompliceerde A/B-testen uit te voeren. Denk hierbij aan testen van product(kenmerken), algoritmen en de volgorde van de stappen bij het afrekenen.
• Er is geen flickering. Dit treedt op wanneer de originele pagina kort wordt weergegeven voordat de B-variant verschijnt. Ook wel Flash of Original Content (FOOC) genoemd.
• Het heeft vaak de voorkeur van development, omdat A/B-testen aan de server-side beter passen bij websitecode.
• Winnende experimenten kunnen meteen worden geïmplementeerd.
• Het maakt gebruik van server-side cookies. Aangezien steeds meer browsers cookies aan de client-side na een paar dagen verwijderen, zijn je testdata hierdoor betrouwbaarder.

Maar er zijn ook nadelen:

• Het is moeilijker om experimenten op te zetten, aangezien je over het algemeen de codetaal van je website moet gebruiken. Hoewel ik ook oplossingen heb gezien met de mogelijkheid om experimenten op te zetten met Javascript en CSS (zoals in client-side tools).
• Er moet voldoende development-capaciteit zijn om experimenten uit te voeren.
• Wanneer je een bestaande oplossing gebruikt (tools zoals Optimizely of ABTasty hebben server-side oplossingen), kan dit behoorlijk duur worden.
• Wanneer je de tool bouwt, heb je developers nodig om de tool te onderhouden en bij te werken.

Mijn ervaring is dat het bouwen van de tool je geld bespaart ten opzichte van het kopen van de tool.

De 10 functies die je kan bouwen

Wanneer je besluit de server-side tool te bouwen, is het aan te raden om de volgende functies chronologisch te implementeren. Het is essentieel om klein te beginnen om de complexiteit te verminderen.

1. De coinflip

De coinflip splitst de websitebezoekers, zodat de controle en variant(en) aan de juiste bezoekers worden getoond. Dit is over het algemeen relatief eenvoudig te bouwen. De targeting zou iets gecompliceerder kunnen zijn.

Hier geldt ook het principe: begin klein. Bijvoorbeeld eerst met het targeten op device.

2. Stop-/startknop

Met een stop- en startknop kunnen meer mensen een experiment starten en stoppen. Het stoppen van een experiment kan belangrijk zijn als de variatie veel slechter presteert of fouten veroorzaakt.

3. Gebruikersinterface

Met een gebruikersinterface wordt je tool gebruiksvriendelijker, zodat meer collega’s er gebruik van kunnen maken. Dit helpt bij het democratiseren van experimenten, waardoor meer product teams hun experimenten kunnen uitvoeren en hun ideeën kunnen valideren.

Met een gebruikersinterface wordt je tool gebruiksvriendelijker, zodat meer collega’s er gebruik van kunnen maken

Ergens tussen functie 1 en 3 moet je een QA- (quality assurance) of voorbeeldlink maken. Dit helpt andere mensen om te controleren of de variant wordt weergegeven en presteert zoals het hoort, voordat het experiment live gaat.

Op een bepaald moment wil je ook een begin- en einddatumfunctie in de tool bouwen, zodat je experimenten gemakkelijker kunt inplannen.

4. Server-side data: belangrijkste KPI

Data aan de server-side zijn over het algemeen betrouwbaarder dan de data op een platform zoals Google Analytics (client-side). Het opzetten van metingen aan de server-side kan een uitdaging zijn. Een oplossing is, nogmaals, om klein te beginnen. Begin bijvoorbeeld met het meten van alleen het aantal bezoekers en conversies van je belangrijkste KPI.

5. Server-side data: verschillende KPI’s

De volgende stap zou zijn om statistieken op te nemen voor meerdere KPI’s.

6. Guardrail metrics en veiligheidscontroles

Met je data die beschikbaar zijn in de tool, kun je guardrail metrics instellen. Guardrail metrics zijn cruciale statistieken voor je website, waarmee je een drempel instelt voordat je gaat experimenteren. Wanneer de aantallen de drempel overschrijden, moet het experiment worden beëindigd of niet tot winnaar worden verklaard. Dit kan gebeuren wanneer ineens blijkt dat je wijzigingen een onverwachte negatieve impact op je business hebben. Paginasnelheid is een veel voorkomende guardrail metric, evenals browserspecifieke prestaties. Je kunt deze guardrail metrics gebruiken als veiligheidscontroles.

7. Geavanceerd segmenteren

Omdat er veel data beschikbaar zijn in de tool, kun je nu ook geavanceerde segmentaties opzetten, waardoor personalisatie-experimenten mogelijk zijn.

In veel situaties kan deze functie in een eerder stadium worden ingebouwd wanneer je een data management platform hebt dat verbinding kan maken met je tool.

8. Automatiseer berekeningen

Hoe meer tijd je bespaart met het berekenen van je resultaten, hoe meer experimenten je kunt uitvoeren. Wanneer je de berekeningen automatiseert, inclusief de significantie berekening, hebben je analisten minder tijd nodig om de resultaten van de experimenten te analyseren.

9. Rapportage en documentatie

De volgende stap zou geautomatiseerde rapportage en documentatie kunnen zijn.

10. Geautomatiseerde experimenten

De laatste stap is geautomatiseerd experimenteren. Hierbij kunnen Scrum-teams en developers geen updates meer live zetten voor alle bezoekers. Elke release zal dus automatisch een experiment zijn. Op deze manier weet de organisatie zeker dat alleen winnaars volledig live worden gezet, wat resulteert in groei.

Server-side experimenteren is de toekomst

Dit artikel gaf een kort overzicht van de functies waarmee je rekening moet houden bij je testtool. De toekomst van online experimenten ligt in testoplossingen aan de server-side. Je kunt niet alleen complexere experimenten opzetten, het resulteert ook in betrouwbaardere experimenten vanwege privacyregels, server-side tracking en geen flikkereffect. Houd bij het bouwen of kopen rekening met je langetermijndoelen en zoek de beste oplossing.

Als je bedrijf niet de ervaring heeft om dergelijke tools te bouwen, neem dan contact op met anderen in de markt. Zoals ze je waarschijnlijk zullen vertellen, is de coinflip relatief eenvoudig te bouwen. Ga daarom aan de slag, begin klein en werk van daaruit verder. Succes!