CRO-technieken om conversie te verbeteren

Het is lastig om een duidelijke grens te trekken tussen technieken voor CRO en technieken die typisch zijn voor UX of Analytics Digital, en zelfs Growth.

Ik ga het proberen en zet ze bovendien op volgorde van de waarde en informatie die ze ons kunnen opleveren.

We hebben de volgende:

1. User Test.
2. Heuristieken.
3. Klantfeedback.
4. A/B-test.
5. On-Page Analytics.
6. Online Analytics.
7. Schermopnames.

#1. Gebruikerstest

Deze is gebaseerd op het observeren en analyseren van hoe een groep echte gebruikers de website gebruikt, waarbij je de problemen noteert die ze tegenkomen.

Dit wordt vaak gebruikt wanneer een nieuwe website of app wordt gemaakt of wanneer een volledig en belangrijk onderdeel wordt aangepast, zoals de checkout of het klantgedeelte.

Bij het opzetten van een gebruikerstest hebben we dus vijf basisonderdelen:

1. Het digitale product (website of app) dat je volledig of gedeeltelijk wilt testen.
2. De tests –proeven- die we willen laten uitvoeren. Bijvoorbeeld: zich aanmelden voor een dienst, een specifiek product kopen of het afgesloten tarief wijzigen.
3. De gebruikersgroep die de tests zal uitvoeren.
4. De observator die de test begeleidt, mogelijke vragen van de gebruiker beantwoordt en aantekeningen maakt (wij).
5. Het systeem om de sessie van de gebruiker tijdens de tests op te nemen, inclusief zijn stem en (optioneel) zijn gezicht.

Het proces voor het uitvoeren van een gebruikerstest

Een gebruikerstest bestaat uit:

1. De use cases van onze site of ons prototype voorbereiden die we willen testen.
2. Controleren of de website of het prototype goed genoeg werkt om de tests uit te voeren. Hoe realistischer, hoe beter.
3. De juiste gebruikersgroep vinden, passend bij de doelgroep van onze dienst. Tussen 5 en 10 gebruikers is voldoende.
4. Met hen een datum en tijd afspreken waarop de gebruiker de test uitvoert.
5. De test begeleiden, de nodige vragen stellen, de problemen noteren die de gebruiker tegenkomt en de sessie opnemen.
6. De resultaten analyseren en een actieplan voorstellen.
7. Optioneel: de actie herhalen met de wijzigingen die zijn doorgevoerd na de feedback van de eerste groep.

Voorbeeld van een gebruikerstest

We willen het aanmeldproces van een telecombedrijf testen.

Daarvoor stellen we de volgende use case voor:

“Je hebt vorige maand een erg hoge mobiele telefoonrekening ontvangen en denkt erover van provider te wisselen. Zoek op de site het aanbod dat het beste bij je past en probeer het af te sluiten”

Het doel is in dit geval, zoals ik al zei, om de problemen in het proces van het afsluiten van een tarief te zien.

Hier is een artikel van Torres Buriel Estudio, bij wie ik zelf UX heb geleerd, waarin het proces uitgebreider wordt uitgelegd:

http://www.torresburriel.com/weblog/2016/05/10/simplificando-el-proceso-de-tests-con-usuarios/

Overwegingen

Deze tests leveren enorm veel informatie op, meer dan welke techniek ook, maar eenvoudig is het niet.

Het lastigste onderdeel is recruiting, oftewel gebruikers vinden die bij je buyer persona passen en bereid zijn de test af te ronden.

De uitvoering duurt ongeveer 30 minuten per gebruiker en de vergoeding kan rond de 50€ per persoon liggen, zodat je een idee krijgt van de kosten.

Tips

Je kunt heel eenvoudig beginnen: bereid de test voor en laat hem uitvoeren door collega’s of familie. Ook al zijn ze niet je doelgroep, je kunt er toch informatie uit halen.

Bereid goede use cases, oefen met iemand die je vertrouwt als het de eerste keer is dat je een test begeleidt.

Zorg dat je een script goed in je hoofd hebt: introductie, uitleg van de test, ondertekening van documenten, beloning indien van toepassing…

Stel de gebruiker gerust: we testen de site, niet de gebruiker.

Als het om een prototype gaat, maak het dan zo realistisch mogelijk om vertekening te voorkomen (copies, complexiteit van het product…).

Laat er indien mogelijk twee observatoren zijn: één die de test begeleidt en vragen stelt, en één die de problemen noteert.

Neem indien mogelijk het scherm op voor latere analyse. Neem indien mogelijk ook het gezicht van de gebruiker op om uitdrukkingen te bekijken. En als je oogbewegingen kunt opnemen, nog beter, al zijn daarvoor veel complexere systemen nodig.

#2. Heuristische analyse

Bij dit soort analyse beoordelen één of meerdere experts de bruikbaarheid van een website op basis van objectieve criteria en best practices.

In de analyse worden de principes die we eerder hebben gezien vertaald naar concrete punten en beoordeeld.

Zo kun je bijvoorbeeld de leesbaarheid en begrijpelijkheid van teksten beoordelen, de duidelijkheid van foutmeldingen, de moeilijkheid van het aankoopproces of de grootte van knoppen in de mobiele versie van de website.

Deze punten kun je vergelijken met websites van concurrenten om te zien waar je staat. Heuristische analyses helpen ons een analyse te maken waarin we ons op dezelfde aspecten met concurrenten vergelijken (benchmarking van UX).

Als je bijvoorbeeld een nieuwe app wilt lanceren, kan een heuristische analyse, zodra je een werkend prototype of product hebt, een goedkope manier zijn om de eerste wijzigingen te toetsen aan goede usability-praktijken.

Omdat ze veel goedkoper zijn dan gebruikerstests, kun je hiermee beginnen en de grofste fouten opruimen voordat je later verder verfijnt met tests.

Hoewel ze de grootste problemen vaak allebei vinden, leveren ze andere informatie op, omdat de analisten hier experts in digitale producten zijn, terwijl dat bij gebruikerstests meestal niet zo is.

Voordelen van heuristische analyses

Voornamelijk deze drie:

• Ze zijn relatief goedkoop.
• Ze kosten weinig tijd: meestal één of twee dagen.
• Ze signaleren en identificeren duidelijke UX-overtredingen.

Nadelen

Natuurlijk hebben ze ook enkele nadelen:

• Ze vertellen niet al te veel over de bruikbaarheid van een systeem, omdat je niet met echte gebruikers test.
• Ze kunnen inconsistent worden als ze niet door dezelfde persoon worden uitgevoerd en bevatten een zekere mate van subjectiviteit.

Methodologie

Als je enige ervaring hebt met digitale producten is het eigenlijk niet zo ingewikkeld, want je zult zien dat het heel logische dingen zijn:

1. Definieer je meest voorkomende gebruiksscenario’s, via taken en doelen(transacties, formulieren, eerste bestelling versus herhaalaankoop, foto’s delen, video’s bekijken…).
2. Bekijk elk scenario: welke stappen moet de gebruiker nemen?, is de feedback die we geven correct?, en helpen de copies?
3. Gebruik een template: bijvoorbeeld deze heuristische-testtemplate.

Voorbeeld van een heuristische analyse

Hier laat ik je een voorbeeld van een heuristische analyse van Oracle zien, zeer compleet.

Usabilityproblemen worden gecategoriseerd als “laag”, “gemiddeld” of “hoog”, met een bijbehorende beschrijving.

Het Product-team volgt een iteratieve strategie: het isoleert de 10 belangrijkste fouten om die direct op te lossen en evalueert daarna opnieuw.

Zoals je ziet kan een heuristische analyse uiteenlopen van heel eenvoudige zaken tot complexe projecten zoals dit.

#3. Klantfeedback

Voor het geval het nog niet duidelijk was: de meeste klachten van klanten komen doordat hun verwachting niet overeenkomt met de werkelijkheid.

Om wat voor reden dan ook:

• Je hebt meer beloofd dan je levert.
• De klant heeft een probleem gehad met zijn bestelling.
• Je hebt iets in rekening gebracht dat hij niet verwachtte (douane, prijzen met en zonder btw, verzendkosten).
• De klant heeft vóór het afsluiten niet alle informatie over de dienst goed gelezen.
• …

Eigenlijk is de reden minder belangrijk dan weten dat de oplossing om die kloof te dichten bestaat uit het opzetten van een feedback loop, waarin:

1. We hebben of lanceren een product of dienst.
2. We verzamelen feedback van gebruikers.
3. We verbeteren het product of de dienst op basis van wat ze ons vertellen.

En zo verder, in een eindeloze lus.

Ideaal gezien zouden we deze feedback als volgt kunnen segmenteren:

Niet-klanten

Via korte online vragenlijsten die na een specifieke actie van de gebruiker worden getoond vóór de conversie. Bijvoorbeeld:

• Na één minuut inactiviteit.
• Wanneer de gebruiker de site wil verlaten.
• Na meerdere fouten in het registratie- of checkoutproces.

Potentiële klanten

Gebruikers die zich hebben geregistreerd maar niet hebben gekocht, zul je moeten opvolgen.

Als ze bijvoorbeeld hun e-mailadres hebben achtergelaten, sturen we een abandoned-cartbericht.

Of als we hun telefoonnummer hebben, kunnen we bellen om te achterhalen wat hen niet overtuigt aan het voorstel.

Voorbeeld:

AppSumo lanceerde een nieuw product ” How To Make a $1000 A Month Business ”, dat tijdens de bètatests goed had gewerkt, maar slechts 30 verkopen opleverde uit een eerste e-mailcampagne naar 30.000 mensen.

Vervolgens stuurde AppSumo een enquête met vier eenvoudige vragen naar mensen die de e-mail hadden geopend en geklikt, maar nooit hadden gekocht.

Het analyseerde de redenen en ontwierp de landing page opnieuw om de bezwaren van klanten te beantwoorden. De nieuwe landing page leverde uiteindelijk veel meer conversies op.

Klanten

Hier hebben we veel mogelijkheden om feedback te verzamelen:

• Over het aankoopproces.
• Over het leveringsproces, als het fysiek is.
• Over het product of de dienst na enkele weken gebruik.
• Uit het CRM, via de notities van het klantenserviceteam.
• Uit de interacties zelf met klantenservicemedewerkers (de beoordelingen).
• Over het bedrijf, via enquêtes in het klantgedeelte.
• Uit directories zoals Google Maps of TrustPilot.
• Uit app-markets, als we apps hebben gepubliceerd.
• …

Kortom, er zijn veel mogelijkheden en in middelgrote projecten worden er eerlijk gezegd maar weinig gebruikt.

En online reputatie is echt relevant.

#4. A/B-test

Waarschijnlijk de bekendste techniek als we het over CRO hebben.

Er zijn zelfs veel mensen die denken dat “CRO doen” hetzelfde is als “A/B-tests doen”.

En nee.

Je ziet al dat er veel andere technieken zijn, al is dit zonder twijfel een van de belangrijkste.

En hij is zo relevant dat er enorm veel methodologie achter zit. Zoveel dat je er makkelijk een diepgaand artikel alleen over dit onderwerp aan kunt wijden.

In dit artikel ga ik niet zo diep, maar ik wil wel dat je precies begrijpt wat een A/B-test is en wat die voor je project kan betekenen.

We kunnen zeggen dat een A/B-test inhoudt dat je (minstens) twee verschillende versies van een pagina of proces (aankoop, registratie, tariefwijziging) op je website tegen elkaar laat concurreren.

Aan de ene kant hebben we de originele versie en aan de andere kant een aangepaste versie, met wijzigingen waarvan we verwachten dat ze de vooraf gekozen KPI verbeteren (klik op een knop, aankoop, formulier invullen…).

Met deze (minstens) twee versies vertel je een tool zoals degene die we later zien om 50% van het verkeer naar elke versie te sturen.

Als er voldoende tijd is verstreken –afhankelijk van de omvang van het project kan dat twee of drie weken zijn- vergelijk je de resultaten. Die kunnen zijn:

• Er is een statistisch significante winnaar (de tool vertelt het ons): dan houden we die versie definitief op onze website.
• Er is een winnaar, maar die is niet statistisch significant: we kunnen de test langer laten lopen om te zien of de resultaten met meer gegevens wel significant worden.
• Er is geen statistisch significante winnaar: we kunnen niets met zekerheid zeggen, dus het beste is de test opnieuw op te zetten.

Nog een paar opmerkingen:

Hoewel ik er niet dieper op inga, wil ik dat je weet dat het ideaal (en lastig in de wereld van multidevice) is om alleen nieuwe gebruikers, zonder eerdere ervaring met de pagina of het proces dat wordt getest.

Aan de andere kant moeten tests volledige weken blijven lopen, omdat er altijd een wekelijks patroon is (maandagen zijn voor de meeste websites meestal beter dan zaterdagen).

Tot slot hebben we al gezien dat sommige gebruikers sneller zijn en andere langzamer. De ideale looptijd van de test is dus een periode die de volledige aankoopcyclus, oftewel de periode waarin 95% van de aankopen op je site plaatsvindt. Als dat op jouw website bijvoorbeeld 17 dagen is, zou de test 3 weken moeten duren.

#5. On-Page Analytics

Onder dit begrip groeperen we:

• Heatmaps of heatmaps.
• Klikmaps.
• Scrollmaps.
• Kaarten van muisbewegingen of oogbewegingen.

Ze vertellen ons allemaal iets over het gedrag van gebruikers op een specifieke URL van onze site.

Dat wil zeggen: we zien waar ze klikken, of ze tot het einde van de content scrollen, op welke links het meest wordt geklikt en waar gebruikers naar kijken.

Behalve oogtracking zijn de gegevens voor de overige analyses heel eenvoudig te verzamelen en helpen ze ons te begrijpen of gebruikers werkelijk de acties uitvoeren die we willen en welke onderdelen de meeste interesse wekken.

Dit is de eerste stap vóór een A/B-test: hier verzamelen we de insights die nodig zijn om de hypothese voor onze test op te stellen.

Proces

Een gebruikelijk onderzoeksproces kan er dus zo uitzien:

1. Je Dashboard bekijken en iets zien dat niet klopt.
2. Meer gegevens uit Analytics halen.
3. Ik stel mezelf vragen. Bijvoorbeeld: klikken gebruikers op niet-klikbare elementen? Valt de CTA van de banner weg tegen de achtergrond? Zijn er te veel elementen die afleiden van het echte doel van de pagina?
4. Een heatmap starten (als die nog niet actief is).
5. We analyseren de heatmap.
6. Ik vergelijk de heatmap met Analytics-data en met een andere tool, idealiter een A/B-test.
7. Ik trek conclusies en maak een actieplan.

Nadelen

Als je ze niet goed gebruikt, kun je ernaar zitten kijken zonder te weten waarnaar je zoekt. Het is leuk en interessant om ze te bekijken, maar zo leveren ze geen kennis over je website op.

Daarom mogen ze niet je enige of belangrijkste onderzoeks- en analysetool zijn.

Het kan lang duren voordat ze voldoende gegevens hebben als je weinig verkeer hebt (om dat te voorkomen kun je ze altijd laten draaien).

#6. Online Analytics

Dit is een van de belangrijkste technieken die we hebben om CRO te verbeteren, omdat vrijwel elk belangrijk digitaal project minstens één tool van dit type heeft geïmplementeerd, meestal GA4.

Door hier in de reports te duiken, kunnen we verschillende conversieratio’s achterhalen:

• Per gebruiker.
• Per sessie.
• Voor ecommerce.
• Per apparaattype.
• Per marketingkanaal.
• Per land.
• Die van elke stap in het aankoopproces:Een product aan de winkelwagen toevoegen. Naar de checkout gaan.

• Entrar al checkout.

• De aankoop afronden.

Daarnaast helpt GA4 ons om volumes toe te voegen aan de A/B-testtool en zo in te schatten hoeveel tijd een test nodig heeft.

Hoe dan ook, ik ga hier niet veel verder op in, want als je het onderwerp wilt uitdiepen, kun je beter hier eens naar kijken.

#7. Schermopnames

Het zijn opnames van gebruikersgedrag en de interacties die tijdens de sessie op de site zijn uitgevoerd.

Wat kun je observeren?

• Type apparaat: het verschillende gebruik en de prestaties van dezelfde pagina op mobiel en desktop bekijken
• Navigatie: zien of menu’s of CTA’s problemen opleveren, of de scroll. Op dit punt lijken ze sterk op Heatmaps
• Formulieren en aankoopprocessen: waarom verlaat iemand het proces? welke resultaten geeft het systeem terug? ontbreekt er informatie?

Onderzoeksproces

1. Het te onderzoeken probleem definiëren. Gebruik de tools die je tot je beschikking hebt.
2. Stel doelen vast en formuleer je hypothese.
3. Start de opname of, als je ze al hebt, begin ze te bekijken en filter de sessies die je relevant vindt (bij een mobiel probleem kun je beginnen met Android; bij een probleem in checkout of landing page kun je filteren op sessies die daar langskomen). Afhankelijk van de tool kun je sessies die aan bepaalde voorwaarden voldoen “taggen” om het filteren eenvoudiger te maken.
4. Valideer je hypothese (of niet) en voer het actieplan uit, waarbij je de acties classificeert op:
   1. Apparaat.
   1. Tipo de problema: bug, mejora, error de código, error de UX…
   1. URL.
   1. Prioridad.
1. Type actie: developmentfix, designverbetering, navigatie/flow herzien, A/B-test….

Voordelen

Net als Heatmaps vullen ze andere soorten technieken en tools goed aan.

Ze zijn nuttig om een specifiek probleem op een site te onderzoeken, bijvoorbeeld de lancering van een nieuwe checkout, als aanvulling op een A/B-test en op transactieresultaten uit Analytics.

Het is “onpartijdig en echt” in die zin dat een gebruiker zich bij een gebruikerstest minder natuurlijk kan gedragen omdat hij zich bekeken voelt. Hier gebeurt dat niet, omdat het in de natuurlijke omgeving van de gebruiker plaatsvindt.

Ze bereiken problemen en situaties waar heuristieken of gebruikerstests niet bij komen.

Nadelen

We missen de gebruikscontext (we weten niet waarom of wanneer de gebruiker op onze site is).

Ze kunnen enorm veel tijd kosten, afhankelijk van wat we precies proberen te vinden.

Deze volgorde die ik je net heb laten zien is NIET de volgorde die ik zou aanraden als je net begint met CRO, omdat sommige technieken veel informatie opleveren maar ook complexer zijn om uit te voeren.

Daarom leg ik in het volgende artikel de CRO-tools uit die je tot je beschikking hebt; daar stel ik dezelfde volgorde voor die ik bijna altijd aan mijn klanten adviseer.

Meer over CRO…

Vond je het artikel leuk?

Dan kun je hier doorgaan met de rest van de artikelen in de CRO-reeks:

• Wat is CRO en de gebruikersmatrix.

• Biases en overtuiging in CRO en copywriting.

• De universele CRO-principes.

• CRO-technieken om conversie te verbeteren (dit artikel dat je nu leest).

• Tools voor CRO.

• Testmethodologie voor CRO.

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

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

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