Selv et showband kan optimere med webanalyse

Hvordan kan et live band, et stort showband, som spiller underholdningsmusik have brug for webstatistik og webanalyse? Og hvordan kan det benyttes? Svarene kommer her.

Udover at være Webanalytiker, så spiller jeg tilfældigvis også basun i Copenhagen Showband. Så dette er en true story

Hvem er Copenhagen Showband?

Copenhagen Showband er et 25-mands showband med dansere. Der er ikke brug for strøm når vi spiller, da vi i stedet for bas har en række tubaer, og tilmed er trommerne mobile, så hele bandet kan hoppe rundt, mellem publikum og op på springvand mens vi spiller (vi har dog ikke selv springvand med – der tager vi hvad vi finder).

Alle har en hjemmeside nu om dage, og selvfølgelig også vores showband. Vi vil meget gerne have at folk besøger den og ser lidt videoer og i bedste fald booker os til et job. Jeg vil ikke beskrive alt om webanalyse i denne case, men vil gerne berette om to analysemuligheder vi netop har kigget nærmere på.

CrazyEgg på forsiden

For at give flere indgangsvinkler til vores indhold har vi valgt at lave en række billeder i bunden, som linker til relevant indhold. Men hvad trykker brugerne mon på? Og trykker de på billedet eller teksten? Det kan man finde ud af på to måder: Ved at lave parametre på linket eller ved at benytte CrazyEgg.

Interne parametre

Hvis der linkes til /media kan man justere linket på billedet til /media?ref=forsidebundbillede og lave et andet for teksten, fx /media?ref=forsidebundtekst. Ulempen ved dette er at man skal huske at lave no-follow opsætning, da der ellers kommer duplicate content. Hvis dit webstatistik system er gearet til det, kan man også benytte interne kampagner.

CrazyEgg

Men i stedet valgte Copenhagen Showband at benytte CrazyEgg. Her er det muligt at se hvor brugerne har klikket, og hvor mange der har klikket på de forskellige links. På den måde kan man hurtigt se hvilke billeder og tekster der tiltrækker flest klik, og evt. kan man prøve at bytte de mindre klikkede ud med andre emner. Måske det ikke skal være billede, men lyd der reklameres for på forsiden. Alt det kan man teste sig frem med, men det kan nu også gøres via ab test. Fordelen ved at benytte CrazyEgg er at formidlingen af data er meget mere pædagogisk, og man kan tilmed se præcis hvor brugeren klikkede. På billedet ses at brugerne fx gerne vil klikke direkte på start-knappen til videoen, mens booking i langt højere grad er fokuseret på teksten. Overordnet kan man ud fra billedet konkludere at elementer der appelerer til hvad man bør gøre, er det der klikkes på. Det kan der testes meget med fremover.

Showbandet på tour

Det store Showband har netop været 10 dage af sted i det store udland, og spillet i både Berlin, Goslar, Østrig, og i flere byer i Italien. Undervejs delte vi flyers ud til de glade publikummer og nu begynder webstatistikken igen at blive interessant. For det er selvfølgeligt interessant at se om det har virket, og om der er nogle der finder ind på sitet. Alle statistik programmerne har en geografisk registrering, så vi kan faktisk se hvilken by brugerne kommer fra. I vores tilfælde har der været klart flest inde fra Tyskland/Berlin, men også de andre lande har givet lidt trafik. Samtidig kan vi se om der er kommet ekstra trafik generelt set til sitet.

Det skal bemærkes at den geografiske registrering er i forhold til udbyderen af forbindelsen, så man kan til tider blive registreret som Århus, selv om man rent faktisk befinder sig i Kalundborg. Den fejlmargin skal man være bekendt med, men der kommer stadig brugbare resultater ud af denne rapport. Også for et showband, som oplevede en klart størst web-succes i Berlin. Det skyldes måske denne optræden i Mauer park, hvor skræmmende mange sad og lyttede til karaoke (det er derfor der er en, der synger med…).

httpv://www.youtube.com/watch?v=xvS3k_AFSUM

Så med denne fortælling synes jeg det er klart at selv et Showband kan have gavn af webstatistik.

Har du selv oplevet tilfælde hvor du har brugt webstatistikken på en sådan lidt lavpraktisk måde? Eller været i tvivl om hvordan du kunne få fordele af at bruge det? Skriv gerne en kommentar.

Historien om Google Analytics stop en 1. aprilsnar

Gårsdagens historie om at Google opgiver Google Analytics var naturligvis en 1. aprilsnar, så ingen behøver frygte at der bliver lavet om på den kant.

Udover historiens indhold så ville jeg også altid linke til kilden i sådanne tilfælde

Og sorry Thore, kunne ikke lade være

2009 bliver sidste kald for Google Analytics

NB: Dette blogindlæg var en 1.aprilsnar

Google annoncerede i dag at Google Analytics desværre kun bliver muligt at bruge året ud, og derefter lukkes der for tracking. Det kommer kort tid efter at Microsoft opgiver Adcenter Analytics.

Det tyder på at markedet for gratis webstatistik er på kraftig retur, så det bliver spændende at se om Yahoo! Web Analytics kommer til at holde ord.

Det er fantastisk ærgeligt for det vil sætte en klar stopper for udbredelsen af webanalyse. I løbet af de næste dage følger jeg op med nærmere info…

Google Analytics – nu med event tracking

Google Analytics hændelsessporing er nu tilgængeligt for alle, så derfor kommer her en trin for trin guide.

Hvor ser finder jeg Google Analytics event tracking?

Gå ind på indhold / content og find “event tracking” under “Site Search”. Den danske udgave kaldes “hændelsessporing”, hvilket lugter af en direkte oversættelse (Google bruger vist deres translate funktion lige rigeligt).

Hvad er fordelene ved Google Analytics event sporing?

Nu har du muligheden for at spore specifikke handlinger på dit site. I Google Analytics er tanken med event sporing at det ikke er en sidevisning, men fx et klik, download eller andet, som du gerne vil spore ud over de normale sidevisninger.

“Det kunne man jo også før”. Jeps, hvis man laver en falsk sidevisning, dvs. ved at lave en onclick kommande hvor værdien pageTracker_trackPageview(‘/klik/element/osv’) returneres. Men det er ikke optimalt.

Fordelene ved at bruge event tracking er følgende:

• Man øger ikke antallet af sidevisninger, så man sikrer at der ikke skabes et kunstigt højt niveau
• Der er flere detaljer end ved det normale trackPageview

Ulemperne ved event sporingen

Heller ikke hos Google Analytics vokser træerne ind i himlen. Man kan ikke sætte eventen / handlingen op som mål. I al fald ikke endnu. Og der er heller ikke en fane (ligesom med e-commerce) hvor man kan se handlingerne. Det er utrolig ærgeligt, for som udgangspunkt er de handlinger man sporer mere interessante end en gennemsnitlig sidevisning. Det er derfor uforståeligt at det ikke indgår som element, der let kan krydses med.

Google Analytics kan have en bagtanke. Efterhånden som brugerne vænner sig til at bruge den nye filter funktion “avancerede segmenter”, så bliver det i højere og højere grad brugerens opgave at lave de kryds og tabeller (i tilpasset rapportering) som man finder relevant.

Endeligt kan det være at det ganske simpelt mangler at blive udviklet og er på vej. Jeg håber naturligvis på sidstnævnte, og mener at det er vigtigt let at kunne gå til disse data. Det er definitionen af Google Analytics – let adgang til de vigtigste data.

Hvordan sporer jeg events i Google Analytics?

Først og fremmest skal din grundkode være den “nye” gs.js udgave. Dette kan du tjekke ved at sammenligne koden implementeret med de to variationer, som vises i Google Analytics.

For at registrere en event skal følgende kode placeres ved handlingen:

pageTracker._trackEvent(kategori, handling, label, værdi)

Hvis handlingen fx er et klik på et element skal koden placeres i en onclick kommando.

I parantesen ses “Kategori”, “Handling”, “label” og “værdi”.

Kategori

Tanken med Kategori er at samle data for alle handlinger, der er under samme kategori. Det kan fx. være alt  der relaterer sig til en specifik side, et tværgående element (flash, video, Blog osv.). Det er vigtigt at vide at alt inden for samme kategori ses som samlet data, og der er derfor ikke muligt at splitte kategori-data op i forhold til “handling”.

Handling

Under handling skal selve handlingen registreres. Det kan være klik, play, download, kommentar osv.. Man kan også bygge det anderledes op, så man som kategori har Download og som handling har fil-typen. Igen vil alt der registreres som “kommentar” blive samlet.

Label

Her har du fri leg til at skrive hvad du har lyst, og det er valgfrit om du benytter det. Du kan bruge dette felt til at angive filens, videoens eller sidens navn, eller hvad du ellers har lyst til. 

Værdi

Dette felt skal indeholde en numerisk værdi, således at der samlet set kommer en samlet værdi ud af alle handlingerne. Dette vil give overblikket over hvor meget værdi handlingerne samlet set har skabt. At bruge dette er frivilligt.

Eksempel på event tracking

Opbygning af koden kan være lidt vanskelig ud fra ovenstående beskrivelse, så derfor skal der eksempler til. Der findes ingen rigtig og forkert, men hvert tilfælde har en mere hensigtsmæssig opsætning end andre. I sidste ende handlinger det udelukkende om dit behov for output.

Lad eksemplet være dette site. Jeg ønsker at spore hvor mange, der kommenterer på mine blogindlæg. Jeg vil gerne have data samlet set samt på blogniveau og laver derfor følgende kode:

pageTracker._trackEvent(Blog, kommentar, blognavn)

Med den opbygning kan jeg se al aktivitet på bloggen under “kategori”, jeg kan se antallet af kommentarer under “handling” under “kommentar” og jeg kan se præcis hvilket blogindlæg det drejer sig om under min “label”.

Hvis jeg ønsker at måle hvor mange, der starter de videoer jeg til tider placerer i mine indlæg, så er dette oplagt metoden. Men med den netop nævnte opbygning kommer jeg i bekneb for variable. Det oplagte ville være

pageTracker._trackEvent(Blog, videostart, blognavn)

Men med de to ovenstående koder på siden, så vil jeg få et samlet tal for kategori med “blog” og et samlet tal for hver af blogindlæggene, og ikke give mig mulighed for at kende til antal kommentarer og start af videoer delt ud på blogindlæggene.

En løsning er at udbygge blognavnet, så det i stedet bliver “blognavn – kommentar” og “blognavn – videostart”. Hovedpointen er at man skal overveje opbygningen, så man kan få de data ud man ønsker.

I øvrigt – tjek ikke installationen i min kode – jeg har desværre ikke fået adgang til eventtracking til dette site endnu.

Vigtige elementer at vide om event sporing

Det kan godt være at en event sporing ikke tæller med som sidevisning, men det tæller stadig med i systemet som en handling. Dette betyder at hvis en bruger går ind på din forside, trykker på et element, som bliver sporet som event, og derefter forlader sitet, så er det IKKE et bounce.

En anden vigtig ting er at Google Analytics kun registrerer op til 500 elementer pr. besøg, hvor elementer er sidevisninger og events. Så hvis man ønsker at registrere hvert sekund der vises af en video som event, så bør man overveje kun at gøre det med korte videoer eller på en anden måde (fx ved brug af Clicktale i stedet for).

Har du fået adgang og startet med at bruge det? Har du andre erfaringer som er relevante at dele? Eller skriv dine udfordringer med brugen, da du nok ikke er den eneste med de problemer. Eller er dette indlæg din gyldne vej ind til start af brugen af Event-tracking og alt er bor´ dæhli?

Hvordan udregnes konverteringsraten?

Alle snakker om konverteringsrater, så er der noget mere oplagt end at få fastlagt definitionen? Definitionen på en konverteringsrate kan gives således:

Konverteringsraten = Salg divideret med Besøg. Dvs. andelen af besøg, som genererede et salg.

For en konverteringsrate er vel en konverteringsrate?

Ovenstående formel er sådan systemerne (Google Analytics, Indextools (Yahoo! Web Analytics) og SiteCatalyst) udregner konverteringsraten. Men derfor behøver det ikke være den bedste måde at udregne den på.

Konverteringsrate i forhold til unikke besøgende?

Giver det et retvisende billede hvis konverteringsraten udregnes i forhold til antal besøg? Nogle produktkategorier køber brugerne ved første besøg, fx. produkter med lav involvering som en CD eller bog og “besøg” giver dermed et forholdsvis reelt billede af konverteringsraten. Når brugeren kommer ind på sitet så bør målet være at sælge i det pågældende besøg. Vender brugeren tilbage efterfølgende, kan det være for at købe endnu en vare, for nu skal han have en bog mere.

Men hvad med salg af varer, som har en længere beslutningsproces? Hvor mange går på Google, søger på tørretumbler, og køber den første og bedste? Konverteringsraten for produkter med større involvering, samt varer, som man køber sjældent bør måske være på baggrund af antallet af unikke besøgende frem for besøg?

Emnet har længe stået på min emneliste, og da Johan Schlüter fra Velux samtidig har bragt emnet op på Linkedin i gruppen “Danish Web Analytics Circle” (hvis du interesserer dig for webanalyse og ikke allerede er medlem af gruppen, så bringes hermed en opfordring), var der ikke flere undskyldninger for ikke at få lavet et indlæg om emnet. Johan skriver:

Visits versus visítor. Er beregningsgrundlaget afhængigt en tidsmæssig besøgsfaktor og hvad er denne?

Om man tager sit udgangspunkt i visits eller visitors bør være afhængigt hvilken type website man holder sig. Nogle websites besøger brugeren en, to eller tre gange inden for en kort periode og købes en vare har jeg en positiv conversion og en højere rate, da jeg qua websites natur beregner udfra visitors, men beregner jeg ud fra visits er det narturligvis kun besøget, hvorved der købes, der registreres positivt og dermed lavere rate. Kunden kommer ikke igen de næste 0,5, en-to-fem år. Omvendt med websites som besøges tit og ofte. Her giver det bedre mening at tale om visits som udgangspunkt for beregningen, da et bogsite, ´bingosite:) etc, har en anderledes relation til kunden, der kommer jævnligt igen og igen. Jeg synes at logikken holder, men så opstår følgende dilemmaer. 1.) Conversion rates på tværs af brancher bliver svære at benchmarke. 2) Hvordan bestemmer vi “universelt tidsmæssigt”, at her er en type A og B website og bør vi gøre det. Hvad siger i?

Johan selv taler dermed for at differentiere definitionen på konverteringsraten alt efter hyppigheden for salg af produktet og når til to dilemmaer: Benchmark på tværs af brancher og definering af hvilken gruppe sitet skal placeres i.

Hvordan benchmarkes konverteringsraten på tværs af brancher?

Med en konverteringsrate på baggrund af visits, benytter mange 2% som benchmark. 2% er en ok konverteringsrate – ikke frygtindgydende lav, men heller ikke prangende og bevis på et gennem-optimeret salgssite. Men hvad er benchmark hvis man i stedet benytter unikke besøgende? Jeg mener ikke problemet er anderledes end hvis man bruger de 2% som benchmark. Dette mener jeg ikke ud fra ovenstående udsagn – hvis konverteringsraten udregnes på baggrund af besøg, så bør det være lettere at få en konverteringsprocent på 2, hvis man sælger bøger, frem for hvis man sælger tørretumblere. Et benchmark er ikke stærkere end at man skal tage sine forbehold, og ud fra benchmarket lave et reelt benchmark. Man har et udgangspunkt for at kunne navigere ud fra det

Hvilken gruppe af konverteringsrater hører sitet til?

Når man som ejer af et site skal placere sit site i forhold til hvordan konverteringsraten bør udregnes, hvad gør man så? I dag er der ingen klar måde at gøre dette på. Skulle jeg komme med et bud, så handler det om at undersøge mængden af research før et køb, dvs. hvor langt tid går der fra at brugeren første gang kigger på nettet efter produktet, til at det konkrete køb foretages? Endnu mere optimalt: Hvor mange gange besøger brugeren ens site, før beslutningen om køb foretages? I Google Analytics kan dette ses under e-commerce delen: Hhv. “Visits to Purchase” og “Days to Purchase”.

Vi kan nu og her lave en branchestandard: Hvis mere end 50% bruger 2 besøg eller flere før køb, så bør unikke besøgende benyttes til udregning af konverteringsraten. Hvis mere end 50% af salgene sker ved første besøg, så bør besøg benyttes.

Unikke besøgende er ikke kun ét tal

Indtil nu har jeg omtalt variablen “unikke besøgende” som ét tal, men så simpelt er det ikke. Unikke besøgende kan være pr. dag, pr. uge eller pr. måned. Forskellen er stor:

Bruger A kommer ind på sitet mandag og torsdag i samme uge. Udregning af unik besøgende pr. dag vil betyde at bruger A tæller som 2. Udregning pr. uge og pr. måned vil begge give 1. Hvis brugeren derimod besøger sitet torsdag og mandag (dvs. mandagen i ugen efter), så vil det tælle som 2 unikke besøgende ved både pr. dag og pr. uge, mens pr. måned tæller som 1. Der er to måder at håndtere dette: Enten at lade alt gå over en kam – konverteringsrate på baggrund af unikke besøgende er ALTID på baggrund af månedlige unikke besøgende, eller også skal der være klare definitioner for hvornår hvilken periode for unikke besøgende benyttes. Hvis sidstnævnte bør gøre sig gældende er det relevant at vide hvornår hvilken periode giver mest mening.

Unikke besøgende pr. dag

Brugeren kommer ind på dit site om morgenen for at læse om et produkt. Brugeren forlader dit site igen, fordi brugeren ønsker at læse om priser og udbudet på andre sites. I frokostpausen vender brugeren tilbage, for det var nu lidt spændende og en ok pris du havde. Om aftenen skal konen lige spørges, men så er beslutningen heller ikke større, end at varen købes samme aften. Som besøg vil dette tælles som 3, men som unik besøgende pr. dag, så er det kun 1. Udregnes konverteringsraten på baggrund af antallet af unikke besøgende pr. dag, så bør det være fordi beslutningen tages samme dag. Typisk skal der flere besøg til, men beslutningen om køb er ikke længere væk, end at den tages samme dag. Produktet kan være en håndpisker (hvor mange mænd har købt en håndpisker uden at spørge konen først? Markering med håndsoprækning).

Unikke besøgende pr. uge

Nu tages beslutningen ikke længere samme aften. Der er brug for mere ro omkring købet, og det kræver en weekend med. Konen skal lige se på udvalget, og være enig i beslutningen, som begge parter måske lige skal tænke over. Produktet kan være nye spisebordsstole. Her vil unikke besøgende pr. uge give en retfærdig konverteringsrate, da brugeren kun tæller med én gang, men også kun har i tankerne at købe én gang i denne periode. Det er vigtigt at pointere at unikke besøgende pr. uge ikke er for en løbende uge, men mandag til søndag (i Google Analytics dog søndag til lørdag, hvis sproget er sat til engelsk), hvilket betyder at brugeren kan tælle med 2 gange inden for en periode på 7 dage.

Unikke besøgende pr. måned

Historien gentager sig. Denne gang er beslutningsprocessen blot længere – mere end en uge, og formentlig under en måned. Produktet kan være en tørretumbler. Man skal liiiige ud og se varen i en butik, og rådføre sig flere steder før valget tages. Igen skal det pointeres at en bruger kan tælle med to gange, selv om besøgende foretages inden for en 30 dages periode – hvis det er over et månedsskift (og her er amerikanerne heldigvis enige i hvornår man deler ).

Hvilken unik til konverteringsraten?

Der er ingen tvivl om at det giver god mening af skille tingene ad, og bruge antallet af unikke besøgende i forhold til beslutningsprocessens længde. Men omvendt giver det et endnu større slør i ønsket efter et benchmark og en ensartet måde at gøre tingene på. Resultatet af at bruge unikke besøgende er at konverteringsraten stiger, og den stiger mere, jo længere periode de unikke besøgende gælder for (dvs. konverteringsraten vil være størst hvis det udregnes på baggrund af månedlige unikke besøgende).

Min holdning er derfor: Rør ikke ved periodens længde for de unikke besøgende. Den eneste effekt dette har, er niveauet for konverteringsraten – udviklingen er ens. Benyt ugentlige unikke besøgende, da det dækker bredest, tager bedst højde for sæson udsving (julen varer en uge rent helligdagsmæssigt, efterårsferien er en uge mv) og endeligt, så er det mit indtryk af størstedelen af produkterne solgt over nettet har en beslutningsperiode mellem 2 og 7 dage (hvis vi renser for de tilfælde hvor besøg vil blive brugt).

Mit forslag til endnu en branchestandard er derfor: I de tilfælde hvor brugeren benytter 2 eller flere besøg før et køb foretages, så skal konverteringsraten udregnes på baggrund af de ugentlige unikke besøgende.

Tak til Johan for et godt indlæg i webanalyse debatten, og for tilladelse til gengivelse her. Jeg håber flere vil starte debatter i gruppen på Linkedin, og ellers er man som altid meget velkommen til at skrive her til bloggen, så jeg kan tage emnet op

Hvad mener du? Er det relevant at dele konvertering op i flere måder at udregne det på, eller bør det kun være på baggrund af besøg? Er mine forslag til branchestandarder for skæve, for overfladiske eller generelt bare ubrugelige? Eller er der skabt historie i den danske webanalyse verden på en tilfældig mandag aften?

Efter flere gange at fået påstanden om “Google Analytics fejl” vil jeg gerne tage debatten op her. Først læste jeg selv oversættelsen hos SørenJ, hvor jeg kommenterede (uden at få svar). Dernæst blev det igen for nylig blæst op som en fejl ved min artikel om webanalyse på kommunikationsforum og endeligt kom kommentaren igen i går til mit indlæg om webstatistik begreber og definitioner.

Google Analytics FEJL og BEVIDSTE MISLEDNING

Påstanden om fejlen handler helt konkret om inddragelse af bouncerate i udregningen af det gennemsnitlige tidsforbrug. I dag er det sådan at når en bruger kun ser en side og derefter forlader sitet igen, så registreres det som et bounce (afvisning på dansk – men det er et tumpet ord). Tidsforbrug på hver enkelt side registreres ved at Google Analytics ved hvornår næste side registreres. Når der ikke er en næste side, da brugeren kun ser en side (ved bounce), jamen så er tidsforbruget lig 0 sekunder. Det trækker derfor ned i det gennemsnitlige tidsforbrug, når besøg som måles som 0 sekunder, tæller med i statistikken. For de giver 0 sekunder til tidsforbruget, men tæller stadig med som et besøg.

Det som især har fået nogle ud af starthullerne er at Google Analytics i dag indregner bounces. Både som besøg og til at udregne det gennemsnitlige tidsforbrug. Det betyder at hvis halvdelen bouncer, og den anden halvdel af de besøgende bruger 1 minut på sitet, så vil den gennemsnitlige besøgstid være 30 sekunder. Hvis bounces derimod ikke tæller med, så vil den gennemsnitlige besøgstid være 1 minut.

Google Analytics store forbrydelse består ifølge artiklen flere ting. Dels er det helt skrækkeligt at et bounce tæller som et besøg, dels er det forkert at det indgår i beregningen af det gennemsnitlige tidsforbrug men værst:::: Google Analytics havde lavet det om så det ikke indgik, men nu har de lavet det tilbage. Fyda fyda fyda, hvor er det bevidst misledning.

Tilbage på sporet

Mit strejf af ironi over den påståede MISLEDNING og FEJL skyldes flere grunde.

• Jeg mener på ingen måde fremlæggelsen og iscensættelsen er et seriøst bidrag til en webanalyse-debat, men bidrager i højere grad til at skræmme folk fra at have tryghed til deres data og deres webstatistik system.
• At lave hetz mod Google Analytics, giver ingen mening, når det omtalte faktisk gælder alle systemer
• En i øvrigt ellers god mulighed for spændende debat om et relevant emne bør ikke drukne i ord som FEJL og BEVIST MISLEDNING. Væk med Ekstra Bladet, ind med Version2.dk

Om vinklen skyldes at man som medarbejder på mediabureau har brug for at fremvise højest mulige resultater over for kunden (højest muligt tidsforbrug og frasortering af alle de brugere, som ikke købte nu og her) ved jeg ikke, men lad os komme tilbage på sporet.

Registerering af tid og gennemsnitlig tidsforbrug

De “almindelige” webstatistik systemer (Google Analytics, Indextools, SiteCatalyst mv) registrerer som omtalt tidsforbruget på en side ved at registrere hvornår næste side loades. Det betyder at brugere, der kun ser en side, registreres som 0 sekunder, lige meget hvor lang tid brugeren var på siden. For sites med stor bounce rate betyder det naturligvis at det gennemsnitlige tidsforbrug trækkes meget ned. For nylig lavede jeg en udregning for et site, som viste at det gennemsnitlige tidsforbrug ville have været 5 minutter mod 3,5 minut normalt, hvis man ikke indregnede bounces i udregningen.

I artiklen lægges der meget vægt på besøg med bounce, men det er vigtigt at pointere at tidsregistreringen udregnes på samme måde ved alle besøg. Dvs. at tidsforbruget på den sidste side aldrig bliver medregnet.

Ønsker man at udregne det reele registrerede gennemsnitlige tidsforbrug pr. besøg, så skal følgende udregnes:

“Systemet gennemsnitlige tidsforbrug” gange med “Total antal besøg”. Dette skal divideres med “Total antal besøg” fratrukket “Bounces”.

Det gennemsnitlige tidsforbrug pr. sidevisning skal først fratrækkes alle bounces, og derefter skal der trækkes en sidevisning fra, for hvert besøg.

Google Analytics og de andre systemer kan overveje at inddrage bounce i deres besøg, men udelukke dem fra udregningen af det gennemsnitlige tidsforbrug. Jeg tror dog det vil forvirre brugerne. Prøv at forklare en almindelig slutbruger ovenstående udregning samtidig med at de skal lære hvad forskellen på et besøg, unik besøgende og sidevisning er. Det vil være klart mere simpelt at det er på baggrund af alle besøg.

Benchmark er vejen frem. For lige meget om bounce indgår eller ej, så er der også altid brugere der liiige henter kaffe imens. Eller læser avis. Ser tv. Snakker med kollegaen osv. Så tallet bliver skubbet både op og ned af forskellige omstændigheder. Med udgangspunkt i at disse omstændigheder er nogenlunde faste for sitet, så er der altid mulighed for at se om tidsforbruget er steget i forhold til sidste uge, måned eller samme periode sidste år. Benchmark, benchmark, benchmark.

Hvordan kan man få det helt reele tidsforbrug?

Bruger man Google Analytics kan man implementere javascript, som laver et kald efter 15 sekunder. Således vil de første 15 sekunder registreres, også for bounces.

Men ellers begynder markedet at have flere alternative værktøjer, hvoraf bla. Clicktale er stærkere på dette område. ClickTale registrerer hele besøget (ja, optager det tilmed), og dette giver derfor mulighed for at få hele tidsforbruget – også på besøg med bounce.

Er et bounce et besøg?

Her begynder den spændende debat. For hvorfor skal et bounce nu tælle som et besøg, når brugeren kun lige kigger ind af butiksvinduet?

Jeg skal ikke ligge skjul på min holdning, og vil derfor komme med en række argumenter for at det bør indgå:

• Et bounce er stadig et besøg. Brugeren kom rent faktisk helt ind på sitet, og så ikke kun resultatet på søgemaskinens resultatoversigt eller lignende.
• Et bounce kan også være en glad bruger. Alle mine læsere fra RSS tror jeg fuldt ud får deres behov udfyldt ved at gå ind og læse dagens blogindlæg, og derefter forlade sitet igen. Jeg ser det ikke som et problem, brugeren er glad og tilfreds (well, måske mit indlæg var total kedeligt, men så må jeg jo stramme op ) og dette bounce bør derfor ikke betragtes som en fiasko.
• Hvis jeg har brugt adwords kroner på at hive en bruger ind på mit site for at eksponere en service eller en vare overfor brugeren, så er det vigtig information at vide hvad brugeren foretog sig. Hvis bounce-raten er høj, så tyder det på at jeg bruger forkerte søgeord eller at min landingpage ikke er god nok. Dårlige resultater er også meget vigtige resultater.
• Muligheden for at analysere sine trafikinvesteringer vil være elendig.

Et argument for at sortere et bounce fra er at brugeren ikke havde relevans til sitet, fx fordi det var et søgeord fra en naturlig søgning, der blot “rimede” på andet indhold på sitet. Det hjælper bare ikke at fjerne bounces da kun få vil havne helt forkert på sitet. Det betyder at alt for mange fejlagtigt vil blive sorteret fra.

For at gøre det endnu mere langhåret, så er et bounce ikke længere blot dem, der har set en sidevisning i Google Analytics. Bruger man det nye Event-tracking, og en bruger ser én side, derefter foretager en handling, der event-trackes (Tryk på flash-elementet på forsiden) og derefter forlades sitet, så er det ikke et bounce. Så nu kan en bruger godt kun have set en side, men ikke være med i statistikken af bounces. Indtil for kort tid siden gjorde det samme sig gældende for brugervariable utm_SetVar, men det ændrede Google Analytics da brugerne ikke var enige i denne betragtning.

Hvis man endelig ønsker at analysere på data uden bounces, så er det bare i gang med filter eller Google Analytics Costum Segmentation.

Debatten om et bounce bør være besøg med 1 sidevisning eller maks 5 sekunder på sitet gemmer jeg til en anden god dag.

Kend derfor dit webstatistikværktøjs begreber og definitioner

Faktum er at det igen skal understreges at det er alfa og omega at kende sit system. Det er utrolig vigtigt at vide hvordan ens data er fremkommet, for at man ved hvad de dækker over. Når man først kender sine data så er det tid til at trylle så websitet for alvor bliver toptjekket og optimeret. Du kan derfor med fordel læse mit tidligere indlæg (fra igår) om webstatistik værktøjernes begreber og definitioner.

Google Analytics lille rettelse

Og hvad angår Google Analytics? Det virker sådan lidt “nervøst” og problematisk at lave en ting om, for at ændre det igen. Jeg kender ikke baggrunden, for data-resultaterne af ændringen er logiske for enhver med lidt matematisk sans. Men det er klart at når man ændrer benchmark, så mister mange deres faste grund at stå på – hvad niveau er de nye tal nu på? Det største problem er light-userne, som ikke har samme fair chance for at fange en sådan ændring, mens professionelle folk bør være helt bekendt med sådanne ændringer via opdateringer på diverse blogs mv.. Jeg tror ikke vi ser ændringer af den kaliber fra Google Analytics lige fremover, med mindre de holder fast i det (og Avinash er enig… ).

Ser du det som et stort problem at bounce indgår i udregningen? Savner du en ny måde at udregne tidsforbrug? Bør besøg kun være brugere, der ser mere end én side? Bør nogle af systemerne tage denne kamp op, eller er det vigtigste blot at alle holder sig til samme standarder? Eller har du helt andre spændende input i denne debat? Giv gerne din mening til kende

Temauge dag 1: Gratis Webstatistik værktøjer

Så er der dømt temauge med gratis produkter, der kan bidrage til optimering af dit website ud fra analyser. Der er mange aspekter i forhold til at indsamle data om sitet og hovedgrupperne er følgende:

• Tracking / webstatistik
• Tracking af klik på sitet
• AB test
• Brugertilfredshedsanalyser
• Analyse af scroll og videoer
• Chat med brugerne – direkte på sitet
• Værktøj til at rekrutere respondenter

Emnerne prioriteres på en måde så de først omtalte er de vigtigste at gennemføre. Dagens emne er derfor

Webstatistik og registrering af brugernes adfærd

Dette område er i fuld udvikling, og i en sådan grad, at systemer, der tidligere kostede penge er blevet gratis. Som kandidater til gratis tracking har vi derfor:

Webstatistik tools: Google Analytics,  Woopra og Yahoo! Web Analytics (dog først gratis tilgængeligt for alle i løbet af 1. Kvartal 2009).

Alle tre tracking systemer leverer de grundlæggende data ved blot at installere en grundkode på alle siderne på dit site. Du får dermed helt gratis adgang til data som

• Hvor kom brugerne fra?
• Hvilke søgeord brugte brugerne til at finde mit site?
• Hvor mange sider så brugerne i gennemsnit?
• Hvilket indhold er det mest læste ?
• Og mange flere statistik data om dit site…

Alt du skal investere er 15 min. Til at gå ind på de ovennævnte sider, oprette en konto, placere tracking kode på dit site og vente på at der kommer data ind. Når du så har fundet ud af hvor fantastisk det er med alle de data, så vil jeg anbefale at gå et skridt længere og sætte mål op, frafiltrere egen IP-adresse og sætte flere detaljer op (som tracking af interne søgninger). Systemerne er ganske gratis, og kræver kun at man opretter en konto hos dem. Hos Woopra skal man dog vente på godkendelse, hvilket kan tage op til flere uger. Tålmodighed er en dyd når man venter spændt J

Hvilket webstatistik system skal du vælge?

De tre gratis systemer udmærker sig på hver sin vis, hvilket giver en god alsidighed i markedet.

Google Analytics

Det lettest tilgængelige system. Det er let at få et overblik over data, og der er opsat dashboard fra start af som viser data fra forskellige faneblade. Det er efter min mening ikke de mest vitale nøgletal, men det er en start at justere ud fra (jeg kan fx. Anbefale at tilføje søgeordene brugeren har brugt for at finde dit site – det er yderst væsentligt at kende). Google Analytics vil jeg i stor udstrækning anbefale til størstedelen der ønsker at gå i gang med at tracke deres websites trafik. Det er som nævnt hurtigt at komme i gang med og giver et godt indtryk af hvad der er muligt. Har man større behov end Google Analytics kan opfylde, så kan man efterfølgende investere i et betalt system (SiteCatalyst eller Netminers) eller se om Yahoo! Web Analytics kan klare de sidste mangler. Største minus ved Google Analytics er at man skal være lidt kreativ med koderne hvis man skal spore events og actions, som ikke har unikke URL´er (fx klik mv).

Yahoo! Web Analytics

Yahoo! Web Analytics er lige så let at implementere som Google Analytics, hvis man venter med action-koderne og de øvrige detaljer. Det kan man fint hvis man til start ønsker at lære denne verden lidt bedre at kende. Systemet er derimod lidt mere komplekst at gå i kast med end Google Analytics og kræver lidt mere tid at sætte sig ind i. Får man bugt med start udfordringerne, og får opsat kampagne oversigt, action tracking, sporing af interne søgninger og ebusiness, så er det til gengæld et ganske avanceret system som før var godt i forhold til prisen, og nu er gratis med samme mange spændende muligheder. Dette system vil jeg derfor anbefale til alle som har mod på at give sig i kast med lidt mere avancerede systemer, eller som vil investere nogle konsulenttimer til at få installationen op og køre i 5 gear. For det er først når detaljerne er kælet for, at systemet for alvor kommer til sin ret.

Woopra

Woopra er i en helt anden kategori. Igen skal koderne blot på alle sider. Forestil dig at du er børmægler og ser aktiekurserne kører hen af skærmen og der er fuld aktivitet med udsving og køb og salg. Sådan er Woopra cirka. Der er kurver og procentmæssige forskelle i forhold til timer og dage og hver gang en ny bruger kommer på sitet popper de op på et landkort. Systemet er dermed super overlegent når det drejer sig om realtime (Yahoo! Web Analytics go home) og man kan tilmed følge en bruger rundt på sitet og starte en chat med brugeren. Dette har sin pris på andre kontoer, og indtil videre har jeg ikke set skyggen af ebusiness eller avancerede opsætninger. Det skal dog siges at systemet stadig er i beta og de varsler en gratis udgave samt en betalt udgave. Jeg håber at den betalte variation bliver langt mere avanceret og at den nuværende forbliver gratis. Mindre kan ikke gøre det, da jeg i så fald mener at systemet bliver for tyndt. Woopra anbefales til dem, som vil have statistikken kørende på væggen så medarbejderne kan se udviklingen samt dem, som ønsker at foretage kvalitative analyser på en lidt anden måde. Nemlig ved at starte en chat med nogle brugere samt at se hvordan enkelte brugerne bevæger sig rundt.

Så opret din konto allerede i dag og få data på dit website i morgen, ganske gratis (well ok.. Kun Google Analytics er klar med det samme, I know, I know). I morgen fortsætter jeg med at fortælle om hvordan du får registreret brugernes klik ganske gratis, så smut ind forbi bloggen igen allerede i morgen.

Læs mere om gratis analyseværktøjer i denne temaserie:

Temadag 2: Gratis registrering af brugernes klik

Temadag 3: Gratis AB test med Google Website Optimizer

Temadag 4: Gratis brugertilfredshedsanalyse

Temadag 5: Lær hvor meget brugerne scroller

Temadag 6: Find ud af brugernes meninger via chat

Inspireret af andre blogs tager jeg stafetten op og laver en tema uge – i næste uge

Gratis webanalyse værktøjer

Hvad er bedre end at øge omsætningen på sit site ud fra en optimering? Hvis optimeringen kan gøres gratis selvfølgelig. Derfor vil hele næste uge omhandle gratis værktøjer, som på hver sin måde kan bidrage til at optimere dit site. Det kommer både til at omhandle tracking, webstatistik, surveys, ab-test samt andre værktøjer der kan bidrage med spændende data. Og lur mig om Avinash ikke er indblandet igen…

Det mest fantastiske med denne uge er at der er rigeligt af tools jeg kan omtale, så det bliver svært at nøjes med en uge… Følg derfor med i hele næste uge og få alle guldkornene.

Det starter allerede i morgen hvor emnet er gratis Webstatistik.

Hilsen Webanalytikeren

Se indlæggene om de gratis analyseværktøjer her:

Temadag 1: Gratis Webstatistik

Temadag 2: Gratis registrering af brugernes klik

Temadag 3: Gratis AB test med Google Website Optimizer

Temadag 4: Gratis brugertilfredshedsanalyse

Temadag 5: Lær hvor meget brugerne scroller

Temadag 6: Find ud af brugernes meninger via chat

Web Analyse firmaer

Det er et broget marked “out there”, så Thore fra www.onlinespecialisten.dk er gået i gang med at lave en liste over potentielle virksomheder og rådgivere når du har brug for assistance til din hjemmeside vedr. analyse og tracking.

Selv med listen til rådighed kan det være svært for en udeforstående virksomhed at vide hvad man skal vælge. Virksomhederne har forskelligt fokus, og fx er der stor forskel på Creuna og Deducta – Creuna er i langt højere grad et udviklingshus, som laver hjemmesider og til tider analyserer lidt på det, mens Deducta i langt højere grad fokuserer på analyse-delen og ikke selv står for udvikling af sites (men har designere til at lave design dannet på baggrund af facts og analyse).

Min anbefaling forud for valget af rådgiver er at surfe godt rundt på virksomhedernes hjemmeside, og se om man mærker en rigtig fokusering og brug af tracking, samt valg af system i forhold til behovet.

Læs mere på onlinespecialisten.dk og få hjælp til at finde hvem der kan hjælpe dig med webstatistikken.