Pas på faldgruberne i Google Analytics: Her er syv af dem

30. december 2016 kl. 07:447
Pas på faldgruberne i Google Analytics: Her er syv af dem
Illustration: Google Analytics.
Der er en lang række faldgruber og svagheder i Google Analytics, selv om det også er et godt basisprodukt til måling af webtrafik. Få mere viden her.
Artiklen er ældre end 30 dage
Manglende links i teksten kan sandsynligvis findes i bunden af artiklen.

Gratisversionen af Google Analytics (GA) er for mange et udmærket produkt med mange analyse- og rapporteringsmuligheder i forhold til at overvåge ens webtrafik. Derfor er GA også måske det mest foretrukne værktøj til opfølgning på online marketing-aktiviteter og status på hjemmesiden.

Men de fleste, der har arbejdet bare lidt med GA, er også stødt på store udfordringer med datakvalitet og rapportering. Som tiden går oplever mange, at der skal tages flere og flere forbehold ift. GA data, hvilket besværliggør rapportering til topledelse og organisation.

Nedenfor er listet de mest kendte problemer med GA, som er gode at have øje for:

Problem 1: GA data ligger på forskellige konti

Det er ganske almindeligt, at en virksomhed har forskellige sprogversioner af deres website, hvor hver sprogversion er et selvstændigt domæne, eksempelvis:

www.example1.dk  
www.example1.de

I GA er virksomheden nødsaget til at oprette en konto for hvert domæne, og kan derfor ikke rapportere en samlet analyse for example1. Har virksomheden/koncernen flere brands/shops, f.eks. www.example2.dk, forstærkes problemet proportionalt.

Problem 2: Data-kontinuiteten brydes ved lancering af nyt website med ny domæne-struktur og ny sti-struktur

Udviklingen i webfunktionalitet går stærkt, og virksomheder skifter med års mellemrum website med nyt design, mobilvenlighed, shopfunktion mv.

Artiklen fortsætter efter annoncen

Det giver anledning til at nytænke såvel domæne struktur og hele arkitekturen på websitet, og f.eks. at gå fra flere domæner til et enkelt domæne som følger:

Gamle domæner:
www.example1.dk
www.example1.de

Nyt samlende domæne med sprogversioner som undersider:
www.example1.com
- www.example1.com/dk
- www.example1.com/de

Arkitekturen ændres næsten altid i forbindelse med et nyt website og centrale landingpages for hjemmesiden skifter sti/URL:
www.example1.dk/oldpath1/landingpage1
kan blive til
www.example1.dk/newpath1/landingpage1

Artiklen fortsætter efter annoncen

GA betragter det nye domæne og/eller de nye stier netop som nye og uden sammenhæng til de gamle, hvilket bryder kontinuiteten i data, og besværliggør at følge udviklinger og foretage analyser på tværs af det gamle og nye website.

Problem 3: Data registreres forkert på kanal, kilde eller kampagne i GA

Af mere eller mindre uforudsigelige årsager sker det, at trafik til hjemmesiden registreres forkert i GA.

Eksempelvis sker det ofte at “organisk trafik” registreres som “henvisningstrafik”, i forbindelse med omdirigering af trafik fra et gammelt til et nyt website.

Endvidere sker det, at trafik fra en online kampagne registreres på flere forskellige kilde-navne eller kampagne-navne, særligt hvis man hyrer et nyt eksternt bureau til at styre online kampagnerne på Google displaynetværket. Således vil man kunne opleve, at en kontinuerlig kampagne registreres under kilderne:
RTB
Real Time Bidding
DoubleClick Bid Manager

En variant af samme problem er at en kampagne benævnt “Online kampagner Q1 2016” indeholder data fra februar til juli 2016...

Det er kun i nogen grad muligt at rette op på disse problemer, men aldrig med tilbagevirkende kraft, og derfor altid med et brud på data-kontinuiteten til følge. Det kræver en streng datadisciplin og dyb indsigt i GA at holde “stien ren”, og disse kompetencer eksisterer typisk ikke i marketingafdelingen, hvor GA håndteres.

Problem 4: Trafik fra Robotter: Bots, Spiders og Spam referals

De fleste har stødt på, at man til tider får store mængder trafik fra kilder man ikke aner hvad er. Typisk ser man trafik fra kilder som tabellen herunder til højre:

Fælles for alle kilder er, at trafikken ikke kommer fra personer der er interesseret i dit website, men fra “robotter”, der udfører forskellige opgaver.

Artiklen fortsætter efter annoncen

Og faktum er, at data fra robotter påvirker øvrige statistikker og analyser i større eller mindre grad, afhængigt af den samlede mængde trafik. Jo mindre “ægte” trafik, jo større påvirkning fra robot-trafikken.

GA tilbyder ganske vist en funktion til at ekskludere trafik fra en række kendte robotter, og det er også muligt manuelt at opsætte filtre, der ekskluderer trafik fra uønskede kilder.

Men ligesom med livet, der leves forlæns og forstås baglæns, opsættes filtre først når skaden er sket og GA tilbyder ingen mulighed for at slette historiske data.

Problem 5: Betalt annoncering i Bing, Yahoo, ASK mv. bliver ikke registreret i GA

I Danmark er Google den altdominerende søgemaskine, men Bing, Yahoo og ASK anvendes i stigende grad både i DK og i udlandet.

Faktisk estimeres det månedlige antal søgninger på verdensplan for de 3 sidstnævnte til at udgøre mere end halvdelen af samme for Google. (https://www.ebizmba.com/articles/search-engines)

Det må forventes, at danske virksomheder, særligt når de markedsfører sig i udlandet, i stigende grad vil benytte annoncering på andre søgemaskiner end Google.

Disse data fanges ikke af GA, men de kan eksporteres fra de enkelte søgemaskiner og efterfølgende importeres manuelt i GA, hvilket er et irritationsmoment, når man gerne vil have fingeren på pulsen.

Hertil kommer risikoen for at lave fejl i dataindlæsningen, som i GA er irreversibel. Dvs. indlæser man et datasæt to gange, eller har man et overlap i to datasæt på en enkelt dag, hænger man på disse fejlagtige data.

Problem 6: Rapport-funktionen er uegnet til C-level rapportering

GA er i sig selv et værktøj som det kræver øvelse og indsigt at mestre, særligt når der skal tages forbehold for datas korrekthed, jf. problem 1 til 5.

I GA er det muligt at definere tilpassede rapporter med udvalgte nøgletal til forskellige interessenter i virksomheden, f.eks. C-level (topledelsen). Det er endvidere muligt at automatisere fremsendelse af rapporter til interessenterne, med et pre-defineret interval, eksempelvis den første i hver måned.

I praksis er der dog så mange udfordringer med rapporternes indhold, at det ikke er en overdrivelse at betegne funktionaliteten som uegnet for de uøvede og u-indsigtsfulde, herunder C-level.

Herunder gennemgås en række praktiske udfordringer med GAs rapportfunktion.

Udviklingsrapporter:

Uanset hvorledes man har opsat de tilpassede rapporter, er perioden der vises i rapporten baseret på data fra de seneste 30 dage. Skal man have vist flere eller andre data, skal perioden ændres manuelt af interessenten, og allerede her kan det gå galt for den uøvede.

Således vil man i en månedsvist udviklingsrapport for 2016 få vist følgende billede som standard (pr. 25/7 2016):

Ikke særligt bevendt, idet rapporten kun indeholder data fra 25/6 til 24/7… Interessenten må derfor ændre perioden manuelt som følger:

Her bemærker man så, at de enkelte måneder ikke står i kronologisk orden, idet GA som default vælger Sessioner som sorteringsnøgle. Dette må man så korrigere for ved at klikke på kolonnen “Måned i året”, før man kan producere dette billede:

Når interessenter, som C-level, typisk kun tilgår GA analysen en gang månedligt, er risikoen for at lave fejl betydelig. Det optimale er naturligvis, at få præsenteret den ønskede rapport med det samme.

Benchmarking:
De fleste, og navnligt C-level, ønsker at få et hurtigt overblik, hvilket som oftest er et tal eller talrække sammenholdt med et benchmark, for at sætte status i relation til et mål. Typisk er Benchmark et budgetmål, og ofte vil man ønske en status mod benchmark for den forgangne måned samt År-til-dato.

En sådan status mod et meningsfyldt benchmark kan GA umiddelbart ikke levere!

GA kan dog som standard vise en udvikling mod enten samme periode sidste år, den tidligere periode, eller man kan definere benchmark-perioden som man vil.

Spørgsmålet er dog hvor relevante disse benchmark mål er. Uanset gælder dog at en sådan rapport ikke kan ikke defineres som fast rapport der kan fremsendes til interessenter.

Den skal skabes manuelt ved hver rapportering, og det kræver øvelse og indsigt. En praktisk løsning er at lade den øvede ekspert i virksomheden skabe rapporterne, gemme dem som PDF filer og fremsende disse til interessenterne.

Udover at det er en manuel opgave for eksperten der skal udføres med fast interval, er det ikke så interessant og spændende for interessenten at læse PDF’er ift. dashboards.

Rullende udviklinger:
GA kan vise udviklinger pr. time, pr. dag, pr. måned. pr. kvartal og pr. år. Men en yderst relevant periodisering som det sæson-udjævnende rullende 12 måneder og udvikling heri, kan ikke skabes i GA.

Mobil-venlig platform:
Selv om Google vægter mobil-venlighed højt, når de tildeler ranking-værdi til alverdens websites, er deres eget værktøj GA ikke mobilvenligt. Således er det stort set umuligt at navigere i GA fra en mobiltelefon.

Problem 7: Summen af problem 1-6 skaber et nyt problem

Det er for mange virksomheder lidt af et kludetæppe at stykke et retvisende billede sammen, med status og udvikling i trafik og omsætning på virksomhedens website eller websites.

Når datarens og data-konsolidering ikke er muligt, mistes tillid til datas korrekthed i organisationen. Når rapporteringsværktøjet ikke kan levere de ønskede rapporter, mistes interessen for web-data i organisationen.

Den dygtige marketingmedarbejder kan nok finde de korrekte svar, men central og værdifuld viden om hjemmesiden og kunderne tenderer til at forblive i marketing og har status som low interest i organisationen og på C-level.

Med den kraftigt stigende rolle som internettet og internethandel spiller i den moderne globaliserede verden, er dette sjældent holdbart.

Analyseværktøjer til onlinedata

En mulig løsning på udfordingerne er analyseværktøjer der er gearet til at samle og håndtere online-data fra flere kilder.

»Kort fortalt kan sådanne værktøjer samle alle virksomhedens online-data, såvel fra GA, Bing Analytics, sociale medier, apps mv. gældende for alle virksomhedens domæner/websites så de kan analysereres på tværs,« siger Jim Møller fra det danske softwarehus Infosuite som er blandt leverandørerne på området med produktet 'Web Analytics'.

Ifølge ham kan løsningen tage hånd om de fleste af de nævne udfordringer, blandt andet på grund af den omfattende datarens og datakonsolidering der bliver foretaget på de historiske data.

7 kommentarer.  Hop til debatten
Denne artikel er gratis...

...men det er dyrt at lave god journalistik. Derfor beder vi dig overveje at tegne abonnement på Version2.

Digitaliseringen buldrer derudaf, og it-folkene tegner fremtidens Danmark. Derfor er det vigtigere end nogensinde med et kvalificeret bud på, hvordan it bedst kan være med til at udvikle det danske samfund og erhvervsliv.

Og der har aldrig været mere akut brug for en kritisk vagthund, der råber op, når der tages forkerte it-beslutninger.

Den rolle har Version2 indtaget siden 2006 - og det bliver vi ved med.

Debatten
Log ind eller opret en bruger for at deltage i debatten.
settingsDebatindstillinger
7
12. januar 2017 kl. 14:48

Jeg synes artiklen er god på den måde at den beskæftiger sig med de problemer som de fleste brugere oplever.

Det er jo ganske givet at der er workarounds og god data governance som Kasper og Morten kommer ind på i kommentarerne, men det ændrer jo bare ikke på, at skaden er sket for mange virksomheder. OG da kompentencerne i virksomhederne på dette felt typisk er ikke eksisterende, kan man jo vælge at gå til den ene type ekspert som Kasper og Morten, eller til en anden type ekspert som Jim Møller fra Infosuite, der er refereret i artiklen.

Infomercial eller ej, så må sige at jeg synes alternativet med en BI løsning lyder besnærende, og er glad for at Version2 har givet mig den indsigt. Kan kun opfordre til at læse https://www.infosuite.dk/data-integration/bi-til-google-analytics-og-sociale-medier/

6
1. januar 2017 kl. 17:56

Savner at Version2 tydeligt skriver når der er tale om en Infomercial.

Øv, at "vogterne" fusker med læserne.

5
30. december 2016 kl. 10:52

Svar på problem 5:Yes, det kunne være ubegribeligt fantastisk hvis Google integrerede med flere tredje part tjenester som Bing, Yandex, Yahoo, Ask, for ikke at nævne utallige affiliate netværk. Det ville spare en masse opstarts og vedligeholdelses arbejde. Heldigvis kan man selv importere Cost data til GA, og man har da to måder at gøre det på:

  • Summation (summer værdier for ens kampagner)
  • Overwrite (overskriv værdier for ens kampagner) Dvs. man har altid muligheden for at overskrive gammel data. Ønsker man helt at fjerne cost kan det simpelt gøres ved at lave en enkelt import af alle kampagner og sætte cost til 0. I vores setup henter vi (via automatiske jobs) cost fra de betalte tjenester som dækker 85+% af vores trafik niveau på daglig basis. Dette køres på kampagne niveau, og kan i princippet udbygges til keyword niveau. Det er dog kun for at se en tendens i GA, da vi har revenue tal i de enkelte tjenester til brug for bid management.

Svar på problem 6:Alt efter opsætning og grundighed kan dette fint benyttes til C-level rapportering. De fleste anvendelser af GA er via en client-side implementering hvor det er brugerens browser der sender tracking requets til GA, hvilket selvfølgelig er en potentiel stor fejlkilde (Javascript eksekvering, div. tracking blockers, m.m.). Derfor kan man med rette anse GA for at vise tendenser snarere end faktiske tal. For kritiske tal, f.eks. salg, kan man med rette anvende deres Meassurement Protocol (server-server) tracking, da man så bliver uafhængig af eksekveringen på klienten. GA er et analyse værktøj, ikke et dashboard værktøj, hvilket også er en af grundende til udrulningen af deres Data Studio løsning som egner sig godt til benchmarking, tilapassede rapporter og visualiseringer.

4
30. december 2016 kl. 10:52

Svar på problem 3:Der er ikke noget som logges forkert i GA af ”uforudsigelige grunde”. Når Organisk trafik registreres som henvisnings trafik i forbindelse med omdirigering af trafik fra et gammelt til et nyt website tyder det på I ikke har opsat jeres ”Referral Exclusion List” korrekt. Nye sessioner i GA startes hver gang indgangskilden ændres, hvilket den jo gør så snart det gamle site omdirigerer til det nye uden at det gamle domæne står anført som ”Excluded Referral”. Kampagner defineres altid ud fra

  • utm_source
  • utm_medium
  • utm_campaign
  • utm_content
  • utm_term GA integrerer naturligvis med GDN (Google Display Network), men det vil altid kun være kilden ”utm_source” som ændres. Kampagne navnet vil altid være det samme som angivet for den enkelte kampagne. Har man ikke lavet om i kanal grupperingen, vil den altid foregå i henhold til Default Channel Grouping:https://support.google.com/analytics/answer/3297892?hl=enMan kan i øvrigt sætte et filter op for et view der altid lowercaser kampagne værdier.

Svar på problem 4:Et meget universelt problem der kan henføres til ”Du ved ikke hvad du ikke ved”. Det er svært på forhånd at ekskludere bot traffik fra kilder man ikke er bekendt med. En hurtig tanke kunne være at det vil være en god ide hvis GA kunne fjerne gammel trafik fra IP’er, domæner, etc. Man definerer som bot trafik. Men overvej hvad der skal ske i det scenarie en forkert IP angives og troværdig data bliver slettet? Det kunne være behjælpeligt hvis man kunne oprette segmenter til ekskludering af IP adresser i GA, men nu er vi ovre i persondata beskyttelse da trafik pludselig i princippet vil kunne nedbrydes på den enkelte bruger.

3
30. december 2016 kl. 10:51

Jeg må indrømme jeg ikke deler samme opfattelse af GA, på trods af jeg ser mange måder hvorpå GA kan forbedres, både gratis versionen og Premium (nu 360). Mange af udsagnene der betegnes som problemer kan omgås med lidt dybere kendskab til GA.

Svar på problem 1:GA arbejder med:

  • Accounts
  • Properties
  • Views En account kan have mange properties som igen kan have mange views. Data fra websitet opsamles på property niveau. Views kan betragtes som ”filtrerede visninger” af data fra den pågældende property. Der er altså ikke noget i vejen for at anvende den samme property for flere domæner og så f.eks. oprette følgende views:
  • Raw (sørg altid for at have rå ufiltreret data)
  • Rollup (kun trafik fra www.example1.dk og www.example1.de)
  • Danmark (kun trafik fra www.example1.dk)
  • Tyskland (kun trafik fra www.example1.de) Et view indeholder kun data fra den dato det er oprettet så sørg for at oprette dem fra start af.

Svar på problem 2:Dette er ikke relateret til GA, snarere et universelt problem. Da GA anvender path værdien til at skelne sider vil to forskellige paths naturligvis blive rapporteret som to forskellige sider. Ser vi på f.eks. Adobe Analytics (tidligere Omniture og SiteCatalyst), anvendes URL’en kun til at definere en side såfremt pageName ikke er sat, så samme ”problem” vil være gældende her. Grunden til jeg skriver ”problem” skyldes at grundig tracking implementeringer af website af en hvis størrelse selvfølgelig har opsat en fyldestgørende side kategorisering ved brug af tilpassede definitioner (custom dimensions). F.eks.:

  • Custom Dimension X (page level 1)
  • Custom Dimension Y (page level 2)
  • Custom Dimension Z (page level 3)
  • … Hvor den sammensatte værdi altid vil være unik og udgøre det egentligt sidenavn som der rapporteres på. Hvis tracking er korrekt implementeret på de gamle og nye sider vil man derfor bevare kontinuiteten. Vil man ikke have det liggende i kildekoden kan man selvfølgelig anvende GTM og konstruere et path/pagename map som mapper gamle og nye paths til et unikt sidenavn.
2
30. december 2016 kl. 10:40

Jeg forstår ikke, hvorfor I kun nævner problemerne uden løsningerne i Google Analytics (hvis man ser bort fra at man skal købe det eksterne værktøj fra dem, der sikkert har sendt jer pressemeddelelsen).

Jeg savner lidt, at I har talt med en ekspert om dette. Artiklen viderebringer en række misforståelser omkring Google Analytics.

Problem 1: I skriver 'konto', når I mener 'ejendom'. Og det er best practice at forskellige domæner har sin egen ejendom. Man kan vælge at lave en roll-up-konto, men hvis man bruger den som sin primære, vil man hurtigt løbe ind i problemer som fx sampling.

Problem 2: Dette kan løses ved at oprette en ny visning, hvor URL'erne i den nye data omskrives til at følge den gamle struktur. Her kunne man så sende det nye URL i en custom dimension på hit scope.

Problem 3: For at løse dette bør man have en klar naming convention i sine UTM-koder. Disse bør i øvrigt altid være lowercase (og ikke med store bogstaver, som I har gjort), da Google Analytics ellers bliver forvirret.

Problem 4: En stor del af disse kan undgås ved at oprette et filter, der kun inkludere det korrekte hostname. I øvrigt også ved at bruge en visning, der ikke slutter med -1. I skriver at man ikke kan rette fejlen historisk. Det er kun delvist korrekt, man kan bruge segmenter til at fjerne dataen historisk og derved løse problemet.

Problem 5: At ting ikke sker automatisk er næppe et problem. Der er RIGTIG meget, der bør sættes op og tilpasses, hvis man arbejder seriøst med webanalyse. At tro Google Analytics bare virker out-of-the-box er nok det største problem af dem alle.

Problem 6: Her bør den ansvarlige opsætte tilpassede rapporter, der automatisk bliver sendt til C-level i PDF-format, hvor de korrekte ting er valgt. Det meste kan lade sig gøre i Google Analytics, men man kan rigtig nok overveje et eksternt værktøj.

1
30. december 2016 kl. 09:17

Goals oprettes typisk for at finde ud af, hvor langt i en given proces en bruger når, før brugeren afbryder. I et bestillingsflow kan man fx se, hvor man taber brugerne henne, og hvor man skal sætte ind for at få konverteringsraten op.

Udfordringen kommer så, når man har brug for at ændre disse goals - man kan ikke slette dem, da de er bundet op på historiske data, og der er et begrænset antal goals til rådighed. Genbruger man sine goals i anden sammenhæng, holder historikken op med at være retvisende.

Findes der et bedre værktøj end GA, som samtidig giver en smule indsigt i demografien? Vi har tidligere anvendt Piwik, men det har af gode grunde ikke adgang til den omfattende viden om brugerne som Google besidder.