Meestal is het schrijven van een test in een A/B-test tool redelijk duidelijk. Je schrijft een stukje JavaScript of jQuery in de code editor, stelt de targeting en triggers in en de gewenste wijzigingen worden uitgevoerd zoals verwacht. Wanneer je echter te maken krijgt met een Single Page Application (SPA) wordt het schrijven van een A/B test een stukje lastiger. Een Single Page Application is namelijk geen traditionele website en gedraagt zich een klein beetje anders, wat soms verwarrende resultaten op kan leveren.
Wat is een Single Page Application?
Traditioneel wordt de html van een website opgebouwd door een server en vervolgens geheel naar de browser gestuurd. De browser ontvangt deze code en rendert de pagina op je scherm. Zodra je klikt op een link om van pagina te wisselen dan wordt dit doorgegeven aan de server en krijgt de browser een volledig nieuwe pagina terug. Het nadeel van de traditionele methode is dat bij elke klik alle content opnieuw gedownload wordt, ook wat eigenlijk helemaal niet vervangen hoeft te worden. Dynamische velden zoals formulieren worden weer gewist, tenzij dit in de code op een andere manier is opgelost.
Een Single Page Application (SPA) werkt iets anders. Bij een SPA is de site volledig gebouwd met JavaScript en bouwt niet de server, maar de browser de pagina. De browser ontvangt een lege pagina van de server met daarbij een pakket aan JavaScript en data en bouwt vervolgens de pagina zelf. Wanneer de gebruiker vervolgens op een link klikt wordt er geen nieuwe pagina geladen, maar krijgt de browser van de server alleen de nieuwe content gestuurd en vervangt dit in de browser zelf en past de url aan indien nodig.
Elementen die niet vervangen hoeven te worden blijven staan, elementen die niet langer nodig zijn worden verwijderd en nieuwe elementen worden gerenderd. Na de eerste keer laden hoeft niet steeds een hele pagina geladen te worden, maar alleen de stukjes content die nodig zijn. Dit zorgt voor betere performance en een meer dynamische website omdat bestaande data blijft staan.
De problemen met A/B-testen op een SPA
Helaas brengt dit alternatieve gedrag van een Single Page Application ook een aantal nadelen met zich mee, waaronder bij het schrijven van A/B-testen.
We lopen namelijk met regelmaat tegen de volgende uitdagingen aan:
- Een test triggert soms niet
Bij een Single Page Application is een paginabezoek eigenlijk geen écht paginabezoek, omdat de browser niet meer daadwerkelijk van pagina wisselt, maar alleen de content en url vervangt.
Hierdoor hebben sommige tools niet in de gaten dat de pagina gewijzigd is en wordt de test niet getriggerd. - Veranderingen verdwijnen weer
Wanneer de elementen op een pagina niet langer relevant zijn haalt de SPA deze weg uit de code en voegt ze zodra nodig weer opnieuw toe. Dit zorgt ervoor dat de wijzigingen die we hebben gedaan ook weer worden weggehaald samen met het element en niet worden onthouden. Is het element vervolgens weer nodig wordt deze opnieuw op de pagina geplaatst en zien we het origineel in plaats van wat we willen zien. - Het element bestaat nog niet wanneer we de test draaien
Omdat een SPA pas de elementen toevoegt zodra ze nodig zijn is het mogelijk dat het element nog niet op de pagina bestaat wanneer we de test activeren. - We kunnen geen click event listener zetten op een niet bestaand element
In sommige gevallen willen we clicks op een element tracken, maar bestaat deze nog niet totdat de gebruiker een bepaalde handeling uitvoert, zoals een klik of scroll naar een bepaalde positie.
Hoe kunnen we dan toch een werkende A/B-test bouwen?
Gelukkig zijn er een aantal dingen die we kunnen doen om om bovenstaande problemen heen te werken.
Pas de triggering van de tool aan
Ten eerste passen we de trigger in de tool aan. Standaard triggeren tools bij elke page load, maar in dit geval moeten we een andere optie gebruiken:
- Activatie event
- Activatie bij url verandering
- Continue activatie
De beste keuze is een activatie event omdat daarmee heel specifiek de test getriggerd kan worden wanneer je dat wilt, maar hiervoor is vaak wat extra development hulp nodig.
Bij activatie bij url verandering “luistert” de tool naar het veranderen van de url en triggert dan de test. Dit benadert de triggering van een traditionele website en zal dan ook het meeste gebruikt worden. Continue activatie is wat minder handig in gebruik omdat de test herhaaldelijk wordt geactiveerd. Dit kan soms nodig zijn, maar in dit geval moeten we een bescherming bouwen die voorkomt dat de wijzigingen meerdere malen worden toegepast.
Wacht op het bestaan van het element om de test te draaien
Als het element dat we aan willen passen nog niet bestaat dan kunnen we een stuk code gebruiken dat wacht todat het element aanwezig is en pas daarna de code draait.
Voeg de volgende code toe aan het begin van je test:
Vervolgens kunnen we deze als volgt gebruiken:
Zodra de waitForElement functie het element heeft gevonden wordt de code binnen het codeblok uitgevoerd.
Gebruik een class en if statement om te kijken of code wijzigingen al zijn toegepast
Zodra de test is uitgevoerd is het aan te raden een class toe te voegen aan het element dat is gewijzigd. Met deze class kunnen we elke keer dat de test wordt getriggerd checken of de code al eens is uitgevoerd. Dit doen we door middel van een if statement om onze code heen waarin we checken of een element met die class bestaat.
Hier checken we:
- Of de knop met de class ‘button-is-changed’ bestaat
- Zo nee, dan voeren we de verandering uit en voegen we daarna die class toe aan de knop
- Als de test nog een keer wordt getriggerd dan wordt de verandering niet nogmaals uitgevoerd om dat het bestaan van de class op het element aangetoont dat de wijzigingen al zijn toegepast
Een click event tracken op een niet-bestaand element
In het geval dat we een event listener willen plaatsen op een element dat op het moment dat de test wordt getriggerd nog niet bestaat is hier een goede workaround voor:
In deze code zetten we een click event listener op de hele pagina en checken we bij elke klik of het geklikte element overeenkomt met de css selector ‘.button-dynamic’ of een element daar binnen.
Door deze code te gebruiken kan een element worden weggehaald en weer toegevoegd, zonder dat de functionaliteit verloren gaat.
De uiteindelijke code
Als we deze oplossingen samenvoegen krijgen we het onderstaande resultaat als basis voor onze A/B-test code voor een SPA:
… Even tussendoor: we sturen elke drie weken een nieuwsbrief met daarin de laatste blogs, teamupdates en natuurlijk nieuws over het aanbod in onze academy. Klik hier om je in te schrijven.
Nu heb jij ook de mogelijkheid om op een Single Page Application lekker te kunnen A/B testen! Heb je vragen over A/B testen op een Single Page Application of wil je meer weten over ons werk? Neem dan contact op.
