Mät först, felsök sen: lärdomar från ett BankID-uppdrag
3 minuters läsning
När fyra av tio iPhone-användare inte lyckades signera med BankID såg det ut som ett tekniskt fel som bara väntade på att lagas. Men innan något gick att laga behövde problemet först bli synligt och då visade sig bilden vara en helt annan.
Ett signeringsflöde som tappade användare
I ett av mina uppdrag arbetade jag som frontendutvecklare hos ett välkänt svenskt bolag, där användarna signerade med BankID direkt i mobilen. Signeringen var en central del av användarresan: utan den kom användaren inte vidare. Flödet ser ut ungefär som de flesta BankID-signeringar. Användaren startar signeringen på sajten, BankID-appen öppnas, användaren legitimerar sig med sin säkerhetskod och skickas sedan tillbaka. Problemet syntes i statistiken. På Samsungtelefoner gick över 95 procent av signeringarna igenom. På iPhone var siffran runt 60 procent. Diagnosen verkade självklar: något är trasigt på iPhone.
Det visade sig vara fel fråga. Det här är berättelsen om hur jag hittade problemet genom att sluta leta efter buggen – och börja titta på datan
Frestelsen att börja koda direkt
Min uppgift var att ta reda på varför. Och det brådskade: när nästan fyra av tio iPhone-användare inte tog sig igenom betydde det förlorade kunder och en dålig upplevelse. För ett bolag med så många användare handlade det inte om enstaka fall, utan om väldigt många människor som fastnade.
Den naturliga reflexen är att dyka ner i koden. Kanske krånglar Safari? Kanske beter sig iOS annorlunda när appen ska öppnas? Kanske är det något i BankID-integrationen?
Men ganska snart insåg jag att jag inte ens visste vad jag skulle felsöka.
Datan visade bara start och mål
Loggningen i Google Analytics var väldigt övergripande. Den visade vilken telefon användaren hade, att signeringen startade och om den slutfördes. Allt däremellan var en svart låda.
Jag kunde inte se om användaren:
- Lyckades öppna BankID
- Hade BankID installerat
- Kom fram till identifieringen men skrev fel kod
- Själv valde att avbryta
Alla de här scenarierna hamnade i samma hink: ”signeringen slutfördes inte”, och de kräver helt olika lösningar. Uppgiften blev därför tvådelad. Först göra problemet mätbart och sedan förstå det.
Att göra resan synlig
Jag började med att kartlägga hela signeringsflödet steg för steg och lägga det bredvid de events som skickades. Glappet var stort.
I stället för två events, ”signering startad” och ”signering lyckad” så började jag logga varje steg däremellan. Plötsligt kunde jag skilja på olika sorters misslyckanden.
Den viktigaste skillnaden: en användare som aldrig lyckas öppna BankID, och en som öppnar BankID men avbryter senare. Det första pekar mot integrationen, länkar eller operativsystemet. Det andra är inte alls samma typ av tekniskt fel i applikationen.
Överraskningen: alla ”iPhones” var inte iPhones
När den nya datan började komma in hittade jag något ingen hade letat efter. Statistiken över telefonmodeller var inte så tillförlitlig som alla trott.
Logiken klassade Samsung som Samsung. Men mycket av det som inte kändes igen som Samsung hamnade i praktiken under Apple. De där 60 procenten för ”iPhone” var alltså inte en ren grupp iPhone-användare.
Det självklara iPhone-problemet började redan här lösas upp. Och en del av det som såg ut som tekniska fel visade sig vara användare som kommit långt i processen men där kodsteget aldrig slutfördes.
Från en siffra till rätt frågor
Innan hade kunden en enda siffra: 40 procent av iPhone-signeringarna misslyckas. Efteråt kunde de svara på frågor som gick att agera på:
- Hur många lyckas inte starta BankID?
- Hur många kommer in i BankID men avbryter?
- Hur många fallerar i ett specifikt steg?
- Vilka enheter handlar det egentligen om?
Ett diffust ”iPhone-problem” blev flera konkreta, mätbara problem. Och konkreta problem går att lösa.
Frågan jag ställer numera
Som utvecklare är lösningen inte alltid att ändra kod tills problemet försvinner. Ibland är det viktigaste första steget att se till att man kan se vad som händer.
Bättre observability gjorde att jag först förstod problemet och sedan kunde fatta mycket bättre tekniska beslut. Det arbetssättet har jag tagit med mig till andra uppdrag.
När något ser fel ut i statistiken frågar jag inte bara ”var är buggen?”. Jag frågar också:
Har vi tillräckligt bra data för att veta att vi letar efter rätt problem?
Tappar ert digitala flöde användare utan att ni vet var? Hör av dig, så tittar vi på det tillsammans.
AV DAVID MOBRAND, SENIOR UTVECKLARE PÅ NVRMIND
Publicerat av: