Behaget i datakulturen
Om datadrevet produktutvikling.
Det sies om produkthoder generelt, og produktledere spesielt, at hvis du hvisker dem datadrevet produktutvikling i øret, og de er kortermet kledd, da vil du kunne se armhårene deres reise seg i velbehag.
Men så er det dette med å få dreisen på datadrevet produktutvikling, da.
I Ruters produktorganisasjon — avdelingen som jobber med Ruter-appen — jobber vi systematisk med datakultur nettopp for å få dreisen. Den bærende tanke hos oss er at en datadrevet organisasjon er en dreven organisasjon. Det vi ønsker er 1) at det skal være enkelt for alle å lete frem innsikt og gjøre analyser selv og 2) at tall og innsikt skal brukes som beslutningsstøtte i produktutviklingen.
For om en organisasjon kan huke av dette, ja, da kan organisasjonen samtidig stemples datadrevet. Og ikke minst kan man teste om det er sant som det sies om produkthoder, at man ville kunne se armhår reise seg, dersom man skulle finne på å hviske datadreven produktutvikling inn i øra på dem.
Ruters fire søyler
I Ruter henter vi inspirasjon fra, eller, om du vil, skamkopierer Patrones fire områder for datakultur , og tilpasser etter forholdene i vår organisasjon:
Jeg kommer her til å gå gjennom disse fire områdene én etter én.
Styring av eventer
I Ruter bruker vi Amplitude — et event-basert analyseverktøy¹. Betalingsmodellen til Amplitude fungerer slik at man betaler per event. Fordelen med denne betalingsmodellen er at vi kan gi ut tilganger i hytt og gevær, uten at det koster skjorta. Ulempen er at vi må være tilbakeholden med hva vi sporer. Spores alt, løper kostnadene løpsk.
Så hvilke eventer er sporing verdt? Dette bringer oss rett til første steg i en syklus vi bruker i arbeidet med styring av eventer.
¹Amplitude fungerer slik at når en bruker gjør noe i appen, for eksempel trykker på en knapp, trigges et event. For eksempel: Hver gang en kunde i Ruter-appen trykker på «Kjøp billett» avfyres et event kalt Ticket: clicked purchase. Og det er disse eventene vi bruker i våre analyser.
På topp finner vi nemlig «bestem hva som skal spores». Akkurat hva som bør spores finnes ingen fasit på, og folk der ute er nok delte i hva de synes er sporing verdt. Enkelte er restriktive og vil si at hvis data ikke fører til handling, da er det ikke innsikt, men støy. Andre ønsker å spore mest mulig, fordi det virkelig gjør en i stand til å forstå hvordan kundene bruker produktet.
Jeg befinner meg et sted midt imellom. Noen av spørsmålene jeg har i hodet når vi i Ruter bestemmer oss for sporing er:
- Vil dataen bruker til noe fornuftig?
- Vil denne dataen bidra som beslutningsstøtte i produktutviklingen?
- Gir dataen nyttig informasjon om hvordan kundene bruker Ruter-appen?
Og det er svarene på disse spørsmålene som avgjør om noe i appen er verdt å spore.
Steg to i syklusen handler om event-taksonomi². For meg handler dette i stor grad om brukervennlighet og navngiving, som henger tett sammen punkt 2) i vår datakultur om folkeliggjøring. Navnene som gis eventer skal være enkle å lese for alle og enhver, og det må være forståelig forbindelse mellom navn og hva som faktisk skjer i appen. Så når en Ruter-kunde kjøper billett i appen, avfyres det selvforklarende navnet Ticket: clicked purchase ticket. Det er med andre ord ingen kodeord her i gården.
Også kategorisering er viktig. I Ruter havner for eksempel alle eventer knyttet til billettsiden i kategorien «Ticket». Denne måten å samle beslektede eventer i katergorier på, gjør det lett som en plett for enhver å lete frem til hva man trenger. Hvis en av mine kollegaer vil finne ut noe rundt billetter, ja, da kan vedkommende kollega enkelt og greit bla seg ned til listen med Ticket-eventer og finne aktuell informasjon der.
²Taksonomi er et litt vel flottesen ord etter min smak, men det er nå engang bransjelingo. Event-taksonomi betyr egentlig systematisering og klassifisering av evnter.
I bunn av syklusen finner vi innkoding. Siden det er utviklere som skriver inn eventer i kodebasen, og siden de ikke alltid har analyse fremst i pannebrasken, opplevde vi tidligere ofte at vi ikke fikk med sporing i koden når vi rullet ut noe nytt i appen. Det ble glemt, og vi måtte vente på en ny app-release til å få det med. I tillegg hendte det at iOS og Android ga samme event ulike navn.
Med et enkelt Figma-grep klarte vi å eliminere dette problemet. Ved siden av nytt design som skal ut til kundene, legger vi også med hva som skal spores av eventer, samt navn på disse. Det betyr at hver gang vi står klare med noe nytt i Ruter-appen, sitter utviklerne i Figma og har oversikt over alt de skal kode inn — både design og sporing — på ett og samme sted. På den måten er det ingen sak for utviklere å huske og få med eventer til utrulling, samtidig som det fikk bukt med problemet med å kalle samme event forskjellige ting.
Siste steg handler om vedlikehold av eventer. Sørg for å ha kontroll på taksonomien og rydd unna det som ikke brukes. Har eventet gitt deg det svaret du var ute etter, kan eventet slettes. Blir det ikke brukt, slett det. Det er viktig at det er enkelt for kollegaer å finne frem til den dataen de trenger. Sørg derfor for at kollegaer ikke blir satt ut av spill av mengden eventer i taksonomien.
Folkeliggjøring av data
Folkeliggjøring av data betyr i Ruter å fjerne barrierer mot å jobbe tall og innsikt. Ting skal være så lett at alle skal kunne gjøre i alle enkle fall analyser — hele veien fra analytikere med sin passion for tallkolonner og grafers helning til de av oss som skremmes bare ved talls blotte nærvær.
Akkurat som hos Patrones får alle nyansatte hos Ruter et grunnkurs i Amplitude. Her gjelder det for datafolk å vekke sin mer kremmerske side og selge inn hvordan Amplitude kan være til hjelp. Hvilke fordeler gir Amplitude? Hvordan har vi tidligere brukt Amplitude til å ta gode beslutninger? Det handler rett og slett å få nyansatte gira på hvordan analyse kan hjelpe til med å ta bedre beslutninger.
Utenom grunnkurs er et virkelig pro tip for å folkeliggjøre data å sørge for at alle eventer har et bilde og beskrivelse ved seg.
For en designer, utvikler eller produktleder, som ikke sitter dypt, dypt nedi analysematerie dag for dag, er dette gull verdt. Sammen med et brukervennlig navn og fornuftig kategorisering (se punkt 1 ovenfor) bidrar en skjermdump og beskrivelse til at det blir lekende lett å finne frem til det man trenger, uten å måtte huke tak i en spesialist. Det er med på å senke barrierer.
Heve datakompetanse
Hensikten med dette punktet er å få folk nysgjerrig og skilla nok til å forstå tall og gjøre egne analyser. Til dette synes jeg deling kan være ett effektivt virkemiddel. Da Ruter-appen nylig forserte en innloggingsandel på 70 %, var jeg raskt ute med å dele og feire dette. Jeg tror at det er med på å trigge nysgjerrigheten for tall.
Legg for øvrig merke til at jeg ikke deler tallet 70 % for seg selv, men supplerer med informasjon om hva produktteamene har gjort for å øke dette, sammen med en setning om hvorfor det spiller en rolle for Ruter at dette tallet er høyt. Dette øker datakompetanse ved at man viser en tydelig forbindelse mellom hva man gjør og hva man måler.
Og en viktig ting i den forbindelse: Med mindre de lever fint med å spre vanity metrics i organisasjonen du jobber i, del aldri tall uten å se tallet i en større sammenheng. For vanity metrics er players. Det er tall som deles for seg selv uten annen informasjon, og som ofte uten grunn får oss til å føle oss bra.
For eksempel kan jeg dele og presentere det som en positiv nyhet at kundene våre bruker masse tid i appen vår. Jippi, folk elsker å henge i Ruter-appen!! Men uten mer informasjon kan vi ikke vite om det rett og slett skyldes lite brukervennlig UX … Vokt dem derfor for deling av tall uten ytterligere informasjon.
Det er også et poeng å sørge for at flest forstår de mer overordnede metrikkene³ som er viktig for Ruter-appen, så som retention, WAU/MAU og activation milestone. Her er ikke vi i mål ennå, og det er et av områdene jeg har en jobb å gjøre fremover.
³Metrikk er måltall, et tall som brukes for å vurdere og evaluere bruk av et produkt.
Data i aksjon
Med data i aksjon menes at tall og innsikt blir brukt til å forstå våre kunder og til å ta beslutninger løpende. For å få til det på en bra måte forsøker vi å ta i bruk modell som også Finn bruker, kalt learning loop. Det går enkelt og greit ut på å koble seg på et produktteam og samarbeide for å finne ut hvilke informasjon de trenger for å ta informerte beslutninger i den videre produktutviklingsprosessen.
Denne øvelse gjorde vi sist da et av våre produktteam skulle kaste om på kjøpsflyten i Ruter-appen og forbedre den. Tidlig i prosessen koblet jeg meg på og satt meg ned sammen med folka som skulle jobbe med dette. Iløpet av denne økten snakket vi sammen for komme fram til hvilke spørsmål de trenger svar på for en best mulig produktutvikling. Det viste seg å være en nyttig øvelse.
Et av de mange gode spørsmålene som kom ut av økten var Hvor mange kjøper enkeltbillett til en annen sone når de alt har 30-dagersbillett for én sone? Dette er interessant å finne ut av fordi disse kundene heller enn enkeltbillett til 40 kroner bør kjøpe «billett for ekstra sone» (det som på folkemunne kalles «tilleggsbillett») for 26 kroner.
Vi så at hver måned kjøper 6 % av alle kunder med gyldig 30-dagersbillett den nevnte enkeltbilletten til en annen sone, mens 33 % kjøper «billett for ekstra sone». Det betyr at nesten 20 % (6/33) kjøper en feil billett når de skal til en annen sone — et altfor høyt tall.
Dette tallet hjelper oss i videreutviklingen av kjøpsflyten. Tallet gjør det tydlig for oss at «billett for ekstra sone» ikke er synlig nok for våre kunder. I dag må de i appen faktisk inn på detaljer til selve 30-dagersbilletten for å finne den. Kanskje bør det flyttes et annet, mer tilgjengelig sted? Sannsynligvis må den det, og akkurat nå jobber våre designere med å finne forbedring av dette, sammen med annet snacks som kom ut av learning loop-økta.
Analyse i hovedrollen
Med denne teksten har dere fått et blikk inn i hvilken rolle produktanalyse spiller i den løpende utviklingen av Ruter-appen. Helst vil vi ha analyse som hovedrolleinnhaver, og denne artikkelen viser dagens fremgangsmåte for å få det til. Helt sikkert finnes det flere veier til målet, og kanskje passer ikke alt herfra til organisasjonen du jobber i, men jeg håper det har vært mye å plukke opp for mange.
Kanskje er heller ikke denne fremgangsmåten som gjelder for Ruter om et år. Det er en produktverden, vet du. Det gjelder å iterere, forbedre. Reparere, subtrahere.
🚌
