Del 1: Introduksjon til webanalyse

Du lurer kanskje på hva webanalyse er og hvorfor det er viktig? Jeg er glad du spør, og denne delen kommer til å besvare dette, håper jeg. Et emne som ofte følger med på kjøpet er søkemotoroptimalisering og andre knep for å nå ut.

Webanalyse handler ikke om enkle knep eller snarveier! Derimot er webanalyse din måte å lære kjenne ditt nettsted, dine brukere og hvordan de bruker nettstedet. Det er en metodisk måte å evaluere om endringer bærer frukt og hva som kan bli enda bedre.

Nettstedet er ikke bare et digitalt sted fylt av sider, bilder og dokumenter. Ofte har man et formål, eller i det minste et håp med det som dets skaper. Noe man ønsker at nettstedet skal bidra med, noe som skal skje. Det kan være å selge varer, formidle kontakt mellom mennesker, informere borgere om samfunnstjenester eller deres rettigheter, og mye annet.

Å jobbe med webanalyse handler om å forbedre, eller kanskje forenkle, det som nettstedet skal muliggjøre. Å gjøre det intuitivt å finne frem til, og enkelt å for eksempel fullføre, alle delsteg i en kjøpsprosess. Webanalyse er altså alle verktøy og oppgaver som bidrar til hvordan man optimaliserer et nettsted!

Man kunne tro at webanalyse går ut på å samle på seg mengder med data for deretter å lete etter nåla i høystakken. Det er ikke helt slik det foregår. Webanalyse er å ved hjelp av innsamlede data nå innsikt i brukerens opplevelse av et nettsted. Med hensikten å forbedre opplevelsen. Å gjøre nettstedet mer nyttig.

Det korte svaret på hva webanalyse er besvares ganske godt av Wikipedia, synes jeg:

Web analytics is the measurement, collection, analysis and reporting of web data for purposes of understanding and optimizing web usage.

Det er lett hendt at fokus havner på å analysere innsamlet besøksstatistikk når man gjør web- eller intranettanalyse. Dog inngår all form for evaluering i begrepet – ikke bare hvordan et nettsted brukes. Jeg hører stadig oftere at bransjekollegaer, utover sin besøksstatistikk, bruker andre typer verktøy for å skaffe seg en oversikt over sine nettsteder. Det man kan trenge oversikt over er å enkelt sile frem sider med diverse problemer. For eksempel å se hvilke sider som ikke lever opp til organisasjonens ambisjon rundt tilgjengelighet, hvor man bruker unødvendig høyoppløste bilder, hvor folk forsvinner fra nettstedet, med mer.

Mye handler om annet enn den besøksstatistikken praktisk talt alle samler inn. Dessuten finnes det andre aspekter enn de strengt kommersielle og standhaftige e-handelsligningene. Men først skal vi gå gjennom grunnlaget i hvordan man jobber med sin webstatistikk, bearbeider sine data, hvilke metoder og verktøy alle trenger å kjenne til. Mye av dette kan du bruke i andre webanalysesammenhenger, forutsatt at tilstrekkelig data finnes tilgjengelig.

Intro til å jobbe målbart – begynn med en nullmåling

Det finnes en rekke aktiviteter for å komme i gang og jobbe målbart med sitt nettsted. En ting er å komme frem til virksomhetsmål som skal styre nettstedets utvikling, noe vi kommer inn på straks, en annen er å få oversikt over situasjonen. Har man allerede et nettsted gjør man noe som kalles for en nullmåling. Det går ut på å gjøre sin aller første måling av hvordan nåsituasjonen er. Det som kommer til å stå som modell for å beskrive fremtidige endringer. De verdiene som du og dine kollegaer kommer til å humre over i kaffepausen om noen år, i beste fall, eller det du bruker i evalueringen for å kvalitetsteste et oppdatert nettsted. Nettstedets referansepunkt rett og slett.

Nå tar jeg kanskje opp det åpenbare, men hvorfor ikke, det er vel like greit så ingen tilfeldigvis går glipp av det. For at det skal være meningsfullt og rettferdig å sammenligne hvordan nettstedet presterer over tid, trenger du å ha kontroll over de omstendighetene som påvirker målingen.

Mitt råd er å utforme minst én side på nettstedet som er den du nullmåler nettstedets tekniske kvalitet mot. Helst har du en testside per type side, si en for startside, en ytterligere for produktsider, en for artikler, og så videre. Det er mot disse sidene du over tid skal kontrollere at nettstedet kontinuerlig blir bedre, eller i det minste ikke dårligere og dårligere. Disse sidene er de adressene du mater inn i verktøy fremover for å sjekke hvor raskt sidene svarer, laster ferdig, om de anses mobilvennlige, etc.

Husk at eksempelinnholdet på disse testsidene også det må bestå over tid. Om det gjør det kan du faktisk stille veldig konkrete – og målbare – akseptansekriterier når du bestiller et helt nytt nettsted. Det er vel ikke mer enn rett at man forventer at et nytt nettsted er bedre enn det foregående, eller hva?

For å holde styr på at redaksjonelt innhold eller slikt som kommer servert fra andre systemer holder riktig kvalitet, kan en arbeidsmetode være å overvåke de mest nyskapte sidene. Ellers risikerer nettstedet å bli stadig dårligere over tid.

Jeg kan mene at all kommunikasjon rundt forbedringer av et nettsted skal inneholde en sammenligning mot både ens nullmåling og det siste referansepunktet før endringen. Da kan man se i konkrete tall at ingenting ble dårligere, og om en lovt forbedring faktisk inntraff. Hvorfor har man da offisielle og utpekte testsider? Jo, da kan leverandøren sjekke sin leveranse mot testsiden før de anser at de er ferdige og roper «Ferdig!»

Disse målingene kan handle om enormt mye mer enn det du får frem i din webstatistikk. Blant annet kan det være:

1. Etterlevelse av oppsatte mål om tilgjengelighet i henhold til WCAG.
2. Språklige ting, som hvilke forkortelser som aksepteres.
3. Hvordan responsiviteten er for eksempel på bilders oppløsning.
4. Hvilken svartid webserveren får lov til å ha under vanskelige grisgrendte forhold via 3G-nettet.
5. Hva eksterne aktører som Google og Pingdom anser om ens ytelse for utålmodige besøkende.

Flere eksempler på målbare akseptansekriterier finner du i den siste delen av boken som tar opp hvilke aktiviteter man kan jobbe med for å få oversikt over nettstedets kvalitet. Før vi har kommet så langt i emnet webanalyse skal vi imidlertid snakke om metoder, dokumentasjon og målsetting.

Dokumentasjon man bør ha før et nytt webprosjekt starter

Det finnes mye å tenke på før man starter et nytt webprosjekt. Disse tingene har en tendens til å endre seg over tid, noe som gjør det vanskelig å gjenbruke forrige webprosjekts krav rett av. Jeg hadde tenkt å ta opp noen punkter jeg vil påstå altfor sjelden diskuteres før et prosjekt kommer skikkelig i gang. Dette er en hurtigintroduksjon i dokumentasjon, det kommer en fordypning senere der stilguide, designmønstre og ytelsesbudsjett diskuteres i lengre ordelag. Denne delen er hva alle involverte i et webprosjekt bør vite.

Nedenstående overskrifter kan du ha i et dokument som følger med prosjektet frem til leveranse – og deretter overleveres til forvaltning av ens egen kontrollinstans (den egne webanalytikeren?). Dette gjøres for å sørge for at man ikke løpende avviker fra den opprinnelige avtalen under sin forvaltning av nettstedet. Poenget er altså ikke at nettstedet skal være skinnende fint på lanseringsdagen, men minst like bra tre måneder senere.

Jeg vet at du har hørt det før – man blir aldri «ferdig» med et nettsted. Det er viktigere hvor bra det fungerer etter et år enn hvor fint det var som prototype. Like gjerne som at du kontinuerlig må forbedre nettstedet for at det ikke skal avvikle seg selv, bør du løpende revidere de målbare kravene du stiller til nettstedet. Du bør stadig heve kravene i takt med at omverdenen endrer seg.

Skal man bruke noen andres innholdsnettverk?

Innholdsnettverk (kalles ofte for CDN - Content Delivery Networks) brukes for å slippe å ha filer lokalt på et eget nettsted. I mange tilfeller gir det raskere nedlastningstid eller andre ytelsesfordeler for brukerne, samtidig som det er både billig og enkelt å få til på sitt nettsted. Vanligste varianten er nok å hente sporingskode for webanalyseverktøy som Google Analytics på denne måten. Deri ligger også den største grunnen til at man trenger å tenke gjennom sin bruk av innholdsnettverk. De krenker mer eller mindre mye brukerens personlige integritet ettersom man blander inn en tredjepart i kommunikasjonen med sin bruker.

Du bør velge nettstedets tredjepartstjenester med stor omhu. Det er du som utgiver av et nettsted som må tenke gjennom dine brukeres integritet, hvilke parter du inviterer inn til å bidra til ditt nettsted og dermed hvordan bruksdata kan komme på avveie. Det er fullt mulig å sette opp egne innholdsnettverk, store som små.

Andre eksempler utover Google Analytics er de nettstedene som henter inn skrifttyper fra Google Fonts eller har en sosial strøm fra Facebook integrert. Mange har knapper for å dele innlegget i sosiale medier eller de som lar Wordpress.com håndtere bildene for våre egne Wordpress-nettsteder. Nesten alltid når man får en kode å lime inn fra en tjeneste, følger denne problematikken med på kjøpet. Tenk innbyggingskode fra videotjenester. Så fort et bilde eller annet visuelt skal vises, hentes det ofte fra tredjepartstjenestens webservere uten at den besøkende aktivt trenger å samhandle med tjenesten.

Man kan drive sitt eget innholdsnettverk, men der kan du selvfølgelig ikke plassere Facebooks nyhetsstrøm eller Google Analytics' sporingskode. Men mye annet. Som bilder, video, designrammeverk som Jquery, eller annet som brukes for å få nettstedet til å fungere som det er tenkt. Da kan man hente inn litt av den gevinsten som et innholdsnettverk tilbyr. For deg som driver et veldig lite nettsted kan du sjekke for eksempel webhotelltjenester som Loopias Autobahn. Slike tjenester er spesiallaget for å raskt sende filer som sjelden eller aldri oppdateres – det vil si statiske filer. Eller om du vurderer at storskala tredjepartstjenester ikke er noen større fare for akkurat dine besøkende, sjekk ut Cloudflare med flere som ofte er enkle å integrere med de fleste webpubliseringssystemene (CMS).

Jeg foreslår at man deler denne problemstillingen i to deler; hvordan gjør vi med webanalyse samt hvordan gjør vi med innholdsnettverk for andre behov.

For webanalyse er Google Analytics enormt vanlig. I 2015 fantes Google Analytics for eksempel på 8 av 10 av kommunenes nettsteder. Ser man integritet mest som et juridisk spørsmål, er det stadig vanligere at kontraktene med leverandørene av webanalyseverktøy gjør det klart at du eier din brukerdata. Vil man verne integriteten ekstra mye nettopp rundt å samle besøkerstatistikk, finnes alternativet Matomo¹ som man kan legge på ens egen webserver. Da blir det vanskeligere for fremmede lands overvåkningsmyndigheter å ha kontroll på dine brukere.

Dessuten finnes veldig mange nisjede verktøy som tilbyr annet nyttig til webanalyse, som å kunne spille inn besøkendes sesjon på nettstedet, spørreskjemaverktøy, A/B-tester, sjekke hvor langt ned brukerne scroller og annet vi kommer til å gå gjennom senere. Det første og kanskje viktigste beslutningen er hvilke av de store drakene du lar få en god oversikt. Kjører du med Google Analytics legges det inn på hver side og du kommer nok til å beholde det veldig lenge. Da får Google veldig mye større innsyn den veien enn om du bygger inn noen spredte Youtube-klipp (Google eier Youtube). Ta et aktivt beslutning og dokumenter gjerne hvordan dere resonnerte.

Angående det andre delspørsmålet, det om innholdsnettverk for å støtte designen av nettstedet, handler det om når man velger å designe nettstedet sitt på en måte som drar nytte av andres tjenester. Fremste argumentet for dette er at disse tredjepartene ofte kan sende innhold raskere til din bruker enn du kan. Altså blir opplevelsen raskere, nettstedet ditt avlastes og kan således ta hånd om flere brukere.

Noen eksempler der man har å vinne på å bruke innholdsnettverk for bedre brukerytelse er:

• Strømme video eller lyd fra et datasenter plassert så nær respektive bruker som mulig.
• La Google, Microsoft eller annet større selskap sende vanlige filer som ikke er unike for ditt nettsted. For eksempel skrifttyper, kodebiblioteker som Jquery, med mer.
• Plassere sine egne statiske filer som bilder, dokumenter, med mer på et innholdsnettverk eller webserver som er spesialisert på rask filoverføring.

Så skal man jo huske på at dette er en ny avhengighet man utsetter nettstedet sitt for, at flere kokker blir involvert for at siden skal vise seg på riktig måte. Dette var noe mange store medier fikk erfare da Facebook hadde en driftsforstyrrelse med sin liker-knapp i 2013.

Wow a Facebook bug has taken down CNN, the Washington Post, Huffington Post, Slate, BuzzFeed, Gawker and Kickstarter...
- John Herrman, BuzzFeed²

Mange ganger har man nok ikke gjort et særlig aktivt valg, eller i det minste ikke et særlig gjennomtenkt valg, det bare ble som det ble. Jeg har selv evaluert prosjekter der spørsmålet om hvorfor det fantes så mange eksterne avhengigheter ble besvart av utvikleren i stil med «vi pleier å gjøre det på den måten». Altså hadde spørsmålet aldri blitt tatt opp med bestilleren. Derfor kan det være bra å forekomme disse automatiske ikke-beslutningene med en dokumentasjon.

Hvilke akseptansekriterier blir det?

Det er ikke alltid man har noen akseptansekriterier over hodet. Iblant har man ikke støtte for dem i avtalen med leverandøren. Når jeg har jobbet som utvikler har vi iblant hatt en ganske omfattende dokumentasjon om hvordan man definerer at man er ferdig med et programvareprosjekt, men det dekker ikke inn alle aspekter av et nettsted. Men har du noen dokumentasjon som definerer et godt håndverk, eller finner en du liker, så diskuter den med leverandøren, eller internt, og kom frem til hvilke deler prosjektet må leve opp til.

Å leve opp til lovgivningen kan virke åpenbart. Men lovgivningen er dels noe som oppdateres og samtidig ikke så svart-hvit i tolkning som man skulle ønske. Når det gjelder nettsteder er det vel primært Lagen om Elektronisk Kommunikation (LEK), der en paragraf populært kalles cookieloven, Personuppgiftslagen (PuL) og Lag om ansvar för elektronisk anslagstavla (1998:112, kalt BBS-loven) som er aktuelle. Det du bør tenke gjennom før webprosjektet, og dokumentere, er om dere i det hele tatt skal bruke cookies. Og om det blir cookies, hvordan dere velger å se på cookie-meldinger med deres samtykkekrav. I 2016, i skrivende stund, har EU en ny personvernlovgivning på gang. Den kommer på sikt å erstatte den svenske PuL-lovgivningen, så kartet tegnes om.

En nykommer er slik Diskrimineringslagen ble skjerpet 1. januar 2015. Fra og med 2015 er det en diskrimineringsgrunn om et nettsted fungerer dårligere for noen med en funksjonsnedsettelse. Til forskjell fra LEK og PuL er dette en lovgivning du trenger å jobbe mer aktivt med ettersom den stiller krav til alt som publiseres. Det er for eksempel ikke ok at brukerne må ha perfekt syn eller hørsel for å ta del av innholdet. Man må også passe seg for hvilke krav man stiller til brukerens motorikk, kognitive evne, etc. En måte å begynne å rede ut tilgjengeligheten er å sette et ønsket nivå. Heldigvis finnes det et standardisert rammeverk for å evaluere tilgjengelighet i form av Web Content Accessibility Guidelines (WCAG). Med WCAG kan man velge ulike nivåer av hvor høy tilgjengelighet man er ute etter, for eksempel WCAG 2.0 nivå AA, der nivå A er slakkere og nivå AAA er strengere.

WCAG løser ikke alle ens utfordringer med tilgjengelighet, men det er en svært god begynnelse og definitivt noe man skal ha med i sine akseptansekriterier overfor sin leverandør. Har man en svensk leverandør kan man alltid sjekke om de kjenner til webbriktlinjer.se – Vägledningen för webbutveckling. Det er fortsettelsen av 24-timmarsmyndigheten, men er definitivt også fornuftig for privat sektor. Den første retningslinjen, med høyeste prioritet, er å følge WCAG 2.0 nivå AA, men der finnes en hel del andre kloke retningslinjer.

Selv har jeg ofte supplert de IT-navlebeskuende kravlistene med en liste med målbare leveransekriterier for det som til syvende og sist lander ute hos en bruker av et nettsted. Det som utviklere kaller frontend, men det har også en hel del med webytelse å gjøre. En lang men på ingen måte komplett liste med aktiviteter finner du i slutten av denne boken.

Dokumentert aksept fra alle leverandører?

Har samtlige leverandører fått oppdragsbeskrivelsen og all annen prosjektdokumentasjon de trenger? Også ens egen IT-avdeling? Min erfaring er at det ikke alltid er slik at oppdragets eksakte formuleringer og krav følger med til alle involverte. Blant annet rotet vi på min arbeidsplass til det med hvordan den av mange forhatte cookie-meldingen skulle se ut og fungere på alle våre nettsteder. Vi er vel et ekstremt tilfelle, med våre nesten tre tusen webredaktører til det hundretalls nettsteder vi driver. Med andre ord er det stikkprøver som gjelder for å verifisere at en oppdragsbeskrivelse jeg har skrevet virkelig har slått igjennom med full kraft overalt.

Så hvordan forebygger man at noen kan si at de ikke visste? Godt spørsmål. Kanskje gjennom å ha en tydeligere, og mer høytidelig, dokumentasjon som beskriver nøyaktig det man mener samt med hvem respektive oppdrag må avstemmes med ved leveranse. Dette er sikkert ikke noe problem om man bare har et fåtall nettsteder eller er få involverte. Men det skader kanskje ikke å tydeliggjøre dette likevel.

Det gjelder at man selv holder seg til denne dokumentasjonen. Senere i boken kommer du til å få en introduksjon til ytelsesbudsjett, der nettopp denne typen krav gjerne får plasseres. Ordet «budsjett» er av største viktighet. Det er nemlig som andre budsjetter noe man skal forsøke å husholdere med, planlegge for å ha et lite overskudd igjen, og at en mindre overskridelse ikke er hele verden.

Personas er nyttig også ved webanalyse

Altfor ofte når jeg har sett organisasjoners personas er det smilende karikaturer av personer fra den tiltenkte målgruppen. Det blir sikkert stadig vanligere at ens personas også har svakheter. Men om du ikke allerede har en slik kan jeg definitivt anbefale å ha en eller flere personas som til sammen har alle vanlige funksjonsnedsettelser.

Hvorfor det? Jo, fordi alle vi som i hverdagen ikke anses å leve med en funksjonsnedsettelse kan rammes av dette, både midlertidig og varig. Si at noen er i sjokk eller personlig krise, ja da er det jo bra om det som er bygget har blitt designet uten å kreve et høyt kognitivt nivå. På slutten av en tøff arbeidsdag er nok de fleste merkbart kognitivt nedsatte, i hvert fall pleier jeg ofte å være det. At vi alle har det vanskelig med synet ble tydelig i og med en mobil atferd og bruk av skjermer utendørs. Svake kontraster fremkommer ikke i det hele tatt på mobilen når man er utendørs en solrik dag. Denne vanskeligheten har de med synshemming også under optimale lysforhold.

Eksempel-persona: Salongberuste Sanjay

Du som jobber med personas får gjerne ha med Sanjay, eller krydre en eksisterende persona med hans egenskaper (men velg et passende navn som fungerer innen din organisasjon). Nå har jeg ikke jobbet med Systembolaget, men om Sverige ikke var så engstelig for alkoholpolitikk kunne man trygt ha regnet med at de hadde hatt en persona som var i det minste salongberuset. Eller?

Så hvilke egenskaper har Sanjay? Hva utmerker ham?

• Språk: Forstår litt svensk, men leser utmerket på hindi.
• Enhet: Moderne mobil, med sprukket display som gir merkelige farger rundt sprekkene.
• Abonnement: Sanjay har flere indiske SIM-kort, men også et svensk med en månedlig surfepott på 500 Mb.
• Sted: Utendørs, midt på dagen, midtsommer, i solskinn (tro det eller ei).
• Tilstand: Litt beruset, det er jo tross alt midtsommer.
• Geografi: I utkanten av 3G-nettet i nordvestlige Dalarna, halvt i radioskygge.

Sanjay er i Dalarna hos venner og feirer en klassisk svensk midtsommer. Noe beruset sprakk han skjermen da han hadde mobilen i baklommen da han datt under leken irsk julaften. Skjermen gir nå rare fargevariasjoner rundt sprekkene. Hans kognitive evne er ikke på topp, motorikken heller ikke helt hundre, og det er skikkelig dårlig mottak der han befinner seg.

Bilde 1: Blant annet Tele2 tilbød i 2016 surfepotter på kun 500 Mb.

Sanjay er selvfølgelig et konsentrat av den utfordringen du har med ditt nettsted, særlig om du driver et nettsted med kriseinformasjon, for eksempel Giftinformasjonen eller annet som gjør ham selvstendig når han kanskje trenger det som mest. Det finnes nok en del å lære av ham. Særlig den kontrasten han tilbyr sammenlignet med Ergonomiske Egon.

Typisk anti-persona: Ergonomiske Egon

Ergonomiske Egon er alltid på topp, godt uthvilt og aldri følelsesmessig påvirket. Egon bruker bare nettet på kontoret, med velinnstilt datatilbehør han selv nøye har valgt ut. Han har selvfølgelig en høyoppløst stor skjerm med bred betraktningsvinkel og ingen vinduer som gir gjenskinn i skjermen. Rask kablet tilkobling helt uten begrensninger.

Egons egenskaper er altfor vanlige som en antakelse når man utformer sine personas. Normalbrukeren ligger selvfølgelig et sted mellom Sanjay og Egon, men begge ytterpunktene eksisterer og særlig kan vi trenge å legge litt omsorg for Sanjays skyld.

En uke med empati for sine brukere

For å i det minste føle litt empati med sine brukere kan man gjøre som Facebook annonserte i 2015, de innførte en ukedag da man kan leve med de forutsetningene ens viktige målgrupper har. I Facebooks tilfelle har deres utviklerpersonell kun 2G-hastighet når de surfer, du vet det der hysterisk trege vi i Sverige hadde før 3G begynte å slå igjennom like etter årtusenskiftet.

People are coming online at a fast rate in emerging markets. In most cases, they are doing so on mobile via 2G connections. But on a typical 2G network, it can take several minutes to download a webpage.[…] Today we're taking another step toward better understanding by implementing "2G Tuesdays" for Facebook employees. On Tuesdays, employees will get a pop-up that gives them the option to simulate a 2G connection. We hope this will help us understand how people with 2G connectivity use our product, so we can address issues and pain points in future builds.
- Chris Marra, code.facebook.com³

Bilde 2: Peter Antonius om hvordan en uke med omsorg for brukerne kan se ut.

Eller som Peter Antonius⁴ foreslo på Twitter kan man ha en hel uke med denne typen innsikt i brukernes virkelighet. Hans forslag går ut på følgende:

• Mandag: Screen Reader Monday
  En dag da man får innholdet på skjermen sin opplest for seg. Program for dette finnes sikkert allerede i din datamaskin/enhet om du aktiverer tilgjengelighetsfunksjonene. Ikke glem å slå av skjermen, ellers blir det nok vanskelig å ikke jukse.
• Tirsdag: 2G Tuesday
  Dagen for å ha en skikkelig treg internettilkobling. Det er nå du merker hvilket materiale du gjerne skulle sluppet å vente lenge på.
• Onsdag: Keyboard Wednesday
  På onsdager får man bare navigere ved hjelp av tastaturet, det vil si musepekeren får fri. Da vil du oppdage når tab-rekkefølgen er feil på nettsteder, om den der meldingen kan lukkes med et mellomrom eller ikke.
• Torsdag: Color Vision Deficiency Thursday
  Torsdagen er for at du ikke skal bruke farge eller nyanse som meningsbærer, det finnes jo de som har nedsatt fargesyn.
• Fredag: Mobile Friday
  Denne dagen kommer du til å ha en liten skjerm du styrer med fingrene. Surt for deg om noe ikke er responsivt bygget eller om zooming er deaktivert.

Man kan selvfølgelig tilpasse disse dagene etter sine egne målgrupper. Som skaper av nettsteder med primært et svensk publikum er den mest åpenbare justeringen å endre tirsdagen til en «treg 3G-tirsdag» for å simulere all svensk grisgrendt strøk og når nettet blir overbelastet et populært sted.

Grunnen til at dette er viktig skyldes at om brukervennligheten er for lav, fungerer ingenting for brukerne. Det lover ikke godt for at måloppnåelse skal skje på nettstedet.

Hvilke interessenter finnes det og hvilke kompetanser er involvert?

Hvilke interessentene er avhenger veldig mye av organisasjonens størrelse, type og kanskje fremst hvor langt man har kommet i den digitale omstillingen. De vanligste interessentene er de med lederansvar innen ulike fagområder. Som markedssjef, personalsjef, økonomisjef, etc. Vi kommer mer inn på det senere, men det finnes ingen poeng i å begynne å rapportere sine funn til disse personene før man er godt forberedt. Særlig ikke en masse tall – såkalt «data puking». Derimot kan man ta kontakt med dem for å etterspørre virksomhetsmål som finnes innenfor deres fagfelt, om de har noen KPI-er utarbeidet allerede. Om du nå ikke allerede har denne informasjonen.

Jeg hadde tenkt å beskrive hvordan et webanalyseteam kan se ut. Men fortvil ikke, det er nok vanligere enn noen vil innrømme at man knapt har en eneste heltidsressurs på å jobbe med webtilstedeværelsen på en strategisk og analytisk måte.

• Markedsanalytiker – er den som omsetter virksomhetens langsiktige og kortsiktige mål. Jobber med målsetting for kampanjer m.m. Det krever både strategiske og taktiske innsatser.
• Konverteringsoptimaliserer – er den som jobber med hvordan man skal lykkes med å konvertere brukerne, det vil si gjøre lojale brukere av spontanbesøkende og kunder av forbipasserende.
• Teknisk analytiker/webutvikler – jobber med spesifikasjon og kanskje utførelsen slik at det går an å samle inn data, for å senere analysere. Om man ikke utvikler sitt eget nettsted blir denne rollen den personen som finnes nær til hånden for å fortelle hva som er mulig å gjøre samt dokumentere hvordan det skal gjøres.
• Data scientist – en rolle ennå uten norsk oversettelse. Det er en selvhjelpstekniker hvis fremste styrker sitter i å kunne samle inn data, bearbeide den, designe rapporter og skape visualiseringer. Kan trolig en del statistikk og forklaringsmodeller om hvordan data skal se ut.

Utover dette finnes en helt vanlig markedsavdeling, eller kommunikasjonsavdeling om det er innen offentlig sektor. Merk at det ikke inngikk noen webstrateg i denne korte listen og heller ikke noen redaktør. Det skyldes at disse snarere er i den mottakende enden av dette teamets konklusjoner enn at de har noe åpenbart å bidra med. Det er ikke alle som er så rendyrkede i sine roller, men la for guds skyld ikke webanalyse bli utelukkende et spørsmål om innhold. Det som også trengs er selvfølgelig noen som leder denne gjengen, noen som sørger for at oppgavene fordeles og så videre.

Datakvalitet

Hva er det viktigste av alt når man skal analysere noe og fatte beslutninger som påvirker ens fremtid? Temmelig ledende spørsmål, men selvfølgelig er det beslutningsunderlaget det handler om. Om din data er undermålig er det nesten meningsløst å forsøke å trekke noen konklusjoner basert på dem. Det er av ytterste viktighet at noen av dem som jobber med webanalyse innen virksomheten har god forståelse for hvordan ens data samles inn og kan verifisere at modellen stemmer med virkeligheten.

Inspiser dine data og gjør en datarevisjon løpende, slik at du ikke fatter beslutninger på undermålig underlag. Du må vite hvordan din data ser ut og hvordan de samles inn. Dette kan være vanskeligere enn man først tenker seg, derfor er det klokt å føre dagbok med nøyaktige notater for hva man gjør. Særlig om ens innsatser påvirker hvilken data som samles inn. Det kan også være til hjelp om man ved et senere tidspunkt skal kunne gjenskape samme webanalysemiljø. Er du bekymret for din datakvalitet og vil bruke en utprøvd modell, sjekk ut Brian Cliftons bok Successful Analytics⁵ og alt det han skriver i kapittel fire, blant annet om Quality Score.

Noe jeg selv har opplevd er at ulike deler av et nettsted sporet bruken til helt ulike kontoer for webstatistikk. Det innebærer blant annet at når man lenker fra startsiden til en underside, regnes det som separate nettsteder. All ens data blir grumsete og vanskelig å jobbe med. Årsaken i akkurat det tilfellet var av velvilje. Slik at respektive interessent (les siloer i organisasjonen) kunne få sin egen konto med webstatistikk og slapp å se resten av organisasjonen. Det vi tapte var at det ble tilnærmet umulig å få en oversikt over hele nettstedet, noe som nok ville vært mer meningsfullt etter min mening.

Løsningen hadde selvfølgelig vært å dobbeltregistrere bruken av nettstedet. Å spore hver sidevisning primært til en overordnet konto men også til respektive interessents egen konto. Eller om vi hadde kjørt Adobe Analytics kunne vi ha brukt en innebygd funksjon for å opprette en delmengde til de interne interessentene som ville slippe å se alt annet. Sporingen kan fikses i etterkant, men det går ikke å trylle frem tapt data. Derfor er det viktig at man har tenkt gjennom før man begynner.

Et stadig større problem er at brukere blokkerer webanalyseverktøy. Da oppstår en usikkerhet om det er en homogen gruppe du går glipp av i dine forsøk på å nå innsikt, eller om det bare er færre brukere jevnt fordelt over alle de gruppene du kjenner til. En måte å forsøke å finne ut av dette er å begynne å jobbe med logganalyse, en teknikk vi kommer til å se mer på i bokens tredje del.

Filtrering

Filtrering kan gjøres på flere ulike nivåer. Til å begynne med kan du velge å filtrere bort hva som i det hele tatt samles opp for din webanalyse. For eksempel er det vanlig at man utelukker innloggede webredaktører og ansatte fra det som samles inn av verktøy som Google Analytics. I nettopp Google Analytics finnes en måte å filtrere bort visse brukere i etterkant. Dette krever at du skriver en hel del dokumentasjon slik at du i etterkant kan verifisere at filtreringen var korrekt og i beste fall kunne justere den. En variant mange brukte tidlig var å utelukke visse serier av IP-numre, det vil si de internettadressene man som kontorarbeider delte på når man besøkte nettet. Denne metoden trengte selvfølgelig å suppleres da de ansatte begynte å surfe på organisasjonens nettsted via mobilen.

Bilde 3: ai-writer.com har vellykket spammet seg inn på listen med avsendernettsteder.

Et annet problem er å håndtere falske data. Du som bruker Google Analytics har sikkert sett de som forsøker å spamme deg ved å sette avsender-URL i referer-listen. Det finnes måter å forsøke å filtrere bort spammerne, men det gjelder å vite at man ikke skjevvrir sin data slik at den blir ubrukelig. Det finnes en hel del tips om hvordan man unngår spam i sin webanalyse, blant annet at man filtrerer bort alt med feil nettadresse⁶. Men for ikke å gjøre seg bort kan det være klokt å prøvekjøre sine filterønsker først som et segment, mer om segmentering nedenfor. Segmentering endrer ikke data, det gir kun en selektiv presentasjon – som en forhåndsvisning av hva et dataødeleggende filter ville gi.

Dessuten kan man ha visningsfiltre, et høyst midlertidig filter. Det går ut på at du slipper å se visse typer opplysninger i den presentasjonen du har foran deg. En helt annen type midlertidig filter kalles for segmentering.

Om segmentering og hvorfor det er viktig

Dine brukere er ikke en homogen gruppe, det kan man heller ikke forutsette at en enkelt gruppe er. For å utforske variasjonen innen en gruppe bruker man segmenter. En segmentering endrer eller manipulerer aldri datakilden man ser på, noe som filtrering iblant gjør. Segmentering handler om å gruppere brukere etter en eller flere felles egenskaper. Segmenter av brukere er interessante å sammenligne med hverandre. For eksempel hva skiller seg mellom kunder på en mobil enhet fra de med nest siste versjon av Internet Explorer? Kanskje skjuler det seg en mulighet til forbedring i lignende sammenligninger.

Eksempler på interessante segmenter kan være de hvis bruksmønster avslører dem som:

• Jobbsøkere. Hvordan skal man veilede dem videre i nettstedet for å få dem til å sende inn en søknad?
• Potensiell kunde. De er sikkert i en annen fase i hvordan de trenger å bearbeides sammenlignet med en eksisterende kunde. Man kan kanskje ikke gjøre antakelsen at de er uinteresserte i organisasjonens support (akkurat som at ikke alle mobile brukere kun er ute etter kontaktopplysninger), men de trenger nok en annen behandling sammenlignet med stammekunden som har vært overbevist lenge.
• Eksisterende kunde. De trenger kanskje en mer personlig opplevelse og rask tilgang til sine kontaktveier.
• Ens egne ansatte. De egne ansatte har ofte visse forkunnskaper, blant annet om organisasjonen, som utmerker dem. Har du som mål å hjelpe dem på ditt eksterne nettsted, trenger de kanskje litt støtte.

Har du hørt om begrepet personalisering? Det er å tilpasse innholdet basert på individuelle faktorer og hvilket segment en bruker tilhører. I sin absolutt enkleste form er det å tilpasse sitt eksterne nettsted til allmennheten og henvise sine egne ansatte til å bruke intranett i stedet.

Iblant kan du støte på ordet filter, og i visse sammenhenger betyr det samme som segmentering. Skal man være språkpoliti handler kanskje et filter primært om hva som skal bort, men at segmentering snarere beskriver hva som skal være igjen. Tenk det som at du enten filtrerer bort 13 873 typer mobile enheter, eller at du segmenterer din data til å kun vise de brukerne som koblet til med en mobil av merket Fairphone.

Det er merkelig nok ganske ofte man trenger å utfordre den uprøvde antakelsen om at alle ens brukere har lignende behov og at de ligner hverandre. Antakelsen om at alle er i ens målgruppe eller at alle brukere i bunn og grunn er like, pleier å falle når man ser på sine segmenter. Der finnes som oftest en stor variasjon.

Det finnes også ofte et uklart bilde av hvem man tiltrekker. Det er bra å fortelle hvem som bruker det man tilbyr, noe verdt å formidle videre til sine interessenter.

Segmentering går ut på å gruppere statistikken etter felles faktorer. Et segment kan være brukere på mobil enhet, et annet kan være brukere fra Norge. Å aldri jobbe med segmentering er veldig risikabelt, i det minste kommer man trolig ikke til å nå noen som helst innsikt.

Segmentering er en strukturert måte å jobbe videre fra de lavest hengende fruktene når man allerede synes man har inspisert de store datamengdene ut fra et helhetsperspektiv. Ellers vet du ikke for hvem du vil skape en forbedring, og det er dessuten enklere å følge opp en endring om du har en tiltenkt målgruppe – et segment av brukere.

Uten å snø seg inn på statistikk er en advarende finger på sin plass når det gjelder å bare se på statistikken på et overordnet plan, eller å ha uspesifikke virksomhetsmål når det gjelder hvem man sikter til.

Risikoen med å se på gjennomsnittsverdier (og ikke segmentere) er at den gjennomsnittlige verdien ikke alltid er representativ for majoriteten av brukere. At alt ses fra et så gjennomsnittlig synspunkt at det ikke finnes noen meningsfulle konklusjoner å trekke. For å ta et eksempel er det fullt mulig å ikke nå bunnen i en innsjø som i gjennomsnitt kun er en meter dyp. Den verdien sier veldig lite om hvor dypt det er som dypest.

Bilde 4: En normalfordelt kurve. Majoriteten av data ligner gjennomsnittet.

En gjennomsnittlig verdi er bare meningsfull om informasjonen er normalfordelt, eller at den gjennomsnittlige verdien har forutsigbare avvik. Med andre ord er den gjennomsnittlige verdien «10 sidevisninger per besøk» ikke noe direkte meningsfullt verdi om halvparten av brukerne gjør kun én sidevisning og resten nesten 20. Det beskriver ikke virkeligheten. Det interessante er snarere at det finnes minst to vidt forskjellige grupper i disse dataene.

For å bøte på dette og få klarhet rundt hvilke avvikende grupperinger man kan følge, brukes altså segmentering. Da kan man dele opp sine brukere i ulike grupper som kan utforskes separat. Eller om man heller vil sammenligne dem med hverandre. Segmentering handler om å filtrere frem en delmengde av brukerne og se på hvilken måte de presterer, om de skiller seg ut på noen måte. Segmentering går ut på å fange ulikheter og avvik i jakt på forbedringspotensial. Ulikheter i hvordan man oppfører seg, hvor man geografisk befinner seg, hvilke produkter man har sett på, med mer.

Hvilke segmenter er verdt å jobbe med?

De segmentene som finnes ferdige i ditt analyseverktøy er de som er så pass åpenbare at leverandøren tror alle trenger dem. Det er ikke de segmentene som gir deg et konkurransefortrinn om brukernes gunst. Snarere er det de virksomhetsspesifikke segmentene som gjør mest nytte. Disse er kanskje til og med så komplekse at du ikke får analyseverktøyet ditt til å liste dem. Du kan trenge å utvide med flere verktøy.

Når man setter opp sine virksomhetsmål finnes det en poeng i å fokusere på noen enkelte segmenter per gjentakelse av analysearbeidet. I eksempelet ovenfor kunne et slikt segment være at man filtrerer bort brukere som bare gjør én eneste sidevisning for i stedet å se trender i bruk blant de som mer flittig bruker nettstedet. Et annet segment kan være å bare se på de som snur i døren, de som bare gjør én eneste sidevisning. Dette er en gruppe som kanskje er verdt å forsøke å konvertere med en kampanje som bare personer i det segmentet ser. Et segment kan også være dine mest verdifulle brukere. Deres atferd kan være interessant å sammenligne med gjennomsnittsbrukeren.

Som sagt, gjennomsnittsverdier gir ikke alltid et særlig rettvisende bilde av virkeligheten. Iblant er det den femtedelen med størst problemer du skal fokusere på til tross for at majoriteten har svært få problemer. Med webanalyse kan du jobbe med flere samtidige grupper av brukere på en strukturert måte.

Det kan være vanskelig å vurdere hvilke segmenter som er fornuftige, ikke minst når virksomheten ikke har eksistert lenge. Mange ganger kan man trenge å lære kjenne sine kunder, brukere og tiltenkte målgruppe først for å vite hvilke segmenter som er viktigst for virksomheten.

Segmenter er ikke nødvendigvis statiske. Når man er tilbake i refleksjonsfasen i sitt analysearbeid skal man ikke betrakte eksisterende segmenter som hellige. De er bare en logisk oppdeling for å utforske og teste forbedringer. Om virksomheten allerede jobber med personas (karikaturer av ens ulike brukere) kan utviklingsarbeidet rundt segmentering gi verdifull tilbakemelding til hva som utmerker respektive persona.

Som du har forstått ved dette laget trenger det som publiseres på nettstedet å være i tråd med de virksomhetsmålene og intensjonene nettstedet har. I dag holder det ikke med å hevde en allmenninteresse eller behandle nettstedet som ens egen informasjonssøppeldynge bare fordi man liker å produsere innhold. Innholdet må bære frukt!

Metode for kontinuerlig webanalyse

Stadig mer begynner virksomheter på nettet å bli tvunget til å leve opp til de kravene eldre og mer etablerte fagområder har hatt på seg lenge. Å ha et nettsted kan akkurat som på 1990-tallet anses å være noe man har fordi alle andre har det. En stor forskjell fra den gang er at i dag har brukerne betraktelig høyere forventninger. Det duger som oftest ikke med å ønske noen velkommen og gi dem litt kontaktopplysninger.

I dag er et nettsted ofte ganske kostbart å utvikle og vedlikeholde. Gjennom å strebe mot virksomhetens mål også på nettstedet kan man styre sine innsatser og være en del av organisasjonens ordinære virksomhet – og leve etter samme rettesnor.

Straks kommer et forslag til metode for å jobbe med webanalyse. De kommende fire kapitlene beskriver hvert av de stegene som utgjør metoden, hvilke ting man skal tenke på i det stadiet av arbeidet samt eksempler på hva resultatet kan være.

Jeg kan ikke ta hele æren for denne metoden, selv om den kan virke åpenbar for visse personer av mer strukturert natur enn undertegnede. Snarere ville jeg forklare at det er et sammenkok av det jeg har lest om emnet gjennom årene og hvordan jeg selv har jobbet med stadige forbedringer av egne nettsteder.

Kortversjon av metoden

Bilde 5: Begynn med virksomhetsmål, så er du i gang.

Før vi går gjennom metodens deler vil jeg gi en rask oversikt, slik at du i hvert steg vet hva som kommer deretter.

1. Arbeide med virksomhetsmål, KPI-er og måleverdier.
2. Samle inn din data, i mellomtiden du samler inn data utvikler du rapporter.
3. Analysere og kommunisere funnene.
4. Utføre forbedringer på nettstedet.

Hva er da KPI-er? En KPI (Key Performance Indicator) er et målbart mål virksomheten har satt opp for å beskrive fremgang. Merk ordet «key», det finnes også «performance indicator» som innebærer at man har målt opp at noe positivt har skjedd, men at det kanskje ikke er noe som er verdt å styre virksomheten mot.

En KPI kan for eksempel være en gjennomsnittlig ordreverdi, andel tilbakevendende kunder, eller hva som helst som er objektivt bra for virksomheten.

Ikke alle KPI-er gir svar innenfor en runde i denne prosessen, dette fordi det kan kreves ulik lang tid å samle på seg data avhengig av hva du måler. Visse KPI-er kan analyseres sjeldnere, men jeg foreslår likevel at du reserverer tid i kalenderen for respektive moment. Er du på moment tre så analyserer du alt det som på det tidspunktet har samlet på seg tilstrekkelig med data.

Moment 1: Å jobbe med målbare virksomhetsmål

Først og fremst må man ha en rettesnor. Om man ikke vet hvor man skal, er det vanskelig å følge opp at man er på rett vei. Har nettstedet en eksistensberettigelse over hodet? Da Web Service Awards (WSA) i 2015⁷ spurte svenske webansvarlige om hva poenget er med deres nettsted, svarte 27 prosent at det ikke finnes et uttalt formål. På sett og vis fant de et enda dårligere resultat i at kun 54 prosent anser seg å ha et definert formål for nettstedets ulike undersider.

Omtrent halvparten kan altså ikke forklare hvorfor en bestemt underside eksisterer, hvilken nytte den skal bidra med. Uten mål blir det vanskelig å styre sin lykke, eller følge opp arbeidet gjennom webanalyse.

Så skal man huske på at selv om mål er viktige, er de ikke verdt noe om man ikke jobber for å oppnå dem. Da er de helt verdiløse og meningsløse. Det er til dette man har sine KPI-er, de skal motivere en til å følge opp virksomhetsmålene, og dette kan trenge å bli en prosess for å faktisk skje.

Tenk på målene som årsaken til at nettstedet ble bygget fra første stund. Forhåpentligvis fantes det en årsak om målsetting på forhånd, ellers er det på tide å ta tak i det nå. Hva ens mål er varierer naturligvis noe avhengig av hvilken type virksomhet man driver.

Fire typer virksomheter

Jeg så en gang en ganske fornuftig (og veldig kategorisk) inndeling av hvilke typer nettsteder som finnes. Den foreslo følgende grovinndeling, at et nettsted i hovedsak handler om:

1. Handel
2. Innhold
3. Skape kontakter mellom personer, eller mellom organisasjoner
4. Selvhjelp

Fire typer nettsteder som skiller seg mye fra hverandre. Alle gir litt forklaring til at målsettingen kan variere stort mellom organisasjoner og at man definerer fremgang på litt ulike måter. For den som jobber med handel er et mål lettere å forklare om det handler om inntekter, salg eller noe annet med en monetær verdi. For organisasjonen som jobber med innhold, for eksempel mediene, kan man i større grad tillate seg å måle hvor mange i en tiltenkt målgruppe som har sett et bestemt innhold. For kontaktskaperen er det relasjoner alt dreier seg om, og selvhjelperen forsøker å løse konkrete problemer.

Iblant kan man lese hos bransjeskribenter at man bør finne sine «objektivt sanne måleverdier». Ja, jeg har forstått at mange henger seg opp i den termen. Med «objektivt sanne» menes at andre enn du, de du jobber med eller folk innen samme yrkesrolle skal være enige om at deres måleverdier er meningsfulle. At de beskriver om noe av viktighet eller verdi har endret seg.

Hvordan ser et verdiskapende besøk ut? Makro- og mikronivå.

Hvilken verdi skal virksomheten få ut av nettstedet? Det handler ikke bare om hvilke mål man har, de målene må bli målbare. Gjør man et grundig forarbeid kan man komme frem til at man, litt halvveis ullent antagelig, kan knytte noen mål til noe målbart på sitt nettsted. Det er ekstremt viktig å forsøke å komme på hvilken verdi som kan oppstå i og med riktig type bruk av nettstedet. Som vanlig er dette veldig mye enklere om man driver handel på sitt nettsted, det er derfor disse eksemplene stadig tas opp. Dog kan det også i andre sammenhenger, som for en kommune, finnes tydelige måter å relatere sine såkalte e-tjenester på nettstedet til en faktisk verdi. For hver gjennomført byggesøknad som leveres inn digitalt finnes potensielt en uteblitt utgift for kommunen. Men også en gevinst for den enkelte borgeren som kunne fullføre en byråkratisk oppgave på avstand, uten å måtte planlegge inn et avbrekk i hverdagen.

Et annet eksempel jeg ofte trekker er det fra for meg veldig kjente helsevesenet, ettersom jeg tilfeldigvis har jobbet mye innen denne virksomheten. Hva er den oppnådde verdien av en bruker på 1177 Vårdguidens e-tjenester? Om denne logger inn og bestiller fornyelse på en resept? Først og fremst skal man huske at jo mindre tid og tanke en borger trenger å legge på å være i helsevesenets omsorg, eller identifisere seg som pasient, er bra for individet. Å da kunne administrere sin helseomsorg på avstand og på kortere tid er veldig verdifullt. Dessuten, om en person ikke dukker opp i helsevesenet reduseres risikoen for smitte, det blir mindre krav til lokaler eller personell på visse steder.

Man kan dele inn målene i følgende kategorier (viktigst først):

1. Makromål – virksomhetens visjon eller storslåtte planer (engasjerte kunder, oppfattes som tankeledende, attraktiv arbeidsgiver, etc.)
2. Mål – ens KPI-er, eller nøkkeltall på norsk. Altså et absolutt mål for å evaluere fremgang. Vil man dele opp KPI-er kan de beskrive:
   2.1. Fullføring av et mål – brukeren gjennomførte alle delsteg på en vellykket måte. Om et mål er at brukeren skal opprette en konto, er en fullføring-KPI at vedkommende oppretter en konto.
   2.2. Fremgang mot et mål – altså et steg i riktig retning, men at brukeren ikke nådde helt frem. Fremgang ville vært at en forbipasserende bruker velger å lese mer om fordelene med å opprette en konto. Close, but no cigar.
3. Mikromål – målbare delmomenter som gjennom hypotese kan bindes til at en bruker har bekreftet makromålet (som å melde seg på et nyhetsbrev, gått fra en landingsside og havnet på en detaljside). Her skal altså en bekreftet interesse kunne bevises. Et interessesignal som markant skiller en kunde fra noen som bare ser seg rundt og fordriver tiden.
4. Måleverdier, eller metrics på engelsk – de øvrige måleverdiene man samler inn. Ofte mest av nysgjerrighet eller for å støtte konklusjonene.

Det punktet man jobber mest med er punkt nummer to. Det første handler om hvorfor man gjør noe over hodet, det vil si hva det går ut på. Mikromålene og fremgangs-KPI-er handler om å evaluere positive hendelser, men de er mest interessante for å finne trender, som for eksempel om trenden har endret seg etter at man redesignet noen funksjon. Problemet med å putte inn sine mikromål som noe man måler i sitt webanalyseverktøy er at de kan overskygge de «ekte» målene. De viktigere målene inntreffer ikke like ofte men er ultimat det man er ute etter, om ingen noen gang fullfører et mål spiller det liksom ingen rolle hvor mange abonnenter man har samlet inn til sitt nyhetsbrev.

Jeg innser at det kanskje ikke i alle sammenhenger er kjempelett å skille på mål og mikromål, og den eksakte skillelinjen er kanskje ikke direkte avgjørende. Forsøk å holde det til at et mål er det som skiller en genuint engasjert person fra en interessent. Et eksempel kan være mikromålet å lede inn brukere mot de stillingannonsene man har på nettstedet, det gir en indikasjon på at noe av en form for verdi har inntruffet under besøket – det var i alle fall ikke helt meningsløst. For å gjøre forskjell mellom mikromålet om vindusshopping rundt stillingsannonser er et oppfylt mål at brukeren faktisk har levert inn en søknad for en stilling. En bekreftet interesse og et gjensidig mål har inntruffet.

Mikromålene gir indikasjon på interesse, et mål skal bekrefte en form for gjensidig nytte eller måloppnåelse.

Sist, og kanskje minst tross alt, måleverdier. Det er alt mellom himmel og jord du kan være nysgjerrig på, som hvilke kilder dine mest verdifulle brukere kommer fra. Måleverdier er som oftest ikke mål i seg selv, mer som en del av bakgrunnshistorien om de andre målene.

Ranger målene seg imellom

Et alternativ i dette arbeidet er å gi respektive mål en relativ verdi. Si at mål må verdsettes mellom null og ti. Setter du en null i verdi på en ny abonnent på nyhetsbrevet, en syver på en ny registrert bruker og ti ved en gjennomført transaksjon? En masse nuller er fortsatt null i verdi. På denne måten kan du relativisere nytten av en masse likere på Facebook, tusenvis av kontaktopplysninger, massevis med kampanjer og så videre med en annen aktivitet som kanskje skaper brorparten av all verdi (med eller uten hjelp av alt det andre).

Sitter du i stedet i situasjonen at nytten av nettstedet er satt i tvil, kan du jo snu på resonnementet. Dels kan du kontre med hvilken verdi som oppstår på grunn av nettstedet, men også hvilket uutnyttet potensial til forbedring som finnes gjennom å jobbe mer strukturert med webanalyse og lære kjenne brukernes opplevelse.

For å omsette de ulike nivåene av mål er det kanskje på tide med et eksempel. 1177 Vårdguiden, altså Sveriges landstings felles nettsted for å gi helse- og helseinformasjon til allmennheten, kunne ha følgende mål:

1. Makromålet er virksomhetens mål at alle innbyggere som noen gang kan ha behov for kontakt med helsevesenet kjenner til 1177.se og har en konto på 1177 Vårdguidens e-tjenester.
2. KPI-er kan blant annet bli «prosentandel av befolkning i opptaksområdet som har innbyggerkonto», eller fullførings-KPI-er som «prosentandel som lykkes med å gjennomføre hele prosessen for reseptfornyelse».
3. Mikromål er sannsynligvis ganske mange, som at en bruker vindusshopper etter helsestasjon å bytte til, leser om sine rettigheter, etc.
4. Måleverdier blir type enhet som er brukt ved besøk, sted, tid og alt annet som kan støtte eller beskrive konklusjonene.

Dette er jo ikke rakettvitenskap så man kan jo tross alt slappe av noe med vederheftigheten, men å slurve kan straffe seg. Enklest, og trolig klokest, er å bruke de målene, visjonene og slikt som allerede er formulert av virksomheten.

Alle virksomhetsmål er ikke målbare. Men med litt fantasi (og iblant med hjelp av en dyktig webutvikler) kan man ofte komme på en måte å i det minste delvis få et bilde av hvor godt et mål oppnås på nettstedet.

Forsøk å sørge for at de virksomhetsmålene som velges ut – og i visse tilfeller bearbeides for å bli målbare – er slike som man kan agere på. En drastisk endring av måleverdien skal ikke møtes av en lunken interesse eller usikkerhet om det er betydningsfullt.

Tørker inspirasjonen om hva deres nettsted skal levere til virksomheten, kan du fundere på hvilken måte nettstedet kan lette for brukerne og samtidig skape verdi for virksomheten. Ikke glem heller å se etter i virksomhetens visjon, planer og annen dokumentasjon da det muligens allerede finnes definerte nøkkeltall som kan gjenbrukes. Bryt ned hver ting til noe som bør kunne isoleres og måles. En utfordring kan være at de målbare virksomhetsmålene må fungere sammen med de langsiktige målene. Det gjelder altså å forsøke å forutse de langsiktige konsekvensene av de målene man setter opp. Å forsøke å unngå negative sideeffekter. For å se hvordan andre måler sin virksomhet kan du sjekke ut lister på nettet med KPI-biblioteker⁸.

Bilde 6: Apropos å forsøke å forutse fremtidige konsekvenser⁹.

Bilde 7: Denne varianten fungerer ganske lenge.

En annen forklaringsmodell man kan låne for kategorisering av mål er den i reklamesammenheng klassiske AIDAS¹⁰. Det vil si at kundereisens konverteringsprosess består av følgende steg, ovenfra og ned:

• A – Attention
• I – Interest
• D – Desire
• A – Action
• S – Satisfaction

Her forsøker man gjennom reklame og markedskommunikasjon å flytte en kunde steg for steg. En kanskje mer nøytral variant er den som webanalytikeren Avinash Kaushik har foreslått¹¹. En oppdeling av din tiltenkte målgruppe avhengig av hvor i overveielsesprosessen de befinner seg:

1. See – En person som matcher en tiltenkt målgruppe.
2. Think – Person i tiltenkt målgruppe som også er bevisst et behov din tjeneste kan hjelpe med.
3. Do – Person bevisst behov din tjeneste kan hjelpe med, og som også er klar til å handle akkurat nå.
4. Care (altså stelle med kunden eller skjemme dem bort), kalles iblant «Coddle» – De personene som er stammekunder, eller i det minste tilbakevendende som har konvertert mer enn én gang.

Foruten at man trenger å definere målbare måter å følge opp sine mål, blir det med disse modellene åpenbart at man trenger flere ulike typer mål. Antagelig minst ett per kategori. Om du sitter fast i målsettinger som måler en digital motpart til en trykksaks opplag, er kanskje en av disse modellene en forløsende måte å diskutere andre vinkler på målsetting.

I det minste jeg har støtt på webansvarlige som utelukkende har hatt definerte mål som ville havne i See-kategorien ovenfor. Den typen mål er veldig vanskelige å forsvare på sitt eget nettsted da det trolig er årsaken til at brukeren havnet på din nettside – vel på plass finnes ingen målbare mål på hva som utgjør et nyttig eller vellykket besøk.

Det er definitivt utenfor emnet for denne boken, men snakker du med en markedsfører ville de nok nevne ord som kanalstrategi, eller kanskje kanalmiks. Det handler om at ditt nettsted ikke nødvendigvis er involvert i alle deler av konverteringsprosessen. Det kan meget vel være slik at man jobber med eksterne bloggere, kjøper søkeord på søkemotorer eller lignende for å bygge kjennskap. Så skjer kanskje de to siste delmomentene i konverteringsprosessen på ditt nettsted, app, eller en kombinasjon av hva man nå har for kontaktpunkter med personen av interesse.

Utover virksomhetsmålene kan man selvfølgelig ha noe nytte av å jobbe med «forfengelighetstall», som antallet sidevisninger per besøk og lignende. Dog er det vanskelig å vise hvilken verdi som forklarer at resultatet er utvetydig bra eller dårlig. Disse tallene skal ikke være det du legger stor anstrengelse ved da mange sidevisninger (eller lignende) knapt er et etterstrebelses-verdig mål for virksomheten. Disse tallene kan være hyggelige anekdoter oss webnerder imellom, men de gir veldig lite innsikt i hvordan nettstedet blir vellykket.

Eksempler på virksomhetsmål omsatt til målbare mål – KPI-er

• Minst 90 % av de som starter registreringsprosessen skal klare å opprette en brukerkonto.
• Minst annenhver saksanmeldelse til kundestøtten skal gjøres via nettstedets spesialbyggede skjema, samt at færre enn 10 % skal skje per e-post.
• Brukerne skal anse at søkefunksjonen gir relevante resultater.
• Kundene skal anse at det er lett å finne kontaktopplysninger til kundeservice og den nærmeste butikken.
• Minst 90 % av de mobile brukerne skal anse at nettstedet er svært brukbart i et mobilt scenario.
• I det minste 95 % av materialet på nettstedet skal ha blitt gransket/revidert det siste året.
• Samtlige sider skal leve opp til tilgjengelighetskravene i WCAG 2.0 nivå AA.
• Gjennomførte kjøp med kampanjepris skal ha under 5 % returer.
• Minst 25 % av de kundene som er rekruttert gjennom søkeordsannonsering skal gjøre en andre bestilling innen et halvår.

Som du merker i disse eksemplene på virksomhetsmål er de ikke begrenset til statistikk som havner i webstatistikkverktøyet, og det er selve poenget. Enkelte har en terskelverdi, som at minst en viss andel skal anse noe eller klare å oppnå noe. I andre tilfeller mangler et spesifikt mål, og der jobber man i stedet med en stadig forbedring. Hvordan du velger å mikse disse oppleggene er opp til deg.

Du trenger å jobbe både med kvantitative verdier som det du får i nettstedstatistikken og kvalitativ etterforskning som er brukernes subjektive meninger. Og avhengig av virksomhetsmål trenger man også å se på andre systemer eller gjøre egen etterforskning.

Eksempler på bearbeidelse av virksomhetsmål

For å gi deg litt oppspill til hvordan et virksomhetsmål kan bearbeides til noe målbart, følger her noen eksempler. Først ut er det som kanskje er det vanskeligste. Det litt for ullne og abstrakte makromålet. Etter det følger et mer konkret og enkelt målbart mål.

«Vi skal oppfattes som et kundefokusert og kompetent selskap»

Selve formuleringen gjør det tydelig at det handler om et makromål, sikkert finnes noe lignende i flere organisasjoners visjonsdokumenter eller forretningsplaner.

Her er det bare å kapitulere direkte overfor at man ikke kan måle en oppfatning på en kvantitativ måte via nettstedstatistikk. Derimot kan man jobbe med nettstedsundersøkelser – du vet de der boksene som spør om du har et øyeblikk til overs for å svare på noen spørsmål om nettstedet. Gjennomfører man spørreundersøkelser eller annen form for markedsundersøkelse kan man synes man får svar på dette makromålets utvikling over tid, bare gjennom å ganske pågående stille spørsmålet.

Men hvordan pokker får man til det med enkeltes brukeres sesjoner på nettstedet? Jo, en måte er å begynne med å inventere om det allerede finnes innhold som relaterer til målet. Er innholdet dessuten «aktivt», altså at man kan fange opp brukersignaler om deres liking, blir det desto enklere. Mangler man helt slikt innhold trenger man å fundere på om dette virkelig er et mål som bør påvirke nettstedets innhold. Kommer man frem til å skape et slikt innhold trenger innholdet å designes slik at man kan følge opp at mottakelsen/bruken er i tråd med målet. Man trenger altså å finne ut hvordan man plasserer en call-to-action, altså noe som kan registrere målet eller mikromålet som oppnådd.

Call-to-action, ofte forkortet CTA, er et begrep du kommer til å snuble over med jevne mellomrom. En CTA er som oftest en knapp. Knappens funksjon kan være at brukeren liker-markerer sidens innhold, setter en karakter, deler et innlegg i sosiale nettverk, legger et produkt i handlekurven med mer.

Denne typen innhold kan man deretter gruppere via sitt webanalyseverktøy slik at man kan følge dets skjebne og hvordan det mottas. Mikromål, eller fremgangs-KPI rent av, for denne gruppen innhold er om det deles videre av brukere. Eller om sidevisninger på disse sidene er en del av at andre målbare virksomhetsmål innfris. Et eksempel på en vellykket brukersesjon kan være at brukeren kom inn på nettstedet via en landingsside om de kompetansene organisasjonen besitter og at brukeren leverte inn en spontan jobbsøknad på en annen del av nettstedet.

«Vår kommunikasjon skal være forståelig»

Dette makromålet er noe offentlig sektor gjerne har uttalt, man vil ikke tillate seg at det interne fagspråket skal ramme allmennheten. Målet er ikke særlig målbart i nåværende stand, men betydelig nærmere enn foregående. Her snakker man altså om innholdet, nettstedets budskap, og at det skal passe den tiltenkte målgruppens språkkunnskaper.

Bilde 8: Har du prøvd å søke etter ting du ikke vil skal finnes på ditt nettsted?

Hvordan finner man ut om man er forståelig? En måte er å jobbe med innholdsanalyse. De fleste nettsteder har allerede en søkefunksjon, og enhver kompetent søkefunksjon har et indeks med alt den vet om nettstedet. Dette indekset kan man inspisere for å finne kjente språklige avarter og rette dem. For å over tid holde kontroll på vanlige dumheter kan kanskje en utvikler opprette et tillegg som utfører søk på alle «dårlige ord», der man håper på å ikke få noen treff.

Har man en søkeredaktør er det dennes oppgave å sjekke språkbruket med jevne mellomrom. En søkefunksjon er sjeldent god på å vise hvor dårlig det er stelt med det innholdet som finnes.

Når det gjelder søkefunksjoner kan man også ta tak i den dårlige samvittigheten med søkeanalyse (noe som har fått et helt eget kapittel senere i boken). Den mest åpenbare nytten med søkeanalyse er å se på de vanligste søkespørsmålene og hvor godt de matcher ord som brukes på nettstedet. Når noen ikke finner kan de forsøke å søke etter det. Det som gjør søkefunksjonen unik i sammenhengen er at der får du vite hva brukeren anser at noe heter.

Selv om debatten om «dagis» kontra «förskola» aldri kommer til å ta slutt, er det viktig å jobbe med synonymhåndtering og strukturere innhold på en måte slik at brukeren har en sjanse til å finne. En relatert KPI er antallet nullresultater i søkefunksjonen, altså når det ikke finnes et matchende innhold. Det har iblant med språkforbistring å gjøre. Som kommune trenger man å sørge for at søk på «dagis» også gir treff på «förskola». Kanskje finnes tilsvarende forskjell i språkbruk også i din bransje?

En annen KPI er hvilket nivå av lesbarhet man streber etter. Det finnes flere metoder for å måle dette, hvorav ingen av dem kommer til å imponere en språkviter. En er lesbarhetsindeks (LIX, test selv på nettet¹²) som forsøker å angi hvor avansert en tekst er. Lesbarhetsindeks er ingen perfekt metode, men kan indikere en teksts kompleksitet. Til forskjell fra å dele ut lathunder til webredaktørene er LIX noe som er målbart for å se om trenden går mot mer komplekse eller enklere setninger.

En ytterligere variant, men for engelsk tekst, er Flesch reading ease¹³ som gir en pekepinn om teksten risikerer å være kompleks. Heller ikke her er metoden eksakt nok til å begynne å lønnssette redaktører etter karakteren, men det er kanskje likevel verdt å overvåke hvordan tekstene utvikler seg, om det skiller seg mellom ulike grupperinger av innhold. Si at man bygger et verktøy som analyserer dette, da blir det interessant å evaluere om enklere tekster presterer bedre eller dårligere enn komplekse. Les mer om A/B-tester senere i boken, men det går an å evaluere om en variant er å foretrekke.

«Våre skandinaviske kunder skal oppfatte oss som et skandinavisk merke»

Bilde 9: Zlatan og en Volvo i et vinterlandskap (kilde: Volvo Cars).

Jeg har aldri hatt innsyn i hva tidligere svenskeide selskaper setter opp for mål når de slutter å være eid eller styrt fra den verdensdelen der de en gang startet. Tenk Volvo Cars, eid omsom av amerikanere, omsom kinesere, men går ut i en omfattende reklamekampanje om at de er «Made by Sweden». Man kan jo mene hva man vil om slikt, men budskapet og hva de vil at folk skal tro om merket Volvo er jo utvetydig – Volvo er svensk!

Together with Zlatan Ibrahimovic we have done a celebration to Sweden. It's our country's unique nature that inspires and challenge the people at Volvo when they develop their cars. It's also here, at home, in the magnificent wilderness that they find their strength. Just as Zlatan does.
- Reklamebyrået F&B i sin beskrivelse av oppdraget¹⁴

Men hvordan måler man om folk tar til seg et slikt budskap, og om det finnes visse brukersegmenter der man kan trenge å jobbe litt ekstra? Det er her kvalitative metoder kommer til nytte. Intervjuer av ulike slag, spørreundersøkelser, gerillatesting i venting på morgenkaffen på nærmeste kaffested.

Det er som du har forstått ikke særlig meningsfullt å gjøre denne typen innsats en eneste gang. Hva skal man gjøre av kunnskapen om at 72 % anser noe? Det er selvfølgelig slik at en verdi oppstår gjennom en endret oppfatning, og ved et visst tidspunkt trenger man kanskje bare å vedlikeholde den posisjonen man er tilfreds med.

Det finnes noen holdepunkter når man utformer spørsmål å stille til sine brukere. Som man spør, får man svar. Jeg pleier ofte å eksemplifisere med hvordan man tror det svenske folk ville svare på spørsmålet «Synes du at Sveriges statsoverhode bør være demokratisk valgt?». Det er et ledende og samtidig villedende spørsmål da mange som vil beholde monarkiet kommer til å svare ja, men gjennom sitt svar angi at de vil si avsette kongen som statsoverhode.

Denne typen problemer er veldig vanlige om man slurver med sine spørsmål, men også når det gjelder hvilke svaralternativer som gis. Noen som jobber mye med dette er mediene, og Sveriges Radios Ekoredaksjon har utarbeidet en helt utmerket sjekkliste¹⁵ som belyser vanlige problemer med spørreskjemasvar. Man skal kunne svare ja på syv spørsmål, nemlig:

1. Er utvalget tilfeldig? Ellers risikerer feilmarginen å bli veldig stor.
2. Har tilstrekkelig mange svart? For generelle generaliseringer trenger man normalt 1000 svarende, eller om det nå er en mindre gruppe bør man kanskje spørre alle.
3. Har tilstrekkelig mange av de spurte stilt opp? Er det under 60 % er det på tide å bli bekymret for om de som lot være å svare kanskje ville svart annerledes enn de som stilte opp.
4. Er undersøkelsen gjort per telefon, via brev eller gjennom besøk? Akkurat Ekot godkjenner ikke webpaneler, men også spørreundersøkelser på nett kan være tvilsomme om man ikke kan vise til at de svarende er utvalgt tilfeldig.
5. Er endringen du vil fortelle om statistisk sikker? Den berømte feilmarginen kan spille deg et puss.
6. Kan du stole på avsenderen? I sammenhenger som på nettet gjelder det å være spørrende rundt hvordan innsamlingen av data har foregått. Om du har en tredjepart som hjelper til, gjelder det at man stoler på at de vet hva de holder på med og gir deg korrekte opplysninger.
7. Er spørsmålene nøytrale og vettig stilt? Den som formulerer spørsmålene kan uvitende komme til å avsløre sin egen mening gjennom hvordan spørsmålene stilles. Spørsmålets formulering kan påvirke svaret man får. Et spørsmål skal være nøytralt og uten verdivurderinger.

Men som nevnt tidligere, dette er ikke rakettvitenskap, vær årvåken på hvilke konklusjoner du baserer på data med mindre nøyaktighet. Gjør ingen storslåtte endringer basert på en statistisk ikke-sikret andel av respondentene. Vil du virkelig være på den sikre siden (og bruke massevis med tid) så spør en statistiker hva hen anser om din metode…

Målbare verdivurderinger og kvalitetskrav

Foruten virksomhetens mål finnes andre ting man vil følge opp, altså de måleverdiene man har prioritert. Det kan handle om hvordan man forventer at nettstedet skal fungere for å være representativt for virksomheten. Dagens Nyheter hadde en artikkelserie høsten 2015 der de påpekte på hvilke måter svensk offentlig sektor lot tredjeparter, som Google, Facebook, m.fl., lytte inn når borgere brukte nettstedene. I visse ekstremtilfeller var tredjepartene organisasjoner som ikke la skjul på at de solgte opplysningene videre. Å da ha med dem på sider som omhandler seksuell legning, seksuell helse, etnisitet eller andre sensitive personopplysninger var selvfølgelig ikke bra i det hele tatt.

Bedre er om man er på det rene med hvilke verdier man har og hva de kan tenkes å innebære for utformingen av nettstedet. Dessuten finnes det en rekke kvalitetskrav man bør stille til seg selv samt gjøre løpende oppfølginger slik at det i alle fall ikke blir dårligere jo lenger bort lanseringsdagen er i bakspeilet.

Hva som forventes av et moderne, effektivt og nyttig nettsted som følger god praksis er foranderlig. Dette stiller krav til å ofte gjøre etterforskning. Siste delen i boken tar opp en lang men virkelig ikke komplett liste med aktiviteter man kan begynne å se på for å få oversikt over situasjonen.

Utover ovennevnte måleverdier finnes det også de måleverdiene som forteller brukerens historie og lar deg få innsikt i brukeropplevelsen. Så vel deres frustrasjoner som fremganger. Som du har skjønt ved dette laget er dette ikke målsettinger med nettstedet, men de er likevel viktige for å ha et komplett bilde av hvordan nettstedet fungerer og kan optimaliseres. Også disse målene skal du ha med deg gjennom denne metoden for webanalyse.

Nedenfor har du et forslag til punkter for å snakke gjennom med webteamet og med leverandører:

1. Skal vi bruke eller i det hele tatt tillate tredjeparters innholdsnettverk? Selv om man kanskje ikke kommer til å være helt konsekvent i dette, er det bra å dokumentere hvilke unntak man kan tenke seg å gjøre. Mange kommer sikkert frem til at de uansett hva vil bruke Google Analytics, men at man ikke tenker å designe nettstedet slik at det har med flere aktører. Midlertidig kan man sikkert putte inn verktøy for å følge opp brukeropplevelsen, få hjelp av tredjeparter på enkeltsider for å utføre A/B-tester med mer. Det viktige er å gjøre et aktivt valg.
2. Hvilke hygienefaktorer/kvalitetskrav er prioritert? Sjekk siste delen i boken for en rekke forslag, men du kommer trolig på flere. Disse kan man dokumentere i noe som kalles stilguide, et emne vi kommer til å behandle i neste del av boken.
3. Hvilke kompromisser er avtalt, og hvilke forbedringer er planlagt? Dokumenter gjerne hvilke punkter man skal leve opp til med den første innsatsen av nettstedet. Det kan jo være slik at man av budsjettgrunner eller lignende trenger å skyve visse krav til fremtiden. Dette er en plan for nettstedets kontinuerlige forbedringer og hvordan man kan måle at planen er oppfylt.
4. Bli enige om hva som skal inngå i en nullmåling! Om man ikke allerede har gjort en nullmåling, eller en måleplan med historiske sammenligningsverdier, er det på tide å begynne med dette.
5. Lag en representativ «testside» som er den samme etter hver oppdatering av nettstedet! Denne skal IT-utførere, utviklere og konsulenter avstemme sine leveranser mot for å vise at deres bidrag ikke forverret kvaliteten, snarere bør man forvente forbedringer.
6. Ha dokumentert buy-in fra alle leverandører! Om man skal gjøre det høytidelig eller formelt er opp til deg og hvordan forholdet ser ut med de som bidrar til nettstedet, men det er viktig at alle er innforstått med de forventningene som finnes.

Sjekkliste for et godt virksomhetsmål for webanalyse

Det finnes en rekke kriterier som peker på at de virksomhetsmålene man har valgt ut er relevante, nemlig at:

1. Det finnes en uttalt interessent. Vet man ikke hvem som burde bry seg, er det ganske fåfengt å begynne å måle.
2. Interessenten kan bli interessert i en markant endring. Om en større endring av måleverdien/KPI-en møtes av en skuldertrekning, kommentarer som «og hva så?» eller uforstand, har du et problem.
3. Måleverdien har påvirkning på virksomhetens måloppnåelse. Har den lite med virksomhetens vei til fremgang, er den ikke en «Key» Performance Indicator.
4. Går å agere på. En måleverdi/KPI trenger å være relatert til noe konkret, som at ved et visst nivå er det ikke lenger lønnsomt å fortsette reklamekampanjen på et bestemt sosialt nettverk. Eller at en del av nettstedet ikke lenger bidrar til virksomhetens mål, at ytterst få verdiskapende brukere drar nytte av det innholdet. Det finnes også informative måleverdier/KPI-er, men de er sjelden særlig interessante til annet enn å forstå sin bruker.
5. Forårsaker ikke negative sideeffekter. Et godt mål er gjennomtenkt nok til at det ikke oppstår problemer et annet sted i virksomheten. For eksempel at et økt salg mest forårsaket merarbeid, flere returer og kunder som følte seg lurt.

Tenk også på at ytterst få bryr seg om tallene! De vil høre innsikt og anbefalinger som er underbygget av innsamlede fakta – ikke en masse tall eller data-prat. Repeter ditt fremlegg på forhånd, avstem rapporten din med en kollega og gjør ytterligere forberedelser, før du forhåpningsfull tar kontakt med ledelsesfolk.

Moment 2: Utarbeide rapporter og metoder for kommende analyse

I moment to er det på tide å begynne å jobbe med hvordan data skal samles inn, hvordan kvaliteten på innsamlingen skal bli god nok og hvordan man skal presentere det. Som allerede nevnt handler rapporter i større grad om tekst enn tall. Selv et fåtall visualiseringer kan være overveldende første gang noen utenfor webteamets kjerne tar del av innholdet. En rapport skal være en fortelling som mottakeren kan huske og fortelle videre!

Begrepet rapport er deilig diffust. Det jeg mener med det er egentlig ikke så komplisert, det handler om hvordan noen skal kunne ta del av det som er inspisert. Iblant kalles det for dashboard (som nok tilsvarer norsk «kontrollpanel»). Det er kanskje ikke mer komplisert enn at man oppretter en ny fane i et Excel-ark der man dokumenterer resultatet av arbeidet.

Bilde 10: Eksempel på dashboard med mange faner, fra Länsstyrelsen i Örebro.

Jeg har gjennom årene sett massevis av ulike måter å bygge opp rapporter. De fleste har vært bra. Det man trenger å tenke på er hvem man henvender seg til. Hvem skal ta del av rapporten og hvilke aktiviteter man håper det skal foranlede. Vi som jobber med å samle inn data, eller vader i nettstedstatistikk dagene i enden, tror kanskje at vi kan agere på data, men antagelig lyver vi for oss selv. Troligvis bygger vi en historie om den dataen vi kontinuerlig mates med, og så reagerer vi automatisk på de avvikelsene vi oppfatter.

En person som sjelden ser samme statistikk opplever derimot at vi spyr ut en masse tall om vi ikke forteller den innsamlede dataens historie snarere enn redegjør for tall. Det kan være lett å glemme. Så lett at det på engelsk har fått et navn – data puking :)

Så det første steget er selvfølgelig å finne ut hvem som kommer til å ha nytte av den informasjonen vi skal samle inn og senere rapportere. Hva har de interessentene for forkunnskaper innen statistikk, web og teknikk? Har man ikke tenkt å tilpasse seg etter interessentene, er det ganske meningsløst å jobbe med webanalyse. Det er jo de som kan hjelpe deg å få gode ting til å skje basert på de bevisene du graver frem.

Bilde 11: Eksempel på verktøy der interessenter selv kan inspisere innsamlede data.

To grunnleggende former for rapportering er om du kommer til å sende dem en sammenstilt rapport i etterkant eller om de trenger å få løpende innsyn. Her er forskjellen også om interessenten vil ha et skrivebordprodukt å ta med på et styremøte eller om de selv aktivt vil følge utviklingen på nettstedet i sanntid. Mest trolig er det at du til slutt kommer til å ha en kombinasjon av begge.

En grov oversikt for arbeidet i dette momentet er følgende:

1. Samle inn data.
2. Vurder kvaliteten på innsamlede data.
3. Foredle innholdet, altså vask det til slik at det er klart for kommende arbeid. Det kan handle om å konvertere geografiske posisjoner fra et format til et annet.
4. Miks inn flere datakilder og dimensjoner. Si at du utvider geografiske posisjoner med gjennomsnittlig ordreverdi.
5. Forprosessering. Arbeid frem modeller for hvordan man skal kunne trekke konklusjoner på potensielt kjempestore datamengder. Kanskje trenger man å gjøre innholdet enklere å jobbe med?
6. Filtrer ut den dataen du trenger. Det kan handle om å bare samle på seg eller sammenstille data om et bestemt brukersegment.
7. Utforskning, visualisering og dataanalyse. For å vite at du har riktig innhold og verifisere alle tidligere steg kan visualisering og generelt utforskende av datamengden være klokt.

Merk gjerne også at din data blir mer verdifull etter hvert steg, det er litt av en foredlingsprosess. Kjører man som generalist fast kan det være en trøst å vite at det finnes ekspertise innen hvert delmoment. Jobber du innen en større organisasjon finnes sikkert denne ekspertisen internt, ellers pleier folk å være uventet hjelpsomme når man hører av seg på sosiale medier (med korte spørsmål).

En ny yrkesrolle som begynte å vokse frem rundt 2015 kalles for data scientist. Det er altså en mangesysler som er god på statistikk, tekniske systemer og som kan hjelpe seg selv med å få teknisk arbeid gjort selv om datakilden er veldig stor. Utover disse kan man trenge å snakke med de som kan innholdet på et nettsted, men gjerne også en webutvikler for å få oversikt over hvordan det skal foregå å samle inn sin data på riktig måte. Sitter man trangt til er det en utvikler i største allminnelighet man er ute etter.

Iblant kan det nemlig kreves at man gjør justeringer i sin tekniske plattform. Utover virksomhetsmålets egne data er det bra å samle inn data som forteller historien rundt virksomhetsmålet – du vil jo gjerne vite hvorfor noe ble bedre, ikke bare at det skjedde.

Å samle inn data kan være vanskelig

Bilde 12: Hvordan logger man automatiske feilmeldinger på et nettsted?

I teorien er det sikkert enkelt å samle inn den dataen man er interessert i. Men jo større det tekniske miljøet blir, desto flere komplekse komponenter hjelper til for å tilby et nettsted. Der jeg jobber, i landstinget, er vi sikkert et ekstremt tilfelle i og med at våre tekniske systemer har en stor beskyttelsesverdi da vi håndterer ytterst sensitive personopplysninger, så hos oss er det ikke alltid gitt at vi vil dra nytte av all den dataen vi har. Samme problem finnes nok hos de fleste, om enn i mindre skala, nå som praktisk talt alle organisasjoner begynner å sette stor verdi på innsamlede data.

Litt avhengig av hva man har for virksomhetsmål kan man trenge å grave i denne nærmest uendelige tekniske kompleksiteten. Aller verst er det når man i detalj vil vite hvorfor et avvik inntraff. Disse datakildene er primært relevante når du i etterkant vil kunne gjøre etterforskning i hvorfor folk forsvant rett før de fullførte et virksomhetsmål på nettstedet.

På min arbeidsplass har det hendt av og til at viktig innhold har havnet i publiseringssystemets papirkurv. For at en side som har havnet i papirkurven skal vises for en ikke-innlogget bruker, havner man på innloggingssiden for publiseringssystemet. Den siden logges ikke i vårt tilfelle av nettstedstatistikken. Altså forsvinner brukere ut i et sort hull, webanalysemessig, og vi taper helt oppsynet med brukerens opplevelse.

En måte som mange nettstedstatistikksystemer tilbyr for å fange opp slikt som ikke er en vanlig sidevisning kalles for hendelser og virtuelle sidevisninger. Det går ut på å bak kulissene registrere at noe inntraff, bra eller dårlig. På mange måter er det praktisk å kunne samle inn signaldata i samme plattform som sin nettstedstatistikk.

Om man nå ikke lykkes med å påvirke diverse feilsider slik at de registrerer brukeren i den vanlige nettstedstatistikken, blir analytikerens tilgang til tekniske logger helt avgjørende. Når det gjelder vanskeligheten med å samle inn data er det for arbeidets troverdighet viktig at man kan svare på spørsmålet om hvordan ens data ble samlet inn, hvilke faktorer som påvirker, og så videre. Det kan være fornuftig å dokumentere hva som utgjør en virtuell sidevisning, når man velger å registrere det som hendelser i stedet, og så videre. Det er kanskje ikke så viktig nøyaktig hvordan man velger å gjøre det, bare man er konsekvent, ellers kan man selv forårsake uønsket variasjon i sin egen datakilde.

Nettopp logganalyse kan komme til å få et oppsving. Det var hva vi brukte i gamle dager på nettet ettersom ikke mange nok hadde støtte for Javascript i sine nettlesere. I dag er problemet snarere at mange brukere blokkerer verktøy for webanalyse for å verne sin integritet. For den store massen dukket dette opp høsten 2015 da Apple slapp iOS 9 som hadde støtte for såkalte content blockers. Disse gjør at man kan blokkere Google Analytics, Matomo, og de fleste andre verktøy som forsøker å ha kontroll på hva brukeren gjør på et nettsted.

Til å begynne med var det mest obskure eller ukjente avsendere til disse blokkererne. Men etter noen måneder kom den åpne og rimelig troverdige organisasjonen Mozilla ut med Focus by Firefox. Plutselig fantes et åpent alternativ uten kommersiell eller skjult baktanke.

Selv før disse innholdsblokkerne fantes innebygd i Apples mobile system har det selvfølgelig eksistert spesielle nettlesere. Og for datamaskiner har annonseblokkere eksistert veldig lenge – de kan brukes også mot verktøy for webanalyse.

Bilde 13: Focus By Firefox gjør det lett å blokkere diverse overvåkning.

Forekomsten av denne typen verktøy er verdt å tenke på når du utformer din innsamling av data. Kommer det verktøyet du velger til å forårsake at alle disse brukerne ikke kan bruke nettstedet? Det kan være nok til at man går konkurs om man har skikkelig uflaks. Min anbefaling er at du selv prøvekjører disse blokkeringsverktøyene og nøye følger hvilken innvirkning de kan ha på ditt nettsted, hvordan de påvirker de verktøyene du velger å bruke. Du har kanskje selv opplevd at det ikke går an å scrolle nedover på et nettsted? Det har i alle fall jeg. Spørsmålet man bør stille seg er, hvor sannsynlig er det at det fåtallet som finner ut at det skyldes deres innholdsblokkerer faktisk velger å gjøre noe med det. Kanskje er det mer sannsynlig at de strunter i det og besøker en konkurrent i stedet?

Konklusjonen av ditt arbeid rundt innsamling av data er at du trenger å sjekke at du har et noenlunde komplett bilde av hva som kan skje for de brukerne som besøker ditt nettsted. Gjør en inventering av hvilke systemer som bidrar til å vise de sidene som kan nås og sjekk at du har innsyn i respektive system. Innen en større organisasjon kan det typisk handle om at man blant annet har følgende systemer som bidrar til nettstedets innhold:

• Selve webpubliseringssystemet, sitt CMS, der redaksjonelt materiale håndteres.
• Et separat dokumenthåndteringssystem (ECM – Enterprise Content Management) for å holde orden på dokumenter, brosjyrer, blanketter med mer.
• En bildebank som ligger i et bildehåndteringsverktøy – et såkalt MAM (Media Asset Management).
• Videoklipp, eller skrifttyper og tredjepartsfiler som ikke er unike for organisasjonen ligger på et innholdsnettverk (CDN – Content Delivery Network) for å gjøre overføringen raskere.
• Diverse spesialløsninger fra eksterne aktører som leses inn via den, unnskyld min rettframhet, komplett verdiløse teknikken Iframe, altså et lite tittehull i siden som leser inn innhold fra en tredjepart.
• Tredjeparter som via API-er bidrar med valutakonverteringer, kortbetalinger eller innhold som aktuelle produkttekster.

Dette trenger man å ha kontroll på. Om ikke annet får man det så fort man begynner å etterforske hvordan det kommer seg at det ser ut som det gjør (eller hvorfor noe ikke ser ut til å fungere som det var tenkt). Det er iblant en interessant utfordring å lykkes med å måle en brukers reise mellom flere ulike systemer, men ofte kommer man langt med å registrere en virtuell sidevisning før nettstedet sender brukeren videre for eksempel til dokumenthåndteringssystemet.

Verktøy for analyse

Det finnes veldig mange verktøy for å jobbe med webanalyse. Dessuten kommer det nye hele tiden. Enkelte er små løsninger som hjelper til med enkeltstående oppgaver, som å bygge opp rapporter, andre er store miljøer som tilbyr deg og interessentene en ganske komplett visning over nåsituasjonen.

Mest kjente typen verktøy er de som hjelper til med nettstedstatistikken. Størst er nok Google Analytics, men Adobe tilbyr en motpart i sin Adobe Analytics som har sine styrker. For den som ikke vil blande inn tredjeparter finnes Matomo. Det er en åpen kildekode-løsning som man kan installere på sitt eget nettsted og da verne om den personlige integriteten. Den bruker vi på min arbeidsplass, og nå i et samfunn, post-Snowden, er det nok stadig flere offentlige aktører som begynner å interessere seg for Matomo.

Disse verktøyene viser egentlig bare den mest åpenbare informasjonen. Altså klikkstrømmen på ens nettsted. Hvor kom brukerne fra, hva gjorde de og skjedde det noe av verdi? Disse verktøyene tilbyr visninger av informasjon som er veldig allmenngyldige. Slikt som er så åpenbart at alle nok kan ha nytte av dem. Det du trenger for å ha kontroll på akkurat ditt nettsted trenger du kanskje å finne ut selv og supplere med?

Det finnes stadig flere verktøy for å hjelpe seg selv med å analysere innsamlet informasjon. Et verktøy jeg har hatt en del nytte av heter Tableau. Det er en måte å utforske den dataen man har samlet inn med håpet om at avvik og mønstre kan gi meg innsikt i hva som kan forbedres for å gjøre nettstedet litt-litt bedre for brukerne. Her finner man nye visninger over den dataen man har samlet på seg. Det kommer jo litt an på hva målet man skal måle handler om eller hvilken type data man ser på. Senere, i den mer avanserte delen av boken, kommer vi til å gå gjennom noen av de nyttige verktøyene som finnes men som blant mange av oss har havnet i skyggen av nettstedstatistikksystemer som Google Analytics.

Det finnes en rekke velbrukte teknikker du kan se på for hvordan rapportene dine kan utformes, og straks kommer vi til å gå gjennom noen av de mulighetene som bys. Det kan være nyttig å ha en webutvikler til hånden inntil du selv vet hvor komplisert ens løsning blir å realisere i det systemet nettstedet kjører på.

En stor del av nytten med rapportarbeidet og metoder er den lærende prosessen. Å arbeide med hvilken nytte man skal strebe mot, å lære kjenne sine brukeres atferd og behov er noe som gjør at hver gjentakelse av dette arbeidet begynner på et nytt høyere nivå.

Enda et begrep du trenger å ha kontroll på er CTR (Click Through Rate), som på norsk pleier å oversettes til gjennomklikkfrekvens. Det angir hvor stor andel av brukerne som valgte å klikke på en bestemt lenke i et søkeresultat, eller følge den call-to-action som finnes på en side de har besøkt. Målet er å ha en høy og forutsigbar CTR da det betyr at brukeren forstår hva den får servert og aksepterer å fortsette mot målet.

Omvandlingstrakt (conversion funnel på engelsk)

Bilde 14: Stort tap i første steg, nesten ingenting i siste. Fra Google Analytics for 1177.se

Den metoden som antagelig er vanligst når det gjelder å rapportere måloppnåelse er å bruke en omvandlingstrakt. Den egner seg spesielt godt for å visualisere hvor stor andel av brukerne som faller fra i en prosess med flere delmomenter. Man definerer et startpunkt og så måler man hvor høy gjennomklikkfrekvensen er på hvert delmoment – altså hvor mange brukere man mister på veien mot målet.

Har man lav gjennomklikkfrekvens kan det blant annet tyde på at man trenger å forbedre brukervennligheten i det momentet der mange brukere forsvinner, eller så er ikke neste steg lokkende nok for brukeren. Om man ikke i det hele tatt har jobbet med omvandlingstrakter kan man få et sjokk første gangen. Kanskje finnes et enormt forbedringspotensial i å redusere andelen frafall på et enkelt steg i en flertrinnsprosess mot et felles mål.

Tenk deg at virksomhetsmålet for et intranett er at minst 90 % skal klare å sende inn sin fravärssøknad. Om da 25 % av dem forsvinner ved første delmomentet, får man forsøke å finne ut hva det skyldes, eller muligens komme frem til et rimeligere mål.

Det er av interesse å segmentere ut de brukerne som ikke fullfører alle steg i en omvandlingstrakt for å lete etter mønstre. Finnes det noen fellesnevnere for hvor de hopper av? Hvor de tar veien? Er det muligens en utydelig call-to-action som gjør at brukerne ikke forstår hva de forventes å gjøre for å komme videre?

Det trenger ikke nødvendigvis å være mange delmomenter for at en omvandlingstrakt skal være egnet som visualisering når du rapporterer webanalysens resultater til dine interessenter. Et enkelt eksempel på omvandlingstrakt kan være hvor stor andel som etter et nettstedssøk faktisk klikker på noen av treffene. Det kunne være en av flere måter å evaluere om en forbedret relevansmodell for søkefunksjonen har vært vellykket. Det en omvandlingstrakt kan fortelle, til forskjell fra gjennomklikkfrekvens, er hva de vanligst brukte utgangene er.

En omvandlingstrakt begrenses ikke til ens nettsted, men kan meget vel være målestokken for gjennomslag for nyhetsbrev per e-post eller til og med noe i den fysiske virkeligheten.

A/B-testing for å sammenligne to ulike alternativer

Bilde 15: A/B-test er å likt en vippe sammenligne alternativ A mot alternativ B.

A/B-testing er en metode for å se hvilket av to alternative måter å utforme noe som fungerer best på ekte brukere. Dette er forhåpentligvis en prestisjeløs test av folks hypoteser for å se hva som fungerer best. Det er litt av en konkurranse som kjøres under en begrenset tid gjennom at alternativ A og alternativ B slumpes ut til brukerne. Etterpå inspiserer man hvordan de to alternativene presterte og om man kan kåre en vinner som får tilliten til å fortsette å finnes (inntil en ny utfordrer dukker opp).

Det kan være et utmerket (og ufarlig) forslag når noen pågående person foreslår en bestemt endring. Helt avvæpnende utbryter man at det er et utmerket forslag som man er ivrig etter å evaluere om det fungerer på levende brukere :)

Med en A/B-test skal man forsøke å besvare tre spørsmål; hvem, hva, og hvorfor.

• Hvem er det endringen retter seg mot? Det er altså et bestemt segment av brukerne, med andre ord en delmengde som har noe bestemt til felles.
• Hva i brukernes atferd håper man skal endres? Det kan for eksempel handle om at flere velger å skrive en produktanmeldelse på nettstedet etter et gjennomført kjøp.
• Hvorfor burde endringen skje? Det trenger å finnes en testbar hypotese om hvordan målet/forbedringen kan oppnås, noe som oftest er en endring i design.

Eksempel på en A/B-test for et nettsted er at man på segmentet brukere som kobler til via en stasjonær datamaskin kontrollerer om en høyrekolonne med ekstrainformasjon fungerer bedre sammenlignet med å legge materialet under artikkelens brødtekst.

A/B-testing kan virkelig gjøre en forskjell. Et av de mer inspirerende eksemplene jeg har hørt er da Obamas presidentvalgkampanje i 2012 gjorde A/B-test for å finne den beste måten å få inn så mye donasjoner som mulig. Etter at de hadde gjennomført 240 stykker A/B-tester¹⁶ hadde de økt konverteringsgraden med 49 %. Lykkes man med den nivået av optimalisering kan det gjøre virkelig stor forskjell.

Tilfeldig utvalg til testgruppe og kontrollgruppe

Tenk på at det kan være forvirrende, og kan forringe testens kvalitet, om man som bruker får ulike versjoner under testperioden. Forsøk å designe testen slik at man konsekvent viser det ene alternativet for en bestemt gruppe brukere. Dessuten er det å foretrekke at utvalget er tilfeldig. Det kan være gjennom at man skiller brukerne gjennom deres geografiske plassering, rangering i verdikjeden eller kanskje avhengig av om det er deres første besøk eller ikke. Utover det slumpes det om man inngår i testgruppen eller kontrollgruppen. Om man får det nye forslaget eller det eksisterende, alternativ A eller B.

Grunnen til at man vil ha dette halvt vitenskapelige opplegget er for at man skal kunne trekke konklusjoner basert på troverdige data. Dersom du har tilstrekkelig mange brukere å teste på, si 5000 brukere, velges 2500 ut tilfeldig til testgruppen – de som man prøvekjører et nytt designforslag eller tekst på. Når testperioden er over sammenligner man testgruppens og kontrollgruppens resultat, hvilken gruppe var mest vellykket i forhold til det målet man ville oppnå? Om forskjellen mellom de to gruppene er større enn forsømmelig, har man funnet noe. Men det kan absolutt være slik at man kommer frem til at det gamle designalternativet fortsatt fungerer best.

Selv om testen kommer frem til at de to alternativene presterer omtrent jevnbyrdig, har man lært seg hvilket slingringsmonn man har og kanskje våger en mer drastisk endring til neste test.

Ting du kan ønske å teste er blant annet:

• Ulike layouter, som om det fungerer bedre med en sidekolonne på brede skjermer eller om den skal plasseres under selve artikkelen. På denne måten kan du undersøke fenomenet «banner blindness».
• Mikrokopi, for eksempel hvilke knapptekster som fungerer best for å dels få et klikk men også for at brukeren skal fullføre hele prosessen – forlatte handlekurver har ingen egentlig verdi.
• Fargealternativer, det er velkjent at folk av ulike kulturer reagerer ulikt på farger¹⁷. I konkurransesammenheng er det beviselig mer sannsynlig¹⁸ å vinne om man har rød bekledning. Så hvilken farge velger du på en knapp for kjøp? Blå, rød, grønn, eller annen? Test!
• Bildespråk, blant annet kan du evaluere hvilken type bilde som fungerer på annonser på en bestemt annonseplass, men også om det er havutsikten eller bassenget som selger hotellpakker ved Middelhavet.
• Brukervennlighetsfaktorer. En interessant ting som dog kan være litt komplisert å teste er om man kan heve opplevelsen av en flertrinnsprosess gjennom å redusere eller øke antallet delmomenter. At brukere ikke orker å klikke mer enn tre steg er en utestet antakelse inntil man faktisk har undersøkt saken. Kanskje blir prosessen mer tydelig om man innfører et ytterligere delmoment. Ved å sammenligne alternativenes omvandlingstrakt ser du hvilket alternativ som beholdt flest brukere til slutt.

Akkurat som med omvandlingstrakt kan og bør A/B-testing brukes i andre sammenhenger enn strengt på selve nettstedet. I e-postutsendelser er det vanlig at man sender ut to alternative meldinger, for eksempel om et tilbud av noe slag. Når man i etterkant analyserer hvilket gjennomslag respektive alternativ fikk, vekkes tanker om hva man muligens kan gjøre bedre i en fremtidig utsendelse.

Multivariat testing for å teste flere ting samtidig

Vil og tør man komplisere det noe, kan man utføre såkalt multivariat testing. Det innebærer at man tester et flertal justeringer samtidig i en pakke, men ellers er det en miks av andre metoder – kanskje primært A/B-testing.

Et eksempel er når man innledningsvis designer landingssider på sitt nettsted. Hvilket alternativ fungerte best av for eksempel:

• Alternativ A med stort dekorasjonsbilde, svulstig overskrift og én eneste call-to-action?
• Alternativ B som uten bilde eller svulstig overskrift bruker plassen til å tilby tre distinkte call-to-actions?
• Alternativ C med en copy-tekst som er personalisert for brukeren basert på vedkommendes klikkemønster, hvordan hen havnet på siden, etc.

Målestokken for hvilket alternativ man skal jobbe videre med er det som har høyest gjennomklikkfrekvens på de call-to-actions man har satt opp. Eller enda heller, om det nå er mulig, måle faktisk lønnsomhet på brukerens sesjon. Første runde av denne testen ville gi svar rundt hvor mange call-to-actions brukerne kan håndtere på én og samme side. Avhengig av hvordan resultatet ser ut kan man designe neste test for å forsøke å optimalisere ytterligere.

Også i denne metoden brukes segmentering for å kunne isolere delmengder av den informasjonen man samler inn, kanskje primært for å fortelle historien rundt det man tester.

Kontroll av kvalitetsfaktorer

Det er ikke alle måleverdier som kan besvares ved hjelp av innsamlet statistikk om brukernes klikk og atferd. For eksempel bør man holde ved like tanken om å kontrollere andre former for kvalitetsindikatorer. Si at kommunikasjonsavdelingen trenger å følge opp publisert materiale. For eksempel liste alt materiale som ikke er oppdatert på et visst antall måneder, eller:

• Liste tunge bilder i størrelsesorden i håp om å kunne optimalisere dem.
• Sjekke om det finnes foreldet teknologi som gjemmer seg et sted. For eksempel Flash-filer eller merkelige dokumentformater.
• Nettsider med sidetitler som ikke følger aktuell praksis innen søkemotoroptimalisering, noe som vanskeliggjør mulighetene å finne disse via søkemotorer.
• Dokumenter som heter noe upassende, for eksempel «Nytt Word-dokument», mangler tittel eller andre vanlige feil som gjør det vanskelig å søke etter innholdet eller er pinlig når noen finner det.
• Materiale som mangler tilstrekkelig mye metadata. For eksempel at beskrivelse av siden, eller at nøkkelord til den egne søkemotoren mangler.
• Sider som svarer veldig tregt. Treg sidevisning kan skyldes mange ting, men ofte handler det om kompleksitet i systemet for å sammenstille alt som skal vises for brukerne. Men iblant har man jo rett og slett en for treg webserver.

På min arbeidsplass har vi drøyt en million sider/dokumenter som er søkbare. Med hjelp av alt det søkemotoren vet om sidene den har indeksert kan vi plukke frem en hel del interessant statistikk. Blant annet at 89 % av innholdet på intranett mangler nøkkelord – med andre ord kan 9 av 10 sider ikke delta i toppstriden på den interne søkemotoren. Ikke rart at søkemotoren har vanskelig for å velge ut hva som er mest relevant. Det er ikke særlig mye bedre på våre eksterne nettsteder.

Bilde 16: Optimizr.com gir rapporter per e-post.

Ta gjerne inspirasjon av de rapportene som kommersielle verktøy har, det er som oftest både enkelt og gratis å melde seg på for en prøveperiode med de fleste verktøy. Når du utvikler din egen mal for rapportering er det selvfølgelig viktig å fokusere på de verdiskapende hendelsene. Ikke bare alle potensielle problemer, utfordringene og varslene som er åpenbare nok til at standardverktøyene løfter dem frem.

For deg som ikke allerede har noen egnet programvare som kan inspisere hele nettstedet, eller i det minste store deler av det, finnes en del verktøy du selv kan kjøre eller sammen med en mer teknisk anlagt kollega. Det jeg selv har kjørt og likt heter SEO Toolkit¹⁹, som er et tillegg til Windows Server. Denne serverversjonen av operativsystemet Windows finnes innen praktisk talt enhver større organisasjon og er nok heller ikke uvanlig blant utviklere i din nærhet.

Bilde 17: SEO Toolkit kan crawle gjennom ditt nettsted og gi en hel del tips.

Eksempler på andre kilder der du kan finne data av kvalitativ eller kvantitativ sort er for eksempel:

• Kundeservice eller IT-avdelingen kan ha logger på saker som angår vanskeligheter med å bruke nettstedet, eller andre saker der nettstedet ikke lyktes med å hjelpe brukeren.
• Brukervennlighetsstudier der jeg jobber har iblant blitt gjort på delsystemer uten min kunnskap og likevel, takknemlig nok, sett på de delene jeg jobber med. Det skader altså ikke å spørre litt rundt.
• Transaksjonsdata som kan gå under mange ulike navn avhengig av kunnskapene hos den du snakker med. For eksempel kan det kalles for tjenesteplattform, Enterprise Service Bus (ESB), integrasjonsplattform, API-er eller lignende. Dette er en form for digital telefonsentral og informasjonsskranke i kombinasjon.

Neste moment er selvfølgelig å inspisere, sammenligne og analysere all data man har samlet inn.

Moment 3: Analysere

Målet med analysefasen er å forstå hvorfor brukerne oppfører seg på en bestemt måte eller mener det de gjør. Det du har gjort så langt er å samle på deg bevis for hva som har skjedd når, og hvor. Nå er det på tide å forsøke å svare på spørsmålet hvorfor. Her får du sjansen til å se hvilke hindre som stopper brukerne fra å gjennomføre de ønskelige aktivitetene på nettstedet og hva du kan ta tak i for å optimalisere verdien av nettstedet.

Det du ganske snart merker som skiller ulike brukere fra hverandre, særlig om du snakker med dem, er at deres tilfredshet påvirkes av i det minste to faktorer, nemlig:

1. Brukerens forventninger før besøket. De kan være ulikt motiverte. Kanskje har du overbevist personen allerede før hen dukket opp.
2. Selve brukeropplevelsen. En veldig motivert bruker holder ut med litt mer enn den som trenger å bearbeides litt for å konvertere. Det kan handle om hvor lett det er å forstå hva man skal gjøre. Hvor mange delmomenter noe har. Om man i det hele tatt kan ta del av nettstedet under de forutsetningene man befinner seg i og hvilken enhet man bruker.

Det første du må fundere på i analysearbeidet er om du har nok data for å kunne trekke noen konklusjoner. Selv om du kommer frem til at du nok har for lite data for å trekke store og vidtrekkende konklusjoner, gir dataene dine deg sikkert indikasjoner på hvordan det ligger an og tips på hvordan du kan gjøre om testen i større skala. Men grav deg ikke ned! Risikoen finnes for at du legger mer tid på å analysere enn å forbedre nettstedet. Nøler du, ta kontakt med en statistiker og nevn nøkkelordet konfidensintervall (altså hvilken feilmargin som finnes) for å fange hens oppmerksomhet. Eller så googler du og setter deg inn i emnet :)

Vær også oppmerksom på eventuelle sesongvariasjoner som kan påvirke testen. Ifølge min erfaring finnes det informasjon og støtte som trengs mer ved bestemte tidspunkter i løpet av året. For eksempel gir data fra min arbeidsplass støtte for at det er vanlig at folk glemmer passordene sine under sommerferien. Dette er også et eksempel på hvordan dine konklusjoner innen webanalyse også kan støtte internkommunikasjonen med prioriteringene i det redaksjonelle arbeidet med intranett. Om nå folk har ekstra vanskelig med passord i slutten av juli og hele august, finnes nok en effektivitetsgevinst i å plassere relevante tips på intranettets startpunkter for hvordan man som ansatt agerer ved glemt passord. Tilsvarende vanskelighet kan sikkert eksterne brukere også ha første gang de skal logge inn etter en lang ferie.

Om du nå likevel skal plassere ut denne sesongsinformasjonen kan du like gjerne gjøre en A/B-test for å evaluere best tenkelige formulering i stedet for å bare skrive sammen noe. Selv ville jeg teste å dels kjøre et spørsmål som tittel, for eksempel «Glemt passordet?» men også det mer aktive «Få nytt passord». Gjør du det som en bildepromo kan du teste hvilken form for bilde eller illustrasjon som presterer best. Her kommer vi inn på de hypotesene rundt tenkte forbedringer som henger sammen med besvarelsen av hvorfor-spørsmålet og viljen til å optimalisere.

De dataene du har samlet inn kan iblant inneholde uønsket variasjon eller ekstreme eksempler. Vil du være helt på den sikre siden er det som sagt aktuelt å koble inn en statistiker, men ofte kan man ved hjelp av historiske data komme frem til hva som er et usannsynlig scenario. Om så er tilfelle er det helt ok å filtrere eller segmentere bort disse spesielle tilfellene. Det du oppnår er statistikk som riktignok ikke er like eksakt, men det går an å se trend over tid. Eksakthet er egentlig mest avgjørende i sammenlignende tester mellom konkurrerende alternativer, om nå inget alternativ vinner en brakseier.

Inspiser det fåtallet som konverterer – eller alle andre?

Basert på de målene og brukersegmentene som er identifisert er det nå man stiller seg spørsmålet om hvilken gruppe som har størst potensial til forbedring. Skal man forsøke å nå kunnskap i om det er mer lønnsomt å optimalisere de som har konvertert, eller de kanskje 98 % som ikke har konvertert. Jeg antar at også du synes det er interessant å forsøke å omvende flere av den store massen brukere. Men selvfølgelig skal man ikke glemme å forsøke å gjøre det enda bedre for de som allerede har bekreftet at de liker virksomhetsmålene gjennom å faktisk konvertere.

Å øke andelen som konverterer med en ynkelig prosentenhet kan innebære en dobling, om du nå hadde én prosent konvertitter før forbedringen og to etter. Det kan være vanskelig å doble nytte/inntekt/etc. på eksisterende brukere eller kunder.

Den ofte lille andelen som konverterer er de som har bekreftet seg som interesserte i det virksomheten tilbyr. Men mange av de andre består i stor grad også av interesserte brukere, men av en eller annen grunn kom de ikke til neste steg. I denne gruppen finnes de som forlater handlekurver, skaffer seg kunnskap om utbudet, leser på, bruker sammenligningsfunksjoner men ikke fullfører noe (ennå).

I analysefasen trenger man å sjekke opp hvor noen faller fra i prosesser, se hvor friksjonen oppstår og komme med forslag til konkrete tiltak til neste moment i arbeidsprosessen. Å analysere går ut på å basert på data og strukturert evaluering komme frem til konklusjoner om hvor bra noe har prestert, samt hypoteser for hvordan noe kan forbedres ytterligere.

Analysens kortsiktige resultat

Basert på de dataene du har samlet inn, bearbeidet og analysert, skal du dokumentere de funnene og lærdommene som er gjort. Det kan være bra å ha en notering som viser med hvilken sikkerhet analysen peker på at man har rett, ingenting feil i å være ydmyk med at dette ikke er en eksakt vitenskap. Skriv gjerne også ned hvilke metoder som ble brukt for respektive test. En logg rett og slett.

Tenk på at bak en utvetydig A/B-test kan det meget vel skjule seg data som tydelig forklarer hvorfor den ene varianten presterte bedre. For eksempel kan det vise seg å være stor forskjell mellom mobile brukere og de med stasjonær datamaskin som besøker en bestemt underside. Kanskje er designelementet som er sidens call-to-action ikke like lett å oppdage på en liten skjerm? Det kan være hva segmenteringen viser, men kan være verdt å teste igjen for å se om den antakelsen stemte. Kanskje kan testen ha relevans for hvordan andre deler av nettstedet kan fungere enda bedre?

Skriv gjerne ned hvilke tester som kan trenge å forbedres og kjøres en runde til gjennom hele analysearbeidet. Det er ikke direkte uvanlig at man ikke får frem noe som er tilstrekkelig tydelig for å trekke noen store konklusjoner, men også det er en kunnskap som ikke er verdiløs.

Som siste punkt i analysefasen sammenstiller du rapporten, ta utgangspunkt i den malen du jobbet med i det foregående momentet og fyll på med innsikter og konklusjoner (og vær forsiktig med å putte inn mer data eller tall enn nødvendig). Denne rapporten er dels noe å arkivere unna, men primært er det nå du skal kunne avstemme funn med de interessentene som «eier» nettstedet eller dets ulike deler.

Ikke ta kontakt med interessentene og si «Vi har 17,39 % flere besøkende sammenlignet med foregående periode», eller andre lignende påstander. Før presentasjon eller overlevering av rapporten kan du og en kollega presentere den for hverandre, der dere begge bytter på å være djevelens advokat – den som klager og stiller spørsmål ved alt mellom himmel og jord. Det du rapporterer om skal gi innsikt og være mulig å agere på. De skal bestå en test jeg selv pleier å kalle for «og hva så?». Kan du ikke besvare motspørsmålet om hvorfor man skal bry seg, er det du vil rapportere om ikke verdig noen andres oppmerksomhet.

Eksempler på ting å fortelle om som både gir innsikt og kan ageres på kan være blant annet:

• «Om utviklingen fortsetter slutter vår kampanje på Facebook å være lønnsom om to uker (da regnet på en kundes gjennomsnittlige lønnsomhet over 5 år).»
• «Over halvparten av våre konkurrenter har nå bedre ytelse enn oss. Det finnes tre enklere tiltak vi gjerne vil teste og evaluere, til å begynne med.»
• «Vi har redesignet prosessen for handlekurven og evaluert den. På mobile enheter har fullføringer doblet seg, men det sank med 7 % på datamaskiner. Totalt sett pluss minus null, men da vi tror på mer mobil trafikk foreslår vi å beholde designen.»
• «Kun et fåtall av våre landingssider følger praksis innen SEO. Vi foreslår redesign av CMS slik at det ikke går an å glemme beskrivelsestekst samt at sidetitler aldri er over 70 tegn lange.»

Moment 4: Utfør forbedringer på nettstedet

Basert på hypoteser og konklusjoner fra analysefasen prioriterer man hvilke forbedringer man først skal ta tak i. Visst arbeid kan ha stor påvirkning og samtidig være en liten innsats, andre ting kan være komplekse på grunn av at de har eksterne avhengigheter – uansett hva har du nå en liste med ting å ta tak i.

Eksempel på arbeid i forbedringsfasen er å flytte på knapper for å øke brukervennligheten, noe som kanskje bare trengs for de med liten skjerm. Har du kjørt A/B-tester «manuelt», det vil si uten et automatisk støtte i webpubliseringssystemet, er det nå du sørger for at bare det vinnende alternativet brukes.

Det siste du gjør i forbedringsfasen er å fylle på ønskelisten med de forbedringene du prioriterte bort å gjøre denne gangen. Den listen kan vise seg å være nyttig fremover når man tilfeldigvis får tid til overs, kanskje kan slå sammen visse aktiviteter som ligner hverandre eller som inspirasjon neste gang man redesigner nettstedet.

Enkelte av de virksomhetsmålene du har satt opp kan ta ganske lang tid å påvirke uansett hva du gjør for forbedringer, så ha en rimelig forventning til hvor raskt du kan begynne å se resultater.

...og hva så?

Etter utførte forbedringer kjører man en ny runde og begynner på nytt med moment ett og sine virksomhetsmål. Dette arbeidet er noe som aldri blir ferdig, det som styrer er snarere ambisjonsnivået. Ambisjonsnivået styrer hvor mange runder man orker med per år.

Bli sertifisert webanalytiker?

Om du føler deg utrygg i din rolle finnes det god hjelp å få, utover denne boken. Selv om du har utdannet deg eller jobbet med statistikk, har en bakgrunn som webutvikler eller på annen måte føler at du har kontroll på mye, kan det være bra å kunne henvise til noe konkret. Eller for å sikre at de erfaringene du har tilegnet deg ikke har store hull på noe viktig område.

Noe som gjør deg til en webanalytiker også ifølge en skeptisk persons perspektiv er å fortjene tittelen. For eksempel for deg som bruker Google Analytics finnes deres Academy, en gratis nettbasert opplæring der du får lære deg både teori og praksis. Der kan du lære deg håndgrepene som kreves i nettopp Google Analytics og til slutt få dine kunnskaper bekreftet gjennom å bli sertifisert på plattformen. Selv om du ikke bruker nettopp Google Analytics kan opplæringen og dens sertifisering være nyttig.

Å ha en sertifisering innen et område er ofte den kvalitetsstempelet som åpner dører, noe som viser at man i det minste har oppnådd et ok nivå ifølge en tredjepart.

Vanlige fallgruver ved arbeid med nettstedstatistikk

Det finnes selvfølgelig mange ulike måter å mislykkes på med sitt analysearbeid, langt flere enn jeg har mulighet til å etterforske eller du har ork til å lese om. Jeg har valgt ut to hovedgrupper som det i alle fall ifølge min erfaring er veldig lett å havne i. Dels om kvaliteten på målene er noe å ha, men også at man går seg vill i sin statistikk.

Vanity metrics – måleverdier eller mål som gir en god magefølelse, men som mangler faktisk verdi

En vanlig tankefeil er det som kalles for «vanity metrics», det vil si måleverdier som tiltaler ens forfengelighet. Hva som tiltaler ens forfengelighet mistenker jeg varierer avhengig av ens yrkesidentitet. Det kan være sammenligninger på verdier som kan synes å være langsøkte i hva de har med et utvetydig godt resultat å gjøre.

Eksempler jeg har hørt ofte gjennom årene er hvor mange sidevisninger man har, eller antallet unike besøkende. Bare fordi man i trykksaksbransjen tidligere kom unna med diffuse tall som i hvilket opplag noe ble utgitt, gjør det ikke verdien til et rimelig virksomhetsmål verdt å strebe mot.

Det er tvilsomt hvilken nytte man kan oppnå gjennom å sette opp mål om gjennomsnittlig antall sidevisninger på et nettsted. Er det utvilsomt bra med mange sidevisninger per besøkende? Er det dårlig? Det gjelder å være selvkritisk til sine mål – da slipper du kanskje at andre er kritiske for deg. I metoden er det innebygd i arbeidsgangen at man reflekterer rundt sine mål. Det er nemlig ytterst naturlig at man justerer målene jo mer man lærer om sitt nettsted, brukernes atferd og det innholdet man tilbyr.

Forholdet mellom webstrategi og systematisk arbeid med webanalyse er det som hjelper deg å holde orden på din miks av målsettinger. Slik at det ikke bare gir god magefølelse.

Webanalyseguruen Avinash Kaushik har, utover See-Think-Do-Care, introdusert «Ladder of awesomeness» for å visualisere dette. Ens webstrategi går ut på hvordan man når høyt opp på stigen, mens webanalysen handler om hvordan man følger opp resultatet, forbedrer og eksperimenterer.

Bilde 18: Avinash' stige illustrerer de stegene som trengs for å skape en god opplevelse på nettet.

I bunnen av stigen finnes de hygienefaktorene som denne boken fokuserer på i sin avsluttende del, øverst finner du markedsføring på høyt nivå. Trenger jeg å nevne at det er meningsløst å være dyktig på markedsføring om de to nederste trinnene er undermålige?

Agenda-amplification effect

At ens egen agenda styrer kan føles lignende vanity metrics. Jeg vil hevde at denne dog handler om hvor nøytral og åpen man er for å lære seg noe nytt. Med statistikk og undersøkelse finner man ofte argumenter hvis eneste verdi er at de bekrefter et svar man allerede har bestemt seg for. For å gjenbruke et eksempel, la oss si at undertegnede, som er skeptisk til kongehusets demokratiske verdi, stiller følgende spørsmål til allmennheten: «Anser du at Sveriges statsoverhode skal være demokratisk valgt?»

Hva tror du svaret ville bli? Jeg tipper på at flere ville svare ja på det spørsmålet sammenlignet med om spørsmålet var formulert slik: «Burde Sverige avsette kongen og ha en demokratisk valgt president i stedet?»

Som man spør får man svar. Og avhengig av ens innarbeidede tankemønstre kan det være vanskelig å være helt objektiv, eller i det hele tatt stille spørsmål som ikke er ledende. Det er bra å være flere om dette arbeidet og kanskje rent av innføre en aktivitet der man utfordrer sine antakelser, utforsker andre forklaringsmodeller, med mer. Det kan finnes andre innsikter der som ikke er i tråd med ens egen agenda.

Vanlige feil rundt statistikk

Den mest åpenbare feilen er at dataen som er samlet inn ikke har en kvalitet som er god nok. Kanskje er den heller ikke representativ for virkeligheten. Så fort man er tvilende til sin datakvalitet slutter man å holde på med statistikk og det blir snarere gjetninger basert på et undermålig underlag. Da er det tilbake til tegnebrettet som gjelder for å finne ut hvordan man kan samle inn data på en god og ordnet måte. Å bruke tredjepartsverktøy er å overlate problemet til noen andre, men selv her er det bra å vite en del om hvordan det foregår. For eksempel kunne de som hadde en stor andel iPhone-brukere antagelig se et før-og-etter for da iOS 9 ble sluppet, da begynte nemlig flere å blokkere blant annet Google Analytics. La oss si at akkurat din tiltenkte målgruppe er sannsynlige brukere av innholdsblokkering, hva sier det deg om din datainnsamling?

Dessuten må underlaget være stort nok for at man skal kunne trekke konklusjoner. Feilmarginen er enormt mye større om du har en håndfull brukere i ditt utvalg sammenlignet med om du har hundretusenvis. Har du en håndfull brukere og et flertall av dette fåtallet støter på et bestemt problem, handler det egentlig ikke om statistikk. Men selv anekdotiske bevis kan være gode nok til å agere på.

Bilde 19: Konfidensintervall vist med rød linje.

Sammenlign med å kaste mynt. Med en perfekt mynt er sjansen for å få krone 50 % og 50 % for å få mynt. Kaster du ti ganger er sjansen for jevn fordeling lavere enn om du kaster tjuefem eller tusen ganger. En måte å være åpen og ærlig med sin usikkerhet kalles for konfidensintervall. Det er en matematisk estimering av hvor ofte man vil ta feil basert på det underlaget som finnes. Har man et konfidensintervall på 95 % tror man seg altså å ta feil hver tjuende gang. For å visualisere dette i rapporter pleier man å vise en rød strek i søyler for å angi innenfor hvilket område usikkerheten er. Da blir det tydeligere å sammenligne to søyler, når deres røde streker overlapper hverandre har man kanskje ikke bevis for å gjøre forskjell på dem.

Korrelasjon sier ingenting om årsakssammenheng!

Bilde 20: Smørsalget og skilsmisser i delstaten Maine viser en tydelig korrelasjon.

Bare fordi to grafer følger hverandre over tid trenger det ikke å bety at de har en felles årsak. En av mine favoritter i dette er den kreative religionen med guden «det flygende spagettimonsteret», der man hyller pirater. Det finnes nemlig en sammenheng mellom synkende antall pirater og drivhuseffekten. Derfor skal man feire «Talk like a Pirate Day» for å redusere drivhuseffekten.

Så finnes det svake årsakssammenhenger, som i iskremsalg og vær.

Hva en statistiker kaller statistisk signifikans kan være verdt å reflektere over. Det handler om at en verdi trenger å være tilstrekkelig avvikende fra en annen for at man skal kunne si at det ikke handler om tilfeldighet. Si at du kjører en A/B-test der du sammenligner gjennomklikkfrekvensen på to ulike designalternativer. Om alternativ A har 23 % og alternativ B har 25 % gjennomklikkfrekvens er det riktignok sant at alternativ B har to prosentpoeng høyere frekvens i testen. For å avgjøre om vi kan kåre alternativ B til vinner må vi vite hvor mange som har blitt stilt overfor alternativ A respektive B (det som kalles for populasjon). Kortversjon av hypotesetestingen er at jo flere som har tatt del av respektive alternativ, desto mindre lureri er det å kåre alternativ B til vinner.

En stor risikofaktor her er at du stoler på at utvalget av brukere til alternativ A og B ble gjort tilfeldig. Ellers kan det skjevvri resultatet mer enn de ynkelige to prosentpoengene vi har som «bevis» for at alternativ B er bedre. Sørg for at dine A/B-tester ikke blir noen statistikeres skrekkeksempel fremover. Ager når du har et ganske stort underlag og stor avvikelse mellom alternativenes prestasjon (eller engasjer en statistiker når du tviler).

Det kan være klokt å ha en statistiker å rådføre seg med, eller å ikke trekke for store veksler på data man ikke er trygg med.

Oppsummering

Nytten med hver omstart av analysearbeidet er at man får sjansen til å se kritisk på sine virksomhetsmål for å se om man virkelig synes at de fortsatt er noe å ha. Troligvis kommer du til å se dem med litt nye øyne over tid og de kan trenge å forbedres, suppleres eller gjøres tydeligere.

Nå følger et parti om å dokumentere sitt ytelsesbudsjett, altså hvilket kvalitetsnivå nettstedet skal leve opp til samt hvordan man gjør designarbeidet mer standardisert og mulig å følge opp. I det arbeidet inngår å bestemme seg rundt en lang rekke hygienefaktorer, gjøre designen litt mer ingeniørmessig og viktigheten av å dokumentere alt.

Fortsett å lese – Del 2: Analytisk vinkel på design, ytelse og innhold