Målinger i praksis: Sånn satt jeg opp produktmålinger

Dette er en artikkelserie i tre deler om målingsarbeid i praksis. Her deler jeg hvordan jeg jobber med målinger i hobbyprosjektetet mitt, en strikkekalkulator. Her kan du lese forhistorien til produktet. Artikkelserien består av hvordan jeg fant gode produktmålinger, hvordan jeg satte opp målingene i Posthog (denne artikkelen), og hvordan jeg bruker målingene i videreutvikling av produktet (kommer).

Valg av analyseverktøy

Nå som jeg har kommet fram til hva de viktigste måltallene mine er, er det på tide å velge et passende analyseverktøy. Jeg har gått for PostHog. Jeg så produktet for første gang på en fagdag i Bekk for noen år siden, der noen viste fram oppsettet de hadde brukt på teamet. Jeg husket jeg likte oppsettet, så jeg installerte det på strikkekalkulatoren for å se hvordan det var i bruk. Jeg ble overbevist, og her er betraktningene mine rundt hvorfor:

• Det var enkelt å ta produktet i bruk, både å sende og visualisere eventer. (Dette gjelder de aller fleste moderne analyseverktøy, noe annet er et stort rødt flagg.)
• God støtte for å lage egne grafer og dashboards.
• Jeg vil helst ikke bruke cookies, og det støttes i PostHog.
• Produktet har innebygd støtte for A/B-testing og funnels.
• Produktet har innebygde feature toggles, som ser ut til å spille på veldig godt lag med forrige punkt.
• Jeg var positivt overrasket over de gode mulighetene til å legge til og å bruke mange forskjellige event properties.
• Produktet har en generøs gratisvariant. Jeg vurderte Plausible lenge, men for å få tilsvarende antall events hadde jeg måttet ut med 40 dollar per måned.

De eneste ankepunktene jeg har med produktet hittil, er:

• Cookie-løs tracking støttes, men hvis man går cookie-løs er det ikke like rett frem å tracke brukersesjoner som det er med Plausible.
• Jeg savner justeringsmuligheter for utseendet til grafene. De innebygde grafene gjør jobben, men jeg synes de har litt vel mye visuelt støy, og jeg har ikke skjønt helt hvordan jeg setter på gode labels. Dette er kanskje bare en treningssak.
• Jeg synes det er knotete å flytte grafene rundt i dashboardene.

De første tallene: En oversikt over KPI-ene

Det første og aller viktigste dashboardet jeg lager, er en oversikt over KPI-ene. Hvis jeg bare skulle hatt ett dashboard, hadde det vært dette. Hvis jeg ikke har vært inne i analyseverktøyet på en stund og lurer på hvordan det står til med strikkekalkulatoren generelt, er det dette dashboardet jeg sjekker.

Jeg vil det skal være helt tydelig hva KPI-ene står på i tidsperioden man har valgt, så det øverste man ser i dashboardet er tre store tall. En graf i tid kan gi mer innsikt hvis man vil se litt nøyere, så dette kommer under. Og dette er hele dashboardet; det gir hovedinnsikten om produktet enkelt og raskt, og jeg trenger sjeldent å endre på det.

Her ser vi tall for 30 dager. Jeg vil si meg veldig fornøyd med tallene:

• Over 25 000 sidevisninger per dag. Dette er nesten det dobbelte av det jeg trodde jeg hadde!
• Hele 43% av sesjonene fører faktisk til at brukeren har oppskriften i viewport i over et minutt. Man kunne sett negativt på dette: 57% bruker ikke kalkulatoren av diverse grunner. Men internett er stort og det er mange veier inn til nettsiden. At nesten halvparten bruker over et minutt på oppskriften tror jeg er et objektivt godt tall. Til sammenligning er en god view/read-ratio på Medium-artikler mellom 20% og 50% — og der måles bare 30 sekunder på siden.
• Omtrent 9 av 10 er fornøyde med oppskriften de får. Det er alltids dårlige tilbakemeldinger som gir noe å jobbe med, men 9 av 10 synes jeg er et ordentlig godt utgangspunkt.

Mer detaljerte dashboards

Jeg likte KPI-ene jeg kom fram til veldig godt, og bestemte meg for å bruke disse som utgangspunkt for noen flere dashboards. Det er mange målinger jeg kan sette opp, og jeg tenker det vil være lurt å fordele dem per KPI. Så for hver KPI lager jeg et dashboard med de tallene jeg tenker er relevante — tall jeg kan prøve å påvirke hvis jeg vil bevege KPI-en. Dette gir meg også en innebygd oppskrift på videre prioritering:

1. Hva skal jeg fokusere på videre? Sjekk KPI-ene og bestem meg for hvilken jeg vil endre på. For eksempel forbedre KPI 1: Øke trafikken.
2. Hvordan skal jeg bevege KPI-en? Sjekk det tilhørende dashboardet og finn mer spesifikke forbedringspunkter. For å bevege KPI 1 kan jeg f.eks. se på hvor brukerne mine kommer fra, innse at jeg får lite trafikk fra sosiale medier, og lage en SoMe-konto eller noe.

I de neste seksjonene beskriver jeg de tre ekstra dashboardene jeg lager, ett for hver KPI.

Detaljdashboard for KPI 1 — antall brukere

I dette dashboardet legger jeg alle tall jeg mener er relevante for å analysere og påvirke hvor mange brukere jeg har. Øverst legger jeg selve KPI-en, både tall og graf, slik som i oversikts-dashboardet.

Videre har jeg lagt til grafer for tre forskjellige metrikker. Den første metrikken er antallet som kommer til siden via en “Dele”-lenke. Dette tallet ligger på cirka 1% av totalen, som er ganske beskjedent.

Neste graf viser fordelingen av språk. Nesten all trafikken er norsk. Det er veldig stort forbedringspotensiale for både dansk og engelsk — jeg vet ikke helt hvorfor disse to ikke gjør det bedre, så dette er en god kandidat å se på hvis jeg vil ha flere brukere.

Siste graf viser hvilke nettsider folk kommer fra:

1. Øverste referrer er min egen side, hobbyhygge.com. Her avdekkes en feil jeg har gjort: Det kommer av en dårlig konfigurert redirect fra grunn-url-en hobbyhygge.com til strikkekalkulator-url-en, og det maskerer hvor brukerne egentlig kommer fra (som mest sannsynlig er Google).
2. Neste på listen er direct, som betyr at referrer mangler — da kan brukeren komme fra mailen sin, eller mer sannsynlig i dette tilfellet, gått direkte på URL-en, f.eks. via et bokmerke.
3. Tredje og siste gode kilde til trafikk er facebook.

Her er et lite irritasjonsmoment i Posthog: Merkelappene og stolpene i stolpediagrammet er ikke rett ved siden av hverandre.

Merk at jeg har hoppet over en del tradisjonelle webanalyse-metrikker, som stickiness, et mål på hvorvidt nye brukere fortsetter å bruke nettsiden over tid. Dette er veldig nyttige metrikker, men er umulig for meg å måle uten en måte å tracke brukere på over tid — via cookies. For å gjøre det enkelt for meg selv, og for å bedre personvernet til brukerne mine, har jeg som nevnt valgt å ikke bruke cookies.

Detaljdashboard for KPI 2 — bruk av kalkulatoren

I forrige artikkel kom jeg fram til følgende måte å måle bruk av kalkulatoren på: Brukeren har oppskriften i viewport i 60 sekunder. Jeg lar fremdeles øverste del av dashboardet være KPI-tallet med graf.

Denne KPI-en er veldig godt egnet til å visualiseres som en trakt (eller funnel), siden den består av tre steg: Komme inn på siden, klikke “Regn ut”, og å ha oppskriften i viewport i 60 sekunder.

Nok et irritasjonsmoment i Posthog: Trakten viser ikke navnene jeg har gitt stegene, bare “Completed x steps”. Merkelig nok er dette ikke tilfellet i neste trakt.

Jeg har også laget en trakt for bruken av tellehjelpen. Her ble jeg positivt overrasket — godt over 1000 personer har faktisk fullført alle stegene i tellehjelpen, i løpet av de siste 30 dagene.

Den siste grafen viser bruken av “Skriv ut”- og “Del”-knappene. Disse tallene påvirker ikke KPI-en direkte, men hvis man klikker på “Skriv ut” tenker jeg det er en god indikasjon på bruk.

Detaljdashboard for KPI 3 — tilfredshet

I hver oppskrift har man muligheten til å gi tilbakemelding: Enten “Bra”, “OK” eller “Dårlig”. Jeg har definert brukertilfredshet som andelen tilbakemeldinger som er “Bra” eller “OK”. Da jeg lagde dette dashboardet innser jeg en svakhet med denne definisjonen — og det er at jeg gjerne vil få folk over fra “OK” til “Bra”. Men jeg beholder KPI-en inntil videre. Som vanlig er KPI med graf øverst.

Resten av dette dashboardet består av kakediagrammer som viser bruker-tilbakemeldinger for gitte parametre som jeg tror er relevante:

1. Språk. Kanskje kalkulatoren gjør det dårligere på dansk og engelsk på grunn av dårlig brukeropplevelse?
2. Om strikkeoppskriften har repeterende instruksjoner eller ikke. Disse kan gjøre oppskriften mer komplisert å følge.
3. Om strikkeoppskriften er helt optimal eller ikke. Jeg skal ikke gå inn på detaljene, men i visse tilfeller klarer jeg ikke å lage en helt jevn strikkeoppskrift med bare 8 instruksjoner, som jeg har satt som maksgrense. Da gjør jeg et kompromiss på hvor jevnt det blir, for å lage en kortere oppskrift som er enkel å følge.

Under vises kakediagrammene. Grønn, gul og rød farge indikerer henholdsvis “Bra”, “OK” og “Dårlig” som tilbakemelding.

Nederst til høyre vises tilfredshet for “ikke-optimale” oppskrifter. Den røde delen av denne er litt større enn i de andre diagrammene, så her har vi definitivt et forbedringspunkt. Til gjengjeld er det ikke så mange som får slike oppskrifter, derfor kan det være bedre å fokusere på andre ting hvis målet er å bevege KPI-en.

Nå som jeg har ett dashboard per KPI i oversikts-dashboardet mitt, legger jeg inn lenker fra hoved-dashboardet til disse. Da blir navigeringen enklere enn å bruke sidemenyen i Posthog.

Konklusjon

Nå er målingene satt opp, og i den prosessen har jeg avdekket flere punkter innsikt som jeg vil bruke i fremtiden. Men flere spørsmål gjenstår. Er dashboardene gode i bruk? Finner jeg enkelt ut av det jeg lurer på? Og aller viktigst: Hvordan kan jeg bruke målingene til å videreutvikle produktet? Dette er spørsmål jeg vil besvare i neste artikkel.

For de spesielt interesserte: Events og properties

All produktanalyse jeg gjør i Posthog bygger på eventene jeg sender, så disse er veldig viktige. I denne seksjonen lister jeg opp alle events og event properties jeg sender — det er litt teknisk, så denne seksjonen er for deg som er ekstra interessert.

Her er listen over events jeg sender:

• Sidevisninger, standard oppsett fra Posthog
• calculateClick: Klikk på “Regn ut”-knappen
• countingHelpStarted og countingHelpFinished : Når man starter og fullfører tellehjelpen
• recipeInViewport { millis } : Sendes hvert 30. sekund brukeren har hatt oppskriften i viewport. millis er en event property som indikerer hvor lenge den har vært i viewport
• copyLinkButtonClick og printRecipeButtonClick : Hhv. klikk på “Kopier lenke”- og “Skriv ut”-knappene
• recipeFeedback { feedback } : Klikk på en av tilbakemeldingsknappene “Bra”, “OK” eller “Dårlig”. feedback er en event property som indikerer hvilken tilbakemelding som er gitt

Vedlagt alle eventene utenom sidevisning-eventet, har jeg lagt ved et sett event properties som sier noe om hvilken strikkeoppskrift brukeren har. Dette er spesielt nyttig når jeg får en “Dårlig” tilbakemelding, da kan jeg slå opp samme oppskrift og se hva det dreier seg om.

• currentStitches og wantedStitches : Input i kalkulatoren
• hasRepeatedInstructions : Noen oppskrifter har gjentakende instruksjoner a la “Gjenta steg a — c 4 ganger”, som kan virke ekstra kompliserte. Dette flagget indikerer om oppskriften har slike instruksjoner
• isOptimal : Noen ganger er oppskriften for lang til å kunne vises på en brukervennlig måte, og da korter jeg ned antall instruksjoner. Dette flagget indikerer hvorvidt dette er gjort
• numberOfInstructions : Antall instruksjoner i oppskriften

Jeg avslutter med å vise et skjermbilde av hvordan jeg bruker eventene til å lage en graf over bruksraten til kalkulatoren, altså KPI 2. Her teller jeg altså hvor mange som har hatt oppskriften i viewport i over 60 sekunder, og regner det ut som en andel av alle sidevisningene. Se hvor enkelt det er å filtrere eventer og å lage formler basert på dem!