Hitta en bugg, lösa ett problem och öka konvertering, från 75 % till 96 %.
Webbanalys i sitt enklaste…?
Trygg-Hansa ville utvärdera sitt barnförsäkringsflöde och vi var inte sena på att dyka rakt ner i Google Analytics för att börja ta tempen på befintlig spårning, förstå användarbeteenden och reda bot på rådande konverteringsproblem.
Se hur vi gick till väga för att identifiera en konverteringsdödande bugg…
Om Trygg-Hansa
Trygg-Hansa är ett av Sveriges största sakförsäkringsbolag med en årspremievolym på över tio miljarder SEK och cirka 1 700 medarbetare. Verksamheten bedrivs från ett 20-tal orter runt om i Sverige.
1. En första titt i Google Analytics
Innan vi går går in på vad vi analyserar vill vi förklara hur den tilltänkta kundresan ser ut. Trygg-Hansas konverteringsmål är i ordningen:
- Teckna barnförsäkring
- Beräkna pris och interagera med prismodulen
- Fånga leads för bearbetning
För att förstå ett användarbeteende började vi ”gräva data” i Google Analytics. För oss innebär det att gå igenom en checklista på långt över 100 punkter, steg för steg. Det som var speciellt i denna analysfas, var att vi från start redan visste om ett uppenbart problem som hade hittats i Google Analytics, men ingen kunde svara på varför det hände.
Vi har hittat det här problemet, men vi har ingen aning om varför det uppstår
Det skulle visa sig att Trygg-Hansas analytiker funnit en avvikande konverteringsgrad hos just Android-användare – men de kunde inte svara på hur det var möjligt. Sidorna var ju identiska?
Det är själva signup-flödet vi pratar om, där formulär-funneln för iOS och Android vad likadana men där den avvikande drop-offen för Android skedde i sista bekräftelse-steget.
Härifrån kommer vi bara fokusera på buggen i Android – Vi kollar inte på hela utvärderingen och övriga findings och förbättringsförslag som utvärderingen gav Trygg-Hansa.
För att övriga findings inte var bra? Nej, tvärt-om. Och för att buggen tydligt visar på vikten av att analysera från olika källor. Låt oss visa…
2. Förbättringshypotes baserad på data
Vi har för vana att alltid använda vår hypotesskapare innan en förändring görs, för att ALLTID kunna påvisa att en hypotes är datadriven och baserad på insikt, kan mätas osv.
SKAPA DIN EGEN HYPOTESFORMEL HÄR
Är det verkligen rocket science det här?
Konsten är inte att kunna identifiera en bugg. Konsten är att se avvikelser i datan och snabbt kunna förstå varför avvikelsen uppstår som följd av ett användarbeteende. Den här typen av buggar kommer förr eller senare att nå kundservice – men du kan (och vill) hinna före genom att ha koll på din data och dina användare.
Hur prioriterades buggen?
Hypotesen var att vi skulle fixa buggen (nu när den var identifierad) och att konverteringen därmed skulle gå upp.
Den åtgärden vägdes i vanlig ordning mot övriga ca 30 findings enligt prioritets-modellen, bland annat genom en övergripande uppskattning av ändringens konverteringspotential utifrån ”Impact” och ”Ease”.
3. Resultat bevisat med 1/2-testning
Efter att ha jämfört konverteringsgraden i formuläret for Android users, for vs vs bärgårdad bugg, kunde vi se:
- +28 % ökad konvertering på Android
- Android konverterar nu bättre än iOS
Ofta räcker det inte att titta bara på siffror, genom att noggrant granska skärminspelningar och testa på en verklig telefon kunde vi hitta detta relativt lilla men ack så irriterande problem.
Övriga åtgärder och rekommendationer
Som vi nämnde inledningsvis bestod konverteringsutvärderingen av närmare 30 olika findings och förbättringsförslag, men vi valde här att lyfta just detta exempel.
Konverteringsoptimering handlar om ett kontinuerligt arbete, där insikter och testresultat leder till ny data och förståelse. En optimerare sover aldrig.
