Webbanalytiker - vad gör de på jobbet?

Resultatet kommer jag presentera under min föreläsning på Webbanalysdagen den 28:e januari i Stockholm. Tippar på att det är ett bra underlag för de som ännu inte dokumenterat sin prestandabudget, genom dessa data får man veta hur bra 100 andra webbplatser faktiskt är.

Men vad jobbar en webbanalytiker med, egentligen?

Jag tror att gängse bild är att en webbanalytiker jobbar med att:

1. Analysera insamlad webbstatistik, exempelvis från Google Analytics, Adobe Analytics, Matomo, mfl.
2. Definiera mål med webbplatsen, så kallade nyckeltal (KPIer, Key Performance Indicator).
3. Ta fram metoder för att mäta hur webbplatsen levererar mot de målen.
4. Konverteringsoptimering, det vill säga jobba med hypoteser kring hur man omvandlar besökare till kunder, får kunder att bli mer lönsamma kunder och så vidare.

När Medieinstitutet beskriver sin utbildning till webbanalytiker skriver de så här:

"Utbildning för dig som vill erhålla spetskompetens inom webbanalys, data-driven marknadsföring, konverteringsoptimering och digitalt affärsmannaskap."
- Medieinstitutet.

Det finns flera olika varianter av webbanalytiker

Själv skulle jag hålla med om ovanstående punktlista, men det är tydligt att vi som jobbar som webbanalytiker har väldigt olika verktygslådor och insikter beroende på våra övriga förkunskaper. En kollega till mig använder i många fall likartade verktyg men lägger mer av sin tid på kampanjanalys, något jag själv knappt satt mig in i. Hans bakgrund är en utbildning inom marknadsanalys.

Andra webbanalytiker jag träffat på har en bakgrund inom kommunikation, journalistik eller reklam. Många av dem tycks vara förförda av det mest basala inom webbanalys, nämligen att det finns så omfattande statistik på hur en webbplats fungerar. Om jag ska vara lite elak är det inte ofta man hör att dessa gör annat än att gräva runt i webbstatistiksystemet. Elakhet nummer två är att det ofta är härifrån man hör om målsättningar som handlar om upplaga, antal läsare eller annat jag själv tycker är komplett meningslösa siffror.

Jag själv är väl en som kommer från webbutvecklingens håll. För sådana personer är inte teknik något nämnvärt hinder och man lägger gärna tid på att automatisera sin webbanalys, man gör massiva utvärderingar och kan jobba med tredjeparters API.

Steg-för-steg: Exempel på automatiserad webbanalys

Nej, detta är inte helt autmatiserat då det behövs en del kodning för att binda ihop delarna. Men att göra motsvarande arbete manuellt är ogörbart, eller skulle åtminstone ta flera månader att slutföra. För de flesta är denna steg-för-steg alldeles för svår, se den som ett exempel på vilka steg man kan ta eller som en insyn i en utvecklares möjligheter kring webbanalys.

Första funderingen är förstås vilka sidor man vill analysera. I mitt fall tänkte jag göra ett mer ambitiöst gräv än i september, då tog jag de 290 svenska kommuners startsidor. Denna gång är det inte offentlig sektor som är målgruppen, så då tar jag IDG:s lista med de 100 sajter de tyckte var bäst 2015, och då inte bara startsidorna.

Är det ens egen webbplats man ska analysera kan man istället kolla efter sin sitemap.xml eller exportera ut sidor från sin webbstatistik. 

Steg 1: Fixa lista med webbplatser att undersöka

För att börja fånga adresser till de hundra sajterna har IDG länkat deras startsidor. Dessa URLar kan jag fånga med ett plugin till Chrome, nämligen Link Klipper.

Steg 2: Tvätta listan med 100 webbplatser med regex

Listan består av både adress och sidans titel enligt nedan syntax:

"http://webbsajt.se/undersida.htm", Sidans sidtitel
"http://webbsajt2.se/undersida.htm", Andra sidans sidtitel

Här kommer reguljära uttryck till hjälp, ofta kallat regex kort och gott. Min favorit bland webbtjänsterna för detta är regex101.com
Där kan man klistra in sin text man vill bearbeta och testa lite olika regex. I detta fallet var lösningen följande regex:

(.*?)",(s.*)

Jag förstår att det ser ut som rena svordomen. Det som händer är att datorn försöker hitta ett mönster i texten, sedan gruppera innehållet. Efter att man hittat ett mönster kan man i en textredigerare som stödjer sök/ersätt med reguljära uttryck ta bort allt man inte vill behålla. I detta fall körde jag Sublime Text. Sökfrågan är den obegripliga texten ovan, det som ska ersättas med är inte mycket tydligare det, nämligen:

1

Det betyder att hela raden ska ersättas med innehållet i första gruppen i mönstret, enbart webbadressen alltså. Det som blir kvar är en lista med en webbadress per rad i textfilen.

Steg 3: Hämta en massa undersidor från respektive startsida

Eftersom jag inte ville analysera enbart startsidor behövde jag få tag på undersidor på respektive webbplats. Nu var det bara hundra webbplatser (tydligen bara 99 som jag fångat från IDG) så då valde jag att besöka varje webbplats manuellt och hämta precis alla länkar de har från sin startsida.

Väl inne på en startsida använde jag återigen Link Klipper i Chrome, då fick jag alla länkar i en kommaseparerad fil med innehåll likt det på bilden ovan. Hade det handlat om många fler sidor hade det varit nödvändigt att programmera någon form av crawler, alltså en programvara som genomsökte webbsidorna efter interna länkar. Det är inte värt det för endast 100 webbplatser.

Steg 4: Slå samman 100 .CSV-filer "automatiskt"

För att slippa öppna och kopiera samman alla sidornas innehåll var det bara att dra dem till Mac-appen TextWrangler. Du som inte har en Mac kan googla efter concatenate text files, eller göra det manuellt.

Nu hade jag en väldigt lång textfil med alla webbadresser länkade från startsidor. 12 950 sidor visade det sig.

Steg 5: Tvätta textfilen

Första tvätten var att köra samma sök/ersätt som ovan, då försvann alla sidors titlar. På grund av att det funnits radbrytningar i vissa sidtitlar fick jag kolla efter det genom att ersätta dubbla radbrytningar med enkla. Till sist en granskning efter länkar till Instagram, Facebook, Twitter med mera som jag inte ville ha med.

Steg 6: Börja köra filen mot Google Pagespeeds API

Nu återstod sysslan att kontrollera de nästan 13 000 adresserna mot Googles Pagespeed API, detta är ju inget man gärna gör manuellt och antecknar resultaten. Jag har tagit fram en massa Python-kod till mitt konto på Github (fanns på github.com/marcusosterberg/webcheck), för närvarande min testkod under branchen minor.

Det som händer här är att Python-koden tar en rad i taget i den långa textfilen, plockar den adressen och ställer en API-fråga till Google. Som svar från Google kommer lite JSON med en massa data om webbadressen.

För att få lov att ställa sådana frågor till Googles API behöver man skaffa sig en API-nyckel, det gör man på Google Developer Console och väljer Pagespeed som tjänst. En manuell API-fråga kan se ut så här:

https://www.googleapis.com/pagespeedonline/v2/runPagespeed?url=http://webbsajt.se&strategy=mobile&key=AIzaSyB4YyEoHoNcEGeP6sute2WA0ZR2zpVrKFw

Och svaret kan se ut så här:

I bilden kan du högt upp läsa ut att speed-betyget är 64 och usability-betyget är 100, sen följer en massa statistik och annan data.

All data från det svaret skrivs in i en databas. Anledningen till det är att det är smidigt att kunna ställa databasfrågor mot denna data. Då kan man be om genomsnittsvärden. Sen går det förstås att exportera ut data från databasen. Jag har också tänkt göra lite visualiseringar i Tableau Public.

Denna körning beräknas ta fyra-fem dagar på mina två datorer, så under tiden hinner jag nog fnula lite på min bok om användarcentrerad webbanalys jag hoppas släppa i sommar.

Det var lite om en utvecklares vinkel på webbanalys :)