Datadrevet produktledelse. Det er det de kule barna gjør nå for tiden, ikke sant? Du har kanskje googlet og funnet ut at det å være «datadrevet» handler om omfattende bruk av produktanalyse i den daglige arbeidsflyten til disse produktlederne.
Men spørsmålet er: Hva gjør de med analysedataene? Hvordan bruker de dem i praksis?
Heldigvis har jeg satt sammen en liste over 6 bruksområder for produktanalyse som kan inspirere deg.
Hva er produktanalyse, og hvorfor bør du bry deg om det?
Produktanalyse er prosessen med å samle inn data om det digitale produktet ditt (inkludert brukeraktivitet, økonomi og så videre), analysere dem og ta beslutninger om det daglige arbeidet og produktstrategien basert på funnene dine.
Bruk av produktanalyse øker kvaliteten på beslutningene du tar som produktleder betydelig, ettersom du kan underbygge og bevise ideene eller løsningene dine ved hjelp av data.
Som kvantitative data utfyller de også de kvalitative dataene du har samlet inn gjennom kundeintervjuer, og gir deg et helhetlig bilde av produktets tilstand samt kunde- eller brukeratferd.
Du kan aktivere produktanalyse for produktet ditt ved å sette opp et spesialisert produktanalyseverktøy som overvåker brukernes aktivitet og sender deg rapporter om brukerinteraksjoner.
Disse verktøyene samler deretter brukerhandlingsdataene de har hentet inn fra produktet ditt, og lar deg lage tilpassede rapporter for å finne svar på noen av spørsmålene du måtte ha om bruken av produktet ditt.
Nå som vi vet hva produktanalyse handler om, kan vi begynne å utforske noen praktiske eksempler på bruk av produktanalyse.
Eksempel nr. 1: Rydd opp i brukergrensesnittet ved å fjerne funksjoner ingen bruker
Gode produkter er ikke de som har flere funksjoner enn konkurrentene. Faktisk blir produkter med for mange funksjoner som regel vanskelige å navigere i for brukerne og umulige å vedlikeholde for produktutviklingsteamet.
Derfor sørger gode produktteam for at produktene deres bare har funksjoner som skaper verdi for brukerne. For å gjøre dette legger du stadig til nye funksjoner du tror folk vil bruke, og fjerner dem du vet ikke lenger er verdifulle.
Det neste åpenbare dilemmaet er hvordan du skal velge hvilke funksjoner som bør fjernes. Det er enkelt: Sjekk bruken av dem med et produktanalyseverktøy!
Bruk et hendelsesbasert produktanalyseverktøy som Mixpanel for å rydde opp
For å kunne spore bruken av en funksjon må du sette opp en hendelse for den og utløse den hver gang brukeren samhandler med funksjonen. Forutsatt at du har satt opp disse hendelsene for produktfunksjonene du ønsker å måle, trenger du bare å opprette en rapport om bruken av funksjonen.
La oss illustrere dette med et eksempel. Tenk deg at du leder Spotify, musikkstrømmetjenesten mange av oss bruker, og at du ønsker å finne ut om det er verdt å fjerne funksjonen for tilfeldig avspilling.
Til dette oppretter vi en ny innsiktsrapport som ser slik ut.
Her har vi valgt funksjonen det gjelder – «Tilfeldig avspilling» – sammen med grunnfunksjonen (vanligvis kjernehandlingen i produktet ditt eller North Star) som vi ønsker å sammenligne den med – i dette tilfellet «Strøm av en sang». For begge har vi valgt alternativet «Tell DAU» for å vise oss antallet unike brukere som bruker tilfeldig avspilling og strømmer musikk hver dag.
Deretter la vi til en enkel formel som beregner prosentandelen av de som strømmer sanger, som har brukt funksjonen for tilfeldig avspilling.
Ved å se på dette diagrammet kan vi trekke to viktige konklusjoner:
- Knapt 0,5 % av alle som strømmer musikk, bruker funksjonen for tilfeldig avspilling.
- Bruken av tilfeldig avspilling har jevnt gått ned fra 1,3 % til 0,5 % den siste måneden.
Basert på denne bruksstatistikken kan vi vurdere Tilfeldig avspilling som en god kandidat for fjerning, slik at vi kan rydde opp i brukergrensesnittet.
Have an account? Log In
Eksempel nr. 2: Finne og løse problemer med brukeropplevelsen som ødelegger oppsettet eller AHA!-flyten
De første stegene brukerne tar i produktet ditt, vil ha stor innvirkning på hvor lenge de forblir brukere, og på livstidsverdien deres. Det er i hvert fall dette jeg har sett utallige ganger i produktene jeg har ledet.
Enhver forbedring i prosessen der brukerne setter opp produktet ditt og når AHA!-øyeblikket sitt, vil til slutt føre til høyere brukerlojalitet for dem.
For å klargjøre: Brukerne når oppsettsøyeblikket når de har utført alle nødvendige konfigurasjoner ved registrering (f.eks. oppgitt kredittkortopplysninger og verifisert dem i en betalingsapp). AHA!-øyeblikket er punktet i brukerreisen der de for første gang opplever fordelene og verdien av produktet ditt (f.eks. gjennomfører en umiddelbar overføring med betalingsappen din).
Det er vanlig å ha problemer med produktopplevelsen underveis, noe som fører til at færre når oppsetts- og vaneøyeblikkene sine. Men den gode nyheten er at du enkelt kan finne dem med et analyseverktøy eller UX-varmekart som disse. Med denne typen data kan team finne ut hvor brukerne faller fra, hvilke trinn som skaper friksjon, og hvordan konverteringen kan forbedres.
Relatert lesning: De 10 beste UX-designverktøyene for produktutviklere
Slik bruker du produktanalyse- og konverteringstrakter i Heap til feilsøking
En av de mest praktiske måtene å spore og feilsøke brukerreiser på (inkludert dem som fører til oppsetts- og AHA!-øyeblikkene dine), er å bruke trakter. En trakt er en liste over hendelser som er plassert i en bestemt rekkefølge, og der du kan se konverteringen av brukere fra én hendelse til en annen.
Slik ser en traktanalyse ut for en grunnleggende registreringsside med ett enkelt e-postfelt og en send-knapp.
For registreringssiden vår sporer vi brukerne for disse hendelsene:
- Visning av registreringssiden.
- Fyller inn brukerens e-postadresse i feltet.
- Klikker på send-knappen.
Som vi kan se, var det over 1 200 brukere som gikk inn på registreringssiden. Likevel var det bare 17 % av disse 1 200 som fylte inn e-postadressen sin, og 90 % av dem som oppga e-postadressen sin, klikket på send-knappen.
Denne trakten forteller oss at det er noe galt med e-postfeltet, og at vi må undersøke nøyaktig hva det er.
Til dette kan vi enten gjennomføre brukertesting av registreringsskjermen eller se på Heap-opptaket av økten, som er et sanntidsvideoopptak av brukerens interaksjon med produktet ditt.
Når det gjelder e-postfeltet, kan det hende at du oppdager at valideringen av e-postadressen er frustrerende, og at brukerne dine gir opp etter å ha forsøkt å skrive inn e-postadressen et par ganger.
Eksempel nr. 3: Måle effekten av funksjoner under gradvis utrulling
Hvor mange ganger har du lagt til en ny, flott funksjon i produktet ditt som var en fullstendig fiasko (altså ikke forbedret bruken, eller til og med skadet den)? Dette har skjedd minst et par ganger, selv for de mest talentfulle produktsjefene.
Ettersom vi ikke alltid vet om funksjonen vi har bygget, vil lykkes eller mislykkes, er det lurt å rulle den ut til et lite antall brukere, sjekke om de bruker den (og om den forbedrer nøkkeltallene dine, som brukerlojalitet eller livstidsverdi) – og deretter, forutsatt at den var vellykket, rulle den ut til alle andre.
Du kan gjennomføre både gradvis utrulling og måling av effekt med en spesialisert produktanalyseplattform som inkluderer viktige funksjoner i analyseprogramvare, som Amplitude.
Sette opp og kjøre eksperimenter med avansert produktanalyseprogramvare som Amplitude
Amplitude leveres med avansert funksjonalitet kalt Eksperimenter. Du kan bruke den til å kjøre A/B-tester eller til gradvis utrulling av funksjoner. Jeg skal ikke gå inn på detaljene ved opprettelse av et eksperiment, siden det er en historie for en annen dag, men du kan se på dokumentasjonen Amplitude har for funksjonen sin. Den beskriver alt fra API-meldinger til integrasjoner, varsler og priser.
La oss nå forestille oss at du har lagt til en videogjennomgang som en del av produktopplæringen, og at du ønsker å øke antallet personer som klikker på avspillingsknappen og ser den. Derfor har du utviklet to løsninger der videoen vises på to forskjellige steder i produktopplæringen.
For å forstå om løsningene dine fungerer (og hvilken som fungerer best), kan vi sette opp et eksperiment med en delvis utrulling på 25 % for variant A og 25 % for variant B.
Når vi starter dette eksperimentet og kjører det en stund for å samle inn statistisk signifikante brukerdata, er det dette vi ser.
Diagrammet ovenfor viser en konverteringstrakt fra besøk på hjemmesiden til start av videoen. Som vi kan se, er variant A vinneren, og den kan optimalisere konverteringen til start av videoen med 3,4 %.
Avhengig av situasjonen kan du vurdere dette som enten en suksess eller en fiasko. Når det gjelder konverteringsfrekvensen for åpning av videoen, vil jeg si at dette er en fiasko, og at det ikke er bryet verdt å rulle den ut til alle. Men hvis resultatet av et eksperiment var en økning i brukerbevaring på 3,4 %, ville det vært en betydelig suksess.
Eksempel nr. 4: Overvåking av produktets helsetilstand
Produkter er levende organismer som kan føle seg friske eller bli «syke». For å sikre at du alltid er klar over produktets helsetilstand, og at du kan identifisere og løse eventuelle problemer med det, må du overvåke produktets «hjerteslag» i form av et dashbord for produktets helsetilstand.
Som et resultat av overvåkingen kan du legge merke til fall eller topper i de viktigste produktmålingene og KPI-ene, som WAU eller klebrighet, som trenger nærmere undersøkelse. Du kan også se at brukerengasjementet gradvis synker – noe som signaliserer at produktet trenger en oppfriskning.
Heldigvis er et dashbord for produktets helsetilstand noe du enkelt kan lage ved hjelp av et hvilket som helst verktøy for forretningsanalyse (f.eks. Mixpanel eller Amplitude).
Sporing av viktige produktmålinger med Mixpanel
Dashbord i Mixpanel består av flere relaterte rapporter som du plasserer side ved side. For et dashbord for produktets helsetilstand kan du vurdere å opprette følgende rapporter:
- DAU, WAU eller MAU for kjernehandlingen din (f.eks. strømming av en sang for Spotify). Valget mellom disse tre avhenger av den naturlige frekvensen for kjernehandlingen. For strømming av sanger vil den være daglig, og dermed blir valget ditt DAU.
- Klebrighet (DAU/WAU, WAU/MAU osv.). Dette viser prosentandelen brukere som er engasjert og kommer tilbake til produktet ditt.
- Registreringer over tid og konverteringer fra gratis → betalt over tid. Du bør følge med på disse to og sørge for at de gradvis øker.
- Kundefrafall. Dette er antallet brukere du har mistet over en periode. En økning her bør gjøre deg bekymret.
- Brukerbevaring. Dette viser antallet brukere som har fortsatt å bruke produktet ditt etter en bestemt tidsperiode (f.eks. 90 dager).
Her er et eksempel på hvordan et typisk dashbord for produktets helsetilstand vil se ut i Mixpanel.
Du står fritt til å legge til andre rapporter i dashbordet hvis de representerer produktets helsetilstand.
Eksempel nr. 5: Ta en beslutning om å lansere eller ikke lansere når QA-teamet har funnet et alvorlig problem i versjonen
En av de vanskeligere produktbeslutningene vi må ta, er å gi grønt lys for lansering av en versjon. Det er vanskelig fordi versjoner nesten aldri er feilfrie. Det blir enda mer komplisert når vi finner en feil som kan skade kundeopplevelsen.
Men hvorfor er det komplisert? Hvis du har en alvorlig feil, bør du vel fikse den først før du lanserer? Tenk deg at du oppdager at det vil ta teamet ditt enda en uke å fikse den, og at markedsføringsteamet allerede har gitt løfter og gjort forberedelser som det er vanskelig å trekke tilbake.
I denne situasjonen har du to valg:
- Gi grønt lys til versjonen og håndter konsekvensene av den alvorlige feilen.
- Gi markedsføringsteamet et godt argument for hvorfor de bør utsette lanseringen.
Begge alternativene ser dårlige ut. Men ikke bekymre deg – det er mulig at den aktuelle feilen vil ha langt mindre innvirkning enn du forestilte deg, og at du kan lansere versjonen uten store konsekvenser.
For å måle konsekvensene av feilen kan vi bruke data fra plattformen vår for produktanalyse.
Bruke Google Analytics til å beregne konsekvensene av feil
Se for deg at du har en feil som forårsaker sporadiske krasj i mobilappen din på Android 6.0.1, og som fullstendig ødelegger kundereisen. For å forstå konsekvensene av denne feilen må vi vite hvor mange brukere som har denne Android-versjonen.
Heldigvis kan Google Analytics, i tillegg til bruksdata, også samle inn og lagre data om de tekniske aspektene ved brukerne våre, for eksempel enhetstyper, operativsystemversjoner, skjermstørrelser og så videre.
Hvis vi åpner rapporten «Tekniske detaljer» og velger alternativet «Operativsystem med versjon», vil vi finne ut at bare 1,2 % av hele brukerbasen bruker Android 6.0.1.
Selv om disse dataene allerede er en indikator på at vi kan gi grønt lys for lanseringen, kan vi gå et skritt videre og også beregne den potensielle økonomiske konsekvensen ved å sjekke inntektene vi får fra brukere av Android 6.0.1.
Hvis vi sammenligner de totale inntektene mellom «alle brukere» og «brukere av Android 6.0.1», vil vi se følgende.
Det viser seg at brukerne som vil oppleve krasj etter lanseringen, ikke genererer noen inntekter for oss. Derfor får det ingen økonomiske konsekvenser å lansere versjonen med feilen. Bonus!
More Articles
Eksempel nr. 6: Identifisere brukergrupper som er verdt markedsføringsinnsatsen din
Alle brukerne dine er ikke like. Noen av dem vil være svært aktive brukere som står for størstedelen av produktbruken din (samt mesteparten av inntektene dine), mens andre vil være inaktive, med lite håp om å engasjere eller tjene penger på dem.
Naturligvis ønsker du å identifisere brukerne som kan gi deg mest inntekter, og konsentrere markedsføringsinnsatsen din om dem. Men hvordan gjør du det?
Du kan dra nytte av produktanalysedataene dine ved å identifisere ulike brukergrupper og sammenligne deres viktigste bruks- og inntektsmål.
Kohortanalyse med Amplitude
Kohorter er grupper av brukere som deler en felles egenskap. Du kan opprette kohorter basert på:
- Plattform (f.eks. Mac- og Windows-brukere). Jeg hadde et produkt der Mac-brukere hadde 30 % høyere LTV enn Windows-brukere.
- Geografi (f.eks. brukere fra Frankrike og Hellas). Avhengig av produktet kan det gi gode inntekter i enkelte land, mens det presterer dårligere i andre.
- Registreringsdato (f.eks. brukere som registrerte seg i november og januar). Se for deg at Black Friday-kampanjen din ble en stor suksess. Du målrettet deg mot de riktige personene, og novemberkohorten din har en mye høyere LTV enn andre måneder.
- Brukeratferd eller bruk av bestemte funksjoner (f.eks. brukere som stokker sanger, og de som ikke gjør det). Når du utvikler en funksjon, ønsker du virkelig at brukerne skal ha bedre engasjement og LTV. Ellers var ikke funksjonen en suksess, og det kan være verdt å fjerne den.
La oss nå opprette et par kohorter i Amplitude og sammenligne dem.
Se for deg at du vil finne ut om det er verdt å investere i markedsføring i Japan. Vi kan opprette en kohort i Amplitude for japanske brukere på denne måten.
Deretter kan vi sammenligne hvor ofte japanske brukere gjennomfører kjøp, med alle andre.
Som vi kan se, foretar japanske brukere flere kjøp enn gjennomsnittet. Derfor er det verdt å be markedsføringsteamet ditt om å målrette seg mot Japan.
Oppsummering
Produktanalyse gjør livet enklere for deg som produktleder ved at du kan ta datadrevne designbeslutninger og ikke bare stole på intuisjonen og magefølelsen din.
Det er flott å ta informerte beslutninger basert på analysedata, men du bør ikke stoppe der. Noen av de andre gode verktøyene du kan bruke for å bli en bedre produktleder, omfatter:
- Sløyfer for kundetilbakemeldinger for å sikre at alle hører kundenes stemme.
- Produktets skisser for å videreutvikle designet raskt og uten problemer.
- PRDs for å samkjøre alle om detaljene i implementeringen av funksjonen, og mer.
- Kurs i produktanalyse er verdifulle ressurser med høy avkastning på investeringen, som gjør deg mer effektiv i rollen din.
I tillegg til å lese disse veiledningene kan du også abonnere på nyhetsbrevet vårt og la oss levere masse nyttig innhold om produktledelse rett i innboksen din!
