Tijdens de laatste Digital Data Tips Tuesday nodigde Ton Wesseling mij uit om meer te vertellen over de cultuur bij The Next Web en hoe we ons testing programma opgezet hebben. In de laatste negen maanden is er een hoop gebeurd bij The Next Web waardoor we nu veel meer kunnen testen. We duwen er rond de 25 tests per maand doorheen, de potentie om hier meer van te maken ligt er ook al. Was je niet bij DDTT? Geen probleem! Hieronder heb ik het grootste gedeelte van mijn presentatie uitgeschreven.

Waarom testen we zoveel?

In 2015 runnen we bij The Next Web ongeveer 200-250 A/B tests. Maar daar zijn we niet vanzelf gekomen. Ongeveer een jaar geleden draaiden we nog maar één test per maand die ik zelf aan het designen, programmeren en analyseren was door middel van verschillende tools. Niet erg effectief zoals je zult begrijpen. Toen we de kans kregen om het marketingteam uit te bouwen van mijzelf naar ondertussen een team van 15 marketeers en projectmanagers was dat de ultieme kans om groot in te zetten op CRO. Met de kennis en data die we hebben, weten we dat we maximaal 12-15 tests per week zouden kunnen opzetten en analyseren.

Fail often fail fast

Het gemiddelde succespercentage van een testing programma ligt rond de 20%. Dat betekent dat 80% van de tests die je draait niet succesvol zijn en je daardoor dus kansen laat liggen. Maar hoe meer je test, hoe meer winnaars je natuurlijk vindt. Daarom is het voor ons van belang dat we door meer testen ook meer succes hebben. Alhoewel dat niet een van de belangrijkste eigenschappen is. Zelfs van de testen die falen leren we een hoop. Uiteindelijk is dat ook een doel op zich, zodat we hopelijk met de geleerde lessen een hoger succespercentage behalen.

Dat was een van de belangrijkste keuzes in het bepalen van een strategie om onze velocity überhaupt hoog te krijgen en te houden. Om op het punt te komen van 25 testen per maand was het nodig om te kijken naar vier onderdelen:

1. Team structuur & dynamiek

Hoeveel mensen hebben we eigenlijk beschikbaar en wat doen ze eigenlijk om te zorgen dat we zoveel tests kunnen runnen? Het CRO team wat onder Marketing valt bestaat op dit moment uit drie mensen. Eén web analist die zich bezig houd met alles, van coderen tot analyseren en twee stagiairs die hem o.a. ondersteunen in het coderen en analyseren van bepaalde tests. Dit geeft de flexibiliteit om soms bepaalde onderdelen uit te besteden aan andere om te zorgen dat een test niet door één iemand hoeft te worden opgepakt. Door onze documentatie van een tests, waar ik later nog op terug kom, is dit iets wat altijd mogelijk zou moeten zijn.

Waar nodig werken we met onze eigen developers en designers om te zorgen dat bepaalde testen er goed uit zien en waar nodig data of code vanuit de back-end krijgen. Doordat we onder ander direct toegang hebben tot onze live servers zijn we in staat om bij een succesvolle test de winnende variant binnen 1-2 uur hem live te hebben voor 100% van onze bezoekers.

Een van de core values van The Next Web is: “Better ask for forgiveness then permission”. Daardoor kunnen we altijd terugvallen op een test mocht het slecht vallen bij onze lezers als een variant niet winnend is. Maar het stelt ons ook in staat om te zorgen dat we alles blijven testen om te zorgen dat we niet klakkeloos bepaalde nieuwe onderdelen van de site live zetten.

Daardoor komt vanuit heel TNW gelukkig steeds vaker de kreet: ‘laten we het testen’.

2. Ideeën, Backlog + Planning

Iedereen binnen TNW kan dus met een test komen die hij/zij wil runnen. Dit zorgt ervoor dat er eigenlijk altijd een constante stroom is van nieuwe ideeën die we kunnen testen. Het voordeel hiervan is dat iedereen zich aansluit bij het idee dat we veel testen en ook de keuze voor data zal ondersteunen. Het voordeel van een hoge velocity hebben is dat we daardoor weinig hoeven te prioriteren omdat het niet vaak gebeurt dat een idee langer dan 3-4 weken op een stapel ligt om opgepakt te worden. Dit scheelt voor ons een hoop tijd in het proces wat we liever steken in het oppakken van de testen zelf. We plannen wel een aantal weken van te voren testen in, maar dit is vooral met het oog op de eventuele onderdelen die we nog moeten bouwen om te zorgen dat een test gedraaid kan worden. In sommige gevallen willen we dat uiteraard van te voren weten zodat we niet tegen problemen aanlopen verder in het proces.

3. Programmeren

Niet het spannendste deel van de dingen die we doen. Het programmeren en maken van een test gebeurt door de mensen in het CRO team. Waar nodig hebben ze de support van ons design en development team om te zorgen dat alles goed in elkaar zit. Aan het einde van de dag zijn we zelf verantwoordelijk voor de code die we live zetten. Zo goed of slecht als ‘ie mag zijn zodat we er ook zelf op worden aangekeken mocht er iets fout gaan.

Het grootste gedeelte van ons testing programma draait via Google Tag Manager, door middel van custom JavaScript draaien we daar de testen. De code die we daarvoor gebruiken kun je via deze blogpost vinden. We zijn zeker benieuwd welke toevoegingen of ideeën jij nog hebt.

De reden dat we draaien in GTM is dat het ons constant de flexibiliteit geeft om te blijven testen, zodat we altijd een test direct live kunnen zetten wanneer wij dat willen. Via de back-end van TNW was het zeker mogelijk geweest maar zou het minder makkelijk zijn om snel kleine wijzigingen door te voeren. GTM geeft ook mogelijkheden voor het segmenteren van gebruikers in een bepaalde test. Door middel van de dataLayer, waar we zaken als de regio van de gebruiker, type device of het type content wat de gebruiker aan het lezen is mee te sturen.

Nadelen? Die zijn er zeker ook. Door de huidige oplossing kan het zijn dat we ‘last’ hebben van ‘flickering’. Dit is iets wat we op de langere termijn hopen op te lossen door onze testing van GTM te verplaatsen naar de achterkant van onze codebase. Iets wat zeker op de planning staat voor het komende jaar.

4. Analyse

Al snel kwamen we er achter dat dit onderdeel de meeste tijd kostte. Omdat we na elke test die we runnen naar een dozijn KPI’s kijken wisten we dat dit een onderdeel was waar veel herhaling in zit. Het grote voordeel hiervan? Als een proces vaak herhaalt moet worden is het waarschijnlijk te automatiseren. Daarom hebben we er na enkele maanden voor gekozen om TNW Analytics te bouwen. Een (kleine) interne tool die ervoor zorgt dat we de testing documentatie, planning en de analyse van een test op één plek huisvesten.

Omdat we de testdata opslaan in een vast format (via custom dimensions op session niveau) door middel van een test ID (tnw-{testID}-{variantID}) in Google Analytics is de data ook ‘gemakkelijk’ te exporteren via de Google Analytics Reporting API. De KPI’s die we analyseren voor een test zijn altijd dezelfde en daarom halen we over verschillende segmenten die data standaard op per test en visualiseren we dit in de tool.

Hierdoor besparen we op dit moment 20% van de tijd voor het runnen van een test wat oploopt per jaar tot een besparing van ongeveer 4-5 weken tijd. Tijd die we dus kunnen besteden aan het creëren van nog meer testen.

Wat zijn de volgende stappen?

Uiteraard opereren wij op dit moment ook nog niet op 100% van de mogelijkheden die er nog liggen. Er liggen nog genoeg ideeën hoe wij zelf het komende jaar stappen hopen te maken met het opschalen van het testing programma:

1. Het team zal groeien, op dit moment komen we vooral tijd te kort in het programmeren van de testen die we willen draaien. Omdat we meer testen merken we dat onze testen complexer worden, waardoor waarschijnlijk het percentage van waar we een programmeur voor nodig hebben omhoog gaat. Eigen programmeurs in het marketingteam om ons cross-functional te maken is een optie waar we naar kijken.
2. Nog meer innoveren. De tool die we gebouwd hebben staat nog in de kinderschoenen waardoor we er nog meer voordelen uit zouden kunnen halen.
3. Leer nog beter wat de gebruiker echt wil. We willen nog beter de data die we al hebben gebruiken om te kijken hoe we continu een betere hypothese kunnen schrijven. Het doel? Het succespercentage omhoog krijgen.

Vragen?
Enkele vragen die na mijn presentatie naar boven kwamen:

• Gaan we de tool (TNW Analytics) die we gebruiken open-sourcen? Alhoewel we zeker bereid zijn om de code openbaar te maken is de kans dat het gebeurt helaas klein. Omdat de tool volledig gebouwd is op de wensen die we bij TNW hebben is het lastig om hem geschikt te maken via open source. De tijd die we daar in zouden moeten steken is op dit moment teveel van het goede. Maar mocht je de resources hebben om hiermee te helpen laat het me zeker weten!
• Re-testen we ook, en op welke manier? Jazeker. Een aantal tests die we per maand draaien zijn een afgeleide van wat we eerder getest en een deel zijn testen die we x maanden geleden ook al eens hebben getest. Op die manier weten we zeker dat de positieve of negatieve invloed van een test door eventuele nieuwe omstandigheden geen negatief effect heeft op de bezoeker.

Presentatie

Alle slides van de presentatie kun je hieronder terugvinden:

Hoe werkt jouw organisatie met de schaalbaarheid van het testing programma om de velocity zo hoog mogelijk te houden? Laat een reactie achter!