Del 3: Webanalyse: Fordypning

I de foregående delene har vi skrapet på overflaten om webanalyse, sett på en arbeidsmetode for et metodisk arbeid og også litt prosjektteori gjennom å diskutere stilguiders og designs påvirkning på analysearbeidet.

Nå er det på tide å gå gjennom mange av de tingene som de fleste av oss ikke automatisk forbinder med webanalyse. Blant annet noen av de verktøyene man kan ha nytte av for å jobbe med oppfølging, og ikke minst en rekke tips og anekdoter fra virkeligheten.

Når det gjelder målbarhet i stort, finnes det to hovedsakelige kategorier av hva måleverdier kan deles inn i (og, ja, man trenger å bruke begge sortene):

• Kvantitative data. Gir tall på hvordan nettstedet presterer, for eksempel all den informasjonen om brukerne som gruppe man kan få frem i sitt statistikkverktøy. Disse måleverdiene gir svar på spørsmålene hvordan, når og hva rundt brukerne. Hvilket utstyr de har, når besøker de nettstedet, hvor kom de fra og så videre. Atferdsdata som gir innsyn i omfanget av noe.
• Kvalitative metoder. Handler om hvordan brukerne opplever nettstedet, slik de selv ville uttrykke det. Disse opplysningene er i form av tekst snarere enn tall. Det kan være svar på spørsmål i en nettstedsundersøkelse, intervjuer, brukertester eller funksjoner på nettstedet der man lar brukeren fortelle hva de syntes om opplevelsen sin eller det de nettopp leste. Utover folks holdning til et nettsted kan det i visse tilfeller handle om at man observerer brukerne slik at man kan ta sjansen til å stille oppfølgingsspørsmål, ved behov. Man leter etter svar på spørsmålet hvorfor. Kvalitativ informasjon bidrar med de perspektivene som kvantitative data mangler.

Angående kvalitative undersøkelser er det klokt å være oppmerksom på i hvilken situasjon brukeren befinner seg i når de skal svare på spørsmål. Du har sikkert opplevd å bli tilbudt å fylle ut en spørreundersøkelse om hvordan du opplever et nettsted. Iblant dukker disse undersøkelsesinvitasjonene opp allerede før man har rukket å begynne å bruke nettstedet. Spørsmålet oppstår da om det ikke påvirker hvordan respondenten fyller ut undersøkelsen? Er svarene deres identiske med besøkende som har klikket rundt på 2-3 sider først? Hvis man har tenkt å trekke konklusjoner basert på disse dataene, er det dumt å gamble med sin datakvalitet.

Bilde 37: Denne typen spørreundersøkelse er direkte uegnet ved en brukers første besøk på et nettsted.

Det kan være klokt å i det minste logge hvor mange sidevisninger brukeren rakk før hen fylte ut undersøkelsen. Om det er en innlogget person eller på annen måte en tilbakevendende bruker, er også det bra å vite. For tilbakevendende brukere er det trolig ikke hele verden å slenge opp undersøkelsen tidlig – de har jo en gang tidligere opplevd nettstedet. Her gjenbruker du dine segmenteringer av brukere. Kanskje oppdager du noen nye interessante grupperinger basert på de metadataene du kan samle inn om respondenten, som hvor de kom fra, om det finnes geografiske forskjeller, etc.

Det er vanskelig å selv evaluere sitt eget nettsted

En ting som ser ut til å være lett å glemme er at vi som skaper, eier, utvikler eller på annet vis er ansvarlige for et nettsted virkelig ikke er representative brukere. Vi er heller ikke særlig flinke til å imitere ekte brukere da vi alle kommer med helt egne oppfatninger og forkunnskaper. Har man vært delaktig, er det kanskje først og fremst ens forkunnskaper som gjør en til en dårlig tester.

Derfor trenger man med jevne mellomrom å gjennomføre brukertester. Innenfor det som kalles universell design, iblant inkluderende design eller design for alle, har man utarbeidet en liste³⁶ med hva en brukbar design går ut på, nemlig:

1. Equitable use – bruken skal være rettferdig og mulig for alle til tross for våre varierende evner.
2. Flexibility in use – allsidighet ved bruk.
3. Simple and intuitive – enkelt og selvforklarende.
4. Perceptible information – innhold og informasjon skal være mulig å oppfatte.
5. Tolerance for error – feiltolerant og tillatende konstruksjon.
6. Low physical effort – skal kreve liten anstrengelse.
7. Size and space for approach and use – det skal finnes rom for bruk og letthet til å gjøre rett.

Disse punktene er ikke spesifikke for digitale skapelser, men kan definitivt brukes på hvordan man designer nettsteder. De ble skapt i 1997 av The Center for Universal Design ved North Carolina State University, så de er sammenstilt lenge før nettet begynte å se ut som det gjør i dag.

Oppstart av et webprosjekt eller en ombygging

Det finnes selvfølgelig enormt mye å tenke gjennom når man skal starte et webprosjekt, uansett om det er innholdet man skal se over, noe ny design som skal til, eller om det er et nytak rundt webanalyse. En forutsetning for at man skal kunne begripe hva som er verdt å analysere, er at man vet hva på et nettsted som er, eller skal bli, det som lever opp til formålet med nettstedet.

Forslag på ting å tenke gjennom tidlig er blant annet:

1. List opp hvilke deler som er viktigst, viktige, normale eller uviktige. Alt kan ikke være viktig for alle tiltenkte målgrupper, alltid.
2. Hvilke deler av nettstedet støtter de viktigste aktivitetene? Disse sidene trenger å analyseres i jakt på forbedringsmuligheter. Som dens plassering av knapper, forståelige tekster, hvor lett det er å finne dit, etc.
3. Hvor enkelt er det å finne mellom de ulike aktivitetene? Tenk forutsetningsløst gjennom navigasjonsstrukturen. Går det for eksempel an å finne tilbake til respektive startpunkt om man har fått en direktelenke via e-post? Er det lett å bytte fra aktiviteten å melde seg på nyhetsbrevet til å rette feilaktige adresseopplysninger?
4. Hvor enkelt er det for brukerne å ta seg gjennom en aktivitet? At en butikks overlevelse henger på at kundene klarer å betale for seg, er ganske åpenbart. På et nettsted trenger man å sørge for at det finnes så få og lave hindre som mulig for å fullføre en aktivitet hele veien.
5. Hva er et vellykket besøk på nettstedet? Hvilke ting skal ha inntruffet for at du objektivt skal kunne peke på en brukers sesjon på nettstedet og si at det var et vellykket besøk? Meldt seg på nyhetsbrev? Lastet ned et whitepaper, lest en nyhet og forsvunnet? Tenk gjennom hvilke måleverdier som viser et vellykket besøk.

Materiale som ikke relaterer til ovennevnte punkter er oftest distraksjoner og ikke interessante å forbedre. Snarere bør det nok fjernes, eller i det minste gjemmes, brukere skal ledes rundt det og det bør merkes som potensielt søppel for den egne søkemotoren. Tenk gjerne gjennom hva som utmerker en verdifull side, som om en side uten en call-to-action kan anses verdifull og i så fall hvorfor. Sett gjerne opp målet at nye nettsider skal ha en call-to-action eller være tett knyttet til et virksomhetsmål.

Hva er da en call-to-action (CTA)? Jo, det er det designelementet på en nettside som brukeren er ment å samhandle med. Det kan være en knapp, en lenke eller hva som nå er grunnen til at siden eksisterer. En CTA er den måten man som skaper av et nettsted forsøker å ledsage brukeren gjennom en aktivitet frem mot et mål – en avslutning.

Det er meningen at du skal se kritisk på nettstedets alle undersider. Visst ville det føles godt om du kunne forklare hva majoriteten av sidene på nettstedet tilfører?

Hvilket materiale er bra (og hva kan kastes)?

Hva er så godt innhold på et eksisterende nettsted, og kan man finne ut hva som fungerer? Jobber du med webanalyse, trenger du å skaffe deg en oppfatning om hva som er kvalitetsfaktorer og hvordan du kan jobbe med målbarhet for å lære kjenne dine brukere og deres atferd.

Å jobbe med webanalyse er mye mer enn å grave seg ned i nettstedstatistikken, det finnes mengder med andre verktøy som kan gi et helikopterperspektiv over din webkommunikasjon. Men for at det skal være meningsfullt å analysere, trenger man først å definere hva som er bra – bra innhold, bra atferd hos brukere, bra kvalitet og hva som er bra for virksomheten. Risikoen er ellers at man jobber med å forbedre materiale som mangler fremtidsutsikter. Men fortvil ikke, det finnes måter å finne ut hva som etterspørres av brukerne. Gjennom søkeanalyse, blant annet.

Noe som har vært forsømt veldig lenge, eller kanskje bare ikke har blitt rukket, er å evaluere om den søkefunksjonen man tilbyr fungerer som den burde. Iblant er søkefunksjonen mest en kilde til frustrasjon. Spørsmålet er om noe så vitalt på et nettsted skal tillates å finnes videre om man ikke følger opp om den bidrar med nytte eller kun er til skade. Søkeanalyse er vårt neste dypdykk.

Søkeanalyse er viktigere enn mange tror

I dag kan man trygt anta at hvert nettsted eller intranett har en søkefunksjon. Enkelte organisasjoner har til og med tatt steget til å bygge noe av en intern-Google, eller Enterprise Search som det pleier å kalles. Der jeg jobber har vi investert tungt i denne teknikken over mange år.

Å reflektere og analysere bruken av den egne søkefunksjonen er det som går under begrepet søkeanalyse (eller Site Search Analytics på engelsk). Det handler altså om å ta del av de ordene som brukes av brukerne og hvilken atferd de har. Hva er vanligst etterspurt, når finner de ikke frem og så videre.

Som du sikkert har regnet ut, er dette ikke det samme som SEO (søkemotoroptimalisering), men det finnes en del likheter mellom å ville nå ut på andres søkemotorer og å forsøke å optimalisere bruken av sin egen søkefunksjon. Søkeanalyse er kanskje mer beslektet med webanalyse enn med SEO. Mange av de webanalyseverktøyene jeg har sett har faktisk funksjoner for å gjøre en grunnleggende søkeanalyse. For eksempel kan man i Google Analytics konfigurere sitt nettstedssøk for å dra nytte av de andre verktøyene som tilbys også for hvordan nettstedets søk fungerer.

Velger man i stedet å selv styre sin skjebne, er det fullt mulig å bearbeide søkeloggene. Det vil si de tekstfilene der alle søkespørsmål noteres av systemet. Da er det bare ens egen fantasi og budsjett som setter grenser.

Søkeanalyse gir et unikt innsyn i brukernes opplevelse

Det som virkelig gjør søkeanalyse unikt er at du får en innsikt i hva brukerne er ute etter. De skriver til og med det med en serie ord om hva de er ute etter. Den typen innsyn kan man bare drømme om å oppnå når det gjelder de atferdsdataene som i øvrig webanalyse i stor grad utgjør. Gjennom at man får så mange ord er det en miks av både kvantitativ og kvalitativ undersøkelse. Både mengde og det personlige.

Motivasjon for å jobbe med søkeanalyse kan blant annet være å støtte sine designbeslutninger. For eksempel fordi du kan vise hvilke ting folk søker etter på nettstedet. At du også har data for å gjøre søkefunksjonen bedre gjør det ikke dårligere, og som vi vet blir søkefunksjonen aldri bedre enn det innholdet den løfter frem. Å jobbe med søkeanalyse kan løfte frem hva som trenger å forbedres med nettstedets innhold, hva som mangler, og mye mer.

Hvordan det fungerer

Først og fremst, gjennom et besøk til en søkefunksjon pleier besøket å fanges inn av webanalyseverktøyet som brukes på nettstedet. På det offentlige nettet er det veldig vanlig at dette verktøyet er nettopp Google Analytics, men det finnes også en rekke andre verktøy med tilsvarende funksjoner. Et som er rettet mot de organisasjonene som er forsiktige med å la andre ta del av deres brukeres surfemønster heter Matomo. Fordelen og ulempen med Matomo er at man kan ha den lokalt i sin egen tekniske miljø, ingen andre trenger å få vite hvilke besøkende ditt nettsted eller søkefunksjon har. Eller hva de søker på.

Foruten selve besøket på nettstedet kan en eller flere ting skje når brukere gjør et søk. Dels om man har konfigurert sitt webanalyseverktøy korrekt, vil det fange opp søkeordet, men det er også vanlig at søkefunksjonen skriver ned søkespørsmålet til en loggfil sammen med litt informasjon om brukeren. Denne ekstrainformasjonen handler sikkert som oftest om dato, tid, brukerens IP-adresse, og kanskje litt informasjon om hvilken type utstyr som er brukt. Les på om user-agent³⁷ om dette interesserer deg.

All denne dataen kan man så analysere frittstående fra sitt vanlige webanalyseverktøy, om man nå har den typen søkefunksjon, helt uavhengig av de funksjonene som allerede finnes i webanalyseverktøyet.

Søkeanalyse risikerer å bli teknisk

Som du merker brukes ord som «logg», «user agent» med mer i denne sammenhengen. Det er helt riktig at dine muligheter til å komme over søkeloggen kan henge på IT-avdelingens velvilje og interesse. Historisk har data som disse blitt samlet inn for bruk av teknikere for å feilsøke tekniske bekymringer, og de har nok ikke tenkt på å dele. Muligens blir du den første til å spørre om tilgang, i det minste som en som ikke jobber på IT. Reaksjonen på spørsmålet kan sikkert variere.

En måte å få fart på diskusjonen kan være å gi dem en gave i form av et nytt bra verktøy. Si at IT får hjelp med finansieringen av et multikompetent verktøy, både for business intelligence og tilfeldigvis også søkeanalyse? Det finnes flere produkter på markedet som kan hjelpe til med søkeanalyse. For oss som er solgt på åpen kildekode står den såkalte ELK-stacken³⁸ ut fra mengden. Det er en kombinasjon av Elasticsearch, Logstash og Kibana. Altså en søkemotor, logganalyseprogramvare og visualisering i én pakke.

Bilde 38: ELK kan se ut som Västra Götalandsregionens søkeredaktørportal. Her inspiseres søkebegrepet «lediga jobb» og ser ut til å vise en sesongvariasjon.

ELK er en tjeneste man installerer på sine servere. Vil man ha et mindre ambisiøst alternativ, synes jeg man kan sjekke ut noe selvhjelpsprogram for dataanalyse og visualisering. En av mine favoritter er Tableau som tilfeldigvis finnes i en versjon som er gratis å bruke, Tableau Public³⁹. Den kan man installere på sin egen datamaskin for å inspisere loggfiler eller datakilder i største allminnelighet.

Søkeanalyse i et innholds- og designarbeid

Som nevnt tidligere kan man få god hjelp ved designbeslutninger. Ikke minst fordi enda mer data om brukerens opplevelse hjelper til i argumentasjonen, men også fordi man får litt av et fasitsvar i diskusjoner om hvordan man skal benevne ting på nettstedet. Det kan bli åpenbart hvordan ting burde fungere eller hvordan ekte levende brukere benevner ting. Her er et verktøy for å møte det stadig høyere kravet om bevis og at organisasjoner vil være datadrevne. Et ord jeg lærte meg da jeg jobbet som utvikler på Sahlgrenska Universitetssjukhuset var vederheftighet, altså noe sin grad av pålitelighet. På en slik arbeidsplass er det ikke en nyhet at man skal kunne underbygge sine påstander med pålitelige data, det er jo hva forskning går ut på – om jeg får lov til å forenkle det hele grovt.

For den som jobber med innholdet kan det være hyggelig å vite hvilke ord ens brukere kjenner til, hva de søker etter og så videre. Det letter å ha en liste med ettersøkte ord når man skal skrive overskrifter, velge hvilke synonymer man krydrer med i ingressen m.m.

Noe annet som søkeanalyse og søkeredaksjonelt arbeid kan bidra med til innholdsarbeidet er å holde etter det hele, å jobbe strategisk med sitt innhold. Blant annet finnes det en arbeidsmetode for å finne det man vil rense bort, takket være søkemotoren. Dette gjøres ved å kaste ut materiale som er RUTtent, det vil si Redundant, Utdatert eller Trivielt. Den typen innhold koster penger enten ved at man forsøker å vedlikeholde det eller når noen brukere faktisk bruker det. Ikke minst er det ofte i veien i søkefunksjonen. RUTtent innhold kommer alltid til å rote det til uansett hvor godt du bygger din egen søkefunksjon, og det kan stjele oppmerksomhet på eksterne søkemotorer fra det innholdet du heller vil løfte frem.

Hvor meningsfullt er innhold ingen finner eller har bruk for? Slikt burde du kunne kaste. Om søkefunksjonen kjenner til innhold som ikke har noen utpekt eier, er nok også det et signal om at ingen ville savne materialet.

Forholdet til søkemotoroptimalisering og klikkstatistikk

Jeg har mange ganger raljert, i sammenhenger rundt søkemotoroptimalisering, om vanskeligheten med å selge inn produktnavn. Som «Windcracker 3000 GLX» når folk googler etter søkebegreper som beskriver hva de er ute etter, som «regnjakke for løping». I søkeanalysen gjemmer det seg semantisk beriket informasjon. Du kan se hvilke ord som er brukt, men i beste fall hvordan søkespørsmål er omformulert i håp om å få bedre treff. Det er en fantastisk kilde til hvordan man bedriver sitt SEO-arbeid.

Søkeanalyse bør være minst like viktig som å sjekke hvordan brukerne oppfører seg på nettstedet. Skal man være helt ærlig, er det webstatistikksystemet samler inn ikke særlig mye mer enn en logget strøm av klikk på ulike ting. Mens søkeanalysen kan nærme seg kvalitative undersøkelser om hva brukerne faktisk lette etter, ikke hvilken vei de klikket under tiden de lette.

Glem den lange halen, nøy deg med den korte halsen (inntil videre)

Om du er kjent med begrepet long tail⁴⁰, det som beskriver variasjon, har du innsett at visse søkespørsmål er ekstremt vanlige mens man raskt havner på sjeldenhetene. Majoriteten av søkespørsmålene er det som kalles for onesies og twosies, altså spørsmålene langt ut i halen, de søkespørsmålene som bare stilles én eller to ganger.

Bilde 39: Det korte hodet og den lange halen ≈ et fåtall søkebegreper er enormt vanlige.

Det kan være bra å vite at fordelingen long-tail beskriver også ofte kalles for Zipf-kurve, 80/20-regelen og sikkert flere navn jeg ikke har hørt ennå. Alle beskriver variasjonen innenfor et volum av noe. I dette tilfellet at stilte søkespørsmål raskt begynner å oppvise et mønster av tilbakevendende søkespørsmål (det korte hodet) men også unikhet (den lange halen).

Jeg har fordelen av å kjenne en matematiker, blant annet jobber han med å regne ut forsikringspremier. Ofte når jeg har et vanskelig spørsmål pleier jeg å benytte sjansen og sparre det med ham. Også i dette tilfellet:

For å være kanskje enda tydeligere: en zipf-kurve viser fordelingen av en mengdes elementer i fallende rekkefølge. Vil man være pirkete er frekvensene normert slik at frekvensene summerer seg til 1, noe som innebærer at det er en sannsynlighetsfordeling som beskrives.
- min venn Morgan Skogh

Kortfattet: det er overraskende vanlig at en bruker søker nettopp på de mest populære søkeordene.

De 100 vanligste søkene er veldig mye vanligere at brukerne søker etter sammenlignet med søkene som er 100-200 vanligst. Det er sannsynlig at de fjorten vanligste søkespørsmålene utgjør hele 10 % av alle søkespørsmål.

Hva skal du gjøre med denne kunnskapen? Om du begynner med å se raskt på de hundre mest vanlige søkespørsmålene og sørger for at det finnes gode svar, kommer du å ha sikret at søkefunksjonen fungerer ok for en ganske stor andel av brukerne. Jo mer du jobber med dette, desto mindre blir gevinsten av forbedringene. Tenk om alt arbeid var så lett å forklare hva som er en passende stor innsats.

Det man leter etter i grunnleggende søkeanalyse er mønstre. Mønstre som gir innsikt i hvordan det fungerer, eller finne mønstre på systematiske bekymringer man kan rette opp.

Et bruksmønster du trenger å kjenne til er hvilke de vanligste søkespørsmålene er. Disse kan endre seg avhengig av tid på året, uken eller døgnet. Disse innsiktene er noe som kan omgjøres til muligheter i hvordan man jobber med sitt innhold. For eksempel å få signal om når sesongvariasjonen for å lete nytt jobb har kommet i gang, når folk har begynt å søke på omgangssyke eller hva det er for innhold som etterspørres av dine brukere.

Segmenter - om mulig

Hva søker de brukerne etter som du har plassert i ditt viktigste segment, de som er mest verdifulle for deg? For å kunne vite dette kan loggene dine trenge å suppleres, eller om du kan dra nytte av avansert filtrering i ditt webanalyseverktøy.

Segmentering går ut på å lære kjenne sine brukere og deres atferd. Det kan vise seg svært verdifullt også når det gjelder webanalyse. I og med at språk er en så naturlig faktor innen søkeanalyse, på grunn av brukernes ordvalg, er de mest åpenbare segmenteringene slikt som kobles til brukernes språk. Det trenger ikke være ulike språk som i hvilket morsmål de har, det kan like gjerne være slik at man finner lekmannsspråk kontra fagtermer.

Eksempler på segmenter som kan være interessante for å lære kjenne sin søkefunksjon er blant annet:

• Hvilken er trafikkkilden? Noe som kan oversettes til hvilket domenenavn, om man har flere, der brukeren startet sitt søk. Tenk kampanjenettsted kontra det vanlige nettstedet.
• Er det en ny søkebruker eller en tilbakevendende?
• Lojalitet og frekvens av å komme tilbake.
• Konverteringer. Blant hvilke brukere oppstår konverteringer, og hva skiller dem fra de der ingenting av interesse inntreffer? På hvilken måte bidrar søkefunksjonen til de sesjonene som konverterer?
• Gjennomsnittlig verdi. For deg som driver handel eller kan oversette en besøkendes aktivering av et mål i faktiske penger, er det interessant å segmentere frem de mest lønnsomme, de normale og sammenligne seg imellom og med de som ikke er lønnsomme. Finnes det lærdommer?
• Geografi er en klassiker. Ikke sjelden finnes forskjeller avhengig av hvor brukerne befinner seg. Kanskje finnes det noe i deres opplevelse du kan forbedre?
• Timing, altså når på døgnet skjer måloppnåelse? Kanskje er det en bestemt tid på uken, måneden eller året. Viktig at både nettstedet og søkefunksjonen er klar for dette og bidrar til en positiv opplevelse.

(La en søkeredaktør ha...) Kontroll på nullresultatene

En tilbakevendende oppgave for den som er ansvarlig for søkefunksjonen er å sjekke hvilke søkespørsmål ens brukere har stilt når det ikke fantes noen treff å vise. Årsakene til at ingen treff vises kan være flere, men det er ikke slik at brukeren bryr seg om det. Ifølge brukeren har søkefunksjonen mislyktes. Bortsett fra om den som søker ikke vil ha noen treff (type søke blant patenter, varemerker man vil registrere, etc.) er nullresultat en gigantisk fiasko. Nullresultat er dessverre ganske vanlig når man søker innenfor nettsteder eller enkelte webapplikasjoner.

Å forsøke å holde kontroll på nullresultater, og sjekke at det finnes godt materiale til de mest populære spørsmålene, er slikt man skal ha en søkeredaktør til. Som navnet antyder er det en person som med redaksjonelle tiltak sørger for at søkefunksjonen fungerer bra. Ofte trenger søkeredaktøren tilgang og tillit til å avhjelpe problemer med innhold som andre har skapt, i alle fall om hen skal kunne være effektiv.

De bekymringene jeg har snublet over til at besøkende får nullresultat har alltid vært en av disse:

1. Det finnes ikke noe relevant materiale som matcher søkespørsmålet.
2. Materialet finnes men kalles for noe annet enn det søkespørsmålet leter etter.
3. Det finnes materiale, men søkefunksjonen har et automatisk filter som gjør at brukerens søkespørsmål bare kjøres mot en delmengde av det søkemotoren kjenner til.

Alle besøkernes søkespørsmål er ikke alltid relevante for nettstedets mål, så hold kontroll på de spørsmålene som spiller rolle. Hvilke søkespørsmål som spiller rolle er et spørsmål du kun kan få svar på gjennom å gjøre grunnarbeidet med å formulere mål for nettstedet.

Om det burde finnes et innhold som matcher søkespørsmålet, trenger det å være innenfor søkeredaktørens mandat å fikse det. Iblant er det så enkelt som å legge til noen nøkkelord til det materialet som burde vises. Andre ganger kan det bli veldig avansert. Som når det trengs en synonymhåndtering, eller om innholdet finnes i en datakilde som søkemotoren ikke har tilgang til. Min bok Webbstrategi för alla har et helt kapittel om informasjonsarkitektur, der finner du tips om hvordan man kan takle denne typen problemer.

Den boken tar også opp en del selvfølgeligheter, kan man synes, om hvordan en feilside skal designes. Når det gjelder å informere en bruker om at ingen treff ble funnet, kan det gjøres på en mer engasjerende måte enn teksten «Sorry, no results». Nullresultatsiden skal være hjelpsom. Det kan være å løfte frem vanlige søkespørsmål, tilby gjetninger rundt stavemåter m.m.

«Hvorfor ikke gjøre som Google?»

Den som jobber med søk og søkeanalyse får med jevne mellomrom høre utakknemlige (og uinformerte) kommentarer om at man burde skjerpe seg. Hvor vanskelig kan det være når Google gjør det der med søk så bra?! Det finnes faktisk et godt svar på det.

Enterprise data simply isn't like web or consumer data – it's characterised by rarity and unconnectedness rather than popularity and context.
– Charlie Hull, flax⁴¹

Det korte svaret er at den informasjonen man har på sitt nettsted, eller innenfor organisasjonen, ikke er sammenlignbar med det Google gjør. Google opererer på et offentlig nett, der milliarder med sider eksisterer, de sidene lenker til hverandre, de konkurrerer om å nå ut på søkemotorene, etc. Hånden i været den webredaktøren som har fulgt opp hvor bra ens materiale har nådd ut på organisasjonens egen søkefunksjon. Hallå, er denne mikrofonen på eller? Syrlige bemerkninger til side, det er nok ikke særlig vanlig, ennå.

Også brukerne du har på din egen søkefunksjon skiller seg markant fra de som går til Google. De brukerne du har på ditt nettsted har allerede funnet frem, de gir nettopp din søkefunksjon tilliten. De som bruker Google er mer åpne for forslag om hvem som kan komme med det beste materialet. Din bruker tror seg å kunne finne noe de tror du har. Ikke minst – de har gitt ditt nettsted tilliten til å løse deres behov! Den tilliten trenger du å forvalte.

Nøkkeltall for å evaluere søkefunksjonen

Foruten at du nok allerede har skjønt at andelen søkebrukere som slipper å se et nullresultat kan være et godt nøkkeltall, finnes det litt flere forslag jeg kan gi. Vil du standardisere spørsmål og kunne sammenligne dine svar med andre søkefunksjoner, sjekker du opp Net Promotor Score (NPS), det finnes litt i denne boken om dette. Da skal brukerne svare 0-10 på spørsmålet om hvor sannsynlig det er at de anbefaler søkefunksjonen til en venn eller kollega.

Forsøk å unngå å umiddelbart havne i å måle spart tid som et nøkkeltall. Det er vanskelig å argumentere for hvilken virksomhetsnytte noen sekunder hit eller dit gir. Det drar litt mot forfengelighetstall å holde styr på hvor stor andel som har søkt og klikker på noe i trefflisten, litt det samme med at man logger om de klikker på topp tre i resultatet. Disse verdiene hjelper deg å lære kjenne sin søkebruker, men det er ikke verdige mål å styre mot.

Akkurat som at du trenger å jobbe med å sette målbare mål på det øvrige nettstedet, kan, og skal, du veve inn søkefunksjonen. Hvilke deler var brukeren på før den gjennomførte et definert mål på nettstedet? Var søkefunksjonen en del av den prosessen?

Vil du ha eksempler på søkespesifikke måleverdier og nøkkeltall, har du noen her:

• Andel spørsmål som returnerer nullresultat. Jobb mot en lav andel, i det minste i de segmentene av brukere som du henvender deg til. Et mikromål er å forsøke å unngå å gi en dårlig opplevelse, som et nullresultat er.
• Andel søkespørsmål eller sesjoner som fører til avslutning. Altså at noe i søkeresultatet ble klikket. Et mikromål at søkefunksjonen bidrar til at brukeren finner noe verdt å klikke på.
• Andel spørsmål som fører til at den besøkende forlater nettstedet. En måleverdi, ikke noe mål, for å se hvilke søkebegreper som ikke lykkes med å beholde søkebrukerens interesse. Tilsvarer avvisningsfrekvens i øvrig webanalyse.
• Hvilke søkespørsmål brukes i sesjoner der brukeren har konvertert. En måleverdi snarere enn mål.
• Hvilke er sidene på nettstedet der flest brukere starter sitt søk. Typisk måleverdi for å forsøke å finne innhold som kan trenge forbedring eller inngå i en A/B-test for å evaluere om man kan påvirke opplevelsen i riktig retning.
• Mål: Konverteringsfrekvens blant de som har brukt søkefunksjonen. Forteller når søkefunksjonen har vært en del av en sesjon som skapte verdi. Kan være vanskelig da det henger på å løfte frem innhold der konvertering kan skje, men interessant som segment for utforskning av hva innen søk som skaper verdi.

Vil du gjøre et enda dypere dypdykk i søkeanalyse, kan jeg anbefale boken Search Analytics for Your Site⁴² av Louis Rosenfeld. Det var den boken jeg leste for å plukke rosinen ut av kaken til det du nettopp leste. Noe jeg ikke har nevnt som han skriver godt om, er en evalueringsmodell av en eksisterende søkefunksjon. Står du overfor oppgaven å kunne bevise at søkets prestasjon over tid har blitt bedre, har du enda en grunn til å lese den boken.

Hva finnes i verktøykassen for webanalyse?

En utbredt misforståelse, eller kanskje overdrevet forenkling, er at webanalyse handler om å gå gjennom innsamlet nettstedstatistikk. Selvfølgelig inngår det arbeidet i å jobbe med webanalyse, men man bør være klar over at man da ser på statistikk basert på hvordan et nettsted er og ikke hva det burde være. I en viss forstand fortjener man det statistikken viser.

Kvantitative verktøy

Nesten for åpenbart til å nevne, men det vanligste kvantitative verktøyet innen webanalyse er alle våre løsninger for å sjekke nettstedstatistikken. Størst markedsandel på det markedet har freemium-verktøyet Google Analytics. Ja, Google Analytics koster penger om nettstedet ditt er stort nok. Så finnes en lang rekke andre verktøy med noen ynkelige prosent markedsandel, som Adobe Analytics og Matomo. Den typen verktøy har vi behandlet i bokens første del, og mangler du noe, lider ikke internett noen mangel på verken tips eller bøker å kjøpe om dette. I denne delen av boken skal vi i stedet fokusere på mindre vanlige verktøy. Vær forberedt på noen appetittvekkere.

Verktøy for innholdsanalyse

Søkekonsulenter vil gjerne kalle dette for indeksanalyse. Det kan faktisk være en god påminnelse for oss som har en søkemotor, at søkemotoren har kunnskap om hva nettstedet inneholder og det kan brukes til oppfølgingsarbeid. Men det finnes mer innen innholdsanalyse som ikke er fullt så naturlig å klumpe sammen med kravet om å ha en egen søkemotor.

Det søkemotorer allerede vet om ditt innhold er blant annet ting som:

• Hvilke ord som finnes på sidene. Det kan du bruke for å holde etter de ordene som organisasjonen har kommet frem til at man ikke skal bruke. Sammenlign med New York Times' liste «Words we don't say»⁴³, men også nyttig for å se om det mangler noe begrep man vil bli funnet på.
• Om sidetitlenes lengde er innenfor god SEO-praksis, si under 70 tegn? Søkemotoren kunne liste de lengste sidetitlene som en rapport.
• Krysssjekke om vanlig ettersøkte ord finnes i sidetitler, overskrifter eller strukturert HTML-markup. Nyttig for å lete etter uutnyttet SEO-potensial, ikke minst for eksterne søkemotorer.
• Følge opp hvilken type materiale som legges ut. For de som anstrenger seg med å bygge en bedre mobil opplevelse, er det interessant å sjekke at trenden av publiserte PDF-dokumenter er avtagende.

Enkelte slike verktøy får man med på kjøpet om man jobber med søkeanalyse for sin egen søkemotor. Vil man se tilsvarende tall for Google, finnes det en stadig voksende verktøykasse på deres Search Console (tidligere Webmaster Tools) og Bing har noe tilsvarende.

Bilde 40: Google Search Console viser hvilke ord den frekvent finner på min bokblogg.

Dessuten kan (den egne) søkemotorens metoder for å samle inn innholdet til sitt indeks sikkert suppleres slik at du slipper å ta frem enda et verktøy som crawler rundt på ditt nettsted. I sin enkleste form er det å utvikle rapporter for når søkemotoren støter på potensielle problemer. Som hvor ofte, eller på hvilke undersider, den støter på 404-feilsider. Eller om den støter på en side med identisk innhold som noe på en annen adresse.

Innen innholdsanalyse rommes som sagt mer enn søketeknikker, noe verktøyet som betalingstjenesten Siteimprove tar fatt i. De fanger inn ødelagte lenker, stavefeil og utfører til og med en del tilgjengelighetstester. For deg som ikke har en ambisiøs søkemotorstrategi kan Siteimprove muligens være løsningen for å holde etter det språklige, slik at den redaksjonelle stilen og merkepresentasjonen følger den kommunikative policyen man har.

Bilde 41: Google rapporterer hvilke brukervennlighetsproblemer de har funnet i innholdet på et nettsted.

Sist men ikke minst innen innholdsanalyse er å samkjøre statistikken over hva som får besøk ifølge din webstatistikk med alt det søkemotoren kjenner til eksisterer. Det som i løpet av 12 måneder ikke har kommet til bruk, burde du kanskje automatisk slette eller arkivere?

Logganalyse

Å analysere logger har igjen fremtiden for seg. Før verktøy som Google Analytics slo igjennom midt på 2000-tallet, var det diverse loggverktøy mange av oss hadde tilgang til. Forskjellen mellom Google Analytics og et loggbasert verktøy er hvordan de samler inn sine data. Google Analytics har historisk sett vært basert på å ligge nær brukergrensesnittet og ha kontroll på bruken som en tredjepart som blir involvert i kommunikasjonen. Enten har man sporet brukere gjennom små kodesnutter med Javascript, men visse lignende verktøy har kjørt med gjennomsiktige små bilder som alternativ metode.

Logger samles derimot inn uten å blande inn tredjeparter. Tilnærmet enhver teknisk dings eller programvare skriver en loggfil bak kulissene. Litt som en dagbok for å vise frem for utviklere eller forvaltende teknikere når de leter etter årsaken til noe.

Grunnen til at jeg tror logganalyse igjen kommer til å bli interessant for stadig flere, er at mange har begynt å nå innsikten om at brukere selektivt blokkerer innhold. De fleste sikkert for å verne om sin integritet. Logger er noe en bruker ikke kan blokkere, det håndteres innenfor tjenesten som brukes.

Akkurat som nevnt i delen om søkeanalyse kan disse loggene bearbeides av programvarer som skaper en merverdi. Plutselig kan man analysere andre ting enn de strengt introverte tekniske aspektene. Man kan få innsikt i hva en programvare driver med, hvilken service den gir brukere.

Vil man gjøre dette i litt større skala finnes verktøy som Splunk og Logstash. Splunk er en programvare som koster etter mengden informasjon man leser inn. Den kan hjelpe deg å dekryptere loggene, finne mønstre og relasjoner. Informasjonsmodellering rett og slett.

Logstash derimot, som en del av ELK-stacken, Elasticsearch-Logstash-Kibana, er et åpent verktøy hvis forretningsmodell er å selge support til større organisasjoner. Produktet i seg selv er gratis, men det kan kreves mye energi å komme i gang.

Fordelene med Splunk og Logstash er at de er produktifiserte. Da blir de mer forståelige fra et IT-innkjøperperspektiv og det finnes support å kjøpe til. Begge løsningene koster en god del penger, men på ulike måter. Å bruke Splunk koster etter hvert som du har vendt deg og ser nytten, mens Logstash krever en mer aktiv IT-forvaltning og utgiftene kommer før nytten er åpenbar.

Nå finnes det en stadig voksende skare av konkurrenter til at IT-avdelingen eier spørsmålet om BI (Business Intelligence). Disse verktøyene fokuserer på at den digitalt modne kunnskapsarbeideren skal kunne hjelpe seg selv. Tableau er et hypet slikt verktøy som fokuserer på selvbetjening for å inspisere mer eller mindre store datamengder. Som hvilken klassisk programvare som helst installeres det på en datamaskin, og så leser du inn en loggfil (eller annen strukturert informasjon). Etter det er det bare å begynne å utforske datakilden. Gjerne gjennom visualisering, noe som får avvik til å stikke ut. En hengiven BI-konsulent jeg ofte møter i disse kretsene pleier å benevne Tableau som et Photoshop for data, med poenget om dets enkelhet til å vise opp noe.

Det jeg selv har hatt enorm nytte av Tableau for, er å raskt sjekke en loggfil fra flere perspektiver. For eksempel en loggfil med noen hundretusen rader med «trege» databasespørringer fra et nettsted som var ekstremt avhengig av databasen for å presentere innhold. Jeg hadde stilt inn slik at databaseserveren noterte en databasespørring til en loggfil om spørringen tok lengre enn 0,5 sekunder å kjøre. Jeg hadde tre ulike typer data i loggen:

1. Tidspunkt for når databasespørringen ble stilt.
2. Hvor lang tid databasespørringen tok å kjøre ferdig.
3. Selve databasespørringen, altså hvilket innhold som ble etterspurt.

Det jeg kunne gjøre takket være visualisering var å ganske enkelt se på denne ellers ganske uhåndterlige datamengden fra flere vinkler. Jeg kunne raskt utelukke at tidspunkt på dagen forårsaket noen treghet. Derimot fantes en sammenheng mellom tiden spørringen tok å fullføre og hvilken tabell i databasen spørringen ble stilt mot (noe som fremgår av databasespørringen). Resultatet var et svært presist underlag for i hvilke deler av systemet det fantes bremseklosser, og hvilke deler som ikke i det hele tatt hadde med saken å gjøre.

Bilde 42: Iblant kommer brukeren ikke engang i kontakt med webserveren.

Dessverre trenger man å være oppmerksom på om man et sted har data som gir et rettferdig bilde av situasjonen. På min arbeidsplass har vi hatt en lengre periode med nøling rundt sikret kommunikasjon over nettet (med SSL-sertifikat). Vår IT-avdeling har ikke vært enig med verden om hvordan et troverdig sertifikat skal se ut, noe som har ført til at våre brukere i visse tilfeller har blitt hindret fra å komme frem til våre tjenester. I visse tilfeller har vi hatt data, for eksempel de gangene brukerne ble stoppet av vår brannmur.

Bilde 43: En brannmurs primære formål er ikke å hjelpe en webanalytiker, men den logger sikkert data du kan bruke.

Hos oss var loggfilen i brannmuren så omfattende at den var nødt til å nullstilles med jevne mellomrom. Utover det var filen så pass stor at det ville bli et stort prosjekt i seg selv å sile frem passelig mye innhold slik at det kunne inspiseres i en programvare vi var kjent med. Det var ved første øyekast ikke verdt anstrengelsen i dette tilfellet.

Ytelsesanalyse

Bilde 44: For å verifisere andre ytelsesdata kan man sammenligne med hvor raskt det har gått for Google å indeksere ditt nettsted.

Rapporter for et nettsteds ytelse kan man få fra flere ulike hold. Vil man ha en kvantifiserbar oversikt, er Googles Search Console nyttig om man går til rapporten Crawlstatistikk. Men er du villig til å betale, sjekk for all del ut Pingdoms tjenester. Fordelen med Pingdom er at de er spesialisert på ytelsesovervåkning og der kan du spesifisere hvorfra overvåkningen skal gjøres. Har du et nettsted som skal gi service for et nordisk marked, er det ikke så interessant hvor raskt det går for en besøkende på USAs vestkyst. Lysets hastighet er riktignok rask, men i disse sammenhengene ikke raskt nok. Med Pingdom kan du for respektive test velge om overvåkningen skal gjøres fra servere i Europa, Nord-Amerika eller Asia.

Bilde 45: Pingdom viser oppetid og svartider for 10 nettsteder om man betaler for seg.

En nyere funksjon i Pingdom er å få vite mer detaljer om nettstedets ytelse. I dette tilfellet peker man ut en eller flere av ens viktigste sider og så overvåkes materialet med et tidsintervall. Det her kan være en god måte å holde kontroll på sine viktigste landingssider, slik at ikke en ubetenksom webredaktør kommer til å publisere et for høyoppløst bilde, eller at andre slurv ikke blir rettet opp i rimelig tid.

Bilde 46: Pingdom anmelder min bokbloggs startside.

Det siste kvantitative ytelsesverktøyet jeg hadde tenkt å tipse om er at du som uansett har Google Analytics faktisk har en visning for Googles verktøy Pagespeed Insights. Der får du vite hvor godt nettstedet ditt presterer og det kan være en god liste for deg som akkurat skal begynne med ytelsesoptimalisering.

Det finnes en lang rekke verktøy som kanskje ikke går under kvantifiserbart flagg i den forstand at man har en stadig pågående innsamling av data. Men mange av disse verktøyene kan integreres, eller av en utvikler hackes sammen, slik at de blir kvantifiserbare og interessante på annen måte enn som manuelle stikkprøver. Det er nå du hopper til det om kvalitative verktøy om du ikke orker teknikaliteter :)

Bilde 47: Apica sjekker hvordan mitt lille nettsted klarer 10 samtidige brukere.

En interessant arbeidsmetode er å være proaktiv og sjekke hvordan nettstedet ditt har det under belastning, å sjekke om det da viser svakheter som kan være verdt å fikse. Et selskap som driver med dette er Apica⁴⁴ og de har verktøyet Loadtest som kan simulere en tilstrømning av brukere til ditt nettsted. Den her typen verktøy har IT-personell som sin primære målgruppe, så de finnes kanskje allerede i din organisasjon, men jeg tror at en normalbegavet webanalytiker fikser denne typen løsninger. Du vil merke at grensesnittene kan være litt uferdige for førstegangsbrukere.

Et annet verktøy du nok ikke har gått glipp av om du følger bloggen min eller vært på noen av mine foredrag, er Googles Pagespeed Insights⁴⁵, som kan brukes frittstående fra Google Analytics. Jeg har siden 2010 brukt det for å belyse behovet for å jobbe med webytelse, hatt topplister og alt i alt sammenlignet titusenvis av nettsteder mot hverandre. Det Pagespeed bidrar med er at det har et API som gjør at man kan integrere sin kontroll for eksempel med sitt CMS. Design gjerne slik at når en side opprettes eller endres, sjekkes den mot en liste av eksterne API-er om den holder mål ifølge deres ytelsesbudsjett. Eller så gjør man som jeg og har semi-automatiske kjøringer av et sett med sider, og når noe mindre bra finnes, varsles berørte personer.

Pagespeed har utover ytelsesfaktorer for mobil og datamaskiner også en rekke brukervennlighetsfaktorer den sjekker. Som om lenker er for tett plassert, om innholdet får plass på skjermen og en del til.

Bilde 48: Sitespeed.io er en hjelpende hånd for den som orker litt teknikk.

Et svensk og åpent prosjekt som på mange måter erstatter Pagespeed Insights er sitespeed.io som gjennom å være et lag mellom deg og API-ene sjekker nettsiden mot både WebPagetest og Pagespeed Insights. For deg som er nysgjerrig finnes prosjektet selvfølgelig på Github der du kan laste ned all deres kode⁴⁶.

Apropos WebPagetest, som allerede er nevnt for deres visuelle sammenligning mellom to ulike nettsteder, er også det et åpent prosjekt. Med litt anstrengelse kan man ha sitt eget lokale miljø for å gjøre de samme testene. Dette er bra for eksempel for deg som vil jobbe med intranettanalyse, eller om du vil kjøre mange flere tester enn gratistjenestene tillater.

Kvalitative verktøy og metoder

For deg som gjespe seg gjennom forskjellen mellom det kvantitative og det kvalitative kan jeg nevne at kvalitative verktøy og metoder er det som ligner stikkprøver. Slikt som ikke imponerer de som jobber med statistikk. Men nytten med kvalitativt arbeid er å gi perspektiv og få svar på spørsmål, ikke bare å kjenne til omfanget av noe. Så det er uten tvil viktig å også jobbe med det kvalitative.

Mange av de kvantitative verktøyene har aspekter som gjør at man kan undersøke enkelte deler av noe, altså kan også de brukes kvalitativt, men jeg hadde ikke tenkt å gjenta dem unødvendig her.

Mange tenker nok på user experience eller tjenestedesign når de hører «kvalitative metoder» og det er ikke så rart, det er en naturlig del for å få oversikt over situasjonen. Vanligvis forbindes kvalitative metoder med ting som:

• Spørreundersøkelser for å forstå de eksisterende brukerne.
• Dybdeintervjuer for å lære seg mer om de tiltenkte målgruppene, deres behov, vaner og preferanser.
• Konkurrentanalyse for å se hvordan man står seg sammenlignet med noen andre.
• Etnografiske studier der man observerer brukerne i deres naturlige miljø.
• Brukertester der man undersøker om det som er konstruert er brukbart, eller hvilke vanskeligheter som kan identifiseres.

Alt dette kan man gjøre med en høyst varierende ambisjonsnivå. Selv om dette er litt utenfor bokens emne, og at det ikke er min ekspertise, hadde jeg tenkt å gi noen tips om det man relativt enkelt kan løse selv.

For punktene listet ovenfor mangler det ikke god litteratur, derfor hadde jeg ikke tenkt å gi meg i kast med å skrive om dem når andre allerede har gjort det så bra. I stedet henviser jeg deg som vil ha en lettbeint læring om hvordan man følger opp og evaluerer brukeropplevelse til Steve Krugs bok Rocket Surgery Made Easy⁴⁷. Du som i stedet vil lese noe avseelig mer akademisk kan sjekke ut boken The Elements of User Experience: User-Centered Design for the Web and Beyond⁴⁸. Steves bok kommer til å gi deg en arbeidsmetode som du tør å prøve selv, noe du kan begynne med til nesten ingen som helst kostnad og øvelseskjøre på kollegaer før du gir deg i kast med utenforstående. Den andre bokens styrke er snarere i sin bevisføring rundt respektive metodes fortjenester. Den kan være bra også for den utålmodige leseren å øyeblikke gjennom for å senere bruke som referanseverk.

Noe som forener de fleste av ovennevnte kvalitative metoder er at de involverer brukere på en eller annen måte. Det kan virke som det er det eneste man har i verktøykassen, men jeg vil påstå at det er direkte feilaktig. At mange av oss har det bildet skyldes at det er nettopp de delene som er forståelige å pakke inn som et tilbud. La oss ikke bli begrenset av hva konsulenter føler seg komfortable med å tilby og sette en prislapp på. La oss i stedet være åpne for alt som kan tenkes å gi innsyn i enkeltes brukeres opplevelser.

Det finnes en lang rekke spesialister du kan dra nytte av for å gjøre en kvalitativ oversikt. Personer som med litt forberedelse kan utrede kvalitative aspekter, gjøre stikkprøver og gi tilbakemelding om tenkelig potensial. Flere av dem har du sikkert allerede som kollegaer. Jeg selv, som ser på nettet fra en webutviklers synspunkt, har en hel del triks du neppe finner hos et brukervennlighetsfirma. Jeg har vanskelig for å tro mindre om andre yrkesgrupper.

RUM-verktøy – vis frem brukernes faktiske opplevelse

Vil du i stedet ha litt mer sikre resultater du ikke trenger å kunne begrunne på egen hånd, finnes alltid RUM (Real User Monitoring) å ty til. Det er i visse tilfeller litt av en uhellig miks mellom kvantitativt og kvalitativt, i alle fall om du har massevis med brukere. Det RUM gjør er å inspisere ekte brukersesjoner og vise dem frem for deg, uten at du trenger å samle sammen brukerne eller oppsøke dem. Slurvet uttrykt spiller man inn brukerens hele sesjon ved hjelp av diverse verktøy. I etterkant kan man så inspisere den brukersesjonen, filtrere blant de innsamlede brukersesjonene i jakt på noe spesielt.

Det kan være en effektiv måte å legge frem sin sak overfor kollegaer, ledere eller kunder. At brukere faktisk har hatt akkurat den opplevelsen.

Bilde 49: Inspiser anonymiserte brukeres sesjoner på nettstedet.

I Google Analytics finnes disse sesjonene under Audience –> User Explorer. Der kan du se litt overordnet informasjon om brukere som gjør at du kan velge å inspisere de opplevelsene som har ført til konvertering, eller hva du nå finner interessant å undersøke. Respektive bruker er avidentifisert og representeres i stedet av et Client Id.

Ved å merke opp innholdet ditt med metadatastandarden Schema.org kan du hjelpe Google å forstå hvilken verdi respektive aktivitet har. Det kan lette når du vil kunne sammenligne konverterende brukere seg imellom. Kanskje finnes det noe å forbedre?

Bilde 50: Rapport fra en brukers opplevelse av å kjøpe en bok.

Bilde 51: Hotjar sporer hvor brukerens musmarkør har beveget seg.

Andre verktøy er for eksempel Hotjar⁴⁹ og Clicktale⁵⁰. Begge har funksjoner for å visuelt spille inn brukerens opplevelse av et nettsted. Man kan se nøyaktig hvor brukeren har stoppet opp, hvor musepekeren beveger seg over skjermen og hvordan de tar seg gjennom det innholdet og delmomenter som finnes.

Det som gjør denne typen verktøy høyinteressante er at de gir innsikt i hvordan brukerreisen faktisk ser ut på vei mot et mål. De gir litt mer kvalitativ vinkel på den ellers så dominerende omvandlingstrakten (conversion funnel på engelsk). En omvandlingstrakt gir deg informasjon om kvantiteten av konverterende brukere i respektive delsteg, mens dette gir deg kvalitativ innsyn i hvordan den opplevelsen kan arte seg.

Pingdom, som vi kommer til å snakke mer om under ytelsesdelen, har også de et RUM-verktøy. Grovt forenklet måler Pingdom hvor raskt et nettsted laster, og normalt sett har de en gjeng servere utplassert rundt kloden som gjør dette for oss. Men det gir jo egentlig ikke kvalitative data, kun kvantitative data, eller rent av fiktive. De har ingenting med en ekte brukers opplevelse å gjøre. Det Pingdoms RUM-verktøy kan være bra til er om man vil vite hvor godt ens nettsted laster for brukere på et annet kontinent. Jeg som historisk har driftet mine private webprosjekter hos Loopia i Västerås burde kanskje vurdere å flytte innholdet nærmere brukerne. Med hjelp av Pingdoms RUM kan jeg følge opp om min engelske blogg er tålelig for ekte brukere som kobler til fra USAs vestkyst. Det er et godt verktøy for å kunne agere basert på ekte data.

Bilde 52: Med Pingdoms RUM-verktøy kan man stille inn hvilke man sporer og hvilke terskelverdier man vil gruppere informasjonen i.

Teknisk kvalitet ved konstruksjon

Bilde 53: Pagespeed Insights gir beskjed om en sides ytelse og brukervennlighet.

Både Google Pagespeed Insights og Sitespeed.io er gangbare også som kvalitative verktøy når man vil gjøre stikkprøver rundt ytelse og det tekniske miljøet. Det kan trenge å gjøres rett etter driftsetting for å sikre at forventet kvalitet er oppnådd.

Jeg håper ikke at konseptet rundt tilgjengelighet kommer som en overraskelse for noen. Det går an å legge veldig mye anstrengelse i den typen arbeid. Iblant er man nødt til å legge mye tid på det da det i stadig flere sammenhenger lovfestes om et minimumsnivå. I USA finnes Section 508⁵¹ om at informasjons- og kommunikasjonsteknologi skal være tilgjengelig. I 2015 ble den svenske diskrimineringslovgivningen skjerpet og begynte å gjelde også i digitale sammenhenger, det ble altså ulovlig å ikke tilby et grunnleggende nivå av tilgjengelighet. Mens boken skrives har jeg ikke fått kjennskap til noen prejudikater om nøyaktig hvor strengt loven tolkes i ulike sammenhenger, men det er verdt å følge med på svensk praksis noen år etter at en ny lov har kommet til. Utover dette ble det i 2016 inngått en avtale⁵² innen EU om at myndigheters nettsteder, intranett og apper skal ha en god tilgjengelighet. Populært kalt Webdirektivet.

For å gjøre seg kjent med emnet kan man teste sin tekniske kvalitet, altså evaluere den koden som lander i brukernes nettleser. Både webstandardorganisasjonen W3Cs tilgjengelighetsstandard WCAG og svenske Webbriktlinjer.se tilbyr en hurtigtest⁵³ du kan prøve. Det er en rekke spørsmål å besvare.

Bilde 54: Det finnes bilder uten korrekt håndtering av alternative tekster hos gp.se

For en mer allmenn kvalitetskontroll finnes det et uendelig antall verktøy som henvender seg til utviklere av ulike sorter. Men et verdt en titt for hvem som helst som bare vil gjøre en helsesjekk på en side, er webbyrået Netrelations Inspector⁵⁴. Det gir rett fram og forståelige beskjeder om blant annet tilgjengelighet.

Visuelle tester

Før mobilbrukernes inntog på nettet pleide webutviklere ofte å manuelt sjekke hvordan det de bygde så ut i de 2-3 siste versjonene av Internet Explorer, siste Firefox og Chrome. I dag er imidlertid variasjonen så enorm at det ikke er mulig å teste på den måten. Det er heller ikke gjennomførbart for de fleste å kjøpe seg utstyr for å teste med, da det stadig trenger å fornyes.

Bilde 55: Hos Filament Group har man et såkalt «device lab» for å kunne prøve design på ulike enheter.

En forskjell siden før smarttelefonene var at da var ambisjonen å gjøre nettsteder «pixel perfect». Det vil si at man sendte lange lister med krav på hvordan ulike ting skulle flyttes noen piksler hit eller dit. Pikselflyttingen har heldigvis de fleste gitt opp i og med responsiv webdesign. Kanskje fordi man har forstått at det er banne meg umulig å få det til å se identisk ut på alle enheter.

En løsning på denne utfordringen er å dra nytte av tjenester som BrowserStack⁵⁵. De har utstyr du kan prøvekjøre via nettet for å vite hvordan et nettsted ser ut. I skrivende stund har de Windows- og Mac-datamaskiner, iOS- og Android-enheter. Merk at det er respektive enhets ekte nettleser som brukes, det er ingen simulering.

BrowserStack kan også integreres i utviklerverktøy slik at testene håndteres litt mer automatisert. Da kan man ha lagrede bilder for å kunne granske om noe har skjedd med viktige sider, dessuten får du en logg over hvordan det har sett ut historisk. Visuelle tester går ut på at viktige designelementer skal synes og ha forutsetning for å fungere, det handler ikke om å overvåke layouten eller detaljer innen formgivning. Du bør være mer interessert i om din call-to-action er borte enn om logoen er en piksel på skeive.

Nå finnes det jo tusenvis av ulike kombinasjoner av enheter og nettlesere. For å begynne å velge litt i den jungelen kan et tips være å kontrollere hvordan det ser ut i de enhetene som har høyest avvisningsfrekvens på ditt nettsted.

Bilde 56: Fra min Mac låner jeg en Windows 7-datamaskin over nettet for å sikre designen på min feilside.

Lag en testside for å evaluere endringer i webdesign

For at det skal være en rettferdig sammenligning fra en måling til en annen, trenger man å teste under de samme forutsetningene. Med andre ord må man sette opp en testside på nettstedet sitt, og den siden er den man gjør tester mot for å vite at resultatene er sammenlignbare over tid. Det som kan variere er webserverens svartid, men sidens innhold i redaksjonell forstand trenger å være det samme fra en gang til en annen.

Gjør du det på denne måten, vet du om endringer i nettstedet har gjort situasjonen bedre eller dårligere. Det kan være at du prøver å bytte tema om du kjører Wordpress, at utviklerne dine har oppgradert noe eller muligens gjort en nyutvikling.

Hvordan man utformer sin testside

For at testsiden din skal være meningsfull gjelder det at den i redaksjonell utforming er den samme over en lengre tid. Om du skal kunne sammenligne resultatet før en oppgradering av publiseringssystemet med etter, gjelder det at innholdet er det samme.

Mitt forslag er at du oppretter en underside utelukkende beregnet for test. Den siden skal inneholde tekst, bilder og slikt som er normalkomplekst for en vanlig side på nettstedet. Det er ikke her du bygger inn en masse merkelige eksterne tjenester, widgets, videoklipp eller slikt som verken du eller de andre involverte har kontroll over.

Gjør en nullmåling

Når du har testsiden din, gjør du en første måling hos de tjenestene du vil bruke, som Google Pagespeed. Så avstemmer du resultatet med alle involverte og dokumenterer det et sted (slik at folk forstår at dette må de leve med fremover). På en passende høytidelig måte burde man sikkert forklare at det ikke er akseptabelt at resultatet blir dårligere over tid, snarere at det bør forbedres.

Ved neste oppdatering eller endring trenger man å sjekke at det faktisk ikke blir dårligere, helst skal det bli bedre, men definitivt ikke dårligere. Med andre ord burde eventuelle eksterne parter, som konsulenter, allerede i oppdraget få vite hvilke akseptansekriterier som finnes. For eksempel at du krever i oppdragsbeskrivelsen at:

Da vi i dag har 67 av 100 ifølge [deres rettesnor], samt at dere som utfører har akseptert å overgå dette nivået, er det å betrakte som en garantisak uten kostnad for oss som kunde om leveranse på opprettet testside ikke er absolutt minst 70 av 100 ifølge [deres rettesnor].

Jeg er ikke jurist, men om utføreren mislykkes med dette bør man forhåpentligvis kunne la være å betale den siste fakturaen.

Noen flere perspektiver på webanalyse

Først og fremst vil jeg som alltid påpeke at det du finner i ditt webstatistikksystem trolig bare er en delmengde av de dataene du trenger for å gjøre et ordentlig arbeid innen webanalyse. Denne innsikten når du sikkert så fort du funderer videre på hvordan du måler virksomhetsmål på nettstedet.

Nøkkeltall (KPI - Key Performance Indicator)

Nøkkeltall er ikke et begrep som er eksklusivt for nettet. Snarere er det et etablert begrep fra lenge innen forretningsverdenen. Et nøkkeltall i vår sammenheng forteller hvordan nettstedet bidrar med verdi til organisasjonen. Det kan være hvordan en kundes aktivitet på nettstedet kan omsettes i kroner og øre, eller hvordan for eksempel organisasjonens omdømme har blitt påvirket.

Mange organisasjoner har allerede nøkkeltall. Det du som webanalytiker har å gjøre er å se om de kan brukes også på nettet. Det er en utmerket måte å gå fra diffus hobbyvirksomhet til å få lederne i organisasjonen til å forstå hvilken nytte nettstedet bidrar med. Det gjør det lettere å forsvare ønskede investeringer og er det felles språket man kan bruke ved heisspitcher med øverste sjef, samt det man tipser om til årsrapporten.

Virksomhetens mål med nettstedet

Om det ikke finnes noen nøkkeltall som kan gjenbrukes (eller lett modifiseres for gjenbruk på nettet) kan du forhåpentligvis finne deres virksomhetsmål dokumentert et sted. Om dere tilfeldigvis mangler både virksomhetsmål og nøkkeltall som er anvendelige på nettstedet, havner deres problem litt utenfor emnet for denne boken, men jeg ville gjette at dere ikke er alene. Tvert imot er det nettopp hva jeg ofte har fått høre når jeg har stilt mine oppdragsgivere det ultimate spørsmålet; «Hvorfor har dere et nettsted, egentlig?!». Det pleier å bli en veldig masse hosting, stirring nedover, skraping med føttene mot gulvet og generelt distré atferd. Jeg forstår at folk skammer seg, men jeg tror ikke at det er så uvanlig.

Sannheten er nok at mange står akkurat i skiftet mellom å ha et nettsted «fordi alle andre har et» og å finne ut nøyaktig hva man vil ha ut av sitt nettsted. I mange tilfeller er de jeg har snakket med midt i et organisasjonstre. Da er ikke alltid de overordnede målene relevante for ens eget nettsted. På sin egen nivå i organisasjonen har man ikke alltid oppsatte virksomhetsmål, eller så er ikke kjennskapen til dem særlig høy.

For myndigheter og offentlig sektor kan man i verste fall lese oppdragsbeskrivelsen man har fått fra staten. Der står ens oppdrag formulert på verst tenkelige byråkratiske språk.

I privat sektor er siste årsrapport sikkert et sted å finne virksomhetsmål, men også mer kortsiktige forhåpninger. Om man har en god forretningsplan dokumentert, vil virksomhetens mål og nyttiggjøring finnes beskrevet der.

Eksempler på formulering av nøkkeltall

Eksempler på hva man kan ønske å måle med hjelp av et nøkkeltall er noe sin påvirkning på ting som:

• Salg
• Fortjenestemargin
• Kostnadsreduksjon
• Gjennomsnittsnivå på kundetilfredshet på en skala
• Maksimal ventetid for en kunde

Da jeg gjorde research på hva et godt nøkkeltall kan tenkes å være, fant jeg frem til boken Key Performance Indicators (KPI): Developing, Implementing, and Using Winning KPIs. Den mener at gode nøkkeltall har følgende egenskaper:

1. Ikke er hardt knyttet til finansielle mål. Det skal ikke uttrykkes i valutatermer. Her er det akkurat som i øvrig webanalyse trenden eller endringen som er interessant.
2. God timing. Det bør gå an å se hvordan nøkkeltallet presterer oftere enn årlig i årsrapporten. Helst vil man jo ha dette oppdelt og sammenligne en time med en annen, men i det minste trenger hver dag eller uke å ha et avstemningspunkt for nøkkeltallets prestasjon.
3. Beslutningsfokus. Ledere av virksomheten skal kunne agere basert på nøkkeltallene.
4. Er forståelige. Samtlige ansatte bør forstå måleverdiens nytte, kunne finne ut hvordan det måles og på hvilken måte man kan agere for at resultatet skal bli bedre.
5. Kan knyttes til bestemte grupper. Ansvaret skal kunne tildeles en enkelt gruppe ansatte og denne gruppen skal gjennom sitt arbeid kunne påvirke nøkkeltallets trend.
6. Har et merkbart gjennomslag. Her kommer meningsfulheten inn, at nøkkeltallet skal gjøre meningsfull nytte i virksomheten. For deg som jobber med balanserte styringskort skal nøkkeltallet påvirke flere enn ett eneste styringskortes perspektiv.
7. Har en begrenset ukjent faktor. Et godt nøkkeltall oppmuntrer positive aktiviteter. Et dårlig gjennomtenkt nøkkeltall derimot kan føre til en ikke-ønsket atferd hos de ansatte, for eksempel at kundestøtten hardselger i stedet for å hjelpe kunden med årsaken til samtalen.

Nøkkeltallene kan i seg selv være av ulike sorter, nemlig om de er kvantitative eller kvalitative. Dette er ikke en bok om statistikk, men noen grunnleggende innsikter i det statistikere jobber med er sunt for enhver webanalytiker. Dette blir litt av en repetisjon, men også en utvidelse av kvalitativt versus kvantitativt.

Kvalitative data, metoder og informasjon - data om følelser, holdninger, opplevelser og meninger

Kvalitative data er de som ikke direkte tiltaler statistikere, de er mer av den ustrukturerte sorten som ikke enkelt kan bearbeides av datamaskiner. Eksempler på kvalitative data er spørreundersøkelser, synspunkter fra brukere, liker-klikk og lignende. Oftest er disse uttrykt på den måten som folk selv uttrykker seg, med menneskelig språk, det vil si på en måte som gjør det vanskelig å tolke om man ikke leser dem og vurderer dem.

Kvantitative data og metoder - data om bruk og atferd

Kvantitative data er, som navnet antyder, data som følger statistiske modeller for hvordan man beskriver noe. Vanligste kilden innen webanalyse i dette tilfellet er nettstedstatistikken der man samler data om hvordan brukere beveger seg på nettstedet – deres atferdsdata som gruppe altså. Så kan det finnes andre datakilder som påvirkes av aktiviteten på nettstedet, eller omvendt at aktiviteter utenfor nettstedet påvirker nettet. Eksempler på det sistnevnte er plutselige trafikktopper og i den grad man kan finne ut årsaken. Det kan handle om helt normal sesongvariasjon, men det kan skyldes utbrudd av sykdommer, midtsommerværet og mye annet.

Standardiserte metoder og måleverdier

For å kunne sammenligne seg med andre organisasjoner finnes det en poeng i å forsøke å gjenbruke andres målbare mål. En måte er å sjekke nettsteder der man lister vanlig brukte nøkkeltall, en annen er å bruke samme verktøy, eller benytte eksisterende metoder for måling. Da får du også hjelp med hvordan målingen skal foregå.

CTR – Click Through Rate, eller gjennomklikkfrekvens

CTR har nok de fleste hørt om. Det handler om å i prosent angi hvor stor andel som har blitt eksponert for et tilbud (ofte kalt call to action) og deretter klikket seg videre mot det felles målet. Dette tilbudet er altså en vei man kan navigere ved å klikke på en knapp, eller lignende, for å legge et produkt i handlekurven, melde seg på et nyhetsbrev, m.m. Om en knapp har en CTR på 77 % innebærer det at 77 % av de som tok del av den valgte å klikke på den. En CTR på 4,1 % i Googles søkeresultater innebærer at 4,1 % klikket på akkurat ditt treff. Hva de andre gjør kan man ikke utlese av en CTR, det er ikke hva man måler. Det hender også at man på sider med flere samtidige tilbud snakker om en CTR som at noe av ens tilbud fikk et klikk.

Iblant hører man det fortelles om hvilken CTR noen har og omgivelsene gir lyd fra seg av å være imponert, eller kommenterer at «det var uvanlig bra». Skal jeg være helt ærlig, har jeg ennå ikke selv forstått dette, og av den litteraturen jeg har lest finnes det ingen optimal CTR. Heller ikke at det skal være meningsfullt å forvente seg en viss CTR. Det her drar mer enn lovlig mot at man måler forfengelige ting. At en viss andel brukere har klikket seg til neste steg betyr ikke at noe virksomhetsmål er oppnådd. Det er likt antall sidevisninger en isolert måleverdi som forteller en historie om bruken, men verdien av den kunnskapen er i seg ekstremt lav annet enn for den som jobber med det spesifikke nettstedet.

Men med det sagt kan det være verdt å eksperimentere med sin CTR for å se om man kan styre om brukernes oppmerksomhet, altså heve sin CTR, og om det i forlengelsen har et positivt sluttresultat. Det er ikke sikkert at en hevet CTR fører til høyere konvertering. Det er det digitales motpart til en pågående selger. På de nettstedene jeg har inspisert er veien frem til en konvertering ofte lang og krokete. Det er ikke selvfølgelig at det fungerer å forsøke å forkorte tiden for brukerens overveielse. Derimot, om man lykkes med å identifisere et brukersegment man tør å eksperimentere med, så sett i gang.

Måter å eksperimentere med høyere CTR:

• Jobb med A/B-testing på ditt eget nettsted eller i annonsesammenheng for å finne ut hvilken som får høyest CTR. Utover det må du være oppmerksom på eventuelle negative konsekvenser. Kanskje forårsaker pågåenheten at brukerne konverterer i mindre grad på de for organisasjonen mest verdifulle tilbudene.
• Let opp sider med lav CTR i søkemotorene og modifiser sidetitlene. Det kan også være verdt å modifisere andre metadata på siden. For å finne siders CTR hos for eksempel Google kan du sjekke ut deres verktøy Search Console.

Bilde 57: Oversikt for min arbeidsgivers CTR hos Google.

Hopping (pogo-sticking)

Brukeratferden å hoppe frem og tilbake mellom sider gjelder nok primært de sidene som har et søkelignende grensesnitt, produktlistinger eller lignende. Det handler altså om at man sporer hvor lenge en bruker blir på en underside de har nådd via en liste med mange andre alternativer. Om dette er en atferd som er verdt å spore på ditt nettsted, vet bare du. Det sies at Google er nysgjerrige på dette for å kunne sammenligne ulike søketreff seg imellom. Det er riktignok bare et signal blant flere andre, men det er nok grunnlag for at en sides relevans er lav om det er vanlig at brukerne raskt som blåbær hopper tilbake.

Ta to sider med identisk relevans på et søkespørsmål hos Google. Om en av sidene i høyere grad enn den andre forårsaker at brukerne kommer tilbake, finnes det nok grunn til å senke dens relative verdi. På samme måte kan man tenke rundt hvordan man selv lister innhold på sitt nettsted. Er det verdt å beholde alt i listen, eller kan listen som helhet prestere bedre om man gjør en endring? Hva skal ligge øverst og hvorfor?

Måter å forsøke å redusere hoppingen:

• Forbedre lastetiden og se om det endrer noe. Det kan være at man har et for tungt bilde, eller venter på et tregt eksternt API.
• Tydeligere bekreftelse av sidens verdi. Det kan skyldes designfaktorer at brukerne ikke forstår eller kan avkode sidens innhold og dermed hopper tilbake. En måte er å forsøke å redusere den kognitive belastningen for brukeren til å finne ut at hen har havnet riktig.

Oppholdstid (Dwell time)

Denne får man være forsiktig med, men i stor skala kan den være meningsfull for å for eksempel vite om lengre materiale faktisk brukes av brukeren, om de leser det eller oppholder seg ved det. Med andre ord trenger man å samkjøre med et mål om hvor lang tid det tar å ta til seg et innhold. Er det primært tekst, er den totale lesetiden en verdi å sammenligne mot. En funksjon som kan integreres i ditt nettsted. Det innholdet som har en høy lesetid og høy oppholdstid gir et signal om at materialet holder en høy kvalitet, har et høyt engasjerende innhold, eller lignende.

Nå tenker du kanskje at dette er forfengelig? Det er bra! Oppholdstiden er et signal blant mange andre for å relativisere hvilket innhold som man i kvantitative tankebaner har grunn til å tro er verdsatt av brukere.

Bilde 58: Beregnet lesetid for et blogginnlegg på min Wordpress-blogg.

Når jeg gjør en større innholdsrevisjon neste gang, er dette en arbeidsmetode jeg tenker å kjøre med. Alternativet å gjøre det manuelt kommer garantert til å gjøre at man skroter verdsatt nisjeinnhold som ikke er så velbrukt men verdsatt av de som fant dit.

Det er ikke så komplisert som du kanskje tror å sammenføre de opplysningene du trenger. Ditt webstatistikkverktøy har sikkert allerede en opplysning om hver sides gjennomsnittlige besøkstid. Det du trenger å gjøre er å få nettstedet til å liste lesetiden for de adressene som finnes. Så slår du sammen de to kildene og bruker sidens adresse som felles referanse. Jeg som er mer komfortabel med databaser ville gjort sammenslåingen den veien. Men enkelte jeg kjenner har ennå ikke trengt å forlate Excel, da «alt du trenger finnes i Excel!».

Fra en søkemotors synspunkt, eller din produktlistings vinkel, kan oppholdstiden snarere ses som et mål på hvor lenge brukeren oppholder seg på søke- eller produkttreffets side før brukeren vender tilbake til listingen.

Net Promoter Score - NPS

Du har trolig støtt på Net Promoter Score (NPS)⁵⁶ men kanskje ikke innsett det. Det man forsøker å oppnå med NPS er å ha en eneste måleverdi som skal gjenspeile hvor bra noe er, hvor lojal kunden eller brukeren er. Karakteren går fra -100 til +100. Er verdien negativ er det en person eller gruppe som mer eller mindre lidenskapelig kommer til å snakke negativt om noe. På den positive enden er hvor mye personen eller gruppen er ambassadører for noe og forteller om det i positive ordelag til sine omgivelser. Får man karakteren -100 betyr det at alle er lidenskapelige i sin avsky, får man +100 er alle så fornøyde at de vil fortelle om det til sine omgivelser. Å ha over null anses å være bra og over +50 er en utmerket karakter.

NPS går ut på å stille et eneste spørsmål, nemlig:

«Hvor sannsynlig er det at du ville anbefale bedriften/produktet/tjenesten/nettstedet til en venn eller kollega?»

Svaret angis av den spurte på en skala fra null til ti, der man til alle nerdenes glede faktisk kan velge null. Dette resultatet regnes så om til tidligere nevnte skala. Respondentene deles opp i tre grupper slik at man vet hva man har med å gjøre. De som har svart:

• 9-10 kalles promoters og er ambassadører fylt av positivitet.
• 7-8 kalles passive og bidrar ikke med mye nytte.
• 0-6 kalles detractors, og man kan anta at de ikke kommer til å snakke vel om det de er spurt om.

Svar mellom 9-10, promoters, antas å skape merverdi i sitt personlige nettverk, for eksempel å ville tipse sine omgivelser når anledningen byr seg. Om du har truffet på noen som har valgt å skaffe seg en Apple-datamaskin, vet du nok hva jeg mener, personen virker overbevist om at løsningen på nesten alle utfordringer finnes innen Apples plattform.

De som svarer 7-8 anses å være passive, deres atferd ligger mellom positivt og negativt.

Svar mellom 0 og 6 anses å være negative (detractors på engelsk). De kommer ikke til å snakke vel om ditt nettsted når det kommer på tale, de kanskje rent av kommer til å motarbeide deres virksomhetsmål.

For å regne ut sitt NPS-karakter regner man gruppenes prosent mot hverandre, for eksempel om du har: 35 % promoters, 40 % passive og 25 % negative så følger du formelen promoters-negative, 35 – 25. Altså blir det +10 i NPS.

Husk å kun sammenligne ditt nettsteds NPS-karakter med sammenlignbare ting. For eksempel kan man kanskje ikke sammenligne en luksusbilprodusentens nettsteds karakter med karakteren for den spanske ambassadens nettsted.

Bilde 59: Soundcloud følger NPS i sin app.

SERVQUAL og RATER

En annen modell for å la brukere bedømme en form for tjeneste eller service er SERVQUAL⁵⁷. Den ble utarbeidet på slutten av 1970-tallet og er ment å brukes for å oppdage hvilket gap som finnes mellom forventet kvalitet og den som oppleves av brukere. Som tidligere nevnt, blant annet med referanse til David Maister, er en formel for kundetilfredshet å sammenligne den faktiske opplevelsen mot den forventningen som fantes på forhånd. Om opplevelsen er i tråd med forventningen er alt vel, men om forventningen er høyere enn opplevelsen blir det problemer.

For å bryte ned opplevd service av en tjeneste, som ikke nødvendigvis må være digital, i en tjenestes ulike dimensjoner har man i SERVQUAL spesifisert noe som kalles RATER. Det er en forkortelse av de innledende bokstavene:

1. Reliability: evnen til å utføre den utlovede tjenesten på en pålitelig og presis måte.
2. Assurance: kunnskapene og høfligheten til den service(personalet) brukerne kommer i kontakt med. Også tonefall i skrevet tekst teller, selvfølgelig. Det går ut på at brukerne skal kunne stole på det som sies og ha tillit til tjenesten.
3. Tangibles: mer anvendelig i et fysisk scenario muligens, handler om de håndgripelige tingene som lokaler, lager. I mer digitale sammenhenger muligens at designen bekrefter at man har havnet riktig.
4. Empathy: at man ivaretar brukerens individuelle behov.
5. Responsiveness: gi service hurtig nok.

Å jobbe etter denne modellen er en miks av både kvalitativ input og kvantitativ måte å beskrive et nåsituasjon. Den kvalitative aspekten er at det tar utgangspunkt i ekte brukere og deres måte å beskrive tjenesten, men samtidig kan man oppsummere hvert punkt med en karakter for å forsøke å kvantifisere det. Fordelen med å kvantifisere det er at tall er lettere å sammenligne over tid, slik at man kan vite om opplevelsen av tjenesten har endret seg.

Triple bottom line

En måte å kategorisere (og nyansere) de målene man har er å veve inn litt av organisasjonens samfunnsansvar i sin måte å måle. Begrepet ble myntet av John Elkington i 1994⁵⁸. På engelsk brukes et begrep du sikkert har hørt om, CSR (Corporate Social Responsibility). Man får altså inn litt moral i arbeidet med oppfølging.

Det hele går ut på at man supplerer de finansielle målene med sosial påvirkning og hva som skjer med miljøet. Med andre ord skal man balansere et rettferdig sosialt klima, at miljøet ikke tar skade, med å også tjene penger. Langsiktighet, rett og slett.

Bilde 60: Video om roboten Liam som demonterer iPhones. Apples verdier som en del av markedskommunikasjonen.

Ja, det er vanskelig nok å finne kloke og målbare virksomhetsmål bare rundt det finansielle. Å da kunne relatere og relativisere det finansielle med sosial- og miljøpåvirkning kan føles overveldende. Samtidig kan det i en større sammenheng være verdt det. Se for eksempel på hvordan Apples kundekommunikasjon har fått i det minste miljøperspektivet innlemmet. Alt fra hvilken miljøpåvirkning ulike produkter har, til å innlede en pressekonferanse med å vise en robot som resirkulerer gamle iPhone. Roboten har til og med et navn, Liam.

Because in a world with limited resources – some things cannot be replaced.
- Apple i presentasjon⁵⁹ av Liam, deres resirkuleringsrobot

For meg som ansatt i en skattefinansiert virksomhet er dette mer naturlig nå enn da jeg jobbet i privat sektor som konsulent. Gjorde vårt lille Göteborgskontor et tilstrekkelig dårlig økonomisk resultat kunne man regne med at det ble lagt ned. Gjorde vi i stedet et kjempeflott økonomisk resultat, skulle man virkelig være en trist type om man syntes vi fløy for mye og tok for lite tog for å tjene inn de pengene.

Det er ikke forenlig med et bærekraftig forretningsdrift å ødelegge miljøet, eller å gjemme inntektene i et skatteparadis om det går utover det samfunnet man virker i.

Triple bottom line er en måte å ikke bli fartblind rundt det økonomiske, men snarere å innse at man har interessenter som ikke er blant aksjonærene. Noe jeg håper stadig flere bedrifter begynner med som en del av sitt arbeid med bærekraft. Kanskje kan vi webanalytikere hjelpe denne utviklingen litt på vei gjennom å velge målbare mål på litt ukonvensjonelle måter.

Om statistikk (og vanlige feil)

De dataene som ikke har en tydelig kobling til virksomhetens mest ambisiøse formål med nettstedet er å betrakte som øvrige data. De er ikke nødvendigvis uviktige på grunn av dette, men de er i det minste ikke åpenbare for hvordan man regner hjem investeringen i form av nye kunder, flere bestillinger i butikken, og så videre.

Segmentering

Akkurat som annen statistikk kan man forsøke å omforme sine data i jakt på funn, eller at man vil se hvordan kampanjen til en bestemt kundegruppe presterer. Et vanlig knep, som vi allerede har berørt en del i boken, er å segmentere. Da kan man fokusere på en delmengde av all statistikk, for eksempel sjekke om reklameutsendelsen i Eslöv har en påvisbar effekt av besøkende fra Eslöv på nettstedet.

En vanlig segmentering mange webanalytikere gjorde rundt 2008 med hjertet i halsen var å segmentere frem mobile brukere. Dette for å forsøke å lære kjenne deres atferd i håp om å ikke miste markedsandeler. Det syntes uunngåelig at majoriteten ville foretrekke å bruke mobilen for å besøke nettet.

For å begripe de tallene som segmenteres kan segmentet trenge å sammenlignes med et annet segment. En interessant utvikling vi så på 1177.se i begynnelsen av 2010-tallet var at økningen av antallet besøkende nesten utelukkende kunne tilskrives segmentet brukere med mobil og nettbrett. Utviklingen innen det segmentet var eksplosiv sammenlignet med de på datamaskin. De ansvarlige fikk hastverk med å få til et responsivt nettsted som var litt mer brukervennlig for de med mindre skjermer. Nå var jo den utviklingen noe de fleste av oss hadde vanskelig for å gå glipp av da det stadig kom på tale. Spørsmålet er bare når man basert på sin egen webanalyse skulle ha tatt en tidlig beslutning om å gå responsivt? Den dataen vi har på våre egne nettsteder er jo det vi har fortjent. Det vil si, før nettstedet fungerer ok for en mobil bruker finnes risikoen for at det segmentet er så lite at man ikke oppdager det – siden de ikke kommer tilbake oftere enn nødvendig.

Bilde 61: Utviklingen for segmentet «mobile & tablet» sto for brorparten av økningen på 1177.se

Samme problemstilling kan man ha rundt om man skal optimalisere for brukere på Playstation, eller det fåtallet i 2016 som kobler til med suspekte user-agents⁶⁰ som «in-car». Hvor mange som kobler til via sin bil trenger du å se i din statistikk før du skal begynne å bry deg?

Være bevisst på sine begrensninger og vanskeligheter

Det her med å tolke data er vanskelig, det skal ikke stikkes under en stol, og mange ganger skal man være tvilende til om man har underlag nok for å trekke noen meningsfulle konklusjoner. Det er klokt å være ydmyk overfor sine data, og har man mulighet til å dobbeltsjekke sine data og hvordan man rapporterer konklusjoner med en statistiker, er det utmerket brukt tid. Uansett hva, sørg for å ha forklaringen av metode og rapport nært til hånden da du kan regne med at det vil stilles spørsmål om bakgrunnen til konklusjonene.

Et vanlig problem akkurat rundt webanalyse er at man ikke kan trekke vidtrekkende konklusjoner på innsamlede data. Ofte fordi endringen ikke er stor nok til å kunne bli statistisk sikkerstilt, eller fordi underlaget er for lite (noe som gjør feilmarginen altfor stor).

Når man som amatør på statistikk ser på data, skader det ikke å minne seg selv om at man er menneskelig. Mennesker gjør feil, ofte. Dessuten gjør vi feil på iblant forutsigbare måter, noe som gjør at man kan ha en liste med vanlige feil i nærminnet før man jubler for høyt om noe man har funnet.

Noen forslag for oss webanalytikere er å være oppmerksomme på ting som:

1. At utvalget er ok og stort nok. Det er ikke statistikk å snakke om anekdoter rundt et fåtall brukeres opplevelser, da handler det om en kvalitativ metode og det er noe helt annet. Innsamlede data trenger å være fra en tilstrekkelig stor undersøkelse, og dessuten er sammensetningen innen den gruppen viktig. Utvalget skal være representativt, noe som ofte beskrives som at det trenger å være tilstrekkelig tilfeldig.
2. Sammenlign ikke epler og pærer. Begge er riktignok frukter, men du må være forsiktig med dine konklusjoner. Gjør du en A/B-test der den ene gruppen utelukkende består av nye besøkende og den andre av tilbakevendende, er det risikabelt å trekke noen konklusjoner.
3. Bekreftelsesbias er den høyst naturlige atferden å lete etter argumenter og bevis for at man har rett. Altså legger man større vekt på slikt som bekrefter den oppfatningen man allerede har. Det her trenger ikke å være en særlig bevisst handling, snarere kan det for mange av oss skje per automatikk – så ton gjerne ned den anklagende tonen når du påpeker dette for noen.
4. Self-selection bias: At vi selv ofte ikke er så veldig representative. Det er minst sagt tvilsomt å tro at man selv tilhører en gruppe av brukerne. Til tross for det er det vanlig at man tar utgangspunkt i seg selv og danner en gruppe brukere basert på det. Her har man altså ødelagt sitt utvalg.
5. Vær forsiktig med dine årsakssammenhenger. Vi mennesker er veldig raske til å trekke konklusjoner på feilaktige grunnlag, det finnes tydeligvis en evolusjonær grunn til det. Baksidene av dette er overtro og at vi ser mønstre der det ikke finnes noen sammenheng. Vil du ha noe lettbeint om dette, kjøp boken Spurious correlations⁶¹, eller om du vil ha noe mer akademisk er boken Why: A Guide to Finding and Using Causes⁶² det du leter etter.
6. Dine konklusjoner blir aldri bedre enn dine data. Det er av høyeste viktighet at man har kontroll på sin datakvalitet. At denne dataen er representativ og at ingenting viktig mangler for å våge å trekke konklusjoner. Husker du mitt eksempel der brukere ble sittende fast i brannmuren? Før jeg kjenner til hvor vanlig det er og hvordan det foregår, er det vanskelig å trekke konklusjoner på de øvrige dataene jeg har samlet inn.

Forsøk å virke innenfor dine begrensninger. Når det føles krøkkete, les deg opp ordentlig eller ta kontakt med noen som er ekspert på området. Innrøm når du ikke vet noe, vær åpen med det, og husk at alt er faktisk ikke heller verdt å finne ut av.

Forfengelighetstall (såkalte «vanity metrics»)

I sin webstatistikk har man massevis med ulike visninger av data, i det minste flere enn man vet hva man skal bruke til. Om man ikke kan koble dem til noe utvetydig bra, risikerer de å kun være interessante fordi de tiltaler din forfengelige side. Nå er ikke engang disse tallene helt verdiløse, men det er viktig å se dem for hva de er. Nemlig tall som du kun kan bruke som anekdoter når du treffer folk innen din egen yrkesgruppe.

Å formulere mål basert på antall sidevisninger per besøkende er mildt sagt tvilsomt, det går ikke helt an å påstå at det relaterer til de målene virksomheten har. Er det virkelig alltid bedre å ha mange sidevisninger? Antagelig ikke, i alle fall ikke alltid.

Det du likevel får lov å bruke med æren i behold av forfengelighetstall er de som forteller den besøkendes historie om deres sesjon på nettstedet. Kan du knytte tallene til et nøkkeltall, eller noe annet verdifullt som skal rapporteres, er det tall verdt å ta vare på. Da har de en verdi, om enn en ringe verdi. De kan da i beste fall fortelle hvorfor et nøkkeltalls trendbrudd inntraff. For eksempel at et styrtdykkende salg sammenfaller med at de besøkende fra en måned til en annen har begynt å bruke mobiler, eller hva som nå er den forfengelige måleverdien.

Hygienefaktorer

Hygienefaktorer er forutsetningene for at dine virksomhetsmål skal kunne inntreffe. Hvorfor noe skal kunne inntreffe. Det er ikke hygienefaktorene som gjør at du tjener penger på ditt nettsted, så de er ikke mål i seg selv, men de er likevel viktige å overvåke. De er selve fundamentet, eller forutsetningene for et verdiskapende nettsted. Disse beskriver det håndverket som utgjør et velfungerende og verdsatt nettsted. Det som gjør det mulig å selge noe, eller at noen kan engasjere seg.

Listen over hygienefaktorer for et nettsted er svært lang. Alt som er målbart, og som påvirker brukerens opplevelse, inngår i hva en webanalytiker har å bekymre seg for når man leter etter optimaliseringspotensial.

Siste delen i denne boken gjør et dypdykk i en rekke hygienefaktorer og andre aktiviteter som kan inngå i et metodisk arbeid for webanalyse, når man leter etter uutnyttet potensial.

Fortsett å lese – Del 4: Aktivitetsplan