Del 3: Webanalyse: Fordybelse

I de foregående dele har vi kradset i overfladen af webanalyse, kigget på en arbejdsmetode til et metodisk arbejde og også lidt projektteori ved at diskutere stilguidernes og designets indflydelse på analysearbejdet.

Nu er det tid til at gennemgå mange af de ting, som de fleste af os ikke automatisk forbinder med webanalyse. Blandt andet nogle af de værktøjer, man kan have gavn af til opfølgningsarbejdet, og ikke mindst en bunke tips og anekdoter fra virkeligheden.

Når det gælder målbarhed generelt, så er der to hovedkategorier af måleværdier (og ja, man skal bruge begge typer):

• Kvantitative data. Giver tal for, hvordan webstedet præsterer, for eksempel al den information om brugerne som gruppe, man kan finde frem til i sit statistikværktøj. Disse måleværdier giver svar på spørgsmålene hvordan, hvornår og hvad vedrørende brugerne. Hvilket udstyr de har, hvornår de besøger webstedet, hvor de kom fra og så videre. Adfærdsdata, der giver indsigt i omfanget af noget.
• Kvalitative metoder. Handler om, hvordan brugerne oplever webstedet, som de selv ville udtrykke det. Disse oplysninger er i form af tekst snarere end tal. Det kan være svar på spørgsmål i en webstedsundersøgelse, interviews, brugertest eller funktioner på webstedet, hvor man lader brugeren fortælle, hvad de syntes om deres oplevelse eller det, de netop læste. Ud over folks holdning til et websted kan det i visse tilfælde handle om, at man observerer brugerne, så man kan tage chancen for at stille opfølgende spørgsmål, hvis der er behov. Man leder efter svar på spørgsmålet hvorfor. Kvalitativ information bidrager med de perspektiver, som kvantitative data mangler.

Angående kvalitative undersøgelser er det klogt at være opmærksom på, i hvilken situation brugeren befinder sig, når de skal svare på spørgsmål. Du har sikkert oplevet at blive tilbudt at udfylde en spørgeundersøgelse om, hvordan du oplever et websted. Nogle gange dukker disse undersøgelsesinvitationer op, allerede inden man er begyndt at bruge webstedet. Spørgsmålet opstår da, om det ikke påvirker, hvordan respondenten udfylder undersøgelsen? Er deres svar identiske med besøgendes, der har klikket rundt på 2-3 sider først? Hvis man har tænkt sig at drage konklusioner baseret på disse data, så er det dumt at gamble med sin datakvalitet.

Billede 37: Denne type undersøgelse er direkte upassende ved en brugers første besøg på et websted.

Det kan være klogt i det mindste at logge, hvor mange sidevisninger brugeren nåede, inden vedkommende udfyldte undersøgelsen. Om det er en logget ind bruger eller på anden måde tilbagevendende bruger, er det også godt at vide. For tilbagevendende brugere er det sandsynligvis ikke hele verden at vise undersøgelsen tidligt – de har jo på et tidligere tidspunkt oplevet webstedet. Her genanvender du dine segmenteringer af brugere. Måske opdager du nogle nye interessante grupperinger baseret på de metadata, du kan indsamle om respondenten, som hvorfra de kom, om der er geografiske forskelle osv.

Det er svært selv at evaluere sit eget websted

En ting, der ser ud til at være let at glemme, er, at vi som skaber, ejer, udvikler eller på anden måde er ansvarlige for et websted, virkelig ikke er repræsentative brugere. Vi er heller ikke særligt gode til at imitere rigtige brugere, da vi alle kommer med helt egne opfattelser og forkundskaber. Har man været involveret, er det måske primært ens forkundskaber, der gør en til en dårlig tester.

Derfor er det nødvendigt med jævne mellemrum at gennemføre brugervenlighedstest. Inden for det, der kaldes universelt design, undertiden inkluderende design eller design for alle, har man udarbejdet en liste³⁶ med, hvad et brugervenligt design går ud på, nemlig:

1. Equitable use – brugen skal være retfærdig og mulig for alle trods vores varierende evner.
2. Flexibility in use – alsidighed ved brug.
3. Simple and intuitive – enkelt og selvforklarende.
4. Perceptible information – indhold og information skal være mulig at opfatte.
5. Tolerance for error – fejltolerant og tilladende konstruktion.
6. Low physical effort – skal kræve lille anstrengelse.
7. Size and space for approach and use – der skal være plads til brug og lethed til at gøre rigtigt.

Disse punkter er ikke specifikke for digitale produkter, men kan absolut anvendes på, hvordan man designer websteder. De blev skabt i 1997 af The Center for Universal Design ved North Carolina State University, så de er sammensat længe før, webben begyndte at se ud, som den gør i dag.

Opstart af et webprojekt eller en ombygning

Der er naturligvis utrolig meget at tænke igennem, når man skal påbegynde et webprojekt, uanset om det er indholdet, man skal se over, noget nyt design, der skal til, eller om det er en ny start med webanalyse. En forudsætning for at kunne forstå, hvad der er værd at analysere, er, at man ved, hvad på et websted der er, eller skal blive, det, der lever op til formålet med webstedet.

Forslag til ting at tænke igennem tidligt er blandt andet:

1. List hvilke dele der er vigtigst, vigtige, normale eller uvigtige. Alt kan ikke være vigtigt for alle tiltænkte målgrupper, altid.
2. Hvilke dele af webstedet understøtter de vigtigste aktiviteter? Disse sider skal analyseres i jagten på forbedringsmuligheder. Som deres placering af knapper, forståelige tekster, hvor let det er at finde derhen osv.
3. Hvor enkelt er det at finde rundt mellem de forskellige aktiviteter? Tænk forudsætningsløst igennem navigationsstrukturen. Kan man for eksempel finde tilbage til den respektive startside, hvis man har fået et direkte link via e-mail? Er det let at skifte fra aktiviteten at tilmelde sig nyhedsbrevet til at rette fejlagtige adresseoplysninger?
4. Hvor enkelt er det for brugerne at komme igennem en aktivitet? At en butiks overlevelse afhænger af, at kunderne klarer at betale for sig, er ret oplagt. På et websted skal man sørge for, at der er så få og lave forhindringer som muligt for at fuldføre en aktivitet hele vejen.
5. Hvad er et vellykket besøg på webstedet? Hvilke ting skal være sket, for at du objektivt kan pege på en brugers session på webstedet og sige, at det var et vellykket besøg? Tilmeldt sig nyhedsbrev? Downloadet et whitepaper, læst en nyhed og forsvundet? Tænk igennem, hvilke måleværdier der viser et vellykket besøg.

Materiale, der ikke relaterer til ovenstående punkter, er oftest distraktioner og ikke interessante at forbedre. Snarere bør det nok fjernes, eller i det mindste skjules, brugere skal ledes uden om det, og det bør markeres som potentielt skrald for den egne søgemaskine. Tænk gerne igennem, hvad der kendetegner en værdifuld side, som for eksempel om en side uden en call-to-action kan anses for værdifuld, og i så fald hvorfor. Sæt gerne et mål om, at nye websider skal have en call-to-action eller være tæt knyttet til et virksomhedsmål.

Hvad er så en call-to-action (CTA)? Jo, det er det designelement på en webside, som brugeren er tænkt at interagere med. Det kan være en knap, et link eller hvad der nu er årsagen til, at siden eksisterer. En CTA er den måde, man som skaber af et websted forsøger at guide brugeren igennem en aktivitet frem mod et mål – en afslutning.

Det er meningen, at du skal kigge kritisk på dit websteds alle undersider. Det ville vel føles godt, hvis du kunne forklare, hvad størstedelen af siderne på webstedet bidrager med?

Hvilket materiale er godt (og hvad kan kasseres)?

Hvad er så godt indhold på et eksisterende websted, og kan man finde ud af, hvad der virker? Arbejder du med webanalyse, er det nødvendigt at danne sig en opfattelse af, hvad kvalitetsfaktorer er, og hvordan du kan arbejde med målbarhed for at lære dine brugere og deres adfærd at kende.

At arbejde med webanalyse er meget mere end at fordybe sig i webstedsstatistikken, der er masser af andre værktøjer, der kan give et helikopterperspektiv over din webkommunikation. Men for at det skal være meningsfuldt at analysere, skal man først definere, hvad der er godt – godt indhold, god adfærd hos brugere, god kvalitet og hvad der er godt for virksomheden. Risikoen er ellers, at man arbejder med at forbedre materiale, der ikke har nogen fremtidsudsigter. Men fortvivl ikke, der er måder at finde ud af, hvad der efterspørges af brugerne. Gennem søgeanalyse, blandt andet.

Noget, der er blevet forsømt i meget lang tid, eller måske bare ikke nået, er at evaluere, om den søgefunktion, man tilbyder, fungerer, som den bør. Nogle gange er søgefunktionen mest en kilde til frustration. Spørgsmålet er, om noget så vitalt på et websted skal have lov til at eksistere, hvis man ikke følger op på, om det bidrager med nytte eller kun er til skade. Søgeanalyse er vores næste dybdedyk.

Søgeanalyse er vigtigere, end nogle tror

I dag kan man roligt antage, at hvert websted eller intranet har en søgefunktion. Visse organisationer har endda taget skridtet til at bygge noget af en intern-Google, eller Enterprise Search, som det plejer at hedde. Der, hvor jeg arbejder, har vi investeret tungt i denne teknologi i mange år.

At reflektere over og analysere brugen af den egne søgefunktion er det, der går under begrebet søgeanalyse (eller Site Search Analytics på engelsk). Det handler altså om at tage del i de ord, som bruges af brugerne, og hvilken adfærd de har. Hvad der oftest efterspørges, hvornår de ikke finder frem, og så videre.

Som du sikkert har regnet ud, er dette ikke det samme som SEO (søgemaskineoptimering), men der er en del ligheder mellem at ville nå ud på andres søgemaskiner og at forsøge at optimere brugen af sin egen søgefunktion. Søgeanalyse er måske mere beslægtet med webanalyse end med SEO. Mange af de webanalyseværktøjer, jeg har set, har faktisk funktioner til at lave en grundlæggende søgeanalyse. For eksempel kan man i Google Analytics konfigurere sin webstedssøgning for at drage nytte af de andre værktøjer, der tilbydes, også for hvordan webstedets søgning fungerer.

Vælger man i stedet selv at styre sin skæbne, er det fuldt muligt at bearbejde søgeloggene. Det vil sige de tekstfiler, hvor alle søgeforespørgsler noteres af systemet. Så er det kun ens egen fantasi og budget, der sætter grænser.

Søgeanalyse giver et unikt indblik i brugernes oplevelse

Det, der virkelig gør søgeanalyse unikt, er, at du får et indblik i, hvad brugerne er ude efter. De skriver endda med en serie ord, hvad de leder efter. Den type indsigt kan man kun drømme om at opnå, når det gælder de adfærdsdata, som øvrig webanalyse i høj grad består af. Fordi man får så mange ord, er det en blanding af både kvantitativ og kvalitativ undersøgelse. Både mængde og det personlige.

Motivation for at arbejde med søgeanalyse kan blandt andet være at understøtte sine designbeslutninger. For eksempel fordi du kan vise, hvilke ting folk søger efter på webstedet. At du også har data til at gøre søgefunktionen bedre, gør det ikke dårligere, og som vi ved, bliver søgefunktionen aldrig bedre end det indhold, den fremhæver. At arbejde med søgeanalyse kan fremhæve, hvad der skal forbedres med webstedets indhold, hvad der mangler, og meget mere.

Hvordan det fungerer

Først og fremmest: gennem et besøg på en søgefunktion plejer besøget at blive opfanget af det webanalyseværktøj, der bruges på webstedet. På det offentlige web er det meget almindeligt, at dette værktøj er netop Google Analytics, men der er også en række andre værktøjer med tilsvarende funktioner. Et, der er rettet mod de organisationer, der er forsigtige med at lade andre få del i deres brugeres surfmønstre, hedder Matomo. Fordelen og ulempen ved Matomo er, at man kan have det lokalt i sit eget tekniske miljø, ingen anden behøver at få at vide, hvilke besøgende dit websted eller søgefunktion har. Eller hvad de søger efter.

Ud over selve besøget på webstedet kan en eller flere ting ske, når brugere laver en søgning. Dels, hvis man har konfigureret sit webanalyseværktøj korrekt, vil det opfange søgeordet, men det er også almindeligt, at søgefunktionen skriver søgeforespørgslen ned til en logfil sammen med lidt information om brugeren. Denne ekstrainformation handler sandsynligvis oftest om dato, tid, brugerens IP-adresse og måske lidt information om, hvilken type udstyr der er brugt. Læs op om user-agent³⁷, hvis dette interesserer dig.

Al denne data kan man derefter analysere uafhængigt af sit sædvanlige webanalyseværktøj, hvis man nu har den type søgefunktion, helt uanset de funktioner, der allerede findes i webanalyseværktøjet.

Søgeanalyse risikerer at blive teknisk

Som du bemærker, bruges ord som "log", "user agent" med mere i denne sammenhæng. Det er helt rigtigt, at dine muligheder for at få adgang til søgeloggen kan afhænge af IT-afdelingens velvilje og interesse. Historisk set er data som disse blevet indsamlet til brug af teknikere til at fejlsøge tekniske problemer, og de har nok ikke tænkt på at dele dem. Muligvis bliver du den første til at bede om adgang, i hvert fald som en, der ikke arbejder på IT. Reaktionen på spørgsmålet kan sikkert variere.

En måde at sætte gang i diskussionen kan være at give dem en gave i form af et nyt godt værktøj. Sig, at IT får hjælp til finansieringen af et multikompetent værktøj, både til business intelligence og ved et tilfælde også søgeanalyse? Der findes en række produkter på markedet, der kan hjælpe med søgeanalyse. For os, der er solgt på open source, skiller den såkaldte ELK-stak³⁸ sig ud fra mængden. Det er en kombination af Elasticsearch, Logstash og Kibana. Altså en søgemaskine, loganalysesoftware og visualisering i én pakke.

Billede 38: ELK kan se ud som Västra Götalandsregionens søgeredaktørportal. Her inspiceres søgebegrebet "lediga jobb" og synes at vise en sæsonvariation.

ELK er en tjeneste, man installerer på sine servere. Vil man have et mindre ambitiøst alternativ, synes jeg, man kan kigge på et selvhjælpsprogram til dataanalyse og visualisering. En af mine favoritter er Tableau, som tilfældigvis findes i en version, der er gratis at bruge, Tableau Public³⁹. Den kan man installere på sin egen computer for at inspicere logfiler eller datakilder i al almindelighed.

Søgeanalyse i et indholds- og designarbejde

Som nævnt tidligere kan man få god hjælp til designbeslutninger. Ikke mindst fordi endnu mere data om brugerens oplevelse hjælper i argumentationen, men også fordi man får lidt af et facit i diskussioner om, hvordan man skal benævne ting på webstedet. Det kan blive tydeligt, hvordan ting burde fungere, eller hvordan rigtige levende brugere benævner ting. Her er et værktøj til at imødekomme det stadigt højere krav om beviser, og at organisationer vil være datadrevne. Et ord, jeg lærte, da jeg arbejdede som udvikler på Sahlgrenska Universitetssjukhuset, var vederhæftighed, altså nogets grad af pålidelighed. På sådan en arbejdsplads er det ikke en nyhed, at man skal kunne bakke sine påstande op med pålidelige data, det er jo, hvad forskning går ud på – hvis jeg må forenkle det hele groft.

For den, der arbejder med indholdet, kan det være rart at vide, hvilke ord ens brugere kender til, hvad de søger efter og så videre. Det letter at have en liste med eftersøgte ord, når man skal skrive overskrifter, vælge hvilke synonymer man krydrer med i indledningen m.m.

Noget andet, som søgeanalyse og søgeredaktionelt arbejde kan bidrage med til indholdsarbejdet, er at holde styr på det hele, at arbejde strategisk med sit indhold. Blandt andet er der en arbejdsmetode til at finde det, man vil rense ud, takket være søgemaskinen. Det gøres ved at kassere materiale, der er RUTtent, dvs. Redundant, Uddateret eller Trivielt. Den type indhold koster penge enten ved, at man forsøger at vedligeholde det, eller når en bruger rent faktisk bruger det. Ikke mindst er det ofte i vejen i søgefunktionen. RUTtent indhold vil altid forvirre, uanset hvor godt du bygger din egen søgefunktion, og det kan stjæle opmærksomhed på eksterne søgemaskiner fra det indhold, du hellere vil fremhæve.

Hvor meningsfuldt er indhold, ingen finder eller har brug for? Sådan noget burde du kunne kassere. Hvis søgefunktionen kender til indhold, der ikke har nogen udpeget ejer, er det nok også et signal om, at ingen ville savne materialet.

Relationen til søgemaskineoptimering og klikstatistik

Jeg har mange gange drillet, i sammenhænge om søgemaskineoptimering, om vanskeligheden ved at sælge produktnavne. Som 'Windcracker 3000 GLX', når folk googler efter søgebegreber, der beskriver, hvad de er ude efter, som 'regnjakke til løb'. I søgeanalysen gemmer der sig semantisk beriget information. Du kan se, hvilke ord der er brugt, men i bedste fald også, hvordan søgeforespørgsler er omformuleret i håb om at få bedre træffere. Det er en fantastisk kilde til, hvordan man bedriver sit SEO-arbejde.

Søgeanalyse bør være mindst lige så vigtigt som at tjekke, hvordan brugerne opfører sig på webstedet. Skal man være helt ærlig, er det, som webstatistiksystemet indsamler, ikke særlig meget mere end en logget strøm af klik på forskellige ting. Mens søgeanalysen kan nærme sig kvalitative undersøgelser af, hvad brugerne faktisk ledte efter, ikke hvilken vej de klikkede under tiden, de ledte.

Glem den lange hale, nøj dig med den korte hals (indtil videre)

Hvis du er bekendt med begrebet long tail⁴⁰, det som skal beskrive variation, har du indset, at visse søgeforespørgsler er ekstremt almindelige, mens man hurtigt ender på sjælenhederne. Majoriteten af søgeforespørgslerne er det, der kaldes for onesies og twosies, altså forespørgslerne langt ude i halen, de søgeforespørgsler, der kun stilles en eller to gange.

Billede 39: Det korte hoved og den lange hale ≈ et fåtal søgebegreber er uhyre almindelige.

Det kan være godt at vide, at den fordeling, long-tail beskriver, også ofte kaldes for Zipf-kurve, 80/20-reglen og sikkert flere navne, jeg endnu ikke har hørt. Alle beskriver variationen inden for en mængde af noget. I dette tilfælde, at stillede søgeforespørgsler hurtigt begynder at udvise et mønster af tilbagevendende søgeforespørgsler (det korte hoved), men også unicitet (den lange hale).

Jeg har den fordel at kende en matematiker, blandt andet arbejder han med at beregne forsikringspræmier. Ofte, når jeg har et svært spørgsmål, plejer jeg at benytte lejligheden til at boltre det med ham. Også i dette tilfælde:

For at være måske endnu tydeligere: en zipf-kurve viser fordelingen af en mængdes elementer i faldende rækkefølge. Vil man være nøjagtig, er frekvenserne normerede, så frekvenserne summerer sig til 1, hvilket indebærer, at det er en sandsynlighedsfordeling, der beskrives.
- min ven Morgan Skogh

På kort dansk: det er overraskende almindeligt, at en bruger søger netop på de mest populære søgeord.

De 100 mest almindelige søgninger er markant mere almindelige at søge efter sammenlignet med søgningerne, der er 100-200 mest almindelige. Det er sandsynligt, at de fjorten mest almindelige søgeforespørgsler udgør hele 10 % af alle søgeforespørgsler.

Hvad skal du gøre med denne viden? Hvis du begynder med hurtigt at kigge på de hundrede mest almindelige søgeforespørgsler og sørger for, at der er gode svar, vil du have sikret, at søgefunktionen fungerer ok for en ret stor andel af brugerne. Jo mere du arbejder med dette, desto mindre bliver gevinsten af forbedringerne. Tænk, hvis alt arbejde var så let at forklare, hvad der er en passende indsats.

Det, man leder efter i grundlæggende søgeanalyse, er mønstre. Mønstre, der giver indsigt i, hvordan det fungerer, eller at finde mønstre i systematiske problemer, man kan rette.

Et brugsmønster, du har brug for at kende til, er, hvilke de mest almindelige søgeforespørgsler er. Disse kan ændre sig afhængigt af tid på året, ugen eller døgnet. Disse indsigter er noget, der kan omsættes til muligheder i, hvordan man arbejder med sit indhold. For eksempel ved at få signal om, hvornår sæsonvariationen med at lede nyt job er kommet i gang, hvornår folk er begyndt at søge på vinterkvalme, eller hvad det er for indhold, der efterspørges af dine brugere.

Segmentér – hvis muligt

Hvad søger de brugere efter, som du har placeret i dit vigtigste segment, de mest værdifulde for dig? For at kunne vide dette kan dine logfiler have brug for at blive suppleret, eller du kan drage nytte af avanceret filtrering i dit webanalyseværktøj.

Segmentering går ud på at lære sine brugere og deres adfærd at kende. Det kan vise sig meget værdifuldt også, når det gælder webanalyse. I og med at sprog er en så naturlig faktor inden for søgeanalyse, på grund af brugernes ordvalg, er de mest oplagte segmenteringer noget, der knyttes til brugernes sprog. Det behøver ikke at være forskellige sprog som i, hvilket modersmål de har, det kan lige så godt være, at man finder lægmandssprog kontra fagtermer.

Eksempler på segmenter, der kan være interessante for at lære sin søgefunktion at kende, er blandt andet:

• Hvad er trafikkilden? Hvilket kan oversættes til, hvilket domænenavn, hvis man har flere, brugeren påbegyndte sin søgning fra. Tænk kampagnesite kontra det sædvanlige websted.
• Er det en ny søgebruger eller en tilbagevendende?
• Loyalitet og frekvens af at komme tilbage.
• Konverteringer. Blandt hvilke brugere opstår konverteringer, og hvad adskiller dem fra dem, hvor intet af interesse sker? På hvilken måde bidrager søgefunktionen til de sessioner, der konverterer?
• Gennemsnitlig værdi. For dig, der driver handel, eller kan oversætte en besøgendes aktivering af et mål til faktiske penge, er det interessant at segmentere de mest lønsomme, de normale og sammenligne indbyrdes og med dem, der ikke er lønsomme. Er der læringer?
• Geografi er en klassiker. Ikke sjældent er der forskelle afhængigt af, hvor brugerne befinder sig. Måske er der noget i deres oplevelse, du kan forbedre?
• Timing, altså hvornår på døgnet sker målopfyldelse? Måske er det en bestemt tid på ugen, måneden eller året. Det er vigtigt, at både webstedet og søgefunktionen er klar til dette og bidrager til en positiv oplevelse.

(Lad en søgeredaktør have...) Styr på nulresultaterne

En tilbagevendende opgave for den, der er ansvarlig for søgefunktionen, er at tjekke, hvilke søgeforespørgsler ens brugere har stillet, når der ikke var nogen træffere at vise. Årsagerne til, at ingen træffere vises, kan være flere, men det er ikke noget, brugeren bekymrer sig om. Ifølge brugeren har søgefunktionen fejlet. Bortset fra, at den, der søger, ikke vil have nogen træffere (typisk søgning blandt patenter, varemærker man vil registrere osv.), er nulresultat en kæmpemæssig fiasko. Nulresultat er desværre ret almindeligt, når man søger inden for websteder eller enkelte webapplikationer.

At forsøge at holde styr på nulresultater og tjekke, at der er godt materiale til de mest populære forespørgsler, er noget, man skal have en søgeredaktør til. Som navnet antyder, er det en person, der med redaktionelle tiltag sørger for, at søgefunktionen fungerer godt. Ofte har søgeredaktøren brug for adgang og tillid til at afhjælpe problemer med indhold, som andre har skabt, i hvert fald hvis vedkommende skal kunne være effektiv.

De problemer, jeg er stødt på som årsager til, at besøgende får nulresultat, har altid været en af disse:

1. Der er intet relevant materiale, der matcher søgeforespørgslen.
2. Materialet findes, men hedder noget andet end det, søgeforespørgslen leder efter.
3. Der er materiale, men søgefunktionen har et automatisk filter, der gør, at brugerens søgeforespørgsel kun køres mod en delmængde af det, søgemaskinen kender til.

Alle besøgendes søgeforespørgsler er ikke altid relevante for webstedets mål, så hold øje med de forespørgsler, der spiller en rolle. Hvilke søgeforespørgsler der spiller en rolle, er et spørgsmål, du kun kan få svar på ved at gøre grundarbejdet med at formulere mål for webstedet.

Hvis der burde findes et indhold, der matcher søgeforespørgslen, er det nødvendigt, at det er inden for søgeredaktørens mandat at ordne det. Nogle gange er det så simpelt som at tilføje et par nøgleord til det materiale, der burde vises. Andre gange kan det blive meget avanceret. Som når der er behov for synonymhåndtering, eller hvis indholdet befinder sig i en datakilde, som søgemaskinen ikke har adgang til. Min bog Webbstrategi för alla har et helt kapitel om informationsarkitektur, der finder du tips til, hvordan man kan tackle denne type problemer.

Den bog tager også en del selvfølgeligheder op, kan man synes, om, hvordan en fejlside skal designes. Når det gælder at informere en bruger om, at ingen træffere blev fundet, kan det gøres på en mere engagerende måde end teksten "Sorry, no results". Nulresultatsiden skal være hjælpsom. Det kan være at fremhæve almindelige søgeforespørgsler, tilbyde gæt vedrørende stavning m.m.

"Hvorfor ikke gøre som Google?"

Den, der arbejder med søgning og søgeanalyse, får med jævne mellemrum utaknemmelige (og uindsatte) kommentarer om, at man burde skærpe sig. Hvor svært kan det være, når Google gør det der med søgning så godt?! Der er 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 svar er, at den information, man har på sit websted eller inden for organisationen, ikke er sammenlignelig med det, Google gør. Google opererer på et offentligt web, hvor milliarder af sider eksisterer, de sider linker til hinanden, de konkurrerer om at nå ud på søgemaskinerne osv. Hånden op den webredaktør, der har fulgt op på, hvor godt ens materiale er nået ud på organisationens egne søgefunktion. Hallo, er denne mikrofon tændt? Sarkasme til side, det er nok ikke særlig almindeligt endnu.

Også de brugere, du har på din egen søgefunktion, adskiller sig markant fra dem, der går til Google. De brugere, du har på dit websted, har allerede fundet frem, de giver netop din søgefunktion tilliden. Dem, der bruger Google, er mere åbne for forslag om, hvem der kan komme med det bedste materiale. Din bruger tror, de kan finde noget, de tror, du har. Ikke mindst – de har givet dit websted tilliden til at løse deres behov! Den tillid skal du forvalte.

Nøgletal til evaluering af søgefunktionen

Ud over at du nok allerede har regnet ud, at antallet af søgebrugere, der slipper for at se et nulresultat, kan være et godt nøgletal, er der et par flere forslag, jeg kan give. Vil du standardisere spørgsmål og kunne sammenligne dine svar med andre søgefunktioner, tjekker du Net Promoter Score (NPS), der er lidt i denne bog om dette. Så skal brugerne svare 0-10 på spørgsmålet om, hvor sandsynligt det er, at de anbefaler søgefunktionen til en ven eller kollega.

Forsøg at undgå straks at havne i at måle sparet tid som et nøgletal. Det er svært at argumentere for, hvilken virksomhedsnytte nogle sekunder frem og tilbage giver. Det trækker lidt i retning af forfængelighedstal at holde øje med, hvor stor en andel der har søgt og klikker på noget i træflisten, lidt det samme med, at man logger, om de klikker på top tre i resultatet. Disse værdier hjælper dig med at lære sin søgebruger at kende, men det er ikke værdige mål at styre efter.

Præcis som du skal arbejde med at sætte målbare mål for det øvrige websted, kan og skal du flette søgefunktionen ind. Hvilke dele var brugeren på, inden vedkommende gennemførte et defineret mål på webstedet? Var søgefunktionen en del af den proces?

Vil du have eksempler på søgespecifikke måleværdier og nøgletal, har du nogle her:

• Andel forespørgsler, der returnerer nulresultat. Arbejd mod en lav andel, i det mindste i de segmenter af brugere, du henvender dig til. Et mikromål er at forsøge at undgå at give en dårlig oplevelse, som et nulresultat er.
• Andel søgeforespørgsler eller sessioner, der fører til afslutning. Altså at noget i søgeresultatet blev klikket. Et mikromål, at søgefunktionen bidrager til, at brugeren finder noget værd at klikke på.
• Andel forespørgsler, der fører til, at den besøgende forlader webstedet. En måleværdi, ikke noget mål, for at se, hvilke søgebegreber der ikke formår at fastholde søgebrugerens interesse. Svarer til afvisningsprocent i øvrig webanalyse.
• Hvilke søgeforespørgsler bruges i sessioner, hvor brugeren har konverteret. En måleværdi snarere end mål.
• Hvilke sider på webstedet starter flest brugere deres søgning fra. Typisk måleværdi til at forsøge at finde indhold, der kan have brug for forbedring eller indgå i en A/B-test for at evaluere, om man kan påvirke oplevelsen i den rigtige retning.
• Mål: Konverteringsfrekvens blandt dem, der har brugt søgefunktionen. Fortæller, hvornår søgefunktionen har været en del af en session, der skabte værdi. Kan være svært, da det afhænger af at fremhæve indhold, hvor konvertering kan ske, men interessant som segment til udforskning af, hvad inden for søgning der skaber værdi.

Vil du lave et endnu dybere dybdedyk i søgeanalyse, kan jeg anbefale bogen Search Analytics for Your Site⁴² af Louis Rosenfeld. Det var den bog, jeg læste for at plukke rosiner af kagen til det, du netop har læst. Noget, jeg ikke har nævnt, som han skriver godt om, er en evalueringsmodel af en eksisterende søgefunktion. Står du over for opgaven at kunne bevise, at søgningens præstation over tid er blevet bedre, har du endnu en grund til at læse den bog.

Hvad findes i værktøjskassen til webanalyse?

En udbredt misforståelse, eller måske overdreven forenkling, er, at webanalyse handler om at gennemgå indsamlet webstedsstatistik. Selvfølgelig indgår det arbejde i at arbejde med webanalyse, men man bør være bevidst om, at man da kigger på statistik baseret på, hvordan et websted er, og ikke hvad det burde være. I en vis forstand fortjener man det, statistikken viser.

Kvantitative værktøjer

Næsten for oplagt til at behøve nævnes, men det mest almindelige kvantitative værktøj inden for webanalyse er alle vores løsninger til at tjekke webstedsstatistikken. Størst markedsandel på det marked har freemium-værktøjet Google Analytics. Ja, Google Analytics koster penge, hvis dit websted er stort nok. Dertil er der en lang række andre værktøjer med en ynkelig procent markedsandel, som Adobe Analytics og Matomo. Den type værktøjer har vi behandlet i bogens første del, og mangler du noget, lider internettet ingen mangel på hverken tips eller bøger at købe om dette. I denne del af bogen skal vi i stedet fokusere på mindre almindelige værktøjer. Vær forberedt på et par appetitvækkere.

Værktøjer til indholdsanalyse

Søgekonsulenter kalder gerne dette for indeksanalyse. Det kan faktisk være en god påmindelse for os, der har en søgemaskine, om at søgemaskinen har viden om, hvad webstedet indeholder, og det kan bruges til opfølgningsarbejde. Men der er mere inden for indholdsanalyse, der ikke er helt så naturligt at klumpe sammen med kravet om at have sin egen søgemaskine.

Det, søgemaskiner allerede ved om dit indhold, er blandt andet ting som:

• Hvilke ord der findes på siderne. Det kan du bruge til at holde øje med de ord, som organisationen er nået frem til, at man ikke skal bruge. Sammenlign med New York Times' liste "Words we don't say"⁴³, men også brugbart til at se, om der mangler et begreb, man gerne vil blive fundet på.
• Om sidetitlens længde er inden for god SEO-praksis, f.eks. under 70 tegn? Søgemaskinen kunne liste de længste sidetitler som en rapport.
• Krydstjekke, om hyppigt eftersøgte ord findes i sidetitler, overskrifter eller struktureret HTML-markup. Brugbart til at lede efter uudnyttet SEO-potentiale, ikke mindst for eksterne søgemaskiner.
• Følge op på, hvilken type materiale der lægges ud. For dem, der anstrenger sig for at bygge en bedre mobil oplevelse, er det interessant at tjekke, at trenden af publicerede PDF-dokumenter er aftagende.

Visse af den slags værktøjer får man med på købet, hvis man arbejder med søgeanalyse for sin egen søgemaskine. Vil man se tilsvarende tal for Google, er der en stadigt voksende værktøjskasse på deres Search Console (tidligere Webmaster Tools), og Bing har noget tilsvarende.

Billede 40: Google Search Console viser, hvilke ord den hyppigt finder på min bogblog.

Desuden kan (den egne) søgemaskines metoder til at indsamle indholdet til sit indeks sikkert suppleres, så du slipper for at fremskaffe endnu et værktøj, der kravler rundt på dit websted. I sin simpleste form er det at udvikle rapporter for, når søgemaskinen støder på potentielle problemer. Som hvor ofte, eller på hvilke undersider, den støder på 404-fejlsider. Eller om den støder på en side med identisk indhold som noget på en anden adresse.

Inden for indholdsanalyse rummes som sagt mere end søgeteknikker, hvilket værktøjet fra betalingstjenesten Siteimprove tager fat på. De fanger ødelagte links, stavefejl og udfører endda en del tilgængelighedstest. For dig, der ikke har en ambitiøs søgemaskinestrategi, kan Siteimprove muligvis være løsningen på at holde efter det sproglige, så den redaktionelle stil og varemærkepræsentation følger den kommunikative politik, man har.

Billede 41: Google rapporterer, hvilke brugervenlighedsproblemer de har fundet i indholdet på et websted.

Sidst men ikke mindst inden for indholdsanalyse er at samkøre statistikken over, hvad der får besøg ifølge din webstatistik, med alt det, søgemaskinen kender til eksisterer. Det, der i 12 måneder ikke er kommet i brug, bør du måske automatisk slette eller arkivere?

Loganalyse

At analysere logfiler har igen fremtiden for sig. Inden værktøjer som Google Analytics slog igennem i midten af 00'erne, var det diverse logværktøjer, mange af os havde til rådighed. Forskellen mellem Google Analytics og et logbaseret værktøj er, hvordan de indsamler deres data. Google Analytics har historisk set været baseret på at ligge tæt på brugergrænsefladen og holde øje med brugen som en tredjepart, der inddrages i kommunikationen. Enten har man sporet brugere via små kodestumper med Javascript, men visse lignende værktøjer har brugt gennemsigtige små billeder som alternativ metode.

Logfiler indsamles derimod uden at inddrage tredjeparter. Næsten enhver teknisk dims eller software skriver en logfil bag kulisserne. Lidt som en dagbog til at vise frem for udviklere eller forvaltende teknikere, når de leder efter årsagen til noget.

Grunden til, at jeg tror, loganalyse igen vil blive interessant for stadig flere, er, at mange er begyndt at indse, at brugere selektivt blokerer indhold. De fleste sikkert for at værne om deres privatliv. Logfiler er ikke noget, en bruger kan blokere, det håndteres inden for den tjeneste, der bruges.

Præcis som nævnt i delen om søgeanalyse kan disse logfiler bearbejdes af software, der skaber merværdi. Pludselig kan man analysere andre ting end de strengt indadvendte tekniske aspekter. Man kan opnå indsigt i, hvad en software laver, hvilken service den giver brugere.

Vil man gøre dette i lidt større skala, findes værktøjer som Splunk og Logstash. Splunk er en software, der koster efter mængden af information, man læser ind. Den kan hjælpe dig med at dekryptere loggene, finde mønstre og relationer. Informationsmodellering, ganske enkelt.

Logstash derimod, som en del af ELK-stakken, Elasticsearch-Logstash-Kibana, er et åbent værktøj, hvis forretningsmodel er at sælge support til større organisationer. Produktet i sig selv er gratis, men det kan kræve meget energi at komme i gang.

Fordelene ved Splunk og Logstash er, at de er produktificerede. Så bliver de mere forståelige ud fra en IT-indkøbers perspektiv, og der er support at købe til. Begge løsninger koster en hel del penge, men på forskellige måder. At bruge Splunk koster, efterhånden som du vænner dig og ser nytten, mens Logstash kræver en mere aktiv IT-forvaltning, og udgifterne kommer, før nytten er åbenbar.

Nu er der en stadigt voksende skare af konkurrenter til, at IT-afdelingen ejer spørgsmålet om BI (Business Intelligence). Disse værktøjer fokuserer på, at den digitalt modne vidensarbejder skal kunne hjælpe sig selv. Tableau er et hypet sådant værktøj, der fokuserer på selvbetjening til at inspicere mere eller mindre store datamængder. Som enhver klassisk software installeres det på en computer, og derefter læser du en logfil ind (eller anden struktureret information). Herefter er det bare at begynde at udforske datakilden. Gerne gennem visualisering, hvilket får afvigelser til at skille sig ud. En hengiven BI-konsulent, jeg ofte støder på i disse kredse, plejer at benævne Tableau som et Photoshop for data, med pointen om dets enkelhed til at vise noget frem.

Det, jeg selv har haft enorm nytte af Tableau til, er hurtigt at kigge på en logfil fra flere perspektiver. For eksempel en logfil med nogle hundredtusind linjer med "langsomme" databaseforespørgsler fra et websted, der var ekstremt afhængigt af databasen for at præsentere indhold. Jeg havde indstillet det, så databaseserveren noterede en databaseforespørgsel til en logfil, hvis forespørgslen tog længere end 0,5 sekunder at køre. Jeg havde tre forskellige typer data i loggen:

1. Tidspunkt for, hvornår databaseforespørgslen blev stillet.
2. Hvor lang tid databaseforespørgslen tog at køre færdig.
3. Selve databaseforespørgslen, altså hvilket indhold der blev efterspurgt.

Det, jeg kunne gøre takket være visualisering, var lidt nemt at kigge på denne ellers ret uhåndterlige datamængde fra flere vinkler. Jeg kunne hurtigt udelukke, at tidspunkt på dagen forårsagede nogen langsomhed. Derimod var der en sammenhæng mellem den tid, forespørgslen tog at fuldføre, og hvilken tabel i databasen, forespørgslen blev stillet mod (hvilket fremgår af databaseforespørgslen). Resultatet var et meget præcist grundlag for, i hvilke dele af systemet der var bremseklodser, og hvilke dele der slet ikke havde med sagen at gøre.

Billede 42: Nogle gange kommer brugeren ikke engang i kontakt med webserveren.

Desværre er det nødvendigt at være opmærksom på, om man et sted har data, der giver et retfærdigt billede af situationen. På min arbejdsplads har vi haft en længere periode med tøven omkring sikker kommunikation over nettet (med SSL-certifikat). Vores IT-afdeling har ikke været enig med verden om, hvordan et troværdigt certifikat skal se ud, hvilket har ført til, at vores brugere i visse tilfælde er blevet forhindret i at komme frem til vores tjenester. I visse tilfælde har vi haft data, for eksempel de gange, brugerne er blevet stoppet af vores firewall.

Billede 43: En firewalls primære formål er ikke at hjælpe en webanalytiker, men den logger sikkert data, du kan bruge.

Hos os var logfilen i firewallen så omfattende, at den var nødt til at nulstilles med jævne mellemrum. Ud over det var filen så stor, at det ville blive et stort projekt i sig at filtrere tilpas meget indhold, så det kunne inspiceres i en software, vi var bekendt med. Ved første øjekast var det ikke besværet værd i dette tilfælde.

Præstationsanalyse

Billede 44: For at verificere andre præstationsdata kan man sammenligne med, hvor hurtigt det er gået for Google at indeksere dit websted.

Rapporter for et websteds præstation kan man få fra flere forskellige steder. Vil man have et kvantificerbart overblik, er Googles Search Console nyttig, hvis man går til rapporten Crawl-statistik. Men er du parat til at betale, så tjek for al del Pingdoms tjenester. Fordelen ved Pingdom er, at de er specialiserede i præstationsovervågning, og der kan du specificere, hvorfra overvågningen skal foretages. Har du et websted, der skal give service til et nordisk marked, er det ikke så interessant, hvor hurtigt det går for en besøgende på USA's vestkyst. Lysets hastighed er ganske vist hurtigt, men i disse sammenhænge ikke hurtigt nok. Med Pingdom kan du for den respektive test vælge, om overvågningen skal foretages fra servere i Europa, Nordamerika eller Asien.

Billede 45: Pingdom viser oppetid og svartider for 10 websteder, hvis man betaler for sig.

En nyere funktion i Pingdom er at få flere detaljer om webstedets præstation. I dette tilfælde peger man en eller flere af sine vigtigste sider ud, og så overvåges materialet med et tidsinterval. Det kan være en god måde at holde øje med sine vigtigste landingssider, så en ubetænksom webredaktør ikke kommer til at publicere et for højopløst billede, eller at andre sjuskefejl ikke bliver rettet i rimelig tid.

Billede 46: Pingdom anmelder min bogblogs startside.

Det sidste kvantitative præstationsværktøj, jeg har tænkt mig at tipse om, er, at du, som alligevel har Google Analytics, faktisk har en visning for Googles værktøj Pagespeed Insights. Der får du at vide, hvor godt dit websted præsterer, og det kan være en god liste for dig, der netop skal begynde med præstationsoptimering.

Der er en lang række værktøjer, der måske ikke går under kvantificerbart flag i den forstand, at man har en konstant igangværende indsamling af data. Men mange af disse værktøjer kan integreres, eller af en udvikler hackes sammen, så de bliver kvantificerbare og interessante på anden vis end som manuelle stikprøver. Det er nu, du springer til det om kvalitative værktøjer, hvis du ikke orker teknikaliteter :)

Billede 47: Apica tjekker, hvordan mit lille websted klarer 10 samtidige brugere.

En interessant arbejdsmetode er at være proaktiv og tjekke, hvordan dit websted har det under belastning, at tjekke, om det da viser svagheder, der kan være værd at rette. Et firma, der beskæftiger sig med dette, er Apica⁴⁴, og de har værktøjet Loadtest, der kan simulere en tilstrømning af brugere til dit websted. Den slags værktøjer har IT-personale som sin primære målgruppe, så de findes måske allerede i din organisation, men jeg tror, en normaltbegavet webanalytiker klarer denne type løsninger. Du vil nok bemærke, at grænsefladerne kan være lidt ufærdige for førstegangbrugere.

Et andet værktøj, du nok ikke har overset, hvis du følger min blog eller har været til en af mine foredrag, er Googles Pagespeed Insights⁴⁵, der kan bruges uafhængigt af Google Analytics. Jeg har siden 2010 brugt det til at belyse behovet for at arbejde med webpræstation, haft toplister og alt i alt sammenlignet titusindvis af websteder med hinanden. Det, Pagespeed bidrager med, er, at det har en API, der gør, at man kan integrere sin kontrol, for eksempel med sit CMS. Design gerne, så når en side oprettes eller ændres, tjekkes den mod en liste af eksterne API'er, om den holder mål ifølge jeres præstationsbudget. Eller man gør som mig og har semi-automatiske kørsler af et sæt sider, og når noget mindre godt findes, underrettes berørte personer.

Pagespeed har ud over præstationsfaktorer for mobil og computere også et antal brugervenlighedsfaktorer, den tjekker. Som om links er for tæt placerede, om indholdet passer på skærmen og en del til.

Billede 48: Sitespeed.io er en hjælpende hånd for den, der orker lidt teknik.

Et svensk og åbent projekt, der på mange måder erstatter Pagespeed Insights, er sitespeed.io, som ved at være et lag mellem dig og API'erne tjekker websiden mod både WebPagetest og Pagespeed Insights. Er du nysgerrig, findes projektet naturligvis på Github, hvor du kan downloade al deres kode⁴⁶.

Apropos WebPagetest, som allerede er nævnt for deres visuelle sammenligning mellem to forskellige websteder, er det også et åbent projekt. Med lidt indsats kan man have sit eget lokale miljø til at lave de samme test. Det er godt, for eksempel for dig, der vil arbejde med intranetanalyse, eller hvis du vil køre mange flere test, end gratistjenesterne tillader.

Kvalitative værktøjer og metoder

For dig, der gabte dig igennem forskellen mellem det kvantitative og det kvalitative, kan jeg nævne, at kvalitative værktøjer og metoder er det, der ligner stikprøver. Noget, der ikke imponerer dem, der arbejder med statistik. Men nytten af kvalitativt arbejde er at give perspektiv og få svar på spørgsmål, ikke bare at kende omfanget af noget. Så det er uden tvivl vigtigt også at arbejde med det kvalitative.

Mange af de kvantitative værktøjer har aspekter, der gør, at man kan undersøge enkelte dele af noget, altså kan de også bruges kvalitativt, men jeg havde ikke tænkt mig at gentage dem unødigt her.

Mange tænker nok på user experience eller tjenestedesign, når de hører 'kvalitative metoder', og det er ikke så mærkeligt, det er en naturlig del af at få styr på situationen. Sædvanligvis forbindes kvalitative metoder med ting som:

• Spørgeskemaer til at forstå de eksisterende brugere.
• Dybdeinterviews for at lære mere om de tiltænkte målgrupper, deres behov, vaner og præferencer.
• Konkurrenceanalyse for at se, hvordan man klarer sig sammenlignet med andre.
• Etnografiske studier, hvor man observerer brugerne i deres naturlige miljø.
• Brugervenlighedstest, hvor man undersøger, om det konstruerede er brugervenligt, eller hvilke vanskeligheder der kan identificeres.

Alt dette kan man gøre med et højst varierende ambitionsniveau. Selvom det er lidt uden for bogens emne, og det ikke er min ekspertise, tænkte jeg alligevel at give et par tips om det, man relativt nemt kan løse selv.

For de ovenfor listede punkter mangler der ikke god litteratur, derfor har jeg ikke tænkt mig at kaste mig ud i at skrive om dem, når andre allerede har gjort det så godt. I stedet henviser jeg dig, der vil have en underholdende læring om, hvordan man følger op og evaluerer brugeroplevelsen, til Steve Krugs bog Rocket Surgery Made Easy⁴⁷. Du, der i stedet vil læse noget væsentligt mere akademisk, kan tjekke bogen The Elements of User Experience: User-Centered Design for the Web and Beyond⁴⁸. Steves bog vil give dig en arbejdsmetode, som du tør prøve selv, noget du kan begynde med til næsten ingen som helst omkostning og øvelseskøre på kolleger, inden du kaster dig over udenforstående. Den anden bogs styrke er snarere i dens bevisføring omkring de respektive metoders fortjenester. Den kan være god selv for den utålmodige læser at skimme igennem for derefter at bruge som opslagsværk.

Noget, der forener de fleste af ovennævnte kvalitative metoder, er, at de involverer brugere på en eller anden måde. Det kan synes at være det eneste, man har i værktøjskassen, men jeg vil hævde, at det er direkte forkert. At mange af os har det billede, skyldes, at det netop er de dele, der er forståelige at pakke ind som et tilbud. Lad os ikke blive begrænset af, hvad konsulenter føler sig trygge ved at tilbyde og sætte en prisseddel på. Lad os i stedet være åbne for alt, der kan tænkes at give indblik i enkelte brugeres oplevelser.

Der er en lang række specialister, du kan drage nytte af for at lave et kvalitativt overblik. Personer, der med lidt forberedelse kan undersøge kvalitative aspekter, lave stikprøver og give feedback om tænkbart potentiale. En del af dem har du sikkert allerede som kolleger. Jeg selv, der ser på webben fra en webudviklers synvinkel, har en hel del tricks, du næppe finder hos et brugervenlighedsfirma. Jeg har svært ved at tro mindre om andre faggrupper.

RUM-værktøjer – vis brugernes faktiske oplevelse

Vil du i stedet have lidt mere sikre resultater, du ikke behøver at kunne begrunde på egen hånd, er der altid RUM (Real User Monitoring) at ty til. Det er i visse tilfælde lidt af en uhellig blanding mellem kvantitativt og kvalitativt, i hvert fald hvis du har masser af brugere. Det, RUM gør, er at inspicere rigtige brugersessioner og vise dem for dig, uden at du behøver at samle brugerne eller opsøge dem. Sjusket udtrykt optager man brugerens hele session ved hjælp af diverse værktøjer. Bagefter kan man derefter inspicere den brugersession, filtrere blandt de indsamlede brugersessioner i jagt på noget bestemt.

Det kan være en effektiv måde at fremlægge sin sag over for kolleger, ledere eller kunder. At brugere rent faktisk har haft præcis den oplevelse.

Billede 49: Inspicér anonymiserede brugeres sessioner på webstedet.

I Google Analytics findes disse sessioner under Audience –> User Explorer. Der kan du se lidt overordnet information om brugere, der gør, at du kan vælge at inspicere de oplevelser, der har ført til konvertering, eller hvad du nu finder interessant at undersøge. Hver bruger er afidentificeret og repræsenteres i stedet af et Client Id.

Ved at opmærke dit indhold med metadatastandarden Schema.org kan du hjælpe Google med at forstå, hvilken værdi den respektive aktivitet har. Det kan lette, når du vil kunne sammenligne konverterende brugere indbyrdes. Måske er der noget at forbedre?

Billede 50: Rapport fra en brugers oplevelse med at købe en bog.

Billede 51: Hotjar sporer, hvor brugerens musemarkør har bevæget sig.

Andre værktøjer er for eksempel Hotjar⁴⁹ og Clicktale⁵⁰. Begge har funktioner til visuelt at optage brugerens oplevelse af et websted. Man kan se præcis, hvor brugeren er standset op, hvor musemarkøren bevæger sig hen over skærmen, og hvordan de kommer igennem det indhold og de delmomenter, der er.

Det, der gør denne type værktøjer højinteressante, er, at de giver indsigt i, hvordan brugerrejsen faktisk ser ud på vej mod et mål. De giver lidt mere kvalitativ vinkel på den ellers så dominerende konverteringstragt (conversion funnel på engelsk). En konverteringstragt giver dig information om kvantiteten af konverterende brugere i det respektive delstep, mens dette giver dig kvalitativ indsigt i, hvordan den oplevelse kan tage sig ud.

Pingdom, som vi kommer til at tale mere om under præstationsdelen, har også et RUM-værktøj. Groft forenklet måler Pingdom, hvor hurtigt et websted indlæses, og normalt har de en bunke servere placeret rundt om i verden, der gør dette for os. Men det giver jo egentlig ikke kvalitativ data, kun kvantitative data, eller direkte fiktive. De har intet med en rigtig brugers oplevelse at gøre. Det, Pingdoms RUM-værktøj kan være godt til, er, hvis man vil vide, hvor godt ens websted indlæses for brugere på et andet kontinent. Jeg, der historisk har driftet mine private webprojekter hos Loopia i Västerås, burde måske overveje at flytte indholdet tættere på brugerne. Med hjælp af Pingdoms RUM kan jeg følge op på, om min engelske blog er tålelig for rigtige brugere, der forbinder fra USA's vestkyst. Det er et godt værktøj til at kunne handle baseret på rigtige data.

Billede 52: Med Pingdoms RUM-værktøj kan man indstille, hvem man sporer, og hvilke tærskelværdier man vil gruppere informationen i.

Teknisk kvalitet ved konstruktion

Billede 53: Pagespeed Insights giver besked om en sides præstation og brugervenlighed.

Både Google Pagespeed Insights og Sitespeed.io er brugbare også som kvalitative værktøjer, når man vil lave stikprøver omkring præstation og det tekniske miljø. Det kan være nødvendigt at gøre direkte efter idriftsættelse for at sikre, at den forventede kvalitet er opnået.

Jeg håber ikke, at konceptet omkring tilgængelighed kommer som en overraskelse for nogen. Det er muligt at lægge enormt meget indsats i den type arbejde. Nogle gange bliver man nødt til at lægge meget tid i det, da det i stadigt flere sammenhænge lovgives om et minimumsniveau. I USA er der Section 508⁵¹ om, at informations- og kommunikationsteknologi skal være tilgængeligt. I 2015 blev den svenske diskrimineringslovgivning skærpet og begyndte at gælde også i digitale sammenhænge, det blev altså ulovligt ikke at tilbyde et grundlæggende niveau af tilgængelighed. Mens bogen skrives, er jeg ikke blevet bekendt med præcedens for, præcis hvor strengt loven fortolkes i forskellige sammenhænge, men det er værd at følge svensk praksis nogle år efter, at en ny lov er tilkommet. Ud over dette blev der i 2016 indgået en aftale⁵² inden for EU om, at myndigheders websteder, intranet og apps skal have god tilgængelighed. Populært kaldet Webdirektivet.

For at stifte bekendtskab med emnet kan man teste sin tekniske kvalitet, altså evaluere den kode, der lander i brugernes webbrowser. Både webstandardorganisationen W3C's tilgængelighedsstandard WCAG og svenske Webbriktlinjer.se tilbyder en hurtigtest⁵³, du kan prøve. Det er en bunke spørgsmål at besvare.

Billede 54: Der er billeder uden korrekt håndtering af alternative tekster hos gp.se

For en mere almen kvalitetskontrol er der et uendeligt antal værktøjer, der henvender sig til udviklere af forskellige slags. Men et, der er værd at se på for enhver, der bare vil lave et helbredstjek på en side, er webbureauet Netrelations Inspector⁵⁴. Det giver klare og forståelige beskeder om blandt andet tilgængelighed.

Visuelle test

Inden mobilbrugernes indtog på webben plejede webudviklere ofte manuelt at tjekke, hvordan det, de byggede, så ud i de 2-3 seneste versioner af Internet Explorer, seneste Firefox og Chrome. I dag er variationen dog så enorm, at det ikke er muligt at teste på den måde. Heller ikke er det gørligt for de fleste at købe udstyr til test, da det konstant skal fornyes.

Billede 55: Hos Filament Group har man et såkaldt "device lab" til at kunne prøve design på forskellige enheder.

En forskel fra før smartphones var, at da var ambitionen at gøre websteder "pixel perfect". Det vil sige, at man sendte lange lister med krav om, hvordan forskellige ting skulle flyttes nogle pixels i den ene eller anden retning. Pixelskubberi har heldigvis de fleste opgivet med responsivt webdesign. Måske fordi man har forstået, at det sørme er umuligt at få det til at se identisk ud på alle enheder.

En løsning på denne udfordring er at drage nytte af tjenester som BrowserStack⁵⁵. De har udstyr, du kan prøvekøre via nettet for at vide, hvordan et websted ser ud. I skrivende stund har de Windows- og Mac-computere, iOS- og Android-enheder. Bemærk, at det er den respektive enheds rigtige webbrowser, der bruges, det er ingen simulering.

BrowserStack kan også integreres i udviklerværktøjer, så testen foregår lidt mere automatiseret. Så kan man have gemte billeder for at kunne gennemgå, om noget er sket med vigtige sider, desuden får du en log over, hvordan det har set ud historisk. Visuelle test går ud på, at vigtige designelementer skal synes og have forudsætning for at fungere, det handler ikke om at overvåge layoutet eller detaljer inden for formgivning. Du bør være mere interesseret i, om din call-to-action er væk, end om logoet er en pixel skævt.

Nu er der jo tusindvis af forskellige kombinationer af enheder og webbrowsere. For at begynde at vælge lidt i den jungle kan et tip være at kontrollere, hvordan det ser ud i de enheder, der har højest afvisningsprocent på dit websted.

Billede 56: Fra min Mac låner jeg en Windows 7-computer over nettet for at sikre designet på min fejlside.

Opret en testside til at evaluere ændringer i webdesign

For at det skal være en retfærdig sammenligning fra en måling til en anden, er det nødvendigt at teste under samme forudsætninger. Med andre ord skal man opsætte en testside på sit websted, og den side er den, man laver test mod for at vide, at resultaterne er sammenlignelige over tid. Det, der kan variere, er webserverens svartid, men sidens indhold i redaktionel forstand skal være det samme fra gang til gang.

Gør du det på denne måde, ved du, om ændringer i webstedet har gjort situationen bedre eller værre. Det kan være, at du prøver at skifte tema, hvis du kører Wordpress, at dine udviklere har opgraderet noget, eller muligvis lavet en nyudvikling.

Hvordan man udformer sin testside

For at din testside skal være meningsfuld, gælder det, at den i redaktionel udformning er den samme over en længere tid. Hvis du skal kunne sammenligne resultatet før en opgradering af publiceringssystemet med efter, gælder det, at indholdet er det samme.

Mit forslag er, at du opretter en underside udelukkende beregnet til test. Den side skal indeholde tekst, billeder og sådant, der er normalkomplekst for en almindelig side på webstedet. Det er ikke her, du indlejrer en masse mærkelige eksterne tjenester, widgets, videoklip eller sådant, hverken du eller de andre involverede har kontrol over.

Lav en nulmåling

Når du har din testside, laver du en første måling hos de tjenester, du vil bruge, såsom Google Pagespeed. Derefter afstemmer du resultatet med alle involverede og dokumenterer det et sted (så folk forstår, at dette må de finde sig i fremover). På en passende højtidelig måde burde man sikkert erklære, at det ikke er acceptabelt, at resultatet bliver dårligere over tid, snarere at det bør forbedres.

Ved næste opdatering eller ændring er det nødvendigt at tjekke, at det faktisk ikke bliver dårligere, helst skal det blive bedre, men absolut ikke dårligere. Med andre ord bør eventuelle eksterne parter, som konsulenter, allerede i opgaven få at vide, hvilke acceptkriterier der er. For eksempel at du kræver i opgavebeskrivelsen, at:

Da vi i dag har 67 af 100 ifølge [jeres rettesnor], samt at I som udfører har accepteret at overgå dette niveau, er det at betragte som en garantisag uden omkostninger for os som kunde, hvis leverance på oprettet testside ikke er absolut mindst 70 af 100 ifølge [jeres rettesnor].

Jeg er ikke jurist, men hvis udføreren fejler med dette, bør man forhåbentlig kunne undlade at betale den sidste faktura.

Nogle flere perspektiver på webanalyse

Først og fremmest vil jeg som altid pointere, at det, du finder i dit webstatistiksystem, sandsynligvis kun er en delmængde af de data, du har brug for til at gøre et ordentligt arbejde inden for webanalyse. Denne indsigt når du sikkert, så snart du tænker videre over, hvordan du måler virksomhedsmål på webstedet.

Nøgletal (KPI - Key Performance Indicator)

Nøgletal er ikke et begreb, der er eksklusivt for webben. Snarere er det et etableret begreb, der længe har eksisteret inden for forretningsverdenen. Et nøgletal i vores sammenhæng fortæller, hvordan webstedet bidrager med værdi til organisationen. Det kan være, hvordan en kundes aktivitet på webstedet kan omsættes i kroner og øre, eller hvordan for eksempel organisationens omdømme er blevet påvirket.

Mange organisationer har allerede nøgletal. Det, du som webanalytiker har at gøre, er at se, om de kan bruges også på webben. Det er en fremragende måde at gå fra uklar hobbyvirksomhed til at få lederne i organisationen til at forstå, hvilken nytte webstedet bidrager med. Det gør det lettere at forsvare ønskede investeringer og er det fælles sprog, man kan bruge ved elevatortaler med den øverste chef, samt det, man tipser om til årsrapporten.

Virksomhedens mål med webstedet

Hvis der ikke er nogen nøgletal, der kan genbruges (eller let modificeres til genbrug på webben), kan du forhåbentlig finde jeres virksomhedsmål dokumenteret et sted. Hvis I tilfældigvis mangler både virksomhedsmål og nøgletal, der er anvendeligt på webstedet, havner jeres problem lidt uden for denne bogs emne, men jeg vil gætte på, at I ikke er alene. Tværtimod er det præcis, hvad jeg ofte har fået at vide, når jeg har spurgt mine opdragsgivere det ultimative spørgsmål: "Hvorfor har I et websted, egentlig?!". Det plejer at blive en masse rømmen, kiggen nedad, skraben med fødderne mod gulvet og generelt distræt adfærd. Jeg forstår godt, at folk skammer sig, men jeg tror ikke, det er så ualmindeligt.

Sandheden er nok, at mange står lige i skiftet mellem at have et websted "fordi alle andre har et" og at finde ud af, præcis hvad man vil have ud af sit websted. I mange tilfælde befinder dem, jeg har talt med, sig midt i et organisationstræ. Så er de overordnede mål ikke altid relevante for ens eget websted. På sit eget niveau i organisationen har man ikke altid opsatte virksomhedsmål, eller kendskabet til dem er ikke særlig højt.

For myndigheder og offentlig sektor kan man i værste fald læse den opgavebeskrivelse, man har fået fra staten. Der står ens opgave formuleret på det værst tænkelige bureaukratiske sprog.

I den private sektor er den seneste årsrapport sikkert et sted at finde virksomhedsmål, men også mere kortsigtede forhåbninger. Hvis man har en god forretningsplan dokumenteret, vil virksomhedens mål og nyttiggørelse nok være beskrevet der.

Eksempler på formulering af nøgletal

Eksempler på, hvad man kan ønske at måle ved hjælp af et nøgletal, er nogets indvirkning på ting som:

• Salg
• Avance
• Omkostningsreduktion
• Gennemsnitsniveau for kundetilfredshed på en skala
• Maksimal ventetid for en kunde

Da jeg har researchet på, hvad et godt nøgletal kan tænkes at være, fandt jeg bogen Key Performance Indicators (KPI): Developing, Implementing, and Using Winning KPIs. Den mener, at gode nøgletal har følgende egenskaber:

1. Ikke er hårdt knyttet til finansielle mål. Det skal ikke udtrykkes i valutatermer. Her er det præcis som i øvrig webanalyse trenden eller forandringen, der er interessant.
2. Veltajmet i tid. Det bør være muligt at se, hvordan nøgletallet præsterer oftere end årligt i årsrapporten. Helst vil man jo have dette opdelbart og sammenligne en time med en anden, men i det mindste skal hver dag eller uge have et afstemningspunkt for nøgletallets præstation.
3. Beslutningsorienteret fokus. Ledere af virksomheden skal kunne handle baseret på nøgletallene.
4. Er forståelige. Samtlige ansatte bør forstå måleværdiets nytte, kunne finde ud af, hvordan det måles, og på hvilken måde man kan handle for, at resultatet bliver bedre.
5. Kan knyttes til bestemte grupper. Ansvaret skal kunne tildeles en enkelt gruppe ansatte, og denne gruppe skal gennem sit arbejde kunne påvirke nøgletallets trend.
6. Har en mærkbar gennemslagskraft. Her kommer meningsfylden ind, at nøgletallet skal gøre meningsfuld nytte i virksomheden. For dig, der arbejder med balancerede scorecards, skal nøgletallet påvirke mere end ét eneste scorecards perspektiv.
7. Har en begrænset ukendt faktor. Et godt nøgletal opmuntrer positive aktiviteter. Et dårligt gennemtænkt nøgletal derimod kan føre til en uønsket adfærd hos de ansatte, for eksempel at kundesupporten hårdsælger i stedet for at hjælpe kunden med årsagen til opkaldet.

Nøgletallene kan i sig selv være af forskellige slags, nemlig om de er kvantitative eller kvalitative. Dette er ikke en bog om statistik, men nogle grundlæggende indsigter i det, statistikere arbejder med, er sundt for enhver webanalytiker. Dette bliver lidt af en gentagelse, men også en udvidelse af kvalitativt versus kvantitativt.

Kvalitative data, metoder og information – data om følelser, holdninger, oplevelser og meninger

Kvalitative data er dem, der ikke direkte tiltaler statistikere, de er mere af den ustrukturerede slags, som ikke nemt kan bearbejdes af computere. Eksempler på kvalitative data er spørgeskemaer, synspunkter fra brugere, synes godt om-klik og lignende. Oftest er disse udtrykt på den måde, folk selv udtrykker sig, med menneskeligt sprog, det vil sige på en måde, der gør det svært at tolke, hvis man ikke læser dem og vurderer dem.

Kvantitative data og metoder – data om brug og adfærd

Kvantitative data er, som navnet antyder, data, der følger statistiske modeller for, hvordan man beskriver noget. Den mest almindelige kilde inden for webanalyse i dette tilfælde er webstedsstatistikken, hvor man indsamler data om, hvordan brugere bevæger sig på webstedet – deres adfærdsdata som gruppe altså. Derudover kan der være andre datakilder, der påvirkes af aktiviteten på webstedet, eller omvendt, at aktiviteter uden for webstedet påvirker webben. Eksempler på sidstnævnte er pludselige trafiktop og i den udstrækning, man kan finde ud af årsagen. Det kan handle om helt normal sæsonvariation, men det kan skyldes udbrud af sygdomme, midsommervejret og meget andet.

Standardiserede metoder og måleværdier

For at kunne sammenligne sig med andre organisationer er der en pointe i at forsøge at genbruge andres målbare mål. En måde er at tjekke websteder, hvor man lister almindeligt brugte nøgletal, en anden er at bruge det samme værktøj eller benytte eksisterende metoder til måling. Så får du også hjælp med, hvordan målingen skal foregå.

CTR – Click Through Rate, eller gennemklikningsfrekvens

CTR har nok de fleste hørt om. Det handler om i procent at angive, hvor stor en andel der er blevet eksponeret for et tilbud (ofte kaldet call to action) og derefter har klikket sig videre mod det fælles mål. Dette tilbud er altså en vej, man kan navigere ved at klikke på en knap eller lignende for at lægge et produkt i indkøbskurven, tilmelde sig et nyhedsbrev m.m. Hvis en knap har en CTR på 77 %, indebærer det, at 77 % af dem, der så den, valgte at klikke på den. En CTR på 4,1 % i Googles søgeresultater indebærer, at 4,1 % klikkede på netop din træffer. Hvad de andre gør, kan man ikke udlede af en CTR, det er ikke det, man måler. Det hænder også, at man på sider med flere samtidige tilbud taler om en CTR som, at noget af ens tilbud fik et klik.

Nogle gange hører man det fortælles om, hvilken CTR nogen har, og omgivelserne lader imponeret, eller kommenterer, at "det var usædvanligt godt". Skal jeg være helt ærlig, har jeg endnu ikke selv forstået dette, og af den litteratur, jeg har læst, er der ingen optimal CTR. Heller ikke at det skulle være meningsfuldt at forvente en bestemt CTR. Det her trækker mere end lovligt i retning af, at man måler forfængelige ting. At en vis andel brugere har klikket sig til næste trin, betyder ikke, at et virksomhedsmål er opnået. Det er ligesom antal sidevisninger en isoleret måleværdi, der fortæller en historie om brugen, men værdien af den viden er i sig selv uhyre lav, bortset fra for den, der arbejder med det specifikke websted.

Men med det sagt kan det være værd at eksperimentere med sin CTR for at se, om man kan styre brugernes opmærksomhed om, altså hæve sin CTR, og om det i forlængelsen har et positivt slutresultat. Det er ikke sikkert, at en højere CTR fører til højere konvertering. Det er det digitales svar på en påtrængende sælger. På de websteder, jeg har inspiceret, er vejen frem til en konvertering ofte lang og kringlet. Det er ikke selvfølgeligt, at det virker at forsøge at forkorte tiden for brugerens overvejelse. Derimod, hvis man formår at identificere et brugersegment, man tør eksperimentere med, så sæt i gang.

Måder at eksperimentere med højere CTR:

• Arbejd med A/B-test på dit eget websted eller i annoncesammenhæng for at finde ud af, hvilken der får højest CTR. Ud over det skal du være opmærksom på eventuelle negative konsekvenser. Måske forårsager påtrængenheden, at brugerne konverterer i mindre udstrækning på de for organisationen mest værdifulde tilbud.
• Find sider med lav CTR i søgemaskinerne, og modificér sidetitlene. Det kan også være værd at modificere anden metadata på siden. For at finde siders CTR hos for eksempel Google kan du tjekke deres værktøj Search Console.

Billede 57: Oversigt for min arbejdsgivers CTR hos Google.

Hoppen (pogo-sticking)

Brugeradfærden med at hoppe frem og tilbage mellem sider gælder nok primært de sider, der har en søgelignende grænseflade, produktlister eller lignende. Det handler altså om, at man sporer, hvor længe en bruger bliver på en underside, de er nået til via en liste med mange andre alternativer. Om det er en adfærd, der er værd at spore på dit websted, ved kun du. Det siges, at Google er nysgerrige på dette for at kunne sammenligne forskellige søgetræffere indbyrdes. Det er ganske vist kun et signal blandt flere andre, men der er nok belæg for, at en sides relevans er lav, hvis det er almindeligt, at brugerne lynhurtigt hopper tilbage.

Tag to sider med identisk relevans for en søgeforespørgsel hos Google. Hvis den ene side i højere grad end den anden forårsager, at brugerne vender tilbage, er der nok grund til at sænke dens relative værdi. På samme måde kan man tænke om, hvordan man selv lister indhold på sit websted. Er det værd at beholde alt i listen, eller kan listen som helhed præstere bedre, hvis man laver en ændring? Hvad skal ligge øverst, og hvorfor?

Måder at forsøge at mindske hopperi:

• Forbedr indlæsningstiden og se, om det ændrer noget. Det kan være, man har et for tungt billede eller venter på en langsom ekstern API.
• Tydeligere bekræftelse af sidens værdi. Det kan skyldes designfaktorer som, at brugerne ikke forstår eller kan afkode sidens indhold og derfor hopper tilbage. En måde er at forsøge at mindske den kognitive byrde for brugeren til at finde ud af, at vedkommende er havnet det rigtige sted.

Opholdstid (Dwell time)

Denne skal man være forsigtig med, men i stor skala kan den være meningsfuld til for eksempel at vide, om længere materiale faktisk bruges, fordi brugeren læser det eller opholder sig ved det. Med andre ord skal man samkøre med et mål for, hvor lang tid det tager at tilegne sig et indhold. Er det primært tekst, er den totale læsetid en værdi at sammenligne med. En funktion, der kan integreres i dit websted. Det indhold, der har en høj læsetid og høj opholdstid, giver et signal om, at materialet holder en høj kvalitet, har et højt engagerende indhold eller lignende.

Nu tænker du måske, at dette er forfængeligt? Det er godt! Opholdstiden er et signal blandt mange andre til at relativere, hvilket indhold man i kvantitative tankebaner har grund til at tro er værdsat af brugere.

Billede 58: Beregnet læsetid for et blogindlæg på min Wordpress-blog.

Fra en søgemaskines synspunkt, eller din produktlistnings vinkel, kan opholdstiden snarere ses som et mål for, hvor længe brugeren opholder sig på søge- eller produkttræfferens side, før brugeren vender tilbage til listen.

Net Promoter Score – NPS

Du har sandsynligvis stødt på Net Promoter Score (NPS)⁵⁶, men måske ikke indset det. Det, man forsøger at opnå med NPS, er at have én eneste måleværdi, der skal afspejle, hvor godt noget er, hvor loyal kunden eller brugeren er. Scoren går fra -100 til +100. Er værdien negativ, er det en person eller gruppe, der mere eller mindre passioneret vil tale dårligt om noget. I den positive ende er det, i hvor høj grad personen eller gruppen er ambassadører for noget og fortæller om det i positive vendinger til sine omgivelser. Får man scoren -100, betyder det, at alle er passionerede i deres afsky, får man +100, er alle så tilfredse, at de vil fortælle om det til deres omgivelser. At have over nul anses for at være godt, og over +50 er en fremragende score.

NPS går ud på at stille ét eneste spørgsmål, nemlig:

"Hvor sandsynligt er det, at du ville anbefale virksomheden/produktet/tjenesten/webstedet til en ven eller kollega?"

Svaret angives af den adspurgte på en skala fra nul til ti, hvor man til alle nørders glæde faktisk kan vælge nul. Dette resultat omregnes derefter til den tidligere nævnte skala. Respondenterne deles op i tre grupper, så man ved, hvad man har med at gøre. De, der har svaret:

• 9-10 kaldes promoters og er ambassadører fyldt med positivitet.
• 7-8 kaldes passive og bidrager ikke med meget nytte.
• 0-6 kaldes detractors, og man kan antage, at de ikke vil tale godt om det, de er blevet spurgt om.

Svar mellem 9-10, promoters, antages at skabe merværdi i sit personlige netværk, for eksempel at ville tipse sine omgivelser, når lejligheden byder sig. Hvis du har mødt nogen, der har valgt at anskaffe en Apple-computer, ved du nok, hvad jeg mener, personen synes overbevist om, at løsningen på næsten alle udfordringer findes inden for Apples platform.

Dem, der svarer 7-8, anses for at være passive, deres adfærd ligger mellem positivt og negativt.

Svar mellem 0 og 6 anses for at være negative (detractors på engelsk). De vil ikke tale godt om dit websted, når det kommer på tale, de vil måske ligefrem modarbejde jeres virksomhedsmål.

For at beregne sin NPS-score beregner man gruppernes procent mod hinanden, for eksempel hvis du har: 35 % promoters, 40 % passive og 25 % negative, følger du formlen promoters minus negative, 35 – 25. Altså bliver det +10 i NPS.

Husk kun at sammenligne dit websteds NPS-score med sammenlignelige ting. For eksempel kan man måske ikke sammenligne en luksusbilproducents websteds score med scoren for den spanske ambassades websted.

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

SERVQUAL og RATER

En anden model til at lade brugere bedømme en form for tjeneste eller service er SERVQUAL⁵⁷. Den blev udviklet i slutningen af 1970'erne og er tænkt at bruges til at opdage, hvilket gab der er mellem forventet kvalitet og den, der opleves af brugere. Som tidligere nævnt, blandt andet med reference til David Maister, er en formel for kundetilfredshed at sammenligne den faktiske oplevelse med den forventning, der var på forhånd. Hvis oplevelsen er i overensstemmelse med forventningen, er alt fryd og gammen, men hvis forventningen er højere end oplevelsen, bliver der problemer.

For at nedbryde oplevet service af en tjeneste, som ikke nødvendigvis skal være digital, i en tjenestes forskellige dimensioner, har man i SERVQUAL specificeret noget, der kaldes RATER. Det er en forkortelse af de indledende bogstaver:

1. Reliability: evnen til at udføre den lovede tjeneste på en pålidelig og præcis måde.
2. Assurance: viden og høflighed hos det service(personale), brugerne kommer i kontakt med. Også tonelejet i skrevet tekst tæller, naturligvis. Det går ud på, at brugerne skal kunne stole på det, der siges, og have tillid til tjenesten.
3. Tangibles: mere relevant i et fysisk scenarie muligvis, handler om de håndgribelige ting som lokaler, lager. I mere digitale sammenhænge muligvis, at designet bekræfter, at man er havnet det rigtige sted.
4. Empathy: at man varetager brugerens individuelle behov.
5. Responsiveness: give service hurtigt nok.

At arbejde ifølge denne model er en blanding af både kvalitativt input og en kvantitativ måde at beskrive et nutidsbillede. Den kvalitative aspekt er, at det tager udgangspunkt i rigtige brugere og deres måde at beskrive tjenesten, men samtidig kan man opsummere hvert punkt med en score for at forsøge at kvantificere det. Fordelen ved at kvantificere det er, at tal er lettere at sammenligne over tid, så man kan vide, om oplevelsen af tjenesten har ændret sig.

Triple bottom line

En måde at kategorisere (og nuancere) de mål, man har, er at flette lidt af organisationens samfundsansvar ind i sin måde at måle på. Begrebet blev skabt af John Elkington i 1994⁵⁸. På engelsk bruges et begreb, du sikkert har hørt om, CSR (Corporate Social Responsibility). Man får altså lidt moral ind i arbejdet med opfølgning.

Det hele går ud på, at man supplerer de finansielle mål med social påvirkning og hvad der sker med miljøet. Med andre ord skal man balancere et retfærdigt socialt klima, at miljøet ikke tager skade, med også at tjene penge. Langsigtethed, ganske enkelt.

Billede 60: Video om robotten Liam, der demonterer iPhones. Apples værdier som en del af markedskommunikationen.

Ja, det er svært nok at finde kloge og målbare virksomhedsmål bare omkring det finansielle. Derefter at kunne relatere og relativere det finansielle med social- og miljøpåvirkning kan føles overvældende. Samtidig kan det i en større sammenhæng være det værd. Se for eksempel på, hvordan Apples kundekommunikation har fået i hvert fald miljøperspektivet indarbejdet. Alt fra hvilken miljøpåvirkning forskellige produkter har, til at indlede en pressekonference med at vise en robot, der genbruger gamle iPhones. Robotten har endda et navn, Liam.

Because in a world with limited resources – some things cannot be replaced.
- Apple i præsentation⁵⁹ af Liam, deres genbrugsrobot

For mig som ansat i en skattefinansieret virksomhed er dette mere naturligt nu, end da jeg arbejdede i den private sektor som konsulent. Gav vores lille Göteborgskontor et tilstrækkeligt dårligt økonomisk resultat, kunne man regne med, at det blev lukket. Gav vi derimod et fremragende økonomisk resultat, ville man virkelig være en kedelig person, hvis man syntes, vi fløj for meget og tog for lidt tog for at tjene de penge.

Det er ikke foreneligt med en bæredygtig forretningsdrift at ødelægge miljøet, eller at gemme indtægterne i et skattely, hvis det går ud over det samfund, man opererer i.

Triple bottom line er en måde ikke at blive fartblind omkring det økonomiske, men snarere at indse, at man har interessenter, der ikke er blandt aktionærerne. Noget, jeg håber, stadig flere virksomheder begynder med som en del af deres arbejde med bæredygtighed. Måske kan vi webanalytikere hjælpe denne udvikling lidt på vej ved at vælge målbare mål på lidt ukonventionelle måder.

Om statistik (og almindelige fejl)

De data, der ikke har en tydelig kobling til virksomhedens mest højtravende formål med webstedet, er at betragte som øvrige data. De er ikke nødvendigvis uvigtige af den grund, men de er i hvert fald ikke oplagte med hensyn til, hvordan man regner investeringen hjem i form af nye kunder, flere afgivne bestillinger i butikken og så videre.

Segmentering

Præcis som anden statistik kan man forsøge at omforme sine data i jagten på fund, eller at man vil se, hvordan kampagnen til en bestemt kundegruppe præsterer. Et almindeligt kneb, vi allerede har berørt en del i bogen, er at segmentere. Så kan man fokusere på en delmængde af al statistik, for eksempel tjekke, om reklameudsendelsen i Eslöv har en påviselig effekt af besøgende fra Eslöv på webstedet.

En almindelig segmentering, mange webanalytikere lavede omkring 2008 med hjertet i halsen, var at segmentere mobile brugere frem. Dette for at forsøge at lære deres adfærd at kende i håb om ikke at tabe markedsandele. Det virkede uundgåeligt, at flertallet ville foretrække at bruge mobilen til at besøge webben.

For at forstå de tal, der segmenteres, kan segmentet have behov for at blive sammenlignet med et andet segment. En interessant udvikling, vi så på 1177.se i begyndelsen af 2010'erne, var, at stigningen i antallet af besøgende næsten udelukkende kunne tilskrives segmentet brugere med mobil og tablet. Udviklingen inden for det segment var eksplosiv sammenlignet med dem på computer. De ansvarlige fik fart under sig til at få lavet et responsivt websted, der var lidt mere brugervenligt for dem med mindre skærme. Nu var jo den udvikling noget, de fleste af os havde svært ved at overse, da det konstant kom på tale. Spørgsmålet er bare, hvornår man baseret på sin egen webanalyse skulle have taget en tidlig beslutning om at gå responsivt? De data, vi har på vores egne websteder, er jo det, vi har fortjent. Det vil sige, inden webstedet fungerer ok for en mobil bruger, er der risiko for, at det segment er så lille, at man ikke opdager det – fordi de ikke kommer tilbage oftere end nødvendigt.

Billede 61: Udviklingen for segmentet "mobile & tablet" stod for broderparten af stigningen på 1177.se

Samme spørgsmål kan man have om, hvorvidt man skal optimere for brugere på Playstation, eller det fåtal under 2016, der forbinder med suspekte user-agents⁶⁰ som "in-car". Hvor mange, der forbinder via deres bil, skal du se i din statistik, før du skal begynde at bekymre dig?

Være bevidst om sine begrænsninger og vanskeligheder

Det med at tolke data er svært, det skal ikke stikkes under stolen, og mange gange skal man være i tvivl om, hvorvidt man har grundlag nok til at drage meningsfulde konklusioner. Det er klogt at være ydmyg over for sine data, og har man mulighed for at dobbelttjekke sine data og den måde, man rapporterer konklusioner på, med en statistiker, er det fremragende brugt tid. Uanset hvad, sørg for at have forklaringen af metode og rapport tæt ved hånden, da du kan regne med, at der vil blive stillet spørgsmål om baggrunden for konklusionerne.

Et almindeligt problem netop omkring webanalyse er, at man ikke kan drage vidtrækkende konklusioner på indsamlede data. Ofte fordi forandringen ikke er tilstrækkelig stor til at kunne blive statistisk signifikant, eller fordi grundlaget er for lille (hvilket gør fejlmarginen alt for stor).

Når man som amatør inden for statistik kigger på data, skader det ikke at minde sig selv om, at man er menneskelig. Mennesker begår fejl, ofte. Desuden begår vi fejl på nogle gange forudsigelige måder, hvilket gør, at man kan have en liste med almindelige fejl i baghovedet, inden man jubler for højt over noget, man har fundet.

Nogle forslag for os webanalytikere er at være opmærksom på ting som:

1. At udvalget er ok og stort nok. Det er ikke statistik at tale om anekdoter fra et fåtal brugeres oplevelser, så handler det om en kvalitativ metode, og det er noget helt andet. Indsamlede data skal være fra en tilstrækkelig stor undersøgelse, og desuden er sammensætningen inden for den gruppe vigtig. Udvalget skal være repræsentativt, hvilket ofte beskrives som, at det skal være tilstrækkeligt tilfældigt.
2. Sammenlign ikke æbler og pærer. Begge er ganske vist frugter, men du skal være forsigtig med dine konklusioner. Laver du en A/B-test, hvor den ene gruppe udelukkende består af nye besøgende og den anden af tilbagevendende, er det risikabelt at drage nogen konklusioner.
3. Bekræftelsesbias er den højst naturlige adfærd at lede efter argumenter og beviser for, at man har ret. Altså lægger man større vægt på det, der bekræfter den opfattelse, man allerede har. Det behøver ikke at være en særlig bevidst handling, snarere kan det for mange af os ske automatisk – så dæmp gerne den anklagende tone, når du påpeger dette for nogen.
4. Self-selection bias: At vi selv ofte ikke er særlig repræsentative. Det er mildt sagt tvivlsomt at tro, at man selv tilhører en gruppe af brugerne. Trods det er det almindeligt, at man tager udgangspunkt i sig selv og danner en gruppe brugere baseret på det. Her har man altså ødelagt sit udvalg.
5. Vær forsigtig med dine årsagssammenhænge. Vi mennesker er meget hurtige til at drage konklusioner på forkerte grundlag, der er tilsyneladende en evolutionær grund til det. Bagsiderne af dette er overtro, og at vi ser mønstre, hvor der ikke er nogen sammenhæng. Vil du have noget letsindet om dette, så køb bogen Spurious correlations⁶¹, eller hvis du vil have noget mere akademisk, er bogen Why: A Guide to Finding and Using Causes⁶² det, du søger.
6. Dine konklusioner bliver aldrig bedre end dine data. Det er af højeste vigtighed, at man har styr på sin datakvalitet. At disse data er repræsentative, og at intet vigtigt mangler for at turde drage konklusioner. Husker du mit eksempel, hvor brugere sad fast i firewallen? Inden jeg kender til, hvor almindeligt det er, og hvordan det foregår, er det svært at drage konklusioner på de øvrige data, jeg har indsamlet.

Forsøg at operere inden for dine begrænsninger. Når det føles kompliceret, så læs ordentligt op, eller tag kontakt med nogen, der er ekspert på området. Indrøm, når du ikke ved noget, vær åben om det, og husk, at alt er faktisk heller ikke værd at finde ud af.

Forfængelighedstal (såkaldte "vanity metrics")

I sin webstatistik har man masser af forskellige visninger af data, i hvert fald flere, end man ved, hvad man skal bruge til. Hvis man ikke kan koble dem til noget utvetydigt godt, risikerer de kun at være interessante, fordi de appellerer til din forfængelige side. Nu er disse tal ikke helt værdiløse, men det er vigtigt at se dem for, hvad de er. Nemlig tal, som du kun kan bruge som anekdoter, når du møder folk inden for din egen faggruppe.

At formulere mål baseret på antallet af sidevisninger per besøgende er mildt sagt tvivlsomt, det kan ikke rigtig påstås at relatere til de mål, virksomheden har. Er det virkelig altid bedre at have mange sidevisninger? Sandsynligvis ikke, i hvert fald ikke altid.

Det, du alligevel med æren i behold må bruge af forfængelighedstal, er dem, der fortæller besøgendes historie om deres session på webstedet. Kan du knytte tallene til et nøgletal eller andet værdifuldt, der skal rapporteres, er det tal, der er værd at pleje. Så har de en værdi, om end en ringe værdi. De kan da i bedste fald fortælle, hvorfor et nøgletals trendbrud er opstået. For eksempel at et styrtdykende salg falder sammen med, at besøgende fra en måned til den næste er begyndt at bruge mobiler, eller hvad det nu er for en forfængelig måleværdi.

Hygiejnefaktorer

Hygiejnefaktorer er forudsætningerne for, at dine virksomhedsmål skal kunne indtræffe. Hvorfor noget skal kunne indtræffe. Det er ikke hygiejnefaktorerne, der gør, at du tjener penge på dit websted, så de er ikke mål i sig selv, men de er alligevel vigtige at overvåge. De er selve fundamentet eller forudsætningerne for et værdiskabende websted. Disse beskriver det håndværk, der udgør et velfungerende og værdsat websted. Det, der gør det muligt at sælge noget, eller at nogen kan engagere sig.

Listen over hygiejnefaktorer for et websted er meget lang. Alt, der er målbart, og som påvirker brugerens oplevelse, indgår i, hvad en webanalytiker har at bekymre sig om, når man søger efter optimeringspotentiale.

Sidste del af denne bog laver et dybdedyk i en række hygiejnefaktorer og andre aktiviteter, der kan indgå i et metodisk arbejde med webanalyse, når man leder efter uudnyttet potentiale.

Fortsæt med at læse – Del 4: Aktivitetsplan