Hver gang jeg går til et foredrag om e-handel eller online forretningsoptimering, så bliver der snakket om splittest (eller A/B-test). Lige for tiden er der rigtigt mange der hører om splittest, men ikke helt hvad det er og slet ikke ved hvordan de skal komme i gang. Jeg har købt domænet splittester.dk, blandt andet for at komme det lidt i møde (også fordi der ikke sker noget brugbart på splittest.dk). Mere om det senere (købte det i går).

Men i dette indlæg vil jeg dele nogle andre erfaringer. I dag har jeg lukket 3 tests ned og startet 3 nye. Det foregår som altid i Optimizely. En af de ting jeg efterhånden har forstået er, at Optimizely og jQuery går hånd i hånd.

Nu ved jeg meget lidt om jQuery, så lidt, at det er nemmere hvis du selv googler det. Men det er et "programmeringssprog" der gør, at jeg tage elementer (eller kode) fra den side jeg laver test på og ændre på dem.

Det er faktisk det Optimizely normalt gør bag kulissen, men det bliver først rigtigt lækkert når man selv kan justere på den. Særlig med meget dynamiske sider er det fuldstændigt uundværligt.

Lad mig dog give nogle eksempler.

Den gode Benjamin Gundgaard, der for tiden har fortjent opmærksomhed med hans e-handelsbog, skriver at det er en god idé at tilføje en forklarende tekst efter "gå-videre"-knapperne i købsflowet i en e-shop. Sikkert nok. Men nu tager jeg jo ikke bare alt for gode vare, så derfor skal det testes i FDM travel (der hvor jeg arbejder til dagligt). Til dagligt ser knappen således ud:

Jeg vil gerne tilføje en lille tekst efter knappen, så det ser således ud:

Det gør jeg ved at indsætte følgende kode i Optimizely:

$("div#proceedBtn").append('<br><br><span style="color: rgb(50, 50, 50); font-size: 11px; font-family: Verdana,Helvetica,sans-serif;">På næste side:&nbsp;Indtastning af kortoplysninger via sikker forbindelse.</span>');


Det er funktionen append() der er smart her. Med den kan jeg tilføje forskellige elementer til den eksisterende knap.

Vi er også igang med at teste om der er felter vi kan undvære i vores tjek-ud forløb, fx det ekstra telefonfelt. Igen kan jeg med jQuery let fjerne et felt og teste resultatet:

$("div.wtChckMg2 > div:eq(8)").css({"display":"none"});

Jeg kan også lave rimeligt avancerede ting, men der har jeg dog brug for lidt hjælp udefra – enten fra kodehoveder i firmaet eller fra Optimizely's super-supporter Ricky, som tager alle henvendelser helt alvorligt. Lad mig også her give et eksempel.

De sider vi i FDM travel har til at vise hvilke hoteller vi har, når du søger på en bestemt dato, et bestemt sted og med et bestemt antal rejsende – er meget dynamiske. Hele websiden "lever" i én session og har derfor ikke en fast URL. Jeg kan altså ikke fortælle Optimizely hvilken side den skal se på, for siden eksisterer kun i nuet (eller i den tid sessionen varer). Samtidigt er hele sidens indhold jo dynamisk fordi det er søgeresultater. Så jeg kan kun identificere elementer på siden via deres ID. Det kan være en DIV, det kan være en H1 eller det kan være en css klasse. Men her er jQuery superstærkt. Lad mig beskrive den løsning jeg har lavet med ord:

"Kære jQuery. Tag en overskrift på siden (der fx hedder 'London, Vælg overnatning og fly'). Tag teksten fra den overskrift og træk ", Vælg overnatning og fly" fra. Gem resten i en variabel. For hvert søgeresultat skal du gøre følgende. Tag hotellets navn og tilføj "Med fly til" og sæt derefter overskriften fra variablen og sæt for enden. Når du har gjort det, så sæt lige et link efter ordet fly, til det fly vi har fundet til pakkerejsen. – ps. du skal kun gøre dette på nogle helt bestemte sider".

Det er teksten markeret med rød ramme, der dynamisk tilpasses og indsættes på alle hotel-resultater (klik på billedet for at se det i fuld størrelse). Jeg måler på antallet af brugere der lægger i kurven og antallet der gennemfører købet.

Hvis man skulle forestille sig at lave en lignende ændring i fx Google Website Optimizer, så ville man være ude på dybt vand. Så selv til store dynamiske sites er Optimizely meget fleksibelt og ultra-stærkt (vi har millioner af unikke besøgende). Jeg synes i hvert fald det er blevet meget sjovere at teste, fordi jeg med jQuery har næsten ubegrænsede muligheder for at variere noget kode som jeg ellers til dagligt ikke har adgang til.

Jeg er med andre ord begyndt at programmere igen

Håber det giver dig lidt indblik i split-testens muligheder. Det eneste der skal til er viljen til at teste, resten er dejligt nemt.

/Ole

http://www.jacobworsoe.dk/danske-split-test-cases-17.html

(Husk også at se nede i indlægget kommentarer, da der ligger links til en den andre cases og tutorials.)

Så er der jo også Which Test Won, hvor der som minimum er en test man kan tjekke ud, desværre koster det nu penge at kigge i deres arkiver (det måtte jo komme).

Husk nu, at det der virker for de andre ikke nødvendigvis virker for dig

Du må selv i gang med at teste – så, det er så nemt at sige. Så min julegave til dig er at jeg i det nye år, selv vil kreere en kom-godt-i-gang guide til Optimizely, som er mit foretrukne værktøj.

Jo, jeg kan da godt stikke dig en case, så kan du vurdere om det har værdi for dig. Se når man lytter til de kloge konverteringshoveder (sådan nogle som mig ), så siger de "Remember the importance of whitespace". Med andre ord, husk at god plads rundt om grafiske elementer gør dem "tydeligere", gør dem nemmere at finde og at trykke på. Så jeg lavede en lille test, hvor jeg blot lavede lidt mere plads rundt om "Gå til betaling" knappen. Man ved jo aldrig…

Her er de to variationer, klippet ud af deres kontekst. Den originale side først:

Og her så variationen med mere luft om knappen:

Ikke så meget hokus pokus der, men det er der til gengæld i resultatet (klik for billedet for at se det i større version:

Resultatet er at 13% procent flere gennemfører købet – og der er en side ind i mellem, vel at mærke. Det er endda en ret præcis måling, for konverteringerne styres af et javascript event på modtagersiden og ikke et tryk på knappen. Der er over 500 konverteringer og en signifikans på over 98%. Dejligt solidt i denne sammenhæng.

Så du kan roligt gå i gang med at sikre at der er luft om knapperne  – hvis du altså tror på det de resultater kan overføres til dit site

God jul!

/Ole

Jeg ser to umiddelbare udfordringer: Tid og konverteringsvariation.

Vi ved godt alle sammen, at flere testdata giver mere troværdige resultater. Jeg har test hvor 200 konverteringer giver et tydeligt resultat og test med 4000 konverteringer uden et tydeligt resultat. Jeg har test hvor resultaterne ser solide ud efter en uge, men ser mudrede ud igen efter 2. De fleste testværktøjer viser resultaternes troværdighed i form af et tal (eller en grafisk visning), en type for statistisk signifikans, der på baggrund af en meget avanceret formel (really) sætter tal på om resultaterne er statistisk troværdige. Det tal skal man tage meget alvorligt. 95% sikkerhed er normen, men 99% eller 100% er langt at foretrække.

(Det ser flot ud herover, men notér lige hvor få konverteringer der er i spil)

Når du ser andres resultater, så kig efter antal konverteringer og statistisk signifikans. Ofte skal du se godt efter, for det er ikke altid folk i branchen er villige til rigtigt at vise de tal frem

Jeg har tidligere skrevet at man ikke kan tage andre konverterings-forbedrings-procenter for gode vare, hvilket jeg kun kan bekræfte efter selv at have testet mere, men skal man tage temperaturen af kvaliteten i andres test, (fx de konsulenter du har betalt dyrt for) så er det netop føromtalte tal der skal kigges efter.

Nå, men tid. Jo altså: Giv dine testresultater tid til at stabelisere sig. Lomme-metoden er at se på grafernes jævnhed. Begynder de at danse, så skal man være forsigtig:

Havde jeg truffet beslutninger på baggrund af ovenstående graf for tidligt, så havde konklusionerne været forkerte. Det er en reel udfordring.

Konverteringsvariation: Det leder mig til en relateret udfordring, nemlig at konverteringsrater ikke er stabile. De kan, ligesom besøgstal, være stærkt svingende. De er også påvirket af omverdenen, af trafik, af kampagner og alt muligt andet. Hvis du er sej er dine splittest segmenterede, sådan at kun en bestemt del af din trafik indgår og der dermed skabes et mere jævnt billede. Men langt de fleste (mig selv inklusive) tester på tværs af al trafik. Hvilket også er ok langt hen ad vejen, selvom det er en fejlkilde vi må forholde os til.

Jeg kan ikke lade være med at blive lidt irriteret, når jeg som her har dykkende konvertering:

Trøsten er, at forholdet mellem de to grafer netop er relativt og derfor stadig udtrykker en forskel mellem de to de variationer. Hvis jeg oveni oplever grafer med de krydsende konverteringsrater, så skaber det jo unægteligt en vis usikkerhed.

Jeg forstår godt ønsket om at at få hurtige resultater, om ikke at bruge alle sine "impressions" op på kontoen (fordi de koster penge) og for at få store og tydelige forskellige i variationernes konverteringsrater. Men faktum er bare, at konverteringsoptimering, ligesom alt andet i denne IT-branche, er drilsk og at man (ligesom i Google Analytics) skal holde tungen lige i munden, når man skal aflæse og reagere på disse tal.

God fornøjelse – hører gerne fra dig hvis du har lignende erfaringer.

/Ole G.

Men først vil jeg sige, at selvom arrangementet rent praktisk var en succes og deltagelse god, så mener jeg ikke rigtigt vi fik svaret på spørgsmålet om, hvordan GA kan bruges til at skabe bedre usability.

Det er måske også grunden til, at jeg gerne vil uddybe her – ikke for nødvendigvis at give et konkret svar, men mere for at sige hvorfor jeg (der trods alt kalder sig usability specialist) synes det er svært – men også interessant – at stille et tilfredsstillende svar.

Hvis du har lyst, kan du se mit oplæg på youtube her:

Link til kommenterede powerpoint slides.

Her kort indlæggets hovedpointer:

Afdækkende/problemsøgende – bekræftende/kvalificerende
For mig er den primære brug af GA: Enten at afdække problemstillinger, altså at identificere steder hvor "det gør ondt" – eller at kvalificere ændringer, altså at se på udviklingen i data, for at vurdere om en designændring har givet den ønskede virkning. I de to dele ligger der ikke selve forbedringen og det er måske en af grundene til at det ikke er GA, men andre processer, der bruges til at skabe bedre usability.

Effekt, effektivitet, tilfredshed
Er jo de tre overordnede dimensioner af brug, som de er beskrevet i ISO-definitionen for usability (9241). Min pointe her er, at vi ikke kan bruge GA til at måle på tilfredsheden, ligesom at det sjældent virker frugtbart at se på de data, der kan bruges til at måle på effektiviteten, fx brugerens tidsforbrug, antallet af sider de kigger på eller antallet af klik. Tilbage bliver "effekt", der primært handler om hvorvidt brugeren kan gennemføre sin opgave. GA kan bruges til at vurdere, hvor langt brugeren kom på vej mod et givent mål, hvordan det end er defineret. Det helt typisk den type viden jeg selv henter fra GA.

Det store webanalyse spørgsmål: Hvad vil du gerne vide
Jeg opfordrer til at du slukker din computer og spørger dig selv: Hvad er det du gerne vil have svar på. Få det formuleret, inden du igen drukner dig selv i tal og grafer der fiser op og ned. Som i alle andre projekter, er det vigtigt at have de rigtige briller på inden du går i gang. Det gælder i særdeleshed også i GA. Formuler det som helt almindelige spørgsmål: "Hvor mange af de brugere der kommer til vores site via forsiden, klikker på billedet øverst på siden?".

De gode svar er relative = du skal bruge mål og konverteringsrater
Det har hjulpet mig at se helt afgrænset på forholdet mellem to elementer i GA. Fx mellem to sider (lad os sige forsiden til en underside) eller en side og et mål (som defineret i GA) eller en side og en hændelse (også kaldet event). Rigtigt mange spørgsmål går på hvordan en sådan konverteringsrate ser ud, forholdet mellem en indgang og et mål. I e-handel tales der meget om konverteringsrater og købstragt og lignende, der på en måde er en række sider/hændelser i rækkefølge, hvor man følger frafaldet undervejs mål et slutmål. I den slags arbejde er mål og proces ret tydeligt formuleret, men alle andre kan også få glæde af at formulere mål for deres site. Det kan være svært for fx websites der mest handler om information/kommunikation, men jeg mener nu alligevel det med fordel kan gøres. Kun derved kan man klarere få et sammenligneligt billede af hvordan bestemte dele af ens site "performer".

Dashboard og event tracking
Der er to steder i GA som jeg trækker frem her. Dashboarded, som man i den nye version af GA kan lave mange af, kan bruges til at: Kommunikere resultater og prioritere ting man vil holde øje med – de af dine kollegaer der ikke bruger GA så tit, kan med fordel gå ind der og se de tal de lige har brug for. Du kan selv bruge det til at holde fokus på de ting der er vigtige for din rolle. Det er let at lave rapporter og præsentere dem på dashboarded. Et glimrende værktøj.

Event tracking har jeg skrevet om tidligere. Det korte budskab her er, at det giver mulighed for at opsætte og styre nogle forsøg, hvor du kan måle på udvalgte elementer på dit website (også ting som ikke er sidevisninger) og bruge disse tal i sammenhæng med alle de andre dejlige tal i GA. I min præsentation taler jeg om tracking af video og hvordan jeg kan give min kollega nogle enkle bud på hvordan hans video-elementer klarer sig (ikke at det direkte er usability, men eksemplet viser hvordan GA kan bruges til at mål på brugen af bestemte dele af sitet).

På det sidste slide  (i videoen altså) opsummerer jeg bare nogle pointer fra ovenstående.

Fra GA til bedre usability?
Her til sidst vil jeg blot tilføje, at jeg tror min vigtigste pointe er at GA er et værktøj der indgår i den cyklus der altid opstår omkring usability: Der afdækkes nogle problemer, der opstilles designforslag, der måles på de designs, der implementeres og måles måske igen for at overveje en ny iteration. Som jeg startede med at sige, så indgår GA for mig i at afdække og kvalificere.

Dog kan man blive meget god til at identificere problemstillinger, hvilket jo næsten er det samme som at identificere problemer i en brugertest. Hvis vi med større sikkerhed kan sige hvor problemet er, så kan vi tage den viden med når vi skal undersøge hvorfor.

Er det så det samme som at gå fra GA til at vide hvad man skal ændre på sitet? Nej, det er det ikke. Dertil skal heldigvis stadig bruges en menneskelig kompetence, sammen med andre værktøjer, både online og offline. Men GA er stadig et godt værktøj i den proces og det giver mening at undersøge og øve sig I at udvide den del af værktøjskassen.

Jeg arbejder dagligt på at blive bedre til at bruge GA til den opgave og jeg kommer til at lave flere SIGCHI arrangementer om emnet. Håber du vil være med. Husk at SIGCHI er på både facebook og Linkedin og at vi meget gerne hører fra dig med ønsker og erfaringer.

De seje konverteringsdrenge, det kunne fx være Craig Sullivan, har styr på (eller foregiver at have styr på) hvordan optimeringer på fx en landing-page, giver de bedst mulige konverteringer hele vejen fra de forskellige version af design brugeren ser, til brugeren foretager makro-konverteringer, altså den afsluttende endegyldige konvertering (som jo typisk er salget).

Han viser det således:

Læs punkterne under billedet, så forstår du hvad han prøver at beskrive (vær opmærksom på at han var "vendt" tallene og taler om damage assessment).
Ok, ingen tvivl om at det er virksomheder med en høj "konverterings-optimerings-modenhed" der kan præstere den slags. Men jeg vil gerne prøve at vise hvordan noget lignende opstår i de test jeg selv laver.

Her har jeg prøvet at indsætte nogle elementer der har givet forbedret konvertering på 4% på en anden siden (husk lige at læse min svada om at disse tal er relative og at du derfor ikke kan bruge dem til at sammenligne med dit eget projekt). Helt naturligt tænker jeg at disse med fordel kan indsættes flere steder og trække de samme forbedrede konverteringer.

Efter en kort periode kan jeg aflæse disse tal i Optimizely:

Øverste graf er et udtryk for hvor mange konverterer på den side jeg tester, altså mikrokonverteringen. Trenden ser indtil videre god ud, selvom den statistiske usikkerhed er for lav. Hvad er endnu mere interessant er grafen derunder. Den viser hvor mange der har lagt et produkt i kurven, altså det trin der kommer efter. Her slår ændringen også igennem, selvom der ikke er nogle ændringer på den side. Den hurtige konklusion er at ændringen på 1. niveau hænger ved hos brugeren. Ja, hvis jeg troede på tallene, så ser det ud til at det giver endnu højere konvertering.

Jeg har altså et værktøj som kan give mig overblik ned gennem vores købstragt, selvom det naturligt tager meget længere tid at få troværdige resultater, jo længere ned i købstragten brugeren kommer (ja, brugerne falder desværre fra…).

Nu er der så gået et par dage og jeg kigger på resultaterne igen:

Øv, nu ser billedet anderledes ud. Jeg er i minus! Og den statistiske usikkerhed er faldet til under 10% – der er altså lang vej igen. Linjerne i den nederste krydser endda hinanden, så resultatet er ikke ligefrem entydigt.

Hvad lærer jeg så af det:

1. Ændringer i design har indflydelse længere end blot på den side hvor testen gennemføres.
2. Man skal tage mål for statistisk usikkerhed alvorligt, data ændrer sig undervejs.
3. 200 konverteringer (eller lignende tal) behøver slet ikke være nok, der er andre faktorer i spil.
4. Meget trafik er ikke i sig selv garant for entydige resultater – jeg har 7.000 pageviews på min testside om dagen, men det tager mig alligevel uger at få et statistik troværdigt resultat.
5. Er det her jeg skal blære mig med at den her side har en engagement% (altså brugere der klikker på noget, modsat bounce rate) på 90%.

Nå ja, den her artikel siger at man slet ikke skal optimere for mikro-konverteringer.

Nu lader jeg denne test køre en tid mere, så kan jeg fortæller hvordan det så går (fortsættelse følger).

Dengang skrev jeg:

"Hvordan nu det. Jo, jeg har en aftale med Post Danmark, online naturligvis, der som iTunes bare trækker beløbet på min konto. Til denne aftale hører en kode, som jeg tydeligt påfører bagsiden af mit brev: OG.L9-2720. Et Voila!

Og hvis jeg nu ikke gider have en konto hos post-konglomeratet, så kan jeg naturligvis lige hente koden via en SMS. Naturligvis. Men hvem gider SMS, der er så håbløst langsomt og tungt."

Men nu er det her, SMS frimærket. Jeg har prøvet det og det er lidt tungt og langsomt, men det virker. Jeg behøver aldrig mere gå i Føtex (eller på posthuset i helt gamle dage) og hente frimærket. Fremtiden længe leve…

Fordi du ikke kan bruge de tal til noget. De er totalt relative. Lad mig give et eksempel:

"Jeg har forøget konverteringsraten med 25%".

For det første ved vi ikke noget om, hvad de 25% dækker over. Hvis jeg havde 20 salg i går og 25 i dag, så er det forøget med 25%. Ikke nødvendigvis imponerende.
Og hvad er det der er forøget? Ofte tales der om konverteringer, men det behøver ikke være mersalg. Det kan også blot være mikro-konverteringer, som tilmeldinger til nyhedsbrev eller bare klik på en søgeknap.

Så forøgelsen i sig selv, om den er 10% eller 200% er ligegyldig. Og der er flere faktorer der spiller ind.

Du kan jo læse lidt på det her: Should I optimize for micro conversions?

Pointen, i denne artikel af Widerfunnel, er at du kan risikere at optimere "lokalt", men samtidigt skade dit salg eller anden makrokonvertering længere nede i salgstragten. Det er en rigtig bitch, fordi du (og jeg) typisk har langt færre konverteringer på makroniveau (altså fx salg) end på mikro (fx søgning på produkt). Nogle optimizere siger 100, andre 200 konverteringer, men er dine variationer i testen meget ensartede kan du risikere at skulle op på langt højere tal.

I eksemplet herunder (sammenklip fra Optimizely), kan du se at jeg har over 800 konverteringer på mig mål, men kun en statistisk sikkerhed på højest 87%. Optimizely selv arbejder som minimum med 95% sikkerhed, og det er jeg altså langt fra. For mange mindre websites er det at have 800 konverteringer rigtigt meget og tager lang tid at indhente. Men alligevel ser jeg ofte personer fra begejstret fortæller om deres forøgelse baseret på 50 konverteringer – det er altså ikke godt nok. Så tag ikke andres tal for gode varer. (Heller ikke mine ).

På samme måde kan man heller ikke sammenligne konverteringsrater i almindelighed. Morten Vadskær fortæller for eksempel altid om hans 9% på kondomaten (der er hak i pladen Morten), men hos mig i rejsebranchen er 9% en umulighed. Lå vi på 9% var vi stenrige. Så de 9% er ligegyldige og siger ikke noget om Morten succes eller dygtighed – i hvert fald ikke i forhold til dit website (med mindre du sælger kondomer). Nu er kunderne måske heller ikke så bange for at brænde fingrene på en pakke kondomer til 25,95, men de er lidt mere forsigtige når det er årets opsparing på turen til Thailand til 40.000. Konkurrence er vist også lidt hårdere i rejsebranchen.

Så skal du lytte til folk der vil fortælle om deres resultater, så spørg hellere til deres metodik, til hvilke erfaringer de kan give videre som er relevante for dit website. Du skal gøre dig dine egne erfaringer. Få fundet dig en optimizer du kan lide at arbejde med, øve dig på at opsætte mål, tjekke om du mener værktøjet er troværdigt: Du kan fx prøve at lave en test med de samme 5 variationer og se hvor længe der skal gå, før alle variationerne scorer lige højt.

Jeg har været igennem et par forskellige værktøjer nu og har fundet min favorit, men selvom jeg kører test med omkring 20.000 besøg om måneden, så føler jeg mig stadig ikke sikker på værktøjet. Stoler jeg ikke på værktøjet, så kan det hele være ligemeget.

Gør det selv

Ligesom med brugertest har jeg det sådan, at du faktisk kan (læs: bør) gøre hele arbejdet selv – ikke købe dig til det udefra. Det er ikke svært at lære og det bliver bedst hvis det er en rolig, langsigtet proces, der følges med de øvrige aktiviteter du har omkring markedsføring og optimering. Det er i hvert fald mit råd. Men modsat brugertest (som jeg fx også har skrevet en bog om og som også er rimeligt let at lære), så er det ikke så let af finde dansksproget, introducerende, hjælpsom tekst om emnet.

Derfor må vi gøre vores egne erfaringer, lære det selv, forstå vores egne tal, relatere dem til vores forretning. Men jeg vil i hvert fald meget gerne dele erfaringer – kender du et godt forum til det?

/Ole

Lad mig starte med hvad de selv skriver:

I denne test har jeg over tusinde der har klikket. Er min konvertering på blot 10%, så har jeg de 100 konverteringer i hus og så har opnået "statistical significance", som det er vist på billedet. Men er det godt nok. Nej, det tror jeg ikke. Det er ikke helt forkert når de fra VWO support sagde at man skal op på 99% i significance, før resultaterne er til at stole på. Men det er ikke problemfrit. Hvis de variationer man afprøver ligner hinanden meget – og det gør de tit når det er små forskelle man tester på (uanset om det er rigtigt eller forkert) – så kan det tage meget lang tid at nå op på de 99%.

Herover ses fx en variation, der har fået 326 konverteringer. Den statistiske signifikans ligger på 73,7%. Som Optimizely også viser visuelt, så er det ikke værd at sætte alle sine penge på. Det tal kan med andre ord vise sig at være meget usikkert og ændrer sig sikkert med tiden. Der skal altså mere tid til, flere konverteringer. Samme tendens ser jeg på projekter med 5.000 besøg. Altså masser af trafik, men stor usikkerhed.

Min erfaring er – fordi jeg ikke er så matematisk velfunderet – at jo mindre ændring, jo mindre forskel mellem variationerne og det originale design, desto længere tid tager det opnå den signifikans.

Samme usikkerhed underbygger at jeg efterhånden er meget tålmodig, når det kommer til at vente på denne signifikans. For jeg kan se hvor meget resultaterne ændrer sig over tid, fra de første tal kommer ind og til at testen ligesom har fundet sig lege. Det er netop det man kan fornemme ud af den grafiske visning på Optimizely:

Kurven flader ligesom ud og forholdet mellem de forskellige version konsolideres.

Men det er stof til eftertanke. Nu er jeg heldig at arbejde et sted hvor jeg kan lave test der får 5.000 besøg på 3 dage. Men havde jeg 10 pr. dag, så er det en lang proces.

Det betyder også at man altid skal være meget forsigtigt med at være for skråsikker med sine resultater. Ligesom at jeg er blevet meget varsom med at læse artikler der siger "Vi skiftede lige en knap og fik 30% flere slag". Som regel er det fordi der er blevet rettet på noget lort eller noget der i forvejen ikke var gennemtænkt. Jeg har meget svært ved at skabe en 30% forbedring på siger der allerede har 80% i engagement (altså 80% besøg resulterede i et klik på siden). Samtidigt så er en stigning fra 5 til 10 salg, jo en forbedring på 100%. Så det lyder hurtigt flot, men det er jo altså MEGET relativt.

Så du kan i nogle tilfælde kopiere hvad andre har gjort, men oftest ikke. Det kan være at din ændring giver positiv forbedring i sig selv, men at du samtidigt fjerner et element som desværre æder selvsamme forbedring.

Så at lave gode tests og få gode resultater – det er i mine øjne stadig en stor udfordring.

/Ole

Jeg har arbejdet med 3: Google Website Optimizer (GWO), Visual Website Optimizer (VWO) og Optimizely. Sidstnævnte er min nye favorit, grundlæggende fordi:

1. Måden man oprettet tests er enkel, visuel, brugervenligt (ja!).
2. Det er supernemt at lave mål (fx tælle konverteringer) – også flere af dem og sammensatte mål.
3. Hele interfacet virker upåklageligt i firefox 4 (modsat fx VWO) – det er effektivt som værktøj.
4. Den kode der skal indsættes på websitet er enkel (modsat fx GWO).

VWO og Optimizely har en fordel fremfor Google, nemlig at man kan opsætte testen "direkte på sitet". Jeg skal ikke gøre det i koden, men ser sitet foran mig og kan klikke mig frem til ændringer jeg vil lave. Desværre er VWO's editor ikke så velsmurt og da jeg arbejder ret iterativt (seeing-moving-seeing), så skal jeg åbne og lukke og redigere mange gange, hvilket er tungt tungt tungt i VWO. Det er endnu værre i GWO, fordi jeg kun kan bruge kode. Så jeg skal visuelt rette siden til i et andet værktøj og så kopiere koden over i GWO.

GWO koster gratis, hvilket er umuligt at slå, men er også mere "hakkebræt". Jeg skal indsætte mindst 3 scripts i Googles version – endda forskellige steder, mens jeg i de andre kun skal indsætte 1. Om Googles version er mere effektiv, rent performance-mæssigt, aner jeg ikke noget om.

I Optimizely bruges <div> tags som målepunkter. Det er genialt. Ud over at det virker rigtigt godt, så betyder det også at jeg fx kan markere en hel menu og gøre den til et mål. Det giver rigtig god mening, hvis jeg vil vurdere om brugeren klikker på menuen eller på indholdet. I de andre to værktøjer, oplever jeg det som at jeg skal vælge bestemte elementer eller links.

Optimizely har også lavet en anden genial feature. Nemlig at kan kan indsætte et javascript event et vilkårligt sted på websitet og så kalde det som mål fra sine tests. Jeg kan altså indsætte et event når min kunde putter noget i kurven og så kalde det event fra nye tests jeg opretter. Jeg skal ikke tilbage og rette i det events kode eller oprette event for hver test. En kodestump der kan kaldes alle steder fra. Det er virkeligt godt tænkt.

Det betyder at jeg fx kan køre mine tests rundt omkring på sitet, men altid forholde dem til vigtige overordnede konverteringer, typisk mine salg.

Optimizely viser ikke, som de andre to, resultaterne som grafer. Hvilket jeg egentligt er begyndt at sætte pris på. Graferne er ofte lidt misvisende. Kurverne krydser eller ligger meget tæt og sender nogle signaler der er svære at tyde – så jeg synes man læser sig blind på dem. Nogle gange tolker jeg på graferne, selvom der slet ikke er noget statistisk belæg for det. Optimizely har lavet et enkelt interface, der erfaringsmæssigt er bedre at arbejder med en VWO, selvom sidstnævnte virker mere funky i designet. Men da vi taler om et værktøj, så giver det mening for mig at søge en vis stringens og enkelhed, den kommer en til gode synes jeg.

Optimizelys grænseflade for resultater.

Optimizely er lidt dyrere. Det koster 79$ om måneden hvis man skal op på 20.000 besøg. Det er i den dyrere ende, men ok hvis man arbejder seriøst med et. Ellers har de en lille pakke til 19$ og der bør alle kunne være med. De har selvfølgelig også et 30-dages prøve tid. Er dit site lille og enkelt, så kig på GWO, men er du ikke til kode, så ville jeg kigge på Optimizely.

I VWO har jeg haft en del problemer med at tracke javascript baserede handlinger, fx en formular som blev aktivere af javascript. I Optimizely var det piece of cake. Det er meget sigende. Jeg kørte også en "benchmark" i VWO, hvor jeg testede tre identiske versioner og jeg fik nogle bekymrende store udsving på op til 10%, selvom jeg havde statistisk signifikans på 94% og havde flere hundrede konverteringer. VWO support siger at jeg skal vente på 99% sikkerhed, men jeg synes ikke helt det er det samme de kommunikerer i deres materiale. Så pointen lige her er: Hvis du skal stole på dine data, så skal du vente på et at er statistisk signifikante og er de ændringer små, så tager det lang tid før de viser sig. Det giver sig selv, brugerne reagerer mindre forskellige på små ændringer.

Jo, så har Optimizely også en anden blæret feature: Man kan se sine resultater live. Har man et site med rimelig god traffik, så er det fedt at sidde og følge udviklingen. Lidt nørdet, men sådan er gamet jo i vores branche. Og så kan man sende andre sine testlinks, også en god feature. Det virker gennemtænk.

Det var lidt hurtige noter fra arbejdsbordet. Jeg vil meget gerne i dialog med andre der arbejder med de her ting på et professionelt niveau. Det er svært at finde sparring og erfaringsudveksling lige her (og indenfor event tracking i GA).

Herunder er et reklamebanner til Optimizely. Det giver mig lidt rabat, hvis du tilmelder dig via det link. Til gengæld er jeg så mere lydhør overfor at hjælpe dig. Deal?

Usability KPI i en kommune

En kommune i hovedstadsområdet ønsker helt overordnet at sætte sig en række mål for brugen af kommunens digitale services – alt fra antal henvendelser i borgerservice om barsel til antallet af downloads af bestemmelser omkring sygefraværsregler. Behovet udspringer primært fra tankegang (tror jeg) omkring at styre fremdrift igennem måling – altså en form for ledelsesstrategi. Det betyder at kommunens afdelinger skal definere en række KPI'er – målepunkter på deres ydelser – og på et mere systematisk niveau kunne afgøre om der sker fremdrift på baggrund af de aktiviteter og initiativer/projekter der sættes i søen. Det giver sikkert alt sammen udmærket mening.

Webafdelingen i pågældende kommune står nu overfor en udfordring, om ikke andet, så som kompetence på det digitale område og ansvarlig for at hjælpe resten af organisationen på vej: Hvilke målepunkter skal der opstilles (på vegne af hele kommunens online servicestruktur) og hvordan skal disse måles?

Jeg blev inviteret til at give lidt input, gennemgå et par måder at måle på usability og tage en diskussion med nogle af medarbejderne omkring hvordan de skulle bevæge sig fremad i den proces. Her er i korte træk hvad vi talte om:

Første trin er at beslutte hvad der skal måles på. De enkelte afdelinger har nogle svagt definerede ønsker og forskellige politiske prioriteter, men trænger til at kigge på to ting: Den ene er at få defineret hvad der skaber værdi for kommunen (eller afdelingerne) og den anden er at undersøge hvad der skaber værdi for brugerne. Værdi kan være at have færre borgere der ringer til kommunen og i stedet selvbetjener sig til svar/løsninger. For begge parter er dette en nemmere og hurtigere løsning = værdi. Målet er selvsagt at skabe mere af den værdi for kommunen, ved at forøge værdien for borgerne (det er jo en slags essens af det arbejde med usability).

Hvordan kan den værdi så måles? Det kan være gennem helt almindelig statistik, altså besøgstal eller lignende. Både på den online del, men også på presset på telefoner og email. Uanset hvordan vi skaber den viden, så vil den blive et udgangspunkt, det vi med fint kan kalde for et benchmark. Der vil også blive behov for nogle tilgange til at teste/måle, hvordan brugen udvikler sig, efterhånden som vi re-designer vores digitale services.

Fra den viden kan man også forsøge at skabe nogle usabilitymål. Et usabilitymål kan indeholde en beskrivelse af hvem der skal kunne hvad og i hvilken grad, samt naturligvis et niveau der skal opnås. Så kan kommunen fra test til test, vurdere om der er fremdrift.
En begrundelse for at tale om usabilitymål og for at se på andre tilgang en at kigge på brugs-relateret statistik, er at fx besøgstal og bouncerate%, ikke siger noget om hvor svært brugerne har ved fx at forstå regler eller love. Der skal andre metoder til.

Tre måder at måle på brugen

Den typiske tilgang er at lave brugertests. At stille repræsentative brugere repræsentative opgaver og tage bestik af hvordan det går. Det giver masser af input til at forbedre de digitale services, men der kan være en udfordring omkring at måle på disse tests. Uden måling kan vi ikke arbejde med målepunkter. Men til en start kan man sagtens få tal ud af brugertests, fx den procentvise gennemførelse af testopgaver, antal klik eller den tid det tager at løse opgaven (alt efter typen af test).

En anden tilgang kan være at gå mere digitalt til værks. Her kommer kommunen lidt til kort, fordi der ligger en række tekniske begrænsninger for hvilke værktøjer der må implementeres på kommunale hjemmesider (hvilket jeg personligt synes er bullocks). Men hvis vi lige ser bort fra det, så kunne en tilgang være hændelses-sporing.

I Google Analytics hedder det også Event Tracking. Det er et spændende og relativt nyt fænomen. Fordelen er at der kan opstilles hele specifikke handlinger online, som tælles og opsummeres i Googles Analytics interfacet. Det kan være klik på bestemte elementer, udfyldning af felter, downloads eller alt muligt andet. Det giver mulighed for at komme lidt mere i detaljen end blot sidevisninger og besøg. Det giver også mulighed for at måle på handlinger der foregår på den enkelte side eller opsamle sammensatte handlinger, som man fokuseret ønsker at tælle.

Denne metode giver ikke indblik i hvorfor brugerne handler som de gør, men prøver i stedet at fokusere på at tælle ønskede handlinger, som et symptom (eller målepunkt) på kvaliteten af brugen.

En tredie tilgang kan være at lave A/B eller multivariant test, hvor forskellige variationer af en hjemmeside, eller dens elementer testes live op mod hinanden. Det er også et område under stor udvikling, som har en vis iboende evidensbaseret styrke, fordi man direkte kan måle hvordan forskellige designs klarer sig.

Det kan gøre på mange måder, fra at teste en enkel sides evne til at skabe flere most-wanted-actions, til at vurdere om en hele sekvens af sider får flere brugere til at gennemføre et bestemt forløb. Om det bruges til e-handel eller til regler for sygedagpenge er som sådan underordnet.

Hvad skal vi måle på?

Så lang så godt. Tre forskellige tilgange som har hver deres styrker og svagheder, som til dels kan minimeres ved at afvikle dem sideløbende. Men også tre tilgange som alle har som forudsætning, at man ved hvad man vil måle på.

Så den største opgave, også for omtalte kommune, er at definere: Hvad vil vi måle på og hvilke mål skal vi sætte for brugen?

Kommunen valgte at starte med at indsamle viden. Lave brugertest og spørgeskemaer, for at få et indtryk af den nuværende brugs-situation(er).

Men kommunen er blot et eksempel. Samme behov opstår i denne tid naturligt i mange andre virksomheder, hvor ledelsen meget gerne vil have bedre styre på fremdrift og værdi af alle de digitale services. Men ikke bare værdi som besøgstal eller antal klik – også værdi som kvalitet i brugen – fordi den kvalitet i stigende grad er en afgørende faktor i virksomhedens strategi.

/Ole Gregersen