Skrevet af: Jesper Mikkelsen
5. juli 2019

7 grunde til at din Google Analytics ehandelsdata ikke stemmer

Indimellem støder vi på kunder, hvor data i Analytics ikke stemmer med dataen i deres webshops backend. Der kan være flere grunde til at dette sker – også flere grunde end dem jeg kommer rundt om her. Dette er dog nogle af de grunde vi oftest ser.

Hvis du helt mangler ehandelsata i Analytics, er det nemt at se, at der er noget galt. I andre tilfælde, hvor du kun mangler nogle transaktioner, kan det være sværere at finde fejlen. I disse tilfælde kræver det mere tid til at undersøge hvor fejlen opstår.

Nogle af tingene herunder kan være i den mere avancerede ende, for den gennemsnitlige webshopejer. Lad derfor være med at gå i panik, hvis noget af det nedenstående er volapyk. Hos WeMarket har vi oplevet mange problemstillinger, og de er sjældent helt ens. Vi er derfor klar til at hjælpe dig, hvis nedenstående er uoverkommeligt.

Små afvigelser vil der næsten altid være

Det er næsten umuligt at komme helt udenom afvigelser. Er der kun nogle få procents afvigelser, kan det sjældent svare sig, at bruge for lang tid på at undersøge hvor fejlen opstår.

En af hovedsynderne her er diverse blockere, som blokerer at data bliver sendt til Google Analytics. Som webshopejer kan det være svært at forestille sig, hvorfor nogen kunne finde på at installere en blocker på deres computer. Grunden er dog som regel for at beskytte privatlivet – enten for at undgå at give sine data videre til andre, mere eller mindre uden samtykke, eller også for i videst mulige omfang undgå remarketing-annoncer på baggrund af de sider og produkter du har besøgt.

Tjek at ehandelsdata er slået til

For god ordens skyld, er det altid en god ide at starte med at tjekke om ehandelsdata er slået til på din konto. Blot så du ikke spilder en masse tid på, at lede efter noget der er en meget simpel løsning på. Måske er du allerede sikker på, at det er slået til – hvis andre har adgang til kontoen, kan de dog være kommet til at slå det fra. Om end det (heldigvis) er usandsynligt, så start der.

Gammel sporingskode

Har du fået installeret Google Analytics for mange år siden, og enten ikke fået en ny hjemmeside siden, eller koden blot er kopieret, når der er kommet ny hjemmeside til, så er der en risiko for at du har en gammel sporingskode installeret.

Der findes overordnet set 3 forskellige typer sporingskode fra Google Analytics:

  • ga.js
  • analytics.js
  • gtag.js

Den sporingskode, vi oftest oplever giver fejl, er ga.js, som er den ældste (fra 2007). Den blev erstattet af analytics.js i 2013, og umiddelbart herefter anbefalede Google at man skiftede til den i stedet. De fleste er (heldigvis) skiftet, men vi har oplevet et par enkelte gange at koden ikke har været skiftet her 5-6 år senere.

gtag.js er seneste skud på stammen i Analytics koder, og blev introduceret i slutningen af 2017. Det er nu den kode som Google Analytics automatisk viser, og beder dig, eller din udvikler om at indsætte, når du opretter en Google Analytics konto.

For langt de fleste vil man uden problemer kunne skifte til gtag.js uden videre. Det er samtidig nemt at indsætte/skifte koden i de fleste systemer.

En nem måde at tjekke hvilken version du har, er at vælge ”Vis kildekode” i din browser, og søge efter ”UA-”. På den måde kommer du let til det sted hvor din Analytics kode er implementeret.

Du får i de fleste browsere muligheden for at få vist kildekoden ved at højreklikke på siden, og vælge punktet ”Vis kildekode” i den menu der nu kommer frem.

Når du skal søge efter ”UA-”, gøres det typisk ved at vælge ”Find” i browserens værktøjslinje. I de fleste browsere kan du også bare trykke på ”CTRL + F” på dit tastatur, for at få søgefeltet frem.

Manglende ecommerce kode på kvitteringssiden

Hvis du helt mangler data om transaktioner og omsætning i Analytics, kan et godt sted at lede også være i den kode som sendes til Analytics omkring ehandelsdataen. Her er det kvitteringssiden på webshoppen som du skal have frem. Lav en testordre. Når købet er gået igennem, så tjek kildekoden på den side som du er blevet sendt til, når transaktionen er gået igennem (fx når dit betalingsvindue sender dig videre).

Hvad du skal lede efter i kildekoden, kan være forskelligt, alt efter hvordan dit webshopsystem eller din udvikler har implementeret koden (hvis det er implementeret). Start med at søge efter ”ecommerce” i kildekoden, da du oftest vil kunne finde det ud fra det.

Hvis du ikke finder ecommerce koden ved at gøre dette, så har du muligvis ikke implementeret det. Bemærk dog at der også kan være andre måder at implementere det på, så hvis ikke du kan finde koden, så tag fat i din udvikler, som kan hjælpe med at undersøge det nærmere.

Forsinkelser i Analytics

Tidligere var der typisk en forsinkelse på data til Analytics på op til 72 timer. Heldigvis er dette sjældent.

Hvis du oplever afvigelser i omsætningen eller transaktionerne, så start med at tjekke at du ikke ser på data fra samme dag. Oftest vil du have de fleste af dataene med, men der kan være mindre forsinkelser på nogle af dataene, om end det sjældent er så store forsinkelser som de 72 timer som kunne være tidligere.

Se kun på data fra dagen før eller tidligere data, for at undgå at du leder efter data som er på vej til at blive vist.

Manglende datalag

Er din Google Analytics indsat igennem Google Tag Manager, så bliver ehandelsdataen ofte indlæst igennem datalag. Datalag kan du ikke nemt finde i kildekoden, ligesom du kan med ecommerce tracking koden.

Igen skal du lave et testkøb og blive på kvitteringssiden du ender på efter transaktionen.

For at se datalag kan du (med Chrome browseren) højreklikke et sted på siden og vælge ”Undersøg” i den menu der kommer frem. Du får nu vist en masse kode, som er volapyk for de fleste.

Her skal du finde det sted øverst hvor der står ”Console” og klikke.

Nu er der kun en pil, og en markør der står og blinker. Her skriver du ”dataLayer” og trykker på ”enter”-knappen.

Her kan du trykke på pilene, for at se hvilken data der er i de forskellige datalag. Tjek at der er et felt der hedder ”transactionalTotal”, og der ud for dette felt står det fulde beløb som din testordre lyder på. Har du dette felt, er det med stor sandsynlighed ikke her fejlen ligger.

Datalag kode indsat forkert

Som ovenfor kan dette især være et problem hvis din Analytics og ecommerce tracking er indsat igennem Google Tag Manager. Datalag koden skal gerne være indsat før selve Google Tag Manager koden, så Google Tag Manager har mulighed for at kunne opfange koden automatisk.

Hvis dit datalag allerede er indsat, og dataen er korrekt, men indsat over Google Tag Manager koden, så kan du følge nedenstående, i stedet for at prøve at overtale udvikleren til at ændre i koden:

Lav en ”trigger” i Google Tag Manager. Som ”udløsertype” i Google Tag Manager skal du vælge ”DOM er klar / DOM ready” under kategorien ”Sidevisning”.

Herefter vælger du at triggeren aktiveres ved ”Nogle hændelser, hvor DOM er klar”. Her skal du vælge når ”Page Path” -> ”Indeholder” -> ”[den del af stien på din kvitteringsside som ikke er dynamisk]”.

Det kunne eksempelvis være ”/shop/cart/checkout?CompletedOrderId”, men er afhængigt af dit shopsystem.

Mange andre ting

Der vil kunne være mange andre ting, som er skyld i at dataen omkring den ehandel du ser i Analytics ikke stemmer med den faktiske data, som nævnt i starten. Ovenfor er de fejl vi oftest ser, og derfor nogle af de steder det typisk kan være godt at starte med at lede.

Med en bred viden inden for online marketing, specielt alle annonceringsmuligheder på Google, har Jesper altid svaret på spørgsmål omkring Google Adwords, Google Shopping, Displayannoncering, remarketing og annoncering på Youtube.