Fire grunner til at du ser (not set) i Google Analytics

15.08.24


5 minutter

Når Google Analytics 4 forteller deg at din største trafikkilde er (not set), føler du deg kanskje ikke noe særlig klokere. La oss fikse problemet!

Se for deg at du har brukt hele forrige måneds markedsbudsjett på en splitter ny kampanje. Du skal inn i Google Analytics 4 for å sjekke hvordan kampanjen har gått og hvilke av kanalene du valgte som gjorde det best. (Not set) møter deg som den øverste kilden til trafikk. 

(Not set) står for over 60 % av omsetningen i kampanjeperioden.

Det er rett og slett ingenting som er mer irriterende enn å ha brukt en hel måneds markedsbudsjett på en splitter ny kampanje og så kan du ikke engang se hvilken kanal som ga mest inntekt.

Dessverre får man ikke gjort noe med dataen som allerede er samlet inn, men du kan heldigvis gjøre noe med fremtidig data slik at fremtidige kampanjer kan spores og  analyseres.

Grunn 1: Ikke prosessert data

Den aller vanligste grunnen til (not set) trafikk i kilde-/medium-rapporten er egentlig ganske enkel. Google Analytics 4 bruker opp mot 48 timer på å prosessere all dataen den samler inn. Derfor vil den ikke alltid kunne vise korrekt data hvis du ser på data fra de siste 48 timene. 

Hvordan fikser jeg dette?

Løsningen for dette problemet er ganske enkel. Vent 48 timer etter at dataen er samlet inn før du begynner å analysere. Har kampanjen gått i hele juli, venter du til 3. august med å analysere dataen.

Grunn 2: Feil i UTM-haler

Kanskje den nest vanligste grunnen til (not set) trafikk i kilde-/medium-rapporten er feil i UTM-haler. UTM-haler brukes for å styre kilde, medium, kampanje, innhold og flere andre parametere. Det gjør det enklere å differensiere hvilke brukere (inkludert kjøp og andre konverteringer) som kommer fra hvilken kanal og enda mer spesifikt hvilken annonse.

Et eksempel på en feil i UTM-haler kan være at det er brukt bindestrek (-) i stedet for understrek (_). Da vil GA4 ikke klare å lese UTM-halen korrekt og legge trafikk som (not set).

Hvordan fikser jeg dette?

Dobbeltsjekk alle UTM-haler som brukes og sjekk at disse følger riktig format og standard. Les mer om hvordan du selv setter opp riktige UTM-haler i dette blogginnlegget.

Grunn 3: Event-tagger kjører før Config-taggen

I GA4 er det viktig at alle eventer som skjer på nettsiden kommer i riktig rekkefølge. Config-taggen som blant annet inneholder eventer som first_visit, session_start, pageview osv. skal fyres av først. Det er i config-taggen kilde/medium blir samlet inn til GA4.

Videre skal alle andre eventer som skjer på en side sendes etter config-taggen. For eksempel innsending av kontaktskjema eller fullføring av et kjøp.

Hvis disse eventene blir sendt før config-taggen, vil ikke Google Analytics 4 klare å identifisere eventene og plassere dem i riktig økt. Det vil føre til at eventer sendt før config-taggen blir liggende uten en kilde/medium og eventer sendt etter config-taggen blir tildelt riktig kilde/medium.

Dette er ofte vanlig på netthandelssider som sender eventer som view_item, view_cart begin_checkout på automatikk når henholdsvis et produkt vises, handlekurven åpnes og utsjekking starter.

Hvordan fikser jeg dette?

Det finnes flere måter å fikse dette på som avhenger av måten GA4 er implementert på. GA4 kan implementeres gjennom Google Tag Manager eller direkte i kildekoden.

Google Tag Manager:

  1. Åpne “Forhåndsvisning”-modus og undersøk hva som fyres først. 
  2. Se hvilke trigger som brukes til GA4-config tag og event-tagger. Er triggeren til event-taggene før triggeren til GA4-config-taggen må dette endres.
  3. Endre GA4-config taggen en trigger som kjører først på hver sidelasting. Dette kan f.eks være “Initialization - All Pages”-triggeren.
  4. Test i “Forhåndsvisning”-modus igjen og sjekket at triggeren til GA4-config taggen er før triggerne for event-tagger.

Direkte i kildekoden (Her trenger du kanskje hjelp av en utvikler):

  1. Undersøk hvor GA4-config koden ligger på nettsiden sin kildekode. Denne skal ligge rett etter “<head>” på hver side.
  2. Gjør den ikke det, bør denne flyttes til øverst i “<head>”. Dette fordi dette er det første som lastes på nettsiden.
  3. Sørg for at GA4-event koder ligger etter GA4-config koden på hver side.

Grunn 4: Feilkonfigurasjon i serverside-parameteret

Denne siste grunnen er litt mer komplisert enn de 3 foregående grunnene, nemlig fordi det innebærer at det er konfigurert serversidesporing. Serversidesporing innebærer oppsett av en clientside Google Tag Manager som sender data til en serverside Google Tag Manager som igjen sender dataen til Google Analytics sine servere. Her må man altså ha tunga rett i munnen når alt settes opp. Glemmer man en liten ting kan det ha stor påvirkning på dataen du til slutt ser i Google Analytics 4.

Grunnen til (not set ) i kilde/medium-rapporten her ligger i oppsettet av eventer i clientside Google Tag Manageren. Alle eventer og config-tagger må konfigureres med et parameter som forteller at eventet skal sendes til serverside Google Tag Manageren.

Det betyr at hvis dette glemmes kun for 1 av 100 eventer, vil dette ene eventet sende data direkte til GA4 og ikke til GA4 via serverside GTM. Dette vil kunne føre til at eventene ikke ankommer GA4 i riktig rekkefølge og at GA4 ikke klarer å tildele riktig kilde/medium til dette eventet.

Hvordan fikser jeg dette?

Det er egentlig ikke så komplisert å fikse. Her må du gjennomgå alle GA4-tagger (eventer og config) som sender data i serverside Google Tag Manager og dobbeltsjekke at de inneholder event parameteret “server_container_url”. Verdien av parameteret må være URL-en til serverside Google Tag Manageren din.

Eksempelvis:

Vi hjelper deg

Det finnes fortsatt utallige grunner til at (not set) kan dukke opp i rapportene dine i Google Analytics 4, men dette var noen av de vanligste og et par litt mer spesifikke. Hvis du fortsatt har (not set) i dine rapporter kan du ta kontakt med oss så hjelper vi deg med å finne kjernen til ditt problem!

På utkikk etter mer lesestoff?

Meld deg på vårt nyhetsbrev
 
Alle rettigheter reservert 2024