Sådan sporer du tiden, der er gået mellem en brugers sessioner
Hele ideen og konceptet bag sessioner i Google Analytics er virkelig mærkeligt til tider. For det første udløber en session (som standard) helt af sig selv efter 30 minutters inaktivitet. Men den udløber også helt automatisk ved midnat. Eller hvis trafikkilden ændres - selv midt i en session (hvilket også er grunden til, at du aldrig må bruge UTM-tags internt på et site).
Som oftests, så er disse mærkværdigheder ikke årsag til nævneværdige problemer. Mest af alt, fordi tiden mellem returnerende brugeres sessioner ofte tælles i dage, uger eller endda måneder.
Fornyligt sad jeg dog i en situation med en kunde, der er en meget stor BtB-grossist. De har en webshop med lidt over 1 mio. produkter og mange af deres kunder er særdeles frekvente besøgende - mange af dem har mange sessioner hver dag. Så vi ville gerne forstå disse brugeres adfærd mere præcist. Ikke over uger og måneder, men helt ned på dagsniveau.
En del af analysen gik på at undersøge præcist hvor lang tid, der går mellem disse sessioner over en dag. Og hvornår der fx bliver lagt noget i kurven, og hvornår noget bliver købt. Målet er at kunne føde disse data ind i marketing automation-programmet eller at kunne lave segmenter og audiences til fx Google Ads og GDN.
Problemet er, at Google Analytics ikke er så velegnet til at måle tiden mellem to sessioner. Dimensionen Dage siden sidste session er ganske enkelt for upræcis i dette tilfælde. Der er ganske vist dimensioner med Dato, Time og Minut. Men de data skal behandles udenfor Google Analytics og kan ikke aktiveres så nemt.
Hvor vi gerne vil hen
Heldigvis kan jeg godt afsløre, at jeg fandt en metode, der med rimelighed netop lod mig spore den præcise tid, der er gået mellem sessioner. Faktisk endte jeg ud med denne type rapport (som bare viser de data, der kommer ind):
Jeg har fremhævet data for blot en enkelt bruger (eller retter, et enkelt Client ID) med to sessioner. Bemærk, at værdien for Time Since Last Session (som er min nye custom metric) er 00:00:00. Det er blot et udtryk for, at den session var den første session (nogensinde) fra det Client ID.
Til gengæld viser den anden session et tidsmål. Tiden - som min løsning måler - er faktisk den præcise tid målt i timer, minutter og sekunder, der er gået mellem denne sessions første (interaktions) hit og den forrige sessions sidste (interaktions) hit.
Med andre ord så vil den målte tid mellem to enkeltsidesbesøg uden andre interaktions-hits faktisk stemme overens med, hvad Google Analytics indirekte rapporterer i tidsdimensionerne. I dette konkrete tilfælde har GA registreret den første session den 2. maj 18:22 og den anden session den 3. maj 10:47. Det svarer til en forskel på 16 timer og 25 minutter.
Den målte tid (16 timer og 22 minutter) er lidt kortere tid end den faktiske tid mellem de to tidspunkter (som er 16 timer og 25 sekunder), men det er blot et udtryk for, at den første session ikke var et enkeltsidesbesøg og havde en omtrentlig sessionsvarighed på 3 minutter.
Se derudover denne variation af rapporten, hvor jeg har en anden (calculated) metric, som jeg har kaldt Average Time between Sessions:
Derfra bør det være nemt nok at forestille sig nogle interessante analyser. Kan vi fx finde nogle ensartede mønstre? Og kan vi identificere nogle segmenter, som vi kan bruge til retargeting eller i marketing automation? Naturligvis bør disse data kombineres med andre metrics; fx med produktvisninger, tilføjelser til kurv og påbegyndelse af checkout - og køb.
Sådan måles den præcise tid mellem sessioner
Løsningen er faktisk relativt simpel, da den i praksis bare beregner tiden mellem to tidsstempler. Der er dog nogle få minimumskrav for at få de bedst mulige data:
- Custom Dimension med Client ID’et
- Custom Dimension med et Session ID
Begge er hurtige at sætte op, hvis du følger Simo Ahava’s guide til at sætte nogle nyttige custom dimensions op. Faktisk har jeg skrevet løsningen som en custom task og har i den forbindelse skamløst kopieret Simo Ahava’s JavaScript-syntaks, som han bruger i sin Custom Task Builder.
Det er ikke så meget, fordi jeg er doven (det er jeg og derfor automatiserer jeg også alting), men fordi det derfor vil være nemmere for dig at implementere løsningen, hvis du allerede har brugt hans fantastiske værktøj. Det er der (forhåbentlig) mange, der gør.
Sådan sættes det op
I denne artikel antager jeg dog - for simplicitetens skyld - at du ikke allerede har en custom task sat op. Hvis du har, så bør du nemt kunne se, hvilke linier kode, du skal bruge og hvor de skal sættes ind.
Anyways, følg blot disse trin i Google Analytics:
- Tilføj en
Tilpasset metric
af typenTid
og navngiv denTime Since Last Session
- Tilføj en
Beregnet metric
af typenTid
og navngiv deneAvg. Time between Sessions
- Indtast formlen for den beregned metric:
{{Time Since Last Session}} / {{Sessioner}}
Åbn derefter Google Tag Manager:
- Tilføj en
Variabel
af typenTilpasset JavaScript
og navngiv denCustom Tasks
- Kopier og indsæt den nedenstående kode ind i variablen
- Rediger værdien af variablen
timeSinceLastSessionIndex
, så den svarer til det index, som din tilpassede metric fik tildelt ved oprettelse - Hvis du manuelt har ændret din session timeout i Google Analytics, skal du også redigere værdien for variablen
sessionTimeout
fra 30 minutter til din egen indstilling (i minutter) - Åbn din variabel for Google Analytics-indstillinger (eller dit primære pageview tag) og tilføj feltet (under
Felter, der skal angives
)customTask
og sæt værdien til{{Custom Tasks}}
Det er faktisk det hele. Og her er den kode, der skal indsættes:
function() { var timeSinceLastSessionIndex = 5; var globalSendHitTaskName = '_ga_originalSendHitTask'; return function (customTaskModel) { window[globalSendHitTaskName] = window[globalSendHitTaskName] || customTaskModel.get('sendHitTask'); var tempFieldObject, dimensionIndex, count, ga, tracker, decorateTimer, decorateIframe, iframe; // timeSinceLastSessionIndex var ni = (customTaskModel.get('nonInteraction') === true) ? true : false; if (typeof timeSinceLastSessionIndex === 'number' && ni === false) { var sessionTimeout = 30; // minutes sessionTimeout = sessionTimeout * 60 * 1000; // milliseconds var lastSession = window.localStorage.getItem("lastSession"); var dateNow = new Date(); var timeNow = dateNow.getTime(); // milliseconds var elapsed = (lastSession == undefined) ? 0 : (timeNow - lastSession); // milliseconds var time = undefined; window.localStorage.setItem('lastSession', timeNow); if (elapsed > sessionTimeout) { time = elapsed / 1000; // seconds } customTaskModel.set('metric' + timeSinceLastSessionIndex, time); } // /timeSinceLastSessionIndex customTaskModel.set('sendHitTask', function (sendHitTaskModel) { var originalSendHitTaskModel = sendHitTaskModel, originalSendHitTask = window[globalSendHitTaskName]; var hitPayload, hitPayloadParts, param, val, regexI, trackingId, snowplowVendor, snowplowVersion, snowplowPath, request, originalTrackingId, hitType, nonInteraction, d; try { originalSendHitTask(sendHitTaskModel); } catch (e) { originalSendHitTask(originalSendHitTaskModel); } }); }; }
Hvordan det virker
For det første starter scriptet med at finde ud af, om det aktuelle hit er et interaktions-hit eller ej. Scriptet fortsætter kun, hvis det netop er et interaktions-hit.
Dernæst findes det sidste tidsstempel, som er gemt (og løbende opdateret) i localStorage. Mest for at undgå cookies. Der vil ikke være et tidsstempel for nye brugere, men det er også helt i orden, da vi ikke kan/skal beregne tiden for en førstegangsbesøgende. Men ellers beregnes tidsforskellen mellem det tidsstempel og tiden lige nu. Og hvis den tidsforskel overstiger indstillingen for sessions-udløb, så sendes forskellen med hit’et til Google Analytics.
Ulemper
Som nævnt, så er sessioner i Google Analytics altså lidt mærkelige. Og det går også udover denne løsning. For eksempel er det ganske enkelt ikke muligt at undersøge, hvorvidt et hit starter en ny session - fx på baggrund af, at kampagnekilden ændres midt i sessionen. Tak til @AnalyticsNinja for lige at påpege det.
På den anden side kan det godt være, at Google Analytics starter en ny session, når kilden ændres midt i sessionen. Men fra et brugerperspektiv, så er det vel reelt ikke en ny session? På samme måde kan man også diskutere, hvorvidt der er tale om en ny session (fra et brugerperspektiv), hvis brugeren fx åbner sitet om morgenen, lader sitet stå i en fane det meste af dagen, og fortsætter om aftenen? Er det virkelig en ny session?
Pointen er blot, at jeg godt kan leve med den lille ulempe, at løsningens eneste kriterie er sessionens standard-udløb og at den ikke tager højde for de øvrige mærkværdigheder.
Men jeg lytter gerne til feedback i kommentarer eller på @phillipvs.