Det har igennem det seneste år ikke skortet på artikler skrevet af folk jeg har mødt på Workaway arrangeret af Refuga. Det følger helt naturligt af at Nikolaj som arrangerer de berømte arbejdsrejser har en fantastisk evne til at samle dygtige og inspirerende mennesker på hver eneste tur. Blandt deltagerne på den seneste tur var blandt andet Michelle, som har startet sin egen forretning som virtuel personlig assistent op helt fra grunden af. Jeg kan varmt anbefale hende, hvis du har brug for hjælp i din virksomhed.
Denne gang skal vi dog dykke lidt dybere og helt tilbage til min første Workaway tur i 2013, hvor vi blandt deltagerne fandt Casper Schneidereit, en allestedsnærværende online marketer, som du helt sikkert er stødt på før.
Mange af os lærte Casper at kende gennem hans webshop shopwithsocks.com, som han siden har afhændet. Casper har været en flittig gæst i diverse podcasts og blogs om online marketing, og har altid mange jern i ilden. Til daglig er han ansat som SEO-medarbejder i online butikken Woolspire. Woolspire sælger garn og formidler strikkeopskrifter til hele Skandinavien og Tyskland.
Det er i den kapacitet, at Casper i denne artikel tager fat på udfordringen med korrekt salgssporing i Google Analytics.
Google Analytics er et uundværligt værktøj for langt de fleste, der arbejder med drift og optimering af webshops. Værktøjet har fået et solidt fodfæste i online verdenen, og rigtig mange markedsføringsbeslutninger tages med rod i de data, der kan høstes fra netop Google Analytics. Hos Woolspire indgår data fra Google Analytics naturligvis også som et vigtigt element i mange væsentlige beslutninger. Af samme årsag er det af stor vigtighed, at disse data faktisk afspejler virkeligheden og dermed kan påregnes som pålidelige og sandfærdige, da beslutningsgrundlaget ellers skævvrides.
For høj omsætning i Google Analytics
Under mit løbende arbejde med at optimere og trimme Woolspire, faldt jeg over et væsentligt mismatch mellem de omsætningsdata som webshoppen oplyste (Prestashop i dette tilfælde), og de omsætningsdata som Google Analytics havde lageret. Dette er i sig selv ikke abnormt. Det er nok nærmere reglen end undtagelsen, at der ikke er 100% overensstemmelse mellem reel omsætning og omsætningstallet i Google Analytics. Den mest nærliggende årsag er, at returneringer og annulleringer ikke automatisk bliver videreført til Google Analytics. Ligeledes kræver den tekniske overlevering af data fra webshoppen til Google Analytics, at Javascript er aktiveret (det er det også hos langt de fleste brugere, men ikke alle).
En omsætningsafvigelse kan der altså findes mange forklaringer på, og typisk vil annulleringer stå for en stor del alt afhængig af produktet, der formidles i webshoppen. Annulleringer kan i øvrigt sagtens ”føres ind” (eller ”trækkes ud” om man vil) i Google Analytics, men den øvelse vil kræve et selvstændigt blogindlæg, så det vil ikke blive behandlet yderligere her.
I mit konkrete tilfælde havde jeg altså et mismatch i data, som ikke udelukkende kunne forklares med annulleringer, refunderinger eller fejlagtig tracking. Jeg satte mig derfor ned med transaktionsudskrifter fra henholdsvis Google Analytics og Prestashop, som dækkede den samme tidsmæssige periode. Efter ganske kort tid fandt jeg en transaktion i Google Analytics, som ikke stod i Prestashop. Den var valid og omsætningstallet passede med det, som blev oplyst i Prestashop.
Transaktion bestod af en masse garn, kundenavnet var reelt, alt harmonerede og virkede til at være i den fineste orden – bare en ikke transaktionsdatoen. I Google Analytics fremstod transaktionen til at være afgivet dags dato, men slog jeg den op i prestashop lå transaktionsdatoen en hel uge tidligere. Jeg kunne se, at lagerfolkene havde pakket og sendt garnet samme dag til kunden. Hvorfor havde Google Analytics så denne transaktion – der lå i uge tilbage i tiden – med i dagens omsætning?
Omsætning for den samme transaktion registreres flere gange på forskellige datoer
For at komme nærmere til problemets kerne, undersøgte jeg dataene for den konkrete transaktion i Google Analytics. Jeg åbnede siden med oversigten over registrerede transaktioner: Konverteringer > E-handel > Salgseffektivitet og søgte efter mit problemfyldte transaktions-id ved at klikke på avanceret (ved siden af søgefeltet), og indtaste det respektive transaktions-id. Det gav mig nedenstående skærmbillede:
Bemærk at omsætningsdata er blevet fjernet og fremgår derfor ikke på dette skærmbillede
Som det ses på ovenstående skærmdump, er der to registreringer for transaktions-id 10627 (se den blå kurve). Med andre ord tæller denne transaktion dobbelt i Google Analytics, og er dermed med til at pumpe omsætningen op.
For at identificere problemets omfang, oprettede jeg en tilpasset rapport. Du kan gøre det sammen ved at vælge Tilpasset i topmenuen og herefter trykke knappen +Ny tilpasset rapport. Rapporten skal se ud som den, jeg har lavet herunder:
Når du kører rapporten, skulle det gerne se sådan her ud. Husk at sortere efter kolonnen Transaktioner som faldende:
Bemærk at omsætningen er igen fjernet i mit eksempel
Du kan eventuelt klikke på avanceret og frasortere alle transaktions-id’er, hvor antallet af transaktioner er lig med 1, da disse jo er valide og dermed uinteressante. Det vil se sådan her ud:
Som det fremgår af min rapport er transaktion-id 8360 registreret hele 11 gange i Google Analytics, og der er adskillige andre transaktioner, som også er registreret rigtig mange gange. Ideelt skulle hver transaktion kun registreres 1 gang.
Hvad skyldes dette?
Helt konkret betyder dette, at trackingkoden for en bestemt transaktion bliver kaldet eller afviklet flere gange og endda over et stort tidsinterval – altså på forskellige datoer. Men hvorfor bliver den så det?
Det skyldes sandsynligvis, at kvitteringssiden bliver tilføjet til foretrukne (eller bookmarked) af en del af kunderne. Garn er langt fra forbeholdt det ældre segment, men en del af de ældre, som handler på nettet, køber meget af deres garn online og er altså solidt repræsenteret i vores kundegruppe. Og netop i dette segment, lader der til at være en tendens til at bookmarke kvitteringssiderne. Hvis kunden en uge senere klikker på sit bookmark-link og åbner kvitteringssiden, vil Google Analytics – såfremt det er uhensigtsmæssigt opsat i shopsystemet – registrere denne åbning og tilføje den til dagens omsætning.
Hvordan kan det løses?
Umiddelbart er løsningen lige til højrebenet. Når først koden til e-handelssporing for en transaktion er genereret, må det ikke kunne lade sig gøre, at shopsystemet producerer den igen – heller ikke når kvitteringssiden bliver genindlæst. Der skal være en funktion eller verificering, der holder øje med, om sporingskoden er blevet registreret og afleveret til brugeren, og er den det, så skal det ikke kunne lade sig gøre igen for det samme transaktions-id.
Jeg håber, indlægget kan tjene som inspiration. Med de konkrete rapporter har du mulighed for, at identificere omfanget af dobbelt tracking i din egen shop, og derfra selv tage bestik af situationen og eventuelt får korrigeret dit shopsystem i en mere hensigtsmæssig retning.
