Del 3: Webbanalys: Fördjupning

I de föregående delarna har vi skrapat på ytan om webbanalys, tittat på ett arbetssätt för ett metodiskt arbete och även lite projektteori genom att diskutera stilguiders och designs påverkan på analysarbetet.

Nu är det dags att gå igenom många av de saker som de flesta av oss inte automatiskt associerar med webbanalys. Bland annat några av de verktyg man kan ha nytta av för att jobba med uppföljning och inte minst ett gäng tips och anekdoter från verkligheten.

När det gäller mätbarhet i stort så finns det två huvudsakliga kategorier av vad mätvärden kan delas in i (och, ja, man behöver använda båda sorter):

• Kvantitativa data. Ger siffror på hur webbplatsen presterar, exempelvis all den information om användarna som grupp man kan få fram i sitt statistikverktyg. Dessa mätvärden ger svar på frågorna hur, när och vad kring användarna. Vilken utrustning de har, när besöker de webbplatsen, var kom de ifrån och så vidare. Beteende-data som ger insyn i omfattningen av något.
• Kvalitativa metoder. Handlar om hur användarna upplever webbplatsen, så som de själva skulle uttrycka det. Dessa uppgifter är i form av text snarare än siffror. Det kan vara svar på frågor i en webbplatsundersökning, intervjuer, användningstester eller funktioner på webbplatsen där man låter användaren tala om vad de tyckte om sin upplevelse eller det de just läste. Utöver folks attityd till en webbplats kan det i vissa fall handla om att man observerar användarna så att man kan ta chansen att ställa följdfrågor, vid behov. Man letar svar på frågan varför. Kvalitativ information bidrar med de perspektiv som kvantitativa data saknar.

Angående kvalitativa undersökningar är det klokt att vara uppmärksam på i vilken situation användaren befinner sig i när de ska svara på frågor. Du har säkert råkat ut för att bli erbjuden att fylla i en enkät om hur du upplever en webbplats. Ibland dyker dessa enkätinviter upp redan innan man hunnit börja använda webbplatsen. Frågan uppstår då om det inte påverkar hur respondenten fyller i enkäten? Är deras svar identiska med besökare som klickat runt på 2-3 sidor först? Om man tänkt dra slutsatser baserat på dessa data så är det dumt att chansa kring sin datakvalitet.

Bild 37: Denna typ av enkät är direkt olämplig vid en användares första besök på en webbplats.

Det kan vara klokt att åtminstone logga hur många sidvisningar användaren hann med innan hen fyllde i enkäten. Om det är en inloggad person eller på annat sätt återkommande användare är också det bra att veta. För återkommande användare är det troligen inte hela världen att slänga upp enkäten tidigt – de har ju någon gång tidigare upplevt webbplatsen. Här återanvänder du dina segmenteringar av användare. Kanske upptäcker du några nya intressanta grupperingar baserat på de metadata du kan samla in om respondenten, som varifrån de kom, om det finns geografiska skillnader, etc.

Det är svårt att själv utvärdera sin egen webbplats

En sak som tycks vara lätt att glömma bort är att vi som skapar, äger, utvecklar eller på annat sätt ansvarar för en webbplats verkligen inte är representativa användare. Vi är inte heller särskilt bra på att imitera riktiga användare då vi alla kommer med helt egna uppfattningar och förkunskaper. Har man varit delaktig är det kanske främst ens förkunskaper som gör en till en dålig testare.

Därför behöver man med jämna mellanrum genomföra användbarhetstester. Inom det som kallas universell design, ibland inkluderande design eller design för alla, har man tagit fram en lista³⁶ med vad en användbar design går ut på, nämligen:

1. Equitable use – användningen ska vara rättvis och möjlig för alla trots våra varierande förmågor.
2. Flexibility in use – mångsidighet vid användning.
3. Simple and intuitive – enkelt och självförklarande.
4. Perceptible information – innehåll och information ska vara möjlig att uppfatta.
5. Tolerance for error – feltolerant och tillåtande konstruktion.
6. Low physical effort – ska förbruka liten ansträngning.
7. Size and space for approach and use – finnas utrymme för användning och lätthet att göra rätt.

Dessa punkter är inte specifika till digitala skapelser men kan definitivt appliceras på hur man designar webbplatser. De skapades 1997 av The Center for Universal Design vid North Carolina State University, så de är sammanställda långt innan webben började se ut som den gör idag.

Uppstart av ett webbprojekt eller en ombyggnation

Det finns förstås oerhört mycket att tänka igenom när man ska påbörja ett webbprojekt, oavsett om det är innehållet man ska se över, någon ny design som ska till eller om det är ett nytag kring webbanalys. En förutsättning för att man ska kunna begripa vad som är värt att analysera är att man vet vad på en webbplats som är, eller ska bli, det som lever upp till syftet med webbplatsen.

Förslag på saker att fundera igenom tidigt är bland annat:

1. Lista vilka delar som är viktigast, viktiga, normala eller oviktiga. Allt kan inte vara viktigt för alla tilltänkta målgrupper, alltid.
2. Vilka delar av webbplatsen stödjer de viktigaste aktiviteterna? Dessa sidor behöver analyseras i jakt på förbättringsmöjligheter. Som dess placering av knappar, förståeliga texter, hur lätt det är att hitta dit, etc.
3. Hur enkelt är det att hitta mellan de olika aktiviteterna? Fundera förutsättningslöst igenom navigationsstrukturen. Går det exempelvis att hitta tillbaka till respektive startpunkt om man fått en direktlänk via e-post? Är det lätt att växla från aktiviteten att anmäla sig till nyhetsbrevet till att rätta felaktiga adressuppgifter?
4. Hur enkelt är det för användarna att ta sig igenom en aktivitet? Att en butiks överlevnad hänger på att kunderna klarar av att betala för sig är ganska uppenbart. På en webbplats behöver man se till att det finns så få och låga hinder som möjligt för att fullfölja en aktivitet hela vägen.
5. Vad är ett lyckat besök på webbplatsen? Vilka saker ska ha inträffat för att du objektivt ska kunna peka på en användares session på webbplatsen och säga att det var ett lyckat besök? Anmält sig till nyhetsbrev? Laddat ner ett whitepaper, läst en nyhet och försvunnit? Fundera igenom vilka mätvärden som visar på ett lyckat besök.

Material som inte relaterar till ovanstående punkter är oftast distraktioner och inte intressanta att förbättra. Snarare ska det nog tas bort, eller åtminstone gömmas, användare ska ledas runt det och det bör markeras som potentiellt skräp för den egna sökmotorn. Fundera gärna igenom vad som utmärker en värdefull sida, som ifall en sida utan en call-to-action kan anses värdefull och i så fall varför. Sätt gärna upp målet att nya webbsidor ska ha en call-to-action eller vara tätt knutet till ett verksamhetsmål.

Vad är då en call-to-action (CTA)? Jo, det är det designelement på en webbsida som användaren är tänkt att interagera med. Det kan vara en knapp, en länk eller vad som nu är anledningen till att sidan existerar. En CTA är det sätt man som skapare av en webbplats försöker ledsaga användaren genom en aktivitet fram mot ett mål – ett avslut.

Det är tänkt att du ska titta kritiskt på din webbplats alla undersidor. Visst skulle det kännas skönt om du kunde förklara vad merparten av sidorna på webbplatsen tillför?

Vilket material är bra (och vad kan kastas)?

Vad är då bra innehåll på en befintlig webbplats och kan man ta reda på vad som funkar? Jobbar du med webbanalys behöver du skaffa dig en uppfattning om vad som är kvalitetsfaktorer och hur du kan jobba med mätbarhet för att lära känna dina användare och deras beteende.

Att jobba med webbanalys är mycket mer än att grotta ner sig i webbplatsstatistiken, det finns mängder med andra verktyg som kan ge ett helikopterperspektiv över din webbkommunikation. Men för att det ska vara meningsfullt att analysera behöver man först definiera vad som är bra – bra innehåll, bra beteende hos användare, bra kvalitet och vad som är bra för verksamheten. Risken är annars att man jobbar med att förbättra material som saknar framtidsutsikter. Men misströsta inte, det finns sätt att ta reda på vad som efterfrågas av användarna. Genom sökanalys, bland annat.

Något som försummats väldigt länge, eller kanske bara inte hunnits med, är att utvärdera om den sökfunktion man erbjuder fungerar som den borde. Ibland är sökfunktionen mest en källa till frustration. Frågan är om något så vitalt på en webbplats ska tillåtas finnas kvar om man inte följer upp om den bidrar med nytta eller endast är av ondo. Sökanalys är vårt nästa djupdyk.

Sökanalys är viktigare än somliga tror

Idag kan man lugnt anta att varje webbplats eller intranät har en sökfunktion. Vissa organisationer har till och med tagit steget till att bygga något av en intern-Google, eller Enterprise Search som det brukar kallas. Där jag jobbar har vi investerat tungt i denna teknik under många år.

Att reflektera och analysera användningen av den egna sökfunktion är det som går under begreppet sökanalys (eller Site Search Analytics på engelska). Det handlar alltså om att ta del av de ord som används av användarna och vilket beteende de har. Vad är vanligast efterfrågat, när hittar de inte fram och så vidare.

Som du säkert räknat ut är detta inte samma sak som SEO (sökmotoroptimering), men det finns en del liknelser mellan att vilja nå ut på andras sökmotorer och att försöka optimera användningen av sin egen sökfunktion. Sökanalys är kanske mer besläktad med webbanalys än med SEO. Många av de webbanalys-verktyg jag sett har faktiskt funktioner för att göra en grundläggande sökanalys. Exempelvis kan man i Google Analytics konfigurera sin webbplatssök för att dra nytta av de andra verktyg som erbjuds även för hur webbplatsens sök fungerar.

Väljer man istället att själv styra sitt öde är det fullt möjligt att bearbeta sökloggarna. Det vill säga de textfiler där alla sökfrågor antecknas av systemet. Då är det bara ens egen fantasi och budget som sätter gränser.

Sökanalys ger en unik insyn i användarnas upplevelse

Det som verkligen gör sökanalys unikt är att du får en insikt i vad användarna är ute efter. De till och med skriver det med en serie ord om vad de är ute efter. Den typen av insyn kan man bara drömma om att nå när det gäller de beteendedata som i övrig webbanalys i mångt och mycket består av. Genom att man får så många ord är det en mix av både kvantitativ och kvalitativ undersökning. Både mängd och det personliga.

Motivation för att jobba med sökanalys kan bland annat vara att stödja sina designbeslut. Exempelvis för att du kan visa på vilka saker folk söker efter på webbplatsen. Att du också har data för att göra sökfunktionen bättre gör det inte sämre, och som vi vet så blir sökfunktionen aldrig bättre än det innehåll den lyfter fram. Att jobba med sökanalys kan lyfta fram vad som behöver bättras på med webbplatsens innehåll, vad som saknas, och mycket mer.

Hur det fungerar

Först och främst, genom ett besök till en sökfunktion så brukar besöket fångas in av webbanalysverktyget som används på webbplatsen. På den publika webben är det väldigt vanligt att detta verktyg är just Google Analytics, men det finns också ett antal andra verktyg med motsvarande funktioner. Ett som är riktat till de organisationer som är försiktiga med att låta andra ta del av deras användares surfmönster heter Matomo. Fördelen och nackdelen med Matomo är att man kan ha den lokalt i sin egen tekniska miljö, ingen annan behöver få reda på vilka besökare din webbplats eller sökfunktion har. Eller vad de söker på.

Förutom själva besöket på webbplatsen så kan en eller flera saker ske när väl användare gör en sökning. Dels om man har konfigurerat sitt webbanalysverktyg korrekt så kommer det fånga upp sökordet, men det är också vanligt att sökfunktionen skriver ner sökfrågan till en loggfil tillsammans med lite information om användaren. Denna extrainformation handlar säkerligen oftast om datum, tid, användarens IP-adress, och kanske lite information om vilken sorts utrustning som använts. Läs på om user-agent³⁷ om detta intresserar dig.

All denna data kan man sedan analysera fristående från sitt vanliga webbanalysverktyg, om man nu har den typen av sökfunktion, alldeles oavsett de funktioner som redan finns i webbanalysverktyget.

Sökanalys riskerar att bli tekniskt

Som du märker används ord som ”logg”, ”user agent” med mera i detta sammanhang. Det är mycket riktigt så att dina möjligheter att komma över sökloggen kan hänga på IT-avdelningens välvilja och intresse. Historiskt har data som dessa samlats in för användning av tekniker för att felsöka tekniska bekymmer, och de har nog inte tänkt på att dela med sig. Möjligen blir du först med att fråga om åtkomst, åtminstone för att vara någon som inte jobbar på IT. Reaktionen på frågan kan säkert variera.

Ett sätt att få fart på diskussionen kan vara att ge dem en present i form av ett nytt bra verktyg. Säg att IT får hjälp med finansieringen av ett multikompetent verktyg, både för business intelligence och av en händelse även sökanalys? Det finns ett flertal produkter på marknaden som kan hjälpa till med sökanalys. För oss som är sålda på öppen källkod så står den så kallade ELK-stacken³⁸ ut ur mängden. Det är en kombination av Elasticsearch, Logstash och Kibana. Alltså en sökmotor, logganalysprogramvara och visualisering i ett paket.

Bild 38: ELK kan se ut som Västra Götalandsregionens sökredaktörsportal. Här inspekteras sökbegreppet ”lediga jobb” och tycks visa en säsongsvariation.

ELK är en tjänst man installerar på sina servrar. Vill man ha ett mindre ambitiöst alternativ tycker jag att man kan kolla in något självhjälpsprogram för dataanalys och visualisering. En av mina favoriter är Tableau som råkar finnas i en version som är gratis att använda, Tableau Public³⁹. Den kan man installera på sin egen dator för att inspektera loggfiler eller datakällor i största allmänhet.

Sökanalys i ett innehålls- och designarbete

Som nämnts tidigare kan man få bra hjälp vid designbeslut. Inte minst för att ännu mer data om användarens upplevelse hjälper till i argumentationen, men också för att man får lite av ett facit i diskussioner om hur man ska benämna saker på webbplatsen. Det kan bli uppenbart hur saker borde fungera eller hur riktiga livs levande användare benämner saker. Här är ett verktyg för att möta det ständigt högre kravet på bevis och att organisationer vill vara datadrivna. Ett ord jag lärde mig när jag jobbade som utvecklare på Sahlgrenska Universitetssjukhuset var vederhäftighet, alltså någontings grad av pålitlighet. På en sådan arbetsplats är det inte en nyhet att man ska kunna backa upp sina påståenden med pålitliga data, det är ju vad forskning går ut på - om jag får lov att förenkla det hela grovt.

För den som jobbar med innehållet kan det vara trevligt att veta vilka ord som ens användare känner till, vad de söker efter och så vidare. Det underlättar att ha en lista med eftersökta ord när man ska skriva rubriker, välja vilka synonymer man kryddar med i ingressen m.m.

Något annat som sökanalys och sökredaktionellt arbete kan bidra med till innehållsarbetet är att hålla efter det hela, att jobba strategiskt med sitt innehåll. Bland annat finns det ett arbetssätt att hitta det man vill rensa bort, tack vare sökmotorn. Detta görs genom att kasta ut material som är RUTtet, det vill säga Redundant, Utdaterat eller Trivialt. Den typen av innehåll kostar pengar antingen genom att man försöker underhålla det eller när någon användare faktiskt använder det. Inte minst är det ofta i vägen i sökfunktionen. RUTtet innehåll kommer alltid att stöka till det oavsett hur väl du bygger din egen sökfunktion och det kan stjäla uppmärksamhet på externa sökmotorer från det innehåll du hellre vill lyfta fram.

Hur meningsfullt är innehåll ingen hittar eller har användning av? Sånt borde du kunna kasta. Om sökfunktionen känner till innehåll som inte har någon utpekad ägare är nog även det en signal om att ingen borde sakna materialet.

Relationen till sökmotoroptimering och klickstatistik

Jag har många gånger raljerat, i sammanhang kring sökmotoroptimering, om svårigheten att sälja in produktnamn. Som 'Windcracker 3000 GLX' när folk googlar efter sökbegrepp som beskriver vad de är ute efter, som 'regnjacka för löpning'. I sökanalysen gömmer sig semantiskt berikad information. Du kan se vilka ord som använts men i bästa fall hur sökfrågor omformulerats i förhoppning om att få bättre träffar. Det är en fantastisk källa till hur man bedriver sitt SEO-arbete.

Sökanalys bör vara minst lika viktigt som att kolla hur användarna beter sig på webbplatsen. Ska man vara helt ärlig så är det som webbstatistiksystemet samlar in inte särskilt mycket mer än en loggad ström av klickningar på olika saker. Medan sökanalysen kan närma sig kvalitativa undersökningar om vad användarna faktiskt letade efter, inte vilken väg de klickade under tiden de letade.

Strunta i den långa svansen, nöj dig med den korta halsen (tills vidare)

Om du är bekant med begreppet long tail⁴⁰, det som avser att beskriva variation, så har du insett att vissa sökfrågor är extremt vanliga medan man snabbt hamnar på ovanligheterna. Majoriteten av sökfrågorna är det som kallas för onesies och twosies, alltså frågorna långt ut i svansen, de sökfrågorna som bara ställs en eller två gånger.

Bild 39: Det korta huvudet och den långa svansen ≈ ett fåtal sökbegrepp är oerhört vanliga.

Det kan vara bra att känna till att fördelningen long-tail beskriver också ofta kallas för Zipf-kurva, 80/20-regeln och säkert fler namn jag inte hört ännu. Alla beskriver variationen inom en volym av något. I detta fallet att ställda sökfrågor snabbt börjar uppvisa ett mönster av återkommande sökfrågor (korta huvudet) men också unikitet (långa svansen).

Jag har förmånen att känna en matematiker, bland annat jobbar han med att räkna ut försäkringspremier. Ofta när jag har en svår fråga brukar jag passa på och bolla den med honom. Även så i detta fallet:

För att vara kanske ännu tydligare: en zipf-kurva visar fördelningen av en mängds element i fallande ordning. Vill man vara petig är frekvenserna normerade så att frekvenserna summerar sig till 1 vilket innebär att det är en sannolikhetsfördelning som beskrivs.
- min vän Morgan Skogh

På kortfattad svenska: det är förvånande vanligt att en användare söker just på de mest populära sökorden.

De 100 vanligaste sökningarna är väldigt mycket mer vanligt att användarna söker efter jämfört med sökningarna som är 100-200 vanligast. Det är troligt att de fjorton vanligaste sökfrågorna utgör hela 10 % av alla sökfrågor.

Vad ska du göra med denna vetskap? Om du börjar med att titta snabbt på de hundra mest vanligaste sökfrågorna och ser till att det finns bra svar kommer du ha säkerställt att sökfunktionen fungerar ok för en ganska stor andel av användarna. Ju mer du jobbar med detta desto mindre blir vinsten av förbättringarna. Tänk om allt jobb var så lätt att förklara vad som är en lagom stor insats.

Det man letar efter i grundläggande sökanalys är mönster. Mönster som ger insikt i hur det funkar, eller hitta mönster på systematiska bekymmer man kan rätta till.

Ett användningsmönster du behöver känna till är vilka de vanligaste sökfrågorna är. Dessa kan förändras beroende på tid på året, veckan eller dygnet. Dessa insikter är något som kan omvandlas till möjligheter i hur man jobbar med sitt innehåll. Exempelvis i att få signal om när säsongsvariationen om att leta nytt jobb kommit igång, när folk börjat söka på vinterkräksjuka eller vad det är för innehåll som efterfrågas av dina användare.

Segmentera - om möjligt

Vad söker de användarna efter som du placerat i ditt viktigaste segment, de som är mest värdefulla för dig? För att kunna veta detta kan dina loggar behöva kompletteras eller om du kan dra nytta av avancerad filtrering i ditt webbanalysverktyg.

Segmentering går ut på att lära känna sina användare och deras beteende. Det kan visa sig mycket värdefullt även när det gäller webbanalys. I och med att språk är en så naturlig faktor inom sökanalys, på grund av användarnas ordval, är de mest uppenbara segmenteringarna sådant som kopplas till användarnas språk. Det behöver inte vara olika språk som i vilket modersmål de har, det kan lika gärna vara så att man hittar lekmannaspråk kontra facktermer.

Exempel på segment som kan vara intressant för att lära känna sin sökfunktion är bland annat:

• Vilken är trafikkällan? Vilket kan översättas till vilket domännamn, om man har flera, där användaren påbörjade sin sökning. Tänk kampanjsajt kontra den vanliga webbplatsen.
• Är det en ny sökanvändare eller en återvändande?
• Lojalitet och frekvens av att komma tillbaka.
• Konverteringar. Bland vilka användare uppstår konverteringar, och vad skiljer dem från de där inget av intresse inträffar? På vilket sätt bidrar sökfunktionen till de sessioner som konverterar?
• Genomsnittligt värde. För dig som bedriver handel eller kan översätta en besökares aktivering av ett mål i faktiska pengar så är det intressant att segmentera fram de mest lönsamma, de normala och jämföra sinsemellan och med de som inte är lönsamma. Finns lärdomar?
• Geografi är en klassiker. Inte sällan finns skillnader beroende på var användarna befinner sig. Kanske finns det något i deras upplevelse du kan förbättra?
• Tajming, alltså när på dygnet sker måluppfyllelse? Kanske är det en viss tid på veckan, månaden eller året. Viktigt att både webbplatsen och sökfunktionen är redo för detta och bidrar till en positiv upplevelse.

(Låt en sökredaktör ha...) Koll på nollresultaten

En återkommande syssla för den som ansvarar för sökfunktionen är att kolla vilka sökfrågor ens användare ställt när det inte fanns några träffar att visa. Orsakerna till att inga träffar visas kan vara flera, men det är inte så att användaren bryr sig om det. Enligt användaren har sökfunktionen misslyckats. Förutom om den som söker inte vill ha några träffar (typ söka bland patent, varumärken man vill registrera, etc.) så är nollresultat ett gigantiskt misslyckande. Nollresultat är dessvärre ganska vanligt när man söker inom webbplatser eller enskilda webbapplikationer.

Att försöka hålla koll på nollresultat, och kolla så det finns bra material till de mest populära frågorna, är sådant man ska ha en sökredaktör till. Som namnet antyder är det en person som med redaktionella åtgärder ser till att sökfunktionen fungerar bra. Ofta behöver sökredaktören behörighet och förtroendet att avhjälpa problem med innehåll som andra skapat, i alla fall om hen ska kunna vara effektiv.

De bekymmer jag snubblat över till att besökarna får nollresultat har alltid varit någon av dessa:

1. Det finns inget relevant material som matchar sökfrågan.
2. Materialet finns men kallas för något annat än det sökfrågan letar efter.
3. Det finns material, men sökfunktionen har ett automatiskt filter som gör att användarens sökfråga bara körs mot en delmängd av det sökmotorn känner till.

Alla besökarnas sökfrågor är inte alltid relevanta för webbplatsens mål, så håll koll på de frågor som spelar roll. Vilka sökfrågor som spelar roll är en fråga du endast kan få svar på genom att göra grundjobbet med att formulera mål för webbplatsen.

Om det borde finnas ett innehåll som matchar sökfrågan behöver det vara inom sökredaktörens mandat att fixa till det. Ibland är det så enkelt som att lägga till några nyckelord till det material som borde visas. Andra gånger kan det bli väldigt avancerat. Som när det behöver till en synonymhantering, eller om innehållet finns i en datakälla som sökmotorn inte har åtkomst till. Min bok Webbstrategi för alla har ett helt kapitel om informationsarkitektur, där hittar du tips på hur man kan tackla denna typ av problem.

Den boken tar också upp en del självklarheter, kan man tycka, om hur en felsida ska designas. När det gäller att informera en användare om att inga träffar hittades kan det göras på ett mer engagerande sätt än texten "Sorry, no results". Nollresultatsidan ska vara hjälpsam. Det kan vara att lyfta fram vanliga sökfrågor, erbjuda gissningar kring stavningar m.m.

"Varför inte göra som Google?"

Den som jobbar med sök och sökanalys får med jämna mellanrum höra otacksamma (och oinsatta) kommentarer om att man borde skärpa sig. Hur svårt kan det vara när Google gör det där med sök så bra?! Det finns faktiskt ett bra 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 korta svaret är att den information man har på sin webbplats, eller inom organisationen, inte är jämförbar med det Google gör. Google verkar på en publik webb, där miljarder med sidor existerar, de sidorna länkar till varandra, de konkurrerar om att nå ut på sökmotorerna, etc. Hand upp den webbredaktör som följt upp hur bra ens material nått ut på organisationens egna sökfunktion. Hallå, är den här micken på eller? Syrligheter åsido, det är nog inte särskilt vanligt, ännu.

Även användarna du har på din egen sökfunktion skiljer sig markant från de som går till Google. De användarna du har på din webbplats har redan hittat fram, de ger just din sökfunktion förtroendet. De som kör med Google är mer öppna för förslag om vem som kan komma med det bästa materialet. Din användare tror sig kunna hitta något de tror du har. Inte minst - de har gett din webbplats förtroendet att lösa deras behov! Det förtroendet behöver du förvalta.

Nyckeltal för att utvärdera sökfunktionen

Förutom att du nog redan listat ut att antalet sökanvändare som slipper se ett nollresultat kan vara ett bra nyckeltal så finns det lite fler förslag jag kan ge. Vill du standardisera frågor och kunna jämföra dina svar med andra sökfunktioner så kollar du upp Net Promotor Score (NPS), det finns lite i denna bok om detta. Då ska användarna svara 0-10 på frågan om hur troligt det är att de rekommenderar sökfunktionen till en vän eller kollega.

Försök undvika att omedelbart hamna i att mäta sparad tid som ett nyckeltal. Det är svårt att argumentera för vilken verksamhetsnytta några sekunder hit eller dit ger. Det drar lite åt fåfängesiffra att hålla koll på hur stor andel som sökt och klickar på något i träfflistan, lite samma med att man loggar ifall de klickar på topp tre i resultatet. Dessa värden hjälper dig att lära känna sin sökanvändare men det är inte värdiga mål att styra mot.

Precis som att du behöver jobba med att sätta mätbara mål på övriga webbplatsen kan, och ska, du väva in sökfunktionen. Vilka delar var användaren på innan den genomförde ett definierat mål på webbplatsen? Var sökfunktionen en del av den processen?

Vill du ha exempel på sökspecifika mätvärden och nyckeltal så har du några här:

• Andel frågor som returnerar nollresultat. Jobba mot en låg andel, åtminstone i de segment av användare som du vänder dig till. Ett mikromål är att försöka undvika att ge en dålig upplevelse, som ett nollresultat är.
• Andel sökfrågor eller sessioner som leder till avslut. Alltså att något i sökresultatet blev klickat. Ett mikromål att sökfunktionen bidrar till att användaren hittar något värt att klicka på.
• Andel frågor som leder till att besökaren lämnar webbplatsen. Ett mätvärde, inte något mål, för att se vilka sökbegrepp som inte lyckas behålla sökanvändarens intresse. Motsvarar avvisningsfrekvens i övrig webbanalys.
• Vilka sökfrågor används i sessioner där användaren konverterat. Ett mätvärde snarare än mål.
• Vilka är sidorna på webbplatsen där flest användare påbörjar sin sökning. Typiskt mätvärde för att försöka hitta innehåll som kan behöva förbättras eller ingå i ett A/B-test för att utvärdera om man kan påverka upplevelsen i rätt riktning.
• Mål: Konverteringsfrekvens bland de som använt sökfunktionen. Berättar när sökfunktionen varit en del av en session som skapade värde. Kan vara svårt då det hänger på att lyfta fram innehåll där konvertering kan ske, men intressant som segment för utforskning av vad inom sök som skapar värde.

Vill du göra en ännu djupare djupdykning i sökanalys kan jag rekommendera boken Search Analytics for Your Site⁴² av Louis Rosenfeld. Det var den boken jag läste för att plocka ihop russinen ur kakan till det du just läst. Något jag inte nämnt som han skriver bra om är en utvärderingsmodell av en befintlig sökfunktion. Står du inför sysslan att kunna bevisa att söks prestation över tid blivit bättre har du ännu en anledning att läsa den boken.

Vad finns i verktygslådan för webbanalys?

En utbredd missuppfattning, eller kanske överdriven förenkling, är att webbanalys handlar om att gå igenom insamlad webbplatsstatistik. Självklart ingår det arbetet i att jobba med webbanalys men man bör vara medveten om att man då tittar på statistik baserat på hur en webbplats är och inte vad den borde vara. I någon mening förtjänar man det statistiken visar.

Kvantitativa verktyg

Nästan för uppenbart för att behöva nämnas, men det vanligaste kvantitativa verktyget inom webbanalys är alla våra lösningar för att kolla webbplatsstatistiken. Störst marknadsandel på den marknaden har freemium-verktyget Google Analytics. Ja, Google Analytics kostar pengar om din webbplats är stor nog. Sedan finns en lång rad av andra verktyg med någon ynka procent marknadsandel, som Adobe Analytics och Matomo. Den typen verktyg har vi avhandlat i bokens första del, och saknar du något så lider inte internet någon brist på varken tips eller böcker att köpa om detta. I den här delen av boken ska vi istället fokusera på mindre vanliga verktyg. Var beredd på några aptitretare.

Verktyg för innehållsanalys

Sökkonsulter vill gärna kalla detta för indexanalys. Det kan faktiskt vara en bra påminnelse för oss som har en sökmotor, att sökmotorn har vetskap om vad webbplatsen innehåller och det kan användas för uppföljningsarbete. Men det finns mer inom innehållsanalys som inte är fullt så naturligt att klumpa ihop med kravet om att ha en egen sökmotor.

Det sökmotorer redan vet om ditt innehåll är bland annat saker som:

• Vilka ord som finns på sidorna. Det kan du använda för att hålla efter de ord som organisationen kommit fram till att man inte ska använda. Jämför med New York Times lista ”Words we don’t say”⁴³, men också användbart för att se om det saknas något begrepp man vill bli funnen på.
• Ifall sidtitlarnas längd är inom god SEO-praxis, säg under 70 tecken? Sökmotorn skulle kunna lista de längsta sidtitlarna som en rapport.
• Korsköra om vanligt eftersökta ord finns i sidtitlar, rubriker eller strukturerad HTML-markup. Användbart för att leta outnyttjad SEO-potential, inte minst för externa sökmotorer.
• Följa upp vilken typ av material som läggs ut. För de som anstränger sig med att bygga en bättre mobil upplevelse är det intressant att kolla att trenden av publicerade PDF-dokument är avtagande.

Vissa såna här verktyg får man på köpet om man jobbar med sökanalys för sin egen sökmotor. Vill man se motsvarande siffror för Google så finns det en ständigt växande verktygslåda på deras Search Console (före detta Webmaster Tools) och Bing har något motsvarande.

Bild 40: Google Search Console visar vilka ord den frekvent hittar på min bokblogg.

Dessutom kan (den egna) sökmotorns metoder för att samla in innehållet till sitt index säkert kompletteras så du slipper ta fram ännu ett verktyg som kravlar runt på din webbplats. I sin enklaste form är att utveckla rapporter för när sökmotorn stöter på potentiella problem. Som hur ofta, eller på vilka undersidor, som den råkar ut för 404-felsidor. Eller om den stöter på en sida med identiskt innehåll som något på en annan adress.

Inom innehållsanalys ryms som sagt mer än söktekniker, vilket verktyg som betaltjänsten Siteimprove tar fasta på. De fångar in trasiga länkar, stavfel och utför till och med en del tillgänglighetstester. För dig som inte har en ambitiös sökmotorstrategi så kan Siteimprove möjligen vara lösning på att hålla efter det språkliga, så den redaktionella stilen och varumärkespresentation följer den kommunikativa policy man har.

Bild 41: Google rapporterar vilka användbarhetsproblem de hittat i innehållet på en webbplats.

Sist men inte minst inom innehållsanalys är att samköra statistiken över vad som får besök enligt din webbstatistik med allt det sökmotorn känner till existerar. Det som under 12 månader inte kommit till användning kanske du automatiskt borde radera eller arkivera?

Logganalys

Att analysera loggar har återigen framtiden för sig. Innan verktyg som Google Analytics slog igenom i mitten av 00-talet var det diverse loggverktyg många av oss hade att tillgå. Skillnaden mellan Google Analytics och ett loggbaserat verktyg är hur de samlar in sin data. Google Analytics har historiskt sett varit baserat på att ligga nära användargränssnittet och haft koll på användningen som en tredjepart som blir inblandad i kommunikationen. Antingen har man spårat användare genom små kodsnuttar med Javascript, men vissa liknande verktyg har kört med genomskinliga små bilder som alternativ metod.

Loggar samlas däremot in utan att blanda in tredjeparter. Nästintill varje teknisk pryl eller programvara skriver en loggfil bakom kulisserna. Lite som en dagbok för att visa upp för utvecklare eller förvaltande tekniker när de letar orsaken till något.

Anledningen till att jag tror logganalys återigen kommer bli intressant för allt fler är på grund av att många börjat nå insikt i att användare selektivt blockerar innehåll. De flesta säkert för att värna om sin integritet. Loggar är inget som en användare kan blockera, det sköts inom tjänsten som används.

Precis som nämnts i delen om sökanalys kan dessa loggar bearbetas av programvaror som skapar ett mervärde. Plötsligen kan man analysera andra saker än de strikt introverta tekniska aspekterna. Man kan nå insikt i vad en programvara håller på med, vilken service den ger användare.

Vill man göra detta i lite större skala finns verktyg som Splunk och Logstash. Splunk är en programvara som kostar efter mängden information man läser in. Den kan hjälpa dig dekryptera loggarna, hitta mönster och relationer. Informationsmodellering helt enkelt.

Logstash däremot, som en del av ELK-stacken, Elasticsearch-Logstash-Kibana, är ett öppet verktyg vars affärsmodell är att sälja support till större organisationer. Produkten i sig är gratis, men det kan krävas mycket energi att komma igång.

Fördelarna med Splunk och Logstash är att de är produktifierade. Då blir de mer begripliga ur en IT-inköpares perspektiv och det finns support att köpa till. Båda lösningarna kostar en hel del pengar, fast på olika sätt. Att använda Splunk kostar allt eftersom du vant dig och ser nyttan, medan Logstash kräver en mer aktiv IT-förvaltning och utgifterna kommer innan nyttan är uppenbar.

Nu finns det en allt mer växande skara av konkurrenter till att IT-avdelningen äger frågan om BI (Business Intelligence). Dessa verktyg fokuserar på att den digitalt mogna kunskapsarbetaren ska kunna hjälpa sig själv. Tableau är ett hypat sådant verktyg som fokuserar på självservice för att inspektera mer eller mindre stora datamängder. Som vilken klassisk programvara som helst så installeras det på en dator och sedan läser du in en loggfil (eller annan strukturerad information). Efter det är det bara att börja utforska datakällan. Gärna genom visualisering, vilket får avvikelser att sticka ut. En hängiven BI-konsult jag ofta stöter på i dessa kretsar brukar benämna Tableau som ett Photoshop för data, med poängen om dess enkelhet att visa upp något.

Det jag själv haft oerhörd nytta av Tableau är för att snabbt kolla på en loggfil ur flera perspektiv. Exempelvis en loggfil med några hundratusen rader med ”långsamma” databasfrågor från en webbplats som var extremt beroende av databasen för att presentera innehåll. Jag hade ställt in så databasservern antecknade en databasfråga till en loggfil om frågan tog längre än 0,5 sekunder att köras. Jag hade tre olika sorters data i loggen:

1. Tidpunkt för när databasfrågan ställdes.
2. Hur lång tid databasfrågan tog att köra klart.
3. Själva databasfrågan, alltså vilket innehåll som efterfrågades.

Det jag kunde göra tack vare visualisering var att lite enkelt titta på denna annars ganska ohanterliga datamängd ur flera vinklar. Jag kunde snabbt utesluta att tidpunkt på dagen orsakade någon långsamhet. Däremot fanns ett samband mellan tiden frågan tog att slutföra och vilken tabell i databasen frågan ställdes mot (vilket framgår av databasfrågan). Resultatet var ett mycket precist underlag för i vilka delar av systemet det fanns bromsklossar, och vilka delar som inte alls hade med saken att göra.

Bild 42: Ibland kommer användaren inte ens i kontakt med webbservern.

Tyvärr behöver man vara vaken för om man någonstans har data som ger en rättvis bild av läget. På min arbetsplats har vi haft en längre period med velande kring säkrad kommunikation över nätet (med SSL-certifikat). Vår IT-avdelning har inte varit överens med världen om hur ett trovärdigt certifikat ska se ut, vilket har lett till att våra användare i vissa fall blivit förhindrade att komma fram till våra tjänster. I vissa fall har vi haft data, exempelvis de gånger användarna blivit stoppade av vår brandvägg.

Bild 43: En brandväggs primära syfte är inte att hjälpa en webbanalytiker, men den loggar säkert data du kan använda.

Hos oss var loggfilen i brandväggen så omfattande att den var tvungen att nollställas med jämna mellanrum. Utöver det var filen så pass stor att det skulle bli ett stort projekt i sig att sålla fram lagom mycket innehåll så det kunde inspekteras i någon programvara vi var bekanta med. Det var vid en första anblick inte värt ansträngningen i detta fall.

Prestandaanalys

Bild 44: För att verifiera andra prestandadata kan man jämföra med hur snabbt det gått för Google att indexera din webbplats.

Rapporter för en webbplats prestanda kan man få från flera olika håll. Vill man ha en kvantifierbar översikt är Googles Search Console nyttig om man går till rapporten Genomsökningsstatisk. Men är du beredd att betala för dig så kolla för all del in Pingdoms tjänster. Fördelen med Pingdom är att de är specialiserade på prestandaövervakning och där kan du specificera varifrån övervakningen ska göras. Har du en webbplats som ska ge service för en nordisk marknad så är det inte så intressant hur snabbt det går för en besökare på USA:s västkust. Ljusets hastighet är visserligen snabbt, men i dessa sammanhang inte snabbt nog. Med Pingdom kan du för respektive test välja om övervakningen ska göras från servrar i Europa, Nordamerika eller Asien.

Bild 45: Pingdom visar upptid och svarstider för 10 webbplatser om man betalar för sig.

En nyare funktion i Pingdom är att få reda på mer detaljer om webbplatsens prestanda. I detta fall pekar man ut en eller flera av ens viktigaste sidor och så övervakas materialet med ett tidsintervall. Det här kan vara ett bra sätt för att hålla koll på sina viktigaste landningssidor, så inte en obetänksam webbredaktör råkar publicera en för högupplöst bild, eller att andra slarvfel inte blir åtgärdade i rimlig tid.

Bild 46: Pingdom recenserar min bokbloggs startsida.

Det sista kvantitativa prestandaverktyget jag tänkt tipsa om är att du som ändå har Google Analytics faktiskt har en vy för Googles verktyg Pagespeed Insights. Där får du reda på hur välpresterande din webbplats är och kan vara en bra lista för dig som precis ska börja med prestandaoptimering.

Det finns en lång rad verktyg som kanske inte går under kvantifierbart flagg så till den mening att man har en ständigt pågående insamling av data. Men många av dessa verktyg kan integreras, eller av en utvecklare hackas ihop, så de blir kvantifierbara och intressant på annat sätt än som manuella stickprov. Det är nu du hoppar till det om kvalitativa verktyg om du inte orkar med teknikaliteter :)

Bild 47: Apica kollar hur min lilla webbplats klarar 10 samtidiga användare.

Ett intressant arbetssätt är att vara proaktiv och kolla hur din webbplats mår under belastning, att kolla om den då visar svagheter som kan vara värda att fixa. Ett företag som sysslar med detta är Apica⁴⁴ och de har verktyget Loadtest som kan simulera en tillströmning av användare till din webbplats. Den här typen av verktyg har IT-personal som sin primära målgrupp, så de kanske redan finns i din organisation, men jag tror att en normalbegåvad webbanalytiker fixar denna typ av lösningar. Du lär märka att gränssnitten kan vara lite ofärdiga för förstagångsanvändare.

Ett annat verktyg du nog inte missat om du följer min blogg eller varit på någon av mina föreläsningar är Googles Pagespeed Insights⁴⁵, som kan användas fristående från Google Analytics. Jag har sedan 2010 använt det för att belysa behovet av att jobba med webbprestanda, haft topplistor och allt som allt jämfört tiotusentals webbplatser mot varandra. Det Pagespeed bidrar med är att det har ett API som gör att man kan integrera sin kontroll exempelvis med sitt CMS. Designa gärna så att när en sida skapas eller ändras så kollas den mot en lista av externa APIer om den håller måttet enligt er prestandabudget. Eller så gör man som jag och har semi-automatiska körningar av en uppsättning sidor, och när något mindre bra hittas meddelas berörda personer.

Pagespeed har utöver prestandafaktorer för mobil och datorer också ett antal användbarhetsfaktorer den kollar. Som ifall länkar är för tätt placerade, om innehållet får plats på skärmen och en del till.

Bild 48: Sitespeed.io är en hjälpande hand för den som orkar med lite teknik.

Ett svenskt och öppet projekt som på många sätt ersätter Pagespeed Insights är sitespeed.io som genom att vara ett lager mellan dig och APIerna kollar webbsidan mot både WebPagetest och Pagespeed Insights. För dig som är nyfiken finns projektet förstås på Github där du kan ladda hem all deras kod⁴⁶.

Apropå WebPagetest, som redan omnämnts för deras visuella jämförelse mellan två olika webbplatser, så är även det ett öppet projekt. Med lite ansträngning kan man ha sin egen lokala miljö för att göra samma tester. Detta är bra exempelvis för dig som vill jobba med intranätanalys, eller om du vill köra många fler tester än gratistjänsterna medger.

Kvalitativa verktyg och metoder

För dig som gäspade dig igenom skillnaden mellan det kvantitativa och det kvalitativa så kan jag nämna att kvalitativa verktyg och metoder är det som liknar stickprov. Sånt som inte imponerar på de som jobbar med statistik. Men nyttan med kvalitativt arbete är att ge perspektiv och få svar på frågor, inte bara att känna till omfattningen av något. Så det är utan tvekan viktigt att även jobba med det kvalitativa.

Många av de kvantitativa verktygen har aspekter som gör att man kan undersöka enskilda delar av något, alltså kan även de användas kvalitativt, men jag tänkte inte repetera dem i onödan här.

Många tänker nog på user experience eller tjänstedesign när de hör ‘kvalitativa metoder’ och det är inte så konstigt, det är en naturlig del för att få koll på läget. Vanligtvis associeras kvalitativa metoder med saker som:

• Enkäter för att förstå de befintliga användarna.
• Djupintervjuer för att lära sig mer om de tilltänkta målgrupperna, deras behov, vanor och preferenser.
• Konkurrensanalys för att se hur man står sig jämfört med någon annan.
• Etnografiska studier där man observerar användarna i deras naturliga miljö.
• Användbarhetstester där man undersöker ifall det som konstruerats är användbart, eller vilka svårigheter som kan identifieras.

Allt detta kan man göra med en högst varierande ambitionsnivå. Trots att detta är lite utanför bokens ämne, och att det inte är min expertis, tänkte jag ändå ge några tips om det man relativt enkelt kan lösa själv.

För punkterna listade ovan saknas det inte bra litteratur, därför tänkte jag inte ge mig i kast med att skriva om dem när andra redan gjort det så bra. Istället hänvisar jag dig som vill ha ett lättsamt lärande om hur man följer upp och utvärderar användarupplevelse till Steve Krugs bok Rocket Surgery Made Easy⁴⁷. Du som istället vill läsa något avsevärt mer akademiskt kan kolla in boken The Elements of User Experience: User-Centered Design for the Web and Beyond⁴⁸. Steves bok kommer ge dig ett arbetssätt som du vågar pröva på själv, något du kan börja med till nästan ingen som helst kostnad och övningsköra på kollegor innan du ger dig i kast med utomstående. Den andra bokens styrka är snarare i sin bevisföring kring respektive metods förtjänster. Den kan vara bra även för den otålige läsaren att ögna igenom för att senare använda som referensverk.

Något som förenar de flesta av ovan nämnda kvalitativa metoder är att de involverar användare på ett eller annat sätt. Det kan tyckas vara det enda man har i verktygslådan, men jag skulle hävda att det är direkt felaktigt. Att många av oss har den bilden beror på att det är just de delarna som är begripliga att paketera som ett erbjudande. Låt oss inte bli begränsade av vad konsulter känner sig bekväma med att erbjuda och sätta en prislapp på. Låt oss istället vara öppna för allt som kan tänkas ge inblick i enskilda användares upplevelser.

Det finns en lång rad specialister du kan dra nytta av för att göra en kvalitativ överblick. Personer som med lite förberedelse kan utreda kvalitativa aspekter, göra stickprov och återkoppla om tänkbar potential. Ett flertal av dem har du säkert redan som kollegor. Jag själv, som ser på webben från en webbutvecklares synvinkel, har en hel del knep du inte lär hitta hos en användbarhetsfirma. Jag har svårt att tro mindre om andra yrkesgrupper.

RUM-verktyg – visa upp användarnas faktiska upplevelse

Vill du istället ha lite mer säkra resultat du inte behöver kunna motivera på egen hand finns alltid RUM (Real User Monitoring) att tillgå. Det är i vissa fall lite av en ohelig mix mellan kvantitativt och kvalitativt, i alla fall om du har massor med användare. Det RUM gör är att inspektera riktiga användarsessioner och visa upp dem för dig, utan att du behöver samla ihop användarna eller söka upp dem. Slarvigt uttryckt så spelar man in användarens hela session med hjälp av diverse verktyg. I efterhand kan man sedan inspektera den användarsessionen, filtrera bland de insamlade användarsessionerna i jakt på något särskilt.

Det kan vara ett effektivt sätt att lägga fram sin sak inför kollegor, ledare eller kunder. Att användare faktiskt haft precis den upplevelsen.

Bild 49: Inspektera anonymiserade användares sessioner på webbplatsen.

I Google Analytics finns dessa sessioner under Audience –> User Explorer. Där kan du se lite övergripande information om användare som gör att du kan välja att inspektera de upplevelser som lett till konvertering, eller vad du nu finner intressant att undersöka. Respektive användare är avidentifierad och representeras istället av ett Client Id.

Genom att märka upp ditt innehåll med metadatastandarden Schema.org kan du hjälpa Google förstå vilket värde respektive aktivitet har. Det kan underlätta när du vill kunna jämföra konverterande användare sinsemellan. Kanske finns det något att förbättra?

Bild 50: Rapport från en användares upplevelse att köpa en bok.

Bild 51: Hotjar spårar var användarens musmarkör rört sig.

Andra verktyg är exempelvis Hotjar⁴⁹ och Clicktale⁵⁰. Båda har funktioner för att visuellt spela in användarens upplevelse av en webbplats. Man kan se precis var användaren stannat upp, var muspekaren rör sig över skärmen och hur de tar sig igenom det innehåll och delmoment som finns.

Det som gör denna typ av verktyg högintressanta är att de ger insikt i hur användarresan faktiskt ser ut på väg mot ett mål. De ger lite mer kvalitativ vinkel på den annars så förhärskande omvandlingskanalen (conversion funnel på engelska). En omvandlingskanal ger dig information om kvantiteten av konverterande användare i respektive delsteg, medan detta ger dig kvalitativ insyn i hur den upplevelsen kan te sig.

Pingdom, som vi kommer prata mer om under prestandadelen, har även de ett RUM-verktyg. Grovt förenklat så mäter Pingdom hur snabbt en webbplats laddar, och normalt sett så har de ett gäng servrar utplacerade runt klotet som gör detta åt oss. Men det ger ju egentligen inte kvalitativ data, endast kvantitativa data, eller rent utav fiktiva. De har inget med en riktig användares upplevelse att göra. Det Pingdoms RUM-verktyg kan vara bra till är om man vill veta hur bra ens webbplats laddar för användare på en annan kontinent. Jag som historiskt driftat mina privata webbprojekt hos Loopia i Västerås kanske borde överväga att flytta innehållet närmre användarna. Med hjälp av Pingdoms RUM kan jag följa upp om min engelska blogg är dräglig för riktiga användare som ansluter från USA:s västkust. Det är ett bra verktyg för att kunna agera baserat på riktiga data.

Bild 52: Med Pingdoms RUM- verktyg kan man ställa in vilka man spårar och vilka tröskelvärden man vill gruppera informationen i.

Teknisk kvalitet vid konstruktion

Bild 53: Pagespeed Insights ger besked om en sidas prestanda och användbarhet.

Både Google Pagespeed Insights och Sitespeed.io är gångbara även som kvalitativa verktyg när man vill göra stickprov kring prestanda och den tekniska miljön. Det kan behöva göras direkt efter driftsättning för att säkerställa att förväntad kvalitet är uppnådd.

Jag hoppas inte att konceptet kring tillgänglighet kommer som en överraskning för någon. Det går att lägga jättemycket ansträngning vid den typen av arbete. Ibland blir man tvungen att lägga mycket tid på det då det i allt fler sammanhang lagstiftas om en lägstanivå. I USA finns Section 508⁵¹ om att informations- och kommunikationsteknik ska vara tillgängligt. 2015 skärptes den svenska diskrimineringslagstiftningen och började gälla även i digitala sammanhang, det blev alltså olagligt att inte erbjuda en grundläggande nivå av tillgänglighet. Under tiden boken skrivs har jag inte nåtts av några prejudikat om exakt hur strikt lagen tolkas i olika sammanhang, men det är värt att bevaka svensk praxis några år efter att en ny lag tillkommit. Utöver detta slöts det under 2016 en överenskommelse⁵² inom EU att myndigheters webbplatser, intranät och appar ska ha en god tillgänglighet. Populärt kallat Webbdirektivet.

För att bekanta sig med ämnet kan man testa sin tekniska kvalitet, alltså utvärdera den kod som landar i användarnas webbläsare. Både webbstandardorganisationen W3C:s tillgänglighetsstandard WCAG och svenska Webbriktlinjer.se erbjuder ett snabbtest⁵³ du kan prova. Det är ett gäng frågor att besvara.

Bild 54: Det finns bilder utan korrekt hantering av alternativtexter hos gp.se

För en mer allmän kvalitetskontroll finns det ett oändligt antal verktyg som vänder sig till utvecklare av olika sorter. Men ett värt en titt för vem som helst som bara vill göra en hälsokontroll på en sida är webbyrån Netrelations Inspector⁵⁴. Den ger raka och begripliga besked om bland annat tillgänglighet.

Visuella tester

Innan mobilanvändarnas intåg på webben brukade webbutvecklare ofta manuellt kolla hur det de byggde såg ut i de 2-3 senaste versionerna av Internet Explorer, senaste Firefox och Chrome. Numera är dock variationen så enorm att det inte är möjligt att testa på det sättet. Inte heller är det görbart för de flesta att köpa på sig utrustning för att testa med då den ständigt behöver förnyas.

Bild 55: Hos Filament Group har man ett så kallat ”device lab” för att kunna prova design på olika prylar.

En skillnad sedan innan smartphones var att då var ambitionen att göra webbplatser ”pixel perfect”. Det vill säga att man skickade långa listor med krav på hur olika saker skulle förflyttas några pixlar åt ena eller andra hållet. Pixelknuffandet har som tur är de flesta gett upp i och med responsiv webbdesign. Kanske för att man förstått att det är banne mig omöjligt att få det att se identiskt ut på alla prylar.

En lösning på denna utmaning är att dra nytta av tjänster som BrowserStack⁵⁵. De har utrustning du kan provköra via nätet för att veta hur en webbplats ser ut. I skrivande stund har de Windows- och Mac-datorer, iOS- och Android-prylar. Märk väl att då är det respektive pryls riktiga webbläsare som används, det är ingen simulering.

BrowserStack kan också integreras i utvecklarverktyg så testen sköts lite mer automatiserat. Då kan man ha sparade bilder för att kunna granska om något hänt med viktiga sidor, dessutom får du en logg över hur det har sett ut historiskt. Visuella tester går ut på att viktiga designelement ska synas och ha förutsättning att fungera, det handlar inte om att bevaka layouten eller detaljer inom formgivning. Du bör vara mer intresserad av ifall din call-to-action är borta än om loggan är en pixel på sniskan.

Nu finns det ju tusentals olika kombinationer av prylar och webbläsare. För att börja välja lite ur den djungeln kan ett tips vara att kontrollera hur det ser ut i de prylar som har högst avvisningsfrekvens på din webbplats.

Bild 56: Från min Mac lånar jag en Windows 7-dator över nätet för att säkerställa designen på min felsida.

Skapa en testsida för att utvärdera förändringar i webbdesign

För att det ska vara en rättvis jämförelse från en mätning till en annan behöver man testa under samma förutsättningar. Med andra ord måste man sätta upp en testsida på sin webbplats och den sidan är den man gör tester mot för att veta att resultaten är jämförbara över tid. Det som kan skilja är webbserverns svarstid, men sidans innehåll i redaktionell mening behöver vara samma från en gång till en annan.

Gör du på detta sätt vet du om förändringar i webbplatsen gjort läget bättre eller sämre. Det kan vara att du prövar att byta tema om du kör Wordpress, att dina utvecklare uppgraderat något eller möjligen gjort en nyutveckling.

Hur man utformar sin testsida

För att din testsida ska vara meningsfull gäller det att den i redaktionell utformning är densamma över en längre tid. Om du ska kunna jämföra resultatet före en uppgradering av publiceringssystemet med efter gäller det att innehållet är detsamma.

Mitt förslag är att du skapar en undersida enbart avsedd för test. Den sidan ska innehålla text, bilder och sådant som är normalkomplext för en vanlig sida på webbplatsen. Det är inte här du bäddar in en massa konstiga externa tjänster, widgets, videoklipp eller sådant varken du eller de andra inblandade har kontroll över.

Gör en nollmätning

När du har din testsida gör du en första mätning hos de tjänster du vill använda, såsom Google Pagespeed. Sedan stämmer du av resultatet med alla inblandade och dokumenterar det någonstans (så folk fattar att detta får de lov att leva med framöver). På något lagom högtidligt sätt borde man säkert förklara att det inte är acceptabelt att resultatet blir sämre över tid, snarare att det bör förbättras.

Vid nästa uppdatering eller förändring behöver man kolla att det faktiskt inte blir sämre, helst ska det bli bättre, men definitivt inte sämre. Med andra ord borde eventuella externa parter, som konsulter, redan i uppdraget få reda på vilka acceptanskriterier som finns. Exempelvis att du kräver i uppdragshandlingen att:

Då vi idag har 67 av 100 enligt [ert rättesnöre], samt att ni som utförare accepterat att överträffa denna nivå, är det att betrakta som ett garantiärende utan kostnad för oss som kund om leverans på upprättad testsida inte är absolut minst 70 av 100 enligt [ert rättesnöre].

Jag är inte jurist, men om utföraren misslyckas med detta bör man förhoppningsvis kunna strunta i att betala den sista fakturan.

Några fler perspektiv på webbanalys

Först och främst vill jag som alltid poängtera att det du hittar i ditt webbstatistiksystem troligen bara är en delmängd av de data du behöver för att göra ett ordentligt arbete inom webbanalys. Denna insikt når du säkert så fort du funderar vidare på hur du mäter verksamhetsmål på webbplatsen.

Nyckeltal (KPI - Key Performance Indicator)

Nyckeltal är inte ett begrepp som är exklusivt för webben. Snarare är det ett etablerat begrepp sedan länge inom affärsvärlden. Ett nyckeltal i vårt sammanhang berättar hur webbplatsen bidrar med värde till organisationen. Det kan vara hur en kunds aktivitet på webbplatsen kan omsättas i kronor och ören, eller hur exempelvis organisationens anseende påverkats.

Många organisationer har redan nyckeltal. Det du som webbanalytiker har att göra är att se om de kan användas även på webben. Det är ett utmärkt sätt att gå från luddig hobbyverksamhet till att få ledarna inom organisationen att förstå vilken nytta webbplatsen bidrar med. Det gör det lättare att försvara önskade investeringar och är det gemensamma språket man kan använda vid hisspitchar med högsta chefen, samt det man tipsar om till årsredovisningen.

Verksamhetens mål med webbplatsen

Om det inte finns några nyckeltal som kan återanvändas (eller lätt modifieras för återanvändning på webben) kan du förhoppningsvis hitta era verksamhetsmål dokumenterade någonstans. Om ni råkar sakna både verksamhetsmål och nyckeltal som är applicerbart på webbplatsen hamnar ert problem lite utanför ämnet av denna bok, men jag skulle gissa att ni inte är ensamma. Tvärtom så är det precis vad jag ofta fått höra när jag frågat mina uppdragsgivare den ultimata frågan; "Varför har ni en webbplats, egentligen?!". Det brukar bli en väldans massa harklingar, tittandes nedåt, skrapande med fötter mot golvet och allmänt disträ beteende. Jag förstår att folk skäms, men jag tror inte att det är så ovanligt.

Sanningen är nog att många står precis i skiftet mellan att ha en webbplats "eftersom alla andra har en" och att lista ut exakt vad man vill ha ut av sin webbplats. I många fall är de jag talat med i mitten av ett organisationsträd. Då är inte alltid de övergripande målen relevanta för ens egen webbplats. På sin egen nivå i organisationen har man inte alltid uppsatta verksamhetsmål, eller så är inte kännedomen om dem särskilt hög.

För myndigheter och offentlig sektor så kan man i värsta fall läsa uppdragshandlingen som man fått från staten. Där står ens uppdrag formulerat på värsta tänkbara byråkratiska språk.

I privat sektor är senaste årsredovisningen säkert en plats att hitta verksamhetsmål, men också mer kortsiktiga förhoppningar. Om man har en bra affärsplan dokumenterad lär verksamhetens mål och nyttiggörande finnas beskrivet där.

Exempel på formulering av nyckeltal

Exempel på vad man kan vilja mäta med hjälp av ett nyckeltal är någontings påverkan på saker som:

• Försäljning
• Vinstmarginal
• Kostnadsreduktion
• Medelnivå på kundnöjdhet på en skala
• Maximal väntetid för en kund

När jag gjort research på vad ett bra nyckeltal kan tänkas vara hittade jag fram till boken Key Performance Indicators (KPI): Developing, Implementing, and Using Winning KPIs. Den menar att bra nyckeltal har följande egenskaper:

1. Inte är hårt knutna till finansiella mål. Det ska inte uttryckas i valutatermer. Här är det precis som i övrig webbanalys trenden eller förändringen som är intressant.
2. Vältajmat i tid. Det bör gå att se hur nyckeltalet presterar mer ofta än årligen i årsredovisningen. Helst vill man ju ha detta uppdelningsbart och jämföra en timme med en annan, men åtminstone varje dag eller vecka behöver ha en avstämningspunkt för nyckeltalets prestation.
3. Beslutsmässigt fokus. Ledare av verksamheten ska kunna agera baserat på nyckeltalen.
4. Är begripliga. Samtliga anställda bör förstå mätvärdets nytta, kunna lista ut hur det mäts och på vilket sätt man kan agera för att resultatet ska bli bättre.
5. Kan knytas till särskilda grupper. Ansvaret ska kunna tilldelas en enskild grupp anställda och denna grupp ska genom sitt arbete kunna påverka nyckeltalets trend.
6. Har ett påtagligt genomslag. Här kommer meningsfullheten in, att nyckeltalet ska göra meningsfull nytta i verksamheten. För dig som jobbar med balanserade styrkort så ska nyckeltalet påverka fler än ett enda styrkorts perspektiv.
7. Har en begränsad okänd faktor. Ett bra nyckeltal uppmuntrar positiva aktiviteter. Ett illa genomtänkt nyckeltal däremot kan leda till ett icke-önskvärt beteende hos de anställda, exempelvis att kundsupporten hårdsäljer istället för att hjälpa kunden med orsaken till samtalet.

Nyckeltalen kan i sig vara av olika sorter, nämligen om de är kvantitativa eller kvalitativa. Detta är inte en bok om statistik, men några grundläggande insikter i det statistiker jobbar med är hälsosamt för vilken webbanalytiker som helst. Detta blir lite av en repetition, men också en utvidgning av kvalitativt versus kvantitativt.

Kvalitativa data, metoder och information - data om känslor, attityder, upplevelser och åsikter

Kvalitativa data är de som inte direkt tilltalar statistiker, de är mer av den ostrukturerade sorten som inte enkelt kan bearbetas av datorer. Exempel på kvalitativa data är enkäter, synpunkter från användare, gilla-klick och liknande. Oftast är dessa uttryckta på det sätt som folk själva uttrycker sig, med mänskligt språk, det vill säga på ett sätt som gör det svårt att tolka om man inte läser dem och värderar dem.

Kvantitativa data och metoder - data om användning och beteende

Kvantitativa data är, som namnet antyder, data som följer statistiska modeller hur man beskriver något. Vanligaste källan inom webbanalys i detta fall är webbplatsstatistiken där man samlar data om hur användare rör sig på webbplatsen - deras beteendedata som grupp alltså. Sedan kan det finnas andra datakällor som påverkas av aktiviteten på webbplatsen, eller tvärt om att aktiviteter utanför webbplatsen påverkar webben. Exempel på det senare är plötsliga trafiktoppar och i den mån man kan lista ut dess orsak. Det kan handla om helt normal säsongsvariation, men det kan bero på utbrott av sjukdomar, midsommarvädret och mycket annat.

Standardiserade metoder och mätvärden

För att kunna jämföra sig med andra organisationer finns en poäng i att försöka återanvända andras mätbara mål. Ett sätt är att kolla in webbplatser där man listar vanligt använda nyckeltal, ett annat är att använda samma verktyg, eller nyttja befintliga metoder för mätning. Då får du även hjälp med hur mätningen ska gå till.

CTR – Click Through Rate, eller genomklickningsfrekvens

CTR har nog de flesta hört talas om. Det handlar om att i procent ange hur stor andel som exponerats för ett erbjudande (ofta kallad call to action) och sedan klickat sig vidare mot det gemensamma målet. Detta erbjudande är alltså en väg man kan navigera genom att klicka på en knapp, eller liknande, för att lägga en produkt i kundvagnen, anmäla sig till ett nyhetsbrev, m.m. Om en knapp har en CTR på 77 % innebär att 77 % av de som tog del av den valde att klicka på den. En CTR på 4,1 % i Googles sökresultat innebär att 4,1 % klickade på just din träff. Vad de andra gör kan man inte utläsa av en CTR, det är inte vad man mäter. Det händer också att man på sidor med flera samtidiga erbjudanden talar om en CTR som att något av ens erbjudanden fick ett klick.

Ibland hör man det berättas om vilken CTR någon har och omgivningen ger ljud ifrån sig av att vara imponerade, eller kommenterar att ”det var ovanligt bra”. Ska jag vara helt ärlig så har jag ännu inte själv förstått detta, och av den litteratur jag läst så finns det ingen optimal CTR. Inte heller att det ska vara meningsfullt att förvänta sig någon viss CTR. Det här drar mer än lovligt åt att man mäter fåfängliga ting. Att en viss andel användare klickat sig till nästa steg betyder inte att något verksamhetsmål uppnåtts Det är likt antal sidvisningar ett isolerat mätvärde som berättar en historia om användningen, men värdet av den vetskapen är i sig oerhört låg annat än för den som jobbar med den specifika webbplatsen.

Men med det sagt så kan det vara värt att experimentera med sin CTR för att se om man kan styra om användarnas uppmärksamhet, alltså höja sin CTR, och om det i förlängningen har ett positivt slutresultat. Det är inte säkert att en höjd CTR leder till högre konvertering. Det är det digitalas motsvarighet till en påflugen säljare. På de webbplatser jag inspekterat är vägen fram till en konvertering ofta lång och krokig. Det är inte självklart att det fungerar att försöka korta ner tiden för användarens övervägande. Däremot, om man lyckas identifiera ett användarsegment som man vågar experimentera med så sätt igång.

Sätt att experimentera med högre CTR:

• Jobba med A/B-testning på din egen webbplats eller i annonssammanhang för att lista ut vilken som får högst CTR. Utöver det måste du vara uppmärksam på eventuella negativa konsekvenser. Kanske orsakar påflugenheten att användarna konverterar i mindre utsträckning på de för organisationen mest värdefulla erbjudandena.
• Leta upp sidor med låg CTR i sökmotorerna och modifiera sidtitlarna. Det kan också vara värt att modifiera annan metadata på sidan. För att hitta sidors CTR hos exempelvis Google så kan du kolla in deras verktyg Search Console.

Bild 57: Översikt för min arbetsgivares CTR hos Google.

Hattande (pogo-sticking)

Användarbeteendet att hoppa fram och tillbaka mellan sidor gäller nog främst de sidor som har ett sökliknande gränssnitt, produktlistningar eller liknande. Det handlar alltså om att man spårar hur länge en användare stannar på en undersida de nått via en lista med många andra alternativ. Om det här är ett beteende som är värt att spåra på din webbplats vet bara du. Det sägs att Google är nyfikna på detta för att kunna jämföra olika sökträffar sinsemellan. Det är visserligen bara en signal bland flera andra, men nog finns det fog för att en sidas relevans är låg om det är vanligt att användarna snabbt som attan backar tillbaka.

Ta två sidor med identisk relevans på en sökfråga hos Google. Om en av sidorna i högre grad än den andra orsakar att användarna kommer tillbaka finns det nog anledning att sänka dess relativa värde. På samma sätt kan man tänka kring hur man själv listar innehåll på sin webbplats. Är det värt att behålla allt i listan, eller kan listan som helhet prestera bättre om man gör en förändring? Vad ska ligga överst och varför?

Sätt att försöka minska hattandet:

• Förbättra laddningstiden och se om det förändrar något. Kan vara att man har en för tung bild, eller väntar på ett långsamt externt API.
• Tydligare bekräftelse av sidans värde. Det kan bero på designfaktorer som att användarna inte förstår eller kan avkoda sidans innehåll och därmed backar tillbaka. Ett sätt är att försöka minska den kognitiva bördan för användaren att lista ut att hen har hamnat rätt.

Hängtid (Dwell time)

Denna får man vara försiktig med, men i stor skala kan den vara meningsfull för att exempelvis veta ifall längre material faktiskt används av användaren läser det eller uppehåller sig vid det. Med andra ord behöver man samköra med ett mått om hur lång tid det tar att ta till sig ett innehåll. Är det primärt text så är den totala lästiden ett värde att jämföra mot. En funktion som kan integreras i din webbplats. Det innehåll som har en hög lästid och hög hängtid ger en signal om att materialet håller en hög kvalitet, har ett hög-engagerande innehåll, eller liknande.

Nu kanske du tänker att detta är fåfängligt? Det är bra! Hängtiden är en signal bland många andra för att relativisera vilket innehåll som man i kvantitativa tankebanor har anledning att tro är uppskattat av användare.

Bild 58: Beräknad lästid för en bloggpost på min Wordpress-blogg.

När jag gör en större innehållsrevision nästa gång är detta ett arbetssätt jag tänker köra med. Alternativet att göra det manuellt kommer garanterat göra att man skrotar uppskattat nischinnehåll som inte är så välanvänt men uppskattat av de som hittat dit.

Det är inte så komplicerat som du kanske tror att sammanföra de uppgifter du behöver. Ditt webbstatistikverktyg har säkert redan en uppgift om varje sidas genomsnittliga besökstid. Det du behöver göra är att få webbplatsen att lista lästiden för de adresser som finns. Sedan slår du samman de två källorna och använder sidans adress som gemensam referens. Jag som är mer bekväm med databaser skulle gjort sammanslagningen den vägen. Men vissa jag känner har ännu inte behövt lämna Excel, då ”allt du behöver finns i Excel!”.

Från en sökmotors synvinkel, eller din produktlistnings vinkel, kan hängtiden snarare ses som ett mått på hur länge användaren uppehåller sig på sök- eller produktträffens sida innan användaren återvänder till listningen.

Net Promoter Score - NPS

Du har troligen stött på Net Promoter Score (NPS)⁵⁶ men kanske inte insett det. Det man försöker uppnå med NPS är att ha ett enda mätvärde som ska återspegla hur bra något är, hur lojal kunden eller användaren är. Betyget går från -100 till +100. Är värdet negativt är det en person eller grupp som mer eller mindre passionerat kommer tala illa om något. På den positiva änden är hur pass mycket personen eller gruppen är ambassadörer för något och berättar om den i positiva ordalag för sin omgivning. Får man betyget -100 betyder det att alla är passionerade i sin avsky, får man +100 är alla så nöjda att de vill berätta om det för sin omgivning. Att ha över noll anses vara bra och över +50 är ett utmärkt betyg.

NPS går ut på att ställa en enda fråga, nämligen:

”Hur sannolikt är det att du skulle rekommendera företaget/produkten/tjänsten/webbplatsen till en vän eller kollega?”

Svaret anges av den tillfrågade på en skala från noll till tio, där man till alla nördars glädje faktiskt kan välja noll. Detta resultat räknas sedan om till tidigare nämnd skala. Respondenterna delas upp i tre grupper så man vet vad man har att göra med. De som svarat:

• 9-10 kallas promoters och är ambassadörer fyllda av positivitet.
• 7-8 kallas passiva och bidrar inte med mycket nytta.
• 0-6 kallas detractors, och man kan anta att de inte kommer tala väl om det de tillfrågats om.

Svar mellan 9-10, promoters, antas skapa mervärde i sitt personliga nätverk, exempelvis att vilja tipsa sin omgivning när tillfälle ges. Om du träffat på någon som valt att skaffa en Apple-dator vet du nog vad jag menar, personen tycks övertygad om att lösningen på nästan alla utmaningar finns inom Apples plattform.

De som svarar 7-8 anses vara passiva, deras beteende ligger mellan positivt och negativt.

Svar mellan 0 och 6 anses vara negativa (detractors på engelska). De kommer inte tala väl om din webbplats när den kommer på tal, de kanske rent utav kommer motarbeta era verksamhetsmål.

För att räkna ut sitt NPS-betyg så räknar man gruppernas procent mot varandra, exempelvis om du har: 35 % promoters, 40 % passiva och 25 % negativa så kommer du följa formeln promoters-negativa, 35 – 25. Alltså blir det +10 i NPS.

Kom ihåg att endast jämföra din webbplats NPS-betyg med jämförbara saker. Exempelvis kanske man inte kan jämföra en lyxbilstillverkares webbplats betyg med betyget för spanska ambassadens webbplats.

Bild 59: Soundcloud följer NPS i sin app.

SERVQUAL och RATER

En annan modell för att låta användare bedöma någon form av tjänst eller service är SERVQUAL⁵⁷. Den togs fram i slutet på 1970-talet och är tänkt att användas för att upptäcka vilket gap som finns mellan förväntad kvalitet och den som upplevs av användare. Som tidigare nämnt, bland annat med referens till David Maister, är en formel för kundnöjdhet att jämföra den faktiska upplevelsen mot den förväntan som fanns på förhand. Om upplevelsen är i linje med förväntan är allt frid och fröjd, men om förväntan är högre än upplevelsen blir det problem.

För att bryta ner upplevd service av en tjänst, som inte nödvändigtvis måste vara digital, i en tjänsts olika dimensioner så har man i SERVQUAL specificerat något som kallas RATER. Det är en förkortning av de inledande bokstäverna:

1. Reliability: förmågan att utföra den utlovade tjänsten på ett pålitligt och precist sätt.
2. Assurance: kunskaperna och hövligheten av den service(personal) användarna kommer i kontakt med. Även tonläge i skriven text räknas, förstås. Det går ut på att användarna ska kunna förlita sig på det som sägs och ha tillit till tjänsten.
3. Tangibles: mer applicerbart i ett fysiskt scenario möjligtvis, handlar om de påtagliga tingen som lokaler, lager. I mer digitala sammanhang möjligen att designen bekräftar att man hamnat rätt.
4. Empathy: att man ombesörjer användarens individuella behov.
5. Responsiveness: ge service skyndsamt nog.

Att jobba enligt denna modell är en mix av både kvalitativ input och kvantitativt sätt att beskriva ett nuläge. Den kvalitativa aspekten är att det utgår från riktiga användare och deras sätt att beskriva tjänsten, men samtidigt kan man summera varje punkt med ett betyg för att försöka kvantifiera det. Fördelen med att kvantifiera det är att siffror är lättare att jämföra över tid, så man kan veta om upplevelsen av tjänsten har förändrats.

Triple bottom line

Ett sätt att kategorisera (och nyansera) de mål man har är att väva in lite av organisationens samhällsansvar i sitt sätt att mäta. Begreppet myntades av John Elkington 1994⁵⁸. På engelska används ett begrepp du säkert hört talas om, CSR (Corporate Social Responsibility). Man får alltså in lite moral i arbetet med uppföljning.

Det hela går ut på att man kompletterar de finansiella målen med social påverkan och vad som händer med miljön. Med andra ord ska man balansera ett rättvist socialt klimat, att miljön inte tar stryk, med att också tjäna pengar. Långsiktighet, helt enkelt.

Bild 60: Video om roboten Liam som monterar ner Iphones. Apples värderingar som en del av marknadskommunikationen.

Ja, det är svårt nog att hitta kloka och mätbara verksamhetsmål bara kring det finansiella. Att då kunna relatera och relativisera det finansiella med social- och miljöpåverkan kan kännas övermäktigt. Samtidigt kan det i ett större sammanhang vara värt det. Se exempelvis på hur Apples kundkommunikation fått åtminstone miljöperspektivet införlivat. Allt från vilken miljöpåverkan olika produkter har, till att inleda en presskonferens med att visa en robot som återvinner gamla Iphone. Roboten har till och med ett namn, Liam.

Because in a world with limited resources – some things cannot be replaced.
- Apple i presentation⁵⁹ av Liam, deras återvinningsrobot

För mig som anställd i en skattefinansierad verksamhet är detta mer naturligt nu än när jag jobbade i privat sektor som konsult. Gjorde vårt lilla Göteborgskontor ett tillräckligt dåligt ekonomiskt resultat kunde man räkna med att det lades ner. Gjorde vi istället ett jättebra ekonomiskt resultat skulle man verkligen vara en tråkmåns om man tyckte vi åkte för mycket flyg och för lite tåg för att tjäna in de pengarna.

Det är inte förenligt med ett hållbart företagande att förstöra miljön, eller att gömma inkomsterna i ett skatteparadis om det går ut över det samhälle man verkar i.

Triple bottom line är ett sätt att inte bli fartblind kring det ekonomiska, utan snarare att inse att man har intressenter som inte är bland aktieägarna. Något jag hoppas allt fler företag börjar med som en del av sitt arbete med hållbarhet. Kanske kan vi webbanalytiker hjälpa denna utveckling lite på traven genom att välja mätbara mål på lite okonventionella sätt.

Om statistik (och vanliga misstag)

De data som inte har en tydlig koppling till verksamhetens mest högtravande syfte med webbplatsen är att betrakta som övriga data. De är inte nödvändigtvis oviktiga på grund av detta men de är åtminstone inte uppenbara hur man räknar hem investeringen i form av nya kunder, fler lagda beställningar i butiken, och så vidare.

Segmentering

Precis som annan statistik kan man försöka omforma sina data i jakt på fynd, eller att man vill se hur kampanjen till en viss kundgrupp presterar. Ett vanligt knep, vi redan berört en del i boken, är att segmentera. Då kan man fokusera på en delmängd av all statistik, exempelvis kolla om reklamutskicket i Eslöv har en påvisbar effekt av besökare från Eslöv på webbplatsen.

En vanlig segmentering många webbanalytiker gjorde runt 2008 med hjärtat i halsgropen var att segmentera fram mobila användare. Detta för att försöka lära känna deras beteende i hopp om att inte tappa marknadsandelar. Det tycktes oundvikligt att majoriteten skulle föredra att använda mobilen för att besöka webben.

För att begripa de siffror som segmenteras kan segmentet behöva jämföras med ett annat segment. En intressant utveckling vi såg på 1177.se under 10-talets början var att ökningen av antalet besökare nästan enbart kunde tillskrivas segmentet användare med mobil och surfplatta. Utvecklingen inom det segmentet var explosionsartat jämfört med de på dator. De ansvariga fick eld i baken att få till en responsiv webbplats som var lite mer användarvänlig för de med mindre skärmar. Nu var ju den utvecklingen något de flesta av oss hade svårt att missa då det ständigt kom på tal. Frågan är bara när man baserat på sin egen webbanalys skulle tagit ett tidigt beslut att gå responsivt? Den data vi har på våra egna webbplatser är ju det vi förtjänat. Det vill säga, innan webbplatsen fungerar ok för en mobil användare finns risken att det segmentet är så litet att man inte upptäcker det – eftersom de inte kommer tillbaka oftare än nödvändigt.

Bild 61: Utvecklingen för segmentet “mobile & tablet” stod för lejonparten av ökningen på 1177.se

Samma frågeställning kan man ha kring om man ska optimera för användare på Playstation, eller det fåtal under 2016 som ansluter med suspekta user-agents⁶⁰ som ”in-car”. Hur många som ansluter via sin bil behöver du se i din statistik innan du ska börja bry dig?

Vara medveten om sina begränsningar och svårigheter

Det här med att tolka data är svårt, det ska inte stickas under stol med, och många gånger ska man vara tveksam till om man har underlag nog för att dra några meningsfulla slutsatser. Det är klokt att vara ödmjuk inför sin data och har man möjlighet att dubbelkolla sin data och hur man rapporterar slutsatser med en statistiker är det utmärkt spenderad tid. Oavsett vad, se till att ha förklaringen av metod och rapport nära till hands då du kan räkna med att det kommer ställas frågor om bakgrunden till slutsatserna.

Ett vanligt problem just kring webbanalys är att man inte kan dra långtgående slutsatser på insamlad data. Ofta för att förändringen inte är tillräckligt stor för att kunna bli statistiskt säkerställd, eller för att underlaget är för litet (vilket gör felmarginalen alldeles för stor).

När man som amatör på statistik tittar på data skadar det inte att påminna sig själv om att man är mänsklig. Människor gör fel, ofta. Dessutom gör vi fel på ibland förutsägbara sätt vilket gör att man kan ha en lista med vanliga misstag i närminnet innan man jublar för högt om något man hittat.

Några förslag för oss webbanalytiker är att vara uppmärksam på saker som:

1. Att urvalet är ok och stort nog. Det är inte statistik att prata om anekdoter kring ett fåtal användares upplevelser, då handlar det om en kvalitativ metod och det är något helt annat. Insamlad data behöver vara från en tillräckligt stor undersökning och dessutom är sammansättningen inom den gruppen viktig. Urvalet ska vara representativt, vilket ofta beskrivs som att det behöver vara tillräckligt slumpmässigt.
2. Jämför inte äpplen och päron. Båda är visserligen frukter, men du måste vara försiktig med dina slutsatser. Gör du ett A/B-test där den ena gruppen enbart består av nya besökare och den andra av återkommande så är det riskabelt att dra några slutsatser.
3. Konfirmeringsbias är det högst naturliga beteendet att leta argument och bevis för att man har rätt. Alltså lägger man större vikt vid sådant som bekräftar den uppfattning man redan har. Det här behöver inte vara en särskilt medveten handling, snarare kan det för många av oss ske per automatik – så tona gärna ned den anklagande tonen när du påpekar detta för någon.
4. Self-selection bias: Att vi själva ofta inte är så värst representativa. Det är minst sagt tveksamt att tro att man själv tillhör en grupp av användarna. Trots det är det vanligt att man utgår man från sig själv och bildar en grupp användare baserat på det. Här har man alltså förstört sitt urval.
5. Var försiktig med dina orsakssamband. Vi människor är väldigt snabba att dra slutsatser på felaktiga grunder, det finns tydligen en evolutionär anledning till det. Baksidorna av detta är vidskepelse och att vi ser mönster där det inte finns något samband. Vill du ha något lättsamt om detta så köp boken Spurious correlations⁶¹, eller om du vill ha något mer akademiskt är boken Why: A Guide to Finding and Using Causes⁶² det du söker.
6. Dina slutsatser blir aldrig bättre än dina data. Det är av högsta vikt att man har koll på sin datakvalitet. Att denna data är representativ och att inget viktigt saknas för att våga dra slutsatser. Kommer du ihåg mitt exempel där användare fastnade i brandväggen? Innan jag känner till hur vanligt det är och hur det går till är det svårt att dra slutsatser på den övriga data jag samlat in.

Försök att verka inom dina begränsningar. När det känns krångligt så läs på ordentligt eller ta kontakt med någon som är expert på området. Medge när du inte vet något, var öppen med det, och kom ihåg att allt är faktiskt inte heller värt att ta reda på.

Fåfängesiffror (så kallade "vanity metrics")

I sin webbstatistik har man massor med olika vyer över data, åtminstone fler än man vet vad man ska ha användning för. Om man inte kan koppla dem till något otvetydigt bra så riskerar de att endast vara intressanta för att de tilltalar din fåfängliga sida. Nu är inte ens dessa siffror helt värdelösa, men det är viktigt att se dem för vad de är. Nämligen siffror som du endast kan använda som anekdoter när du träffar folk inom din egen yrkesgrupp.

Att formulera mål baserat på antalet sidvisningar per besökare är minst sagt tveksamt, det går inte riktigt att påstå att det relaterar till de mål verksamheten har. Är det verkligen alltid bättre att ha många sidvisningar? Antagligen inte, åtminstone inte alltid.

Det du ändå får lov att använda med hedern i behåll av fåfängesiffror är de som berättar besökarens historia om deras session på webbplatsen. Kan du knyta siffrorna till ett nyckeltal, eller annat värdefullt som ska rapporteras, så är det siffror värda att vårda. Då har de ett värde, om än ett ringa värde. De kan då i bästa fall berätta varför ett nyckeltals trendbrott inträffat. Exempelvis att en störtdykande försäljning sammanfaller med att besökarna från en månad till en annan börjat använda mobiler, eller vad som nu är det fåfängliga mätvärdet.

Hygienfaktorer

Hygienfaktorer är förutsättningarna för att dina verksamhetsmål ska kunna inträffa. Varför något ska kunna inträffa. Det är inte hygienfaktorerna som gör att du tjänar pengar på din webbplats, så de är inte mål i sig, men de är ändå viktiga att bevaka. De är själva fundamentet, eller förutsättningarna för en värdeskapande webbplats. Dessa beskriver det hantverk som utgör en välfungerande och uppskattad webbplats. Det som gör det möjligt att sälja något, eller att någon kan engagera sig.

Listan över hygienfaktorer för en webbplats är mycket lång. Allt som är mätbart, och som påverkar användarens upplevelse, ingår i vad en webbanalytiker har att bekymra sig för när man söker efter optimeringspotential.

Sista delen i denna bok gör en djupdykning i ett antal hygienfaktorer och andra aktiviteter som kan ingå i ett metodiskt arbete för webbanalys, när man letar outnyttjad potential.

Fortsätt läs – Del 4: Aktivitetsplan