Google Analytics med fejl. Eller..?
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
Pingback: www.anyhed.dk
…hvor jeg kommenterede (uden at få svar)…
Det er vist meget normalt derovre
Hejsa.
Jamen så må jeg vel hellere kommentere….
Min artikel har aldrig været tiltænkt som EB journalistik og problemet som jeg belyser er skam reelt nok. Jeg har fået talt med Google Danmarks Analyticsmand, Thomas, der kender til problemstillingen og egentlig ikke forstår hvorfor Google ikke selv gør noget ved det….
Og derfor er en artikel da relevant uanset om værktøjet er gratis eller ej – for det er et fabelagtigt værktøj. Bare federe når man ved hvad man evt. kan komme ud for ved brugen af værktøjet.
Jeg har ingen intentioner om at køre hetz mod hverken Google eller dig Jacob (du går da pænt hårdt til mig med din mediebureau bemærkning -måske lidt EB agtig???), men blot informere.
Tilgengæld er det da super fedt at der kommer noget dialog og diskussion så problemer/fejl bliver belyst.
Mere af det.
Søren J ;o)
PS. Måske skal man kaste lidt mudder engang imellem førend folk får øjnene op…. Jeg ved det ikke, jeg spørger bare!!??
@Mikael: Oki, det var min første kommentar
Jeg synes blot man bør kommentere når der fremlægges argumenter og holdninger.
@Søren: Hej Søren. Tak for din kommentar
Jeg har på ingen måde interesse i at køre hårdt på dig, også fordi at du selv angav at det var en oversættelse. Men derfor har du stadig videreformidlet det, uden at kommentere mere på det omkringliggende. Som jeg prøver at sige, så synes jeg vinklen er forkert ved at kalde det for fejl og blot omtale dele af problematikken/baggrunden for det omtalte. Og som sagt, så undrede det mig at det kun er Google Analytics der er i rampelyset, når flere systemer bruger samme metode…
Jeg håber ikke der er brug for mudder for at få øjnene op for både mulighederne og udfordringerne ved webanalyse, det bør kunne gøres på en mere elegant vis.
Den såkaldte fejl som Thomas selv mener er et problem, er det helt simpelt at bounce indgår i udregningen af tiden? Ville det være mere reelt ikke at inddrage den? Jeg kan godt se både for og imod. Eller måske man bør gribe fat om problemet længere tilbage, så man somehow får registreret tid på 1-page visitors i stedet? Det ville give en langt mere brugbar løsning, frem for at sminke på såret.
Hvor stort synes andre problemet er?
Jeg har aldrig helt fattet hvorfor nogen bruger Visit Duration som en metric. Primært fordi der rent teknisk er sindsygt mange fejlkilder, der kan give vilde udsving.
Et eksempel, ud over alt det du ellers hiver frem: Jeg klikker mig ind på et site, læser forsiden i 1 minut, klikker mig videre, læser næste side i 1 minut, og klikker mig så væk. Hvad er min reelle Visit Duration så?
Eksempel 2: Jeg er en erfaren nethandlende, der er ude efter en helt specifik dingenot. Jeg Googler den frem, klikker mig ind på dit site, propper dingenoten i min kurv, og har suset igennem din checkoutprocess inden der er gået 5 minutter. Er mit besøg mere eller mindre værd, end en der har fjumret rundt i din butik i et kvarter, uden at ende med at købe noget?
Desuden er det egentligt ligemeget om ens værktøj måler det på den ene eller på den anden måde. Bare den gør det konsekvent ens! For det handler om at fokusere på et metric, sætte ind med forbedringer, og måle om de har haft en positiv eller negativ effekt på denne metric. Og så er det sådan set ligegyldigt om den pågældende metric er “5” eller “4” til at starte med.
Derfor synes jeg personligt ikke at problemet er til at få øje på. For mig er Visit Duration en ubetydelig og meningsløs metric.
Det var min mening, du bad selv om den
@ Søren: Super at høre din mening. Kun på den måde får man en spændende debat
Jeg er helt enig i at det som sådan er en “pudsig” metric, som ikke altid er lige relevant. Men i nogle tilfælde kan den være meget vigtig, og der er det vigtigt at vide præcis hvad der ligger bag data.
Forestil dig en kursusudbyder, som har en masse vigtig info om kurset. Hvis den gennemsnitlige læsetid er 5 sekunder, så bør det være et klart signal om brugerne ikke læser en brøkdel af indholdet, og man derfor bør optimere teksten/fremstillingen på siden. Skyldes den lave læsetid derimod en høj bounce-rate, og at størstedelen af de reele læsere i virkeligheden bruger over 1 min (ja ok, der skal en ret høj bounce rate til at det kan lade sig gøre), så bør man overveje om det lave tidsforbrug i højere grad skyldes irrelevante besøgende (som ender i et bounce), mens de øvrige synes siden er godt skrevet og opstillet.
Så problemet er reelt nok, for det er stadig forkerte anbefalinger man kan ende med, hvis man ikke analyserer ud fra de rigtige parametre. Vil jeg i al fald mene
Jeg kan huske at man i starten af 2000, for at lave en online-liste (brugere der er online på din side lige nu) var ude i den samme problemstilling. Man havde nemlig behov for at vide om brugeren (her identificeret via ip) var på siden eller om han/hun var smuttet.
Her gjorde man det ‘samme’ som Google Analytics gør nu, man sætter en timeout på brugeren (ga benytter sig af cookies her), og hvis denne timeout ikke bliver nulstillet (som følge af sideskift eller anden interaktion) efter en given tidsperiode, så definerer man brugeren som forsvundet.
Dette er selvfølgelig ikke rigtig ‘rigtigt’, da brugeren bare kan være igang med at læse en lang artikel, eller at han/hun har forladt computeren i et stykke tid. (Desuden kan brugeren ligeledes miste sin identifikation i processen, cookies osv)
– GA sætter kunder der har ‘forladt’ siden i den åndsvage nul-sekunders-besøg’s kasse. Som ikke er en metric man kan bruge til noget reelt.
For at kunne udregne dette mere præcist, havde man overordnet to løsninger (den ene mere dum end den anden):
– Man satte et onunload i body tagget, som, når brugeren lukkede browseren åbnede et lille vindue (før popup-blockerens tid), der timeouttede brugeren.
– Man satte et loop i Javascripten, der blev ved med at kalde databasen (eller anden server-side-løsning) hvert sekund eller ligne. Hvis databasen ikke modtog dette kald, var brugeren defineret som forsvundet. – Dette er åndsvagt, hovedsagligt, fordi det kræver dette konstante kald.
Det rent tekniske i denne metric er altså problemfyldt, og der er ingen løsninger i øjeblikket. Google’s metode er okay, da den giver et tal, men fejlmargen er så enorm, at metoden kun er ‘okay’.
Man kunne forestille sig, at browserne i fremtiden fik mulighed for at fortælle siden at kunden havde lukket siden. – Meeeeeen, det er en en helt anden debat :).
Bare min halvtekniske bemærkning.
@Bror: Mange tak for dit mere tekniske indspark. Det er absolut interessant at grave mere i den tekniske del, for hvis det kan løses, så er der jo ingen grund til at finde det bedste alternativ.
Woopra gør alt andet lige et eller andet anderledes: Man kan brugerens adfærd og hvilken side bugeren er på. Dette forsvinder når brugeren forlader sitet. Ved du hvordan det sker rent teknisk?
Woopra benytter sig af #2 ‘løsning’, den står og pinger brugeren hvert 5. sekund (eller sådan).
Prøv at installere Firebug, vælg Net, og gå til en side der har Woopra installeret (som her), man kan se at den står og henter
http://webanalytiker.dk.woopra-ns.com/ping/cookie=7IPXOHTLW287T0GL4H3T7JAUIO8SJYJB&ra=R5MQPCFBRNDKSEJG4PP1927QYODVPK8T
Med nogle specifikke parametre sat.
Jeg går udfra at Woopra fanger nogle oplysninger om brugeren ved første besøg, og så gemmer den dem i en cookie. Som den så køre det her ‘keep-alive’-ping script på (ved hvert sideskift opdatere den så). – Hvilket i bund og grund er meget proces-krævende.
Woopra er smart hvis man skal vise lidt lir til chefen, men, når alt kommer til alt er det dumt.
—
Jeg kan se at du også har Clicktale kørende! Det vil sige du har to script’s der parvis står og pinger fremmede servere
– Du er selvfølgelig lovligt undskyldt – da det trods alt er en side der omhandler webanalytics.