Steeds vaker wordt er geëxperimenteerd binnen organisaties en wordt er gestreefd naar een validatiegedreven cultuur binnen bedrijven. Zo draaien we bij Online Dialogue in samenwerking met onze klanten regelmatig A/B-testen. Het draaien van A/B-testen heeft ook zo zijn valkuilen. Een van deze valkuilen is het zogenoemde flicker effect. Dit effect kan het gedrag en de testresultaten beïnvloeden. In dit blog leggen wij uit wat het flicker effect is en hoe je dit kan oplossen.
Wat is een flicker effect
Bij het flicker effect, ook wel FOOC (Flash of Original Content) genoemd, krijgen de bezoekers eerst het origineel te zien en worden de aanpassingen vervolgens toegepast waardoor het visueel waarneembaar wordt.
Technisch gezien heb je bij client-side A/B-testen altijd een kleine interval. In een ideale situatie is dit zo kort, dat het voor het menselijk brein niet tot nauwelijks zichtbaar is. Zodra deze interval langer wordt en als het hinderlijk of duidelijk zichtbaar wordt ervaren is er sprake van een Flicker effect. Met name als er duidelijk te zien is dat er een aanpassing wordt gedaan na het laden van een pagina.
Het veroorzaken van een flicker effect wordt bepaald door 3 factoren:
1 Timing
Wanneer een pagina, de testtool, of de gebruikte assets (afbeeldingen, lettertypen) langzaam laden zal dit duidelijker waarneembaar zijn dan wanneer dit binnen enkele milliseconden plaatsvindt. Dit kan gebeuren doordat de bestanden erg groot zijn of wanneer de gebruiker een trage verbinding heeft, zoals bij een slechte verbinding.
2 De positie
Wanneer een element bovenaan de pagina staat is deze als eerst waarneembaar zonder interactie van de gebruiker, hierdoor is de kans groter dan wanneer deze “onder de vouw” staat of helemaal onderaan de pagina. Het duurt namelijk langer voordat de gebruiker het betreffende element visueel kan waarnemen.
3 Het formaat
Wanneer de visuele grootte toeneemt, hoe groter de kans dat dit ook wordt waargenomen. Het is een groot verschil of je een hero afbeelding opnieuw inlaadt of een tekstuele aanpassing.
Hoe op te lossen?
Vermijd het gebruik van Google Tag Manager voor het plaatsen van het script
Google Tag Manager is een fantastische tool om scripts in te laden op de website, maar in het geval van A/B-testen raden wij dit af.
Google Tag Manager moet namelijk eerst geladen worden. Dit script is een erg groot script en pas zodra deze klaar is met laden begint de rest te laden. De scripts die vanuit Google Tag Manager komen worden door GTM in een willekeurige volgorde geladen, wat kan betekenen dat de A/B-test tool zeer laat geladen wordt.
Het is daarom aan te raden om de scripts van A/B-test-tool altijd direct in je code te plaatsen.
Plaats het script van de A/B-test-tool zo hoog mogelijk in de code
Hoe hoger het script in de code staat, hoe eerder het script geladen wordt. Wij raden daarom aan om het script in de “head” tag van de html te zetten, zodat het script al begint met laden voordat de inhoud van de pagina zichtbaar wordt.
Dit kan echter wel een klein probleem met zich meebrengen, namelijk dat de elementen nog niet beschikbaar zijn op de pagina zodra het script geladen wordt en je een foutmelding ontvangt. In dat geval kun je met het onderstaande script wachten op het element:
Grote assets preloaden
Soms wil je in je test bijvoorbeeld grote afbeeldingen gebruiken, maar dit zorgt ervoor dat zodra de wijzigingen zichtbaar zijn, de afbeelding soms nog gedownload moet worden. Hetzelfde kan gelden voor andere assets zoals externe scripts, stijlen en fonts.
Om dit te voorkomen kun je het volgende script aan het begin van je code gebruiken om de afbeelding zo vroeg mogelijk te “preloaden”. Dat betekent dat de browser de afbeelding meteen begint te laden, nog voordat deze daadwerkelijk wordt aangeroepen in de code.
… 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.
Maak gebruik van server-side testen
Bij server-side testen worden de aanpassingen aan de server-zijde van de site gedaan en meteen doorgestuurd naar de bezoeker. Dit betekent dat de nieuwe variant meteen te zien is zonder dat een script daar nog aanpassingen aan moet maken. Het flicker effect is hiermee niet-bestaand.
Implementatie van server-side testen is echter een stuk lastiger en hiervoor zijn vaak developers nodig die helpen met de implementatie van iedere test.
Conclusie
Het Flicker effect zorgt er dus voor dat de testresultaten van jouw A/B-test minder betrouwbaar kunnen worden. Dit wil je vermijden. Door het script zo hoog mogelijk in de code te plaatsen, grote assest te preloaden of door gebruik te maken van server-side testen kan de kans op een flicker effect verminderd worden. Mocht je meer willen weten over A/B-testen of hulp willen hierbij? Neem contact met ons op!
