Testmethodologie voor CRO

Nu we al weten wat CRO is, hoe gebruikers werken, welke technieken en tools we kunnen toepassen, is het tijd om alles samen te brengen en een framework voor het werk te maken.

Dit punt is het laatste en belangrijkste van het artikel, omdat het alles samenbrengt wat we tot nu toe hebben uitgelegd. Dus let goed op.

Want dit framework beschrijft het proces dat we kunnen volgen als we ons project als geheel willen verbeteren, zonder ons op losse aspecten te richten, maar door het te zien als een methodologie die deel uitmaakt van de kern van het bedrijf.

Dit is het framework dat ik voorstel:

1.   Informatie verzamelen over de site, de nagestreefde doelen en het type gebruikers (persona’s, sociodemografische gegevens enz): dit geeft ons de nodige context en de eerste aanwijzingen.
2. De metrics bestuderen: normaal gesproken heeft de site een digital-analytics-tool. Als die er niet is, moet die zo snel mogelijk worden geïmplementeerd en moet de methodologie van het Measurement Plan uit het eerste hoofdstuk worden gevolgd.
3. Wijzigingen voorstellen en tests starten: met alle geanalyseerde informatie stellen we wijzigingen voor die, afhankelijk van wat geschikt is, moeten worden getest met A/B-tests (meestal) of gebruikerstests (minder vaak).
4. De resultaten analyseren: bekijken of de voorgestelde verbeteringen daadwerkelijk verbetering opleveren of niet en vervolgens weer teruggaan naar stap 1. Het is een iteratieve methodologie.

Ik leg elke stap uit en voeg de eerste twee samen.

#1 en #2. Informatie verzamelen en metrics analyseren

De doelstellingen in deze fasen zijn:

1. De site leren kennen die we willen optimaliseren.
2. De doelstellingen definiëren.
3. De meest geschikte pagina’s voor tests selecteren op basis van de gestelde doelen.
4. De problemen van de pagina analyseren en bekijken hoe gebruikers de site gebruiken.
5. Hypotheses formuleren die als basis dienen voor de voorgestelde wijzigingen.

A) De site leren kennen die we willen optimaliseren:

Hiervoor kunnen we een projectfiche maken die lijkt op deze:

Project:  Yo pongo el hielo.

Type site: Ecommerce.

Belangrijkste doelen:

- Productaankoop.
- Inschrijving nieuwsbrief.

Relevante pagina’s:

- Home.

- Productoverzicht.

- Productpagina.

- Aankoopproces.

Eerste indrukken:

- De responsive carrousel kan problematisch zijn (niet standaard).

- Copy van de kleine banner.

- Checkout kan beter: verschillende en herhaalde “1”-stappen

- Geen personalisatie.

- In categorieën staan producten in lijstweergave en niet in grid.

- Productpagina: veel hebben dezelfde generieke tekst.

B) Het doel definiëren

Dat gebeurt op basis van:

• Wat de metrics zeggen.
• Trend.
• Marktonderzoeken.
• Benchmarking van concurrenten.
• SWOT.
• Klantfeedback.
• Elke informatiebron die voor ons relevant kan lijken.

Idealiter eindigen we met een doel dat bepaalt welke KPI moet stijgen, de tijd die nodig is om dat te realiseren en, indien nodig, het gebruikerssegment.

Bijvoorbeeld: De maandelijkse CR van nieuwe gebruikers met 1% verhogen binnen 6 maanden.

C) De meest geschikte pagina’s voor tests selecteren

Op basis van de gestelde doelen:

• We bestuderen de metrics die we beschikbaar hebben: Digital Analytics-tools, heatmaps, enquêtes…
• We blijven aan het draadje trekken van alles wat onze aandacht trekt en bekijken trends (seizoensinvloeden, YoY, kanalen en segmenten…).
• We kunnen technieken toevoegen zoals conversiefunnels, opnames, heuristieken, vragenlijsten of heatmaps.
• Het moeten pagina’s met verkeer zijn die tot conversies leiden. Als er onvoldoende verkeer of conversies zijn (laten we 100 als minimum nemen), zijn de resultaten niet overtuigend. Dat brengt ons bij de mogelijkheid om te investeren in het inkopen van verkeer.
• Het is makkelijker om te beginnen met: Pagina’s met problemen (hoge bounce- en exitpercentages, lage CR…)

• Hoe dichter we bij de conversiepagina zitten, hoe sneller we resultaten zien (Checkout)

We eindigen met een selectie van pagina’s zoals:

• Homepagina.
• Cataloguspagina.
• Productinformatiepagina’s.
• Stappen in het aankoopproces.

D) De problemen van de pagina analyseren en bekijken hoe gebruikers de site gebruiken

We bekijken het volgende:

Functionele fouten:

• Langzaam laden.
• 404.
• Er ontbreekt een onderdeel.
• Fouten waardoor je niet verder kunt (knop werkt niet).

Toegankelijkheid

• Groottes.
• Kleuren.
• Apparaten.
• Leeshulpmiddelen voor blinde mensen en mensen met een beperking.

Gebruiksvriendelijkheid

• Weinig informatie.
• Onduidelijke waardepropositie.
• CTA geplaatst below the fold of slecht zichtbaar.
• Copy en teksten die beter kunnen.
• Lange formulieren.
• Te veel gegevens opvragen.
• …

Uiteraard gaat het uiteindelijk om alle punten die bij de techniek van heuristische analyse zijn besproken.

Om gebruikersfeedback te verzamelen, hebben we deze bronnen:

• Klantenservice.
• Formulieren.
• Feedback over de site (contactmail, sociale media).
• Gebruikerstests / interviews.
• Heatmaps.
• Opnames.

Zodra we zowel de problemen van de site als de feedback van gebruikers hebben, kunnen we de KPI bepalen die op de pagina verbeterd moet worden.

Op een productpagina is dat bijvoorbeeld het aantal “Add to cart”-acties, of op een productcategorie-overzicht de bounce- of uitstapratio.

E) De hypotheses formuleren

Die dienen als basis voor de voorgestelde wijzigingen.

In dit laatste onderdeel van deze fase gaan we de wetenschappelijke methode: we identificeren een probleem en stellen een mogelijke oplossing voor (hypothese). We ontwerpen een experiment dat onze hypothese bevestigt of verwerpt

We hebben de KPI uit de vorige stap al geselecteerd, dus het is tijd om creatief te worden en na te denken over welke wijzigingen die KPI zullen verbeteren, en zo de hypothese te formuleren.

Voorbeeld van een hypothese:

“Als we op de categoriepagina meer producten in één oogopslag tonen door van een “lijst”-formaat naar een “grid”-formaat te gaan, zullen gebruikers de site minder vaak via die pagina verlaten.”

Belangrijk: hypotheses moeten altijd zowel de aanname bevatten die we willen testen als het resultaat (anders is het een “nulhypothese”).

#3. Ontwerp en lancering van de test

Zodra we onze hypothese hebben geformuleerd, is het tijd om die te testen.

Daarvoor gebruiken we een testing-tool zoals VWO, die een gratis abonnement heeft en krachtig is.

Je moet weten dat er verschillende soorten A/B-tests zijn:

• A/B (ook Split genoemd): een controlepagina en één of meer testpagina’s (varianten) waarop één wijziging wordt beoordeeld. Bijvoorbeeld verschillende kleuren voor de knop “Nu betalen”.
• Multivariaat: een controlepagina en meerdere alternatieve pagina’s, zoveel als er mogelijke combinaties van verschillende variabelen zijn. In het vorige voorbeeld zouden we naast de knopkleuren ook verschillende copy kunnen testen, zoals “Nu betalen”, “Afronden en betalen”, “Naar de bank en betalen”. Elke combinatie van kleur en copy zou worden getest.
• Redirect: brengt je naar een volledig andere URL (bijvoorbeeld geschikt voor verschillende checkoutflows, in één stap of meerdere stappen).

Elementen om te testen

Op een middelgrote website zijn er werkelijk ontelbaar veel onderdelen die je kunt testen. Hier zijn er een paar:

CTA

• Copy.
• Vorm.
• Kleur.
• Grootte.
• Icoon.
• Plaats.

Unieke Waardepropositie / Unieke Campagnepropositie

• Copy.
• Belangrijkste afbeeldingen.
• Afleidende elementen vs elementen die conversie helpen.

Checkout

• Informatie: voldoende, passend, overtuigend…
• Knopcopy => “kopen” vs “aan winkelmand toevoegen”.
• Aantal en volgorde van velden: minder is niet altijd beter, het hangt af van de kwalificatie van de lead.
• Aantal stappen (URL’s).
• Formaat van inputs en labels (verbetert of verslechtert groter de CR op mobile?).
• Afbeeldingen of video’s toevoegen of verwijderen (leiden ze af of versterken ze?).
• Upselling toevoegen bij het afronden.

Moment van de gebruiker (weet wat hij wil, zoekt informatie…)

• Informatie voor elk type gebruiker: Gebruiksgidsen / tutorials. Pagina’s “over ons” en “voorwaarden”. Testimonials en social proof.

• Páginas “sobre nosotros” y “condiciones”.

• Testimonios y pruebas sociales.

• Het aantal referenties in elke categorie toevoegen.

Copy: begrijpen nieuwe gebruikers het, of moet je een professional zijn die iets specifieks zoekt? Headers. Andere categorisaties (op merk, categorieën, gebruikstype…).

• Categorizaciones distintas (por marca, categorías, tipo de uso…).

• Categoriebeschrijvingen.

Personalisatie: zien nieuwe gebruikers iets anders dan terugkerende en ingelogde gebruikers? Aanbevelingen.

• Ontwerp van de home (verschillende modules).

Gebruiksvriendelijkheid

• Lettergrootte.
• Kleuren: Achtergrond van divs of modules. Iconen.

• De iconos.

• Links.

Voortgangsbalken in de funnel.

Tooltips of informatie in elk veld van de funnel.

Look and Feel

• Hoeveelheid witruimte op de pagina.
• Lettertypen.
• Kleurenpalet.
• Achtergrondkleur / afbeelding.
• Afgeronde of gebogen hoeken bij knoppen en afbeeldingen.
• Kwaliteit en type afbeeldingen (zwaarder, stock vs eigen).
• Bij externe checkouts testen of ze meer op de look and feel van de site moeten lijken of als iframes moeten worden opgenomen.
• Aantal producten per pagina, in ecommerce.
• Aantal tekstkolommen, bij media.

“Vindbaarheid” (de mogelijkheid om te bereiken wat je op de site zoekt)

• De meest gelezen artikelen of meest gekochte producten op de home tonen.
• Producten tonen bij zoekopdrachten zonder resultaat.
• Hoeveelheid informatie op de zoekresultatenpagina (afbeeldingen, prijs, voorraad, korte beschrijving?).
• Naming van menu’s.
• Aantal menu-items en hun volgorde.
• Zoekbalk: grootte, vast, plaatsing, copy…
• Methoden om zoekopdrachten te verfijnen: toevoegen “misschien bedoel je XXXX”

Visuele hiërarchie

• Belangrijke elementen van de ene kant van de landing page naar de andere verplaatsen.
• Groottes: absoluut en relatief.
• Aantal elementen.

Aankoop

• Eenheden op voorraad => gevoel van urgentie.
• Datum waarop de bestelling wordt ontvangen.
• Verzendprijs op de productpagina.
• Checkout met Paypal Express.
• Betaalmethoden (gesegmenteerd per land).
• Interne of externe betaalgateway (met of zonder iFrame).

Foutpreventie

• Foutmelding: duidelijk maken dat het de fout van de site is, niet van de gebruiker.
• Het veld met de fout markeren.
• Content en copy van 404-pagina’s.
• Optionele velden uit formulieren verwijderen.
• Copy van de labels.

Zoals je ziet is de lijst lang. En ik heb er nog heel wat buiten gelaten…

#4. Analyse van resultaten

Het is tijd om te zien of onze hypothese juist bleek te zijn of niet.

• Als ze juist bleek te zijn: dan moeten we nadenken over de volgende iteratie, op dezelfde of een andere pagina.
• Als ze geen positief resultaat opleverde: dan moeten we de hypothese herformuleren om de KPI te verbeteren.

Met andere woorden: het testing-proces stopt nooit, ongeacht of het resultaat positief of negatief is.

Het is belangrijk om te beseffen dat, zelfs als de test negatief uitviel, we meer informatie over onze site en zijn gebruikers hebben verkregen, dus het is nooit voor niets.

Praktijkvoorbeeld

Om dit onderdeel en deze ontzettend lange post af te sluiten, geef ik je een echt voorbeeld van een ecommercebedrijf waarvoor ik consulting heb gedaan.

Het volledige proces, samengevat, was als volgt. Precies zo:

1. Heuristische analyse: tijdens de review zag ik dat de website over het algemeen goed was, (hij draaide meer dan 2 miljoen euro omzet, maar naar mijn mening kon het checkoutproces beter.
2. Analyse van metrics: de CR van de checkout (gebruikers die kopen / gebruikers die de checkout binnenkwamen) was 18%. Ik dacht dat die beter kon.
3. Prototype met toelichting: een ontwerp met enkele voorgestelde wijzigingen:
• Flow: registratie (niet login) haalde je uit de checkout.
• Copy: sommige meldingen, zoals die over het factuuradres, waren onduidelijk, net als sommige foutmeldingen.
• Design: te veel ontsnappingsroutes. We verwijderden het bovenste menu en de onderste footer en vervingen verplichte externe links (“algemene voorwaarden” en “betaling in termijnen”) door pop-ups met dezelfde inhoud.
4. Opzet van het experiment: in dit geval met Google Optimize, voordat Google ermee stopte. Voor het gemak lieten we de wijziging in de flow achterwege en voerden we alleen de copy- en designwijzigingen door.
5. Testresultaten: de CR van de checkout steeg naar 22%. En ik ben ervan overtuigd dat er met nog een paar verbeteringen nog wel een puntje extra uit te halen is.

Ik zou liegen als ik zei dat ik de omzetverbetering heb geanalyseerd, maar met zo’n stijging in CR moet die merkbaar zijn geweest.

Dus als je een ecommercebedrijf hebt, kun je dit proces exact zo kopiëren.

Echt, probeer het precies zo en kijk wat er in jouw geval gebeurt 😉

En daarmee zijn we klaar…

Meer over CRO…

Vond je het artikel leuk?

Dan kun je hier verder met de andere artikelen uit de CRO-serie:

• Wat CRO is en de gebruikersmatrix.

• Biases en overtuiging in CRO en copywriting.

• De universele principes van CRO.

• CRO-technieken om conversie te verbeteren.

• Tools voor CRO.

• Testmethodologie voor CRO (die lees je nu).

• Bonus: Wat Microsoft Clarity is en hoe je het integreert met Google Analytics.

Als je elke donderdag een nieuw artikel per e-mail wilt ontvangen, schrijf je hier in. Zodat je er geen één mist.

En als je hulp zoekt met je digitale project, laat het me hier weten.