[GA4] Anbefalte fremgangsmåter for tagging for å unngå problemer med ikke-tilordnet trafikk, (not set)-verdier og direkte trafikk

Google Analytics 4-tagger har flere konfigurasjonsalternativer som kan påvirke økt- og brukeridentitet. Hvis de ikke er riktig konfigurert, kan det føre til at trafikkilder ikke kan identifiseres eller kategoriseres, og andre problemer i rapporter. Disse problemene fører til at det opprettes «Ikke tilordnet»-rader i kanalgrupper i rapporter, (not set)-verdier og en uventet høy andel av trafikk som kategoriseres som direkte.

I Google Analytics 4-rapporter vises «Ikke tilordnet»-raden når Analytics ikke kan kategorisere kilden til trafikken. Analytics kategoriserer trafikkilder i kanaler basert på faste regler. Kanalen for organisk søk omfatter for eksempel trafikk fra alle søkemotorer. Kanaler er organisert i kanalgrupper. Hvis du bruker standardkanalgruppene, finner du den spesifikke logikken for kategorisering av trafikk i definisjonene av standardkanaler. Kanalgrupper kan ses på bruker-, økt- eller hendelsesnivå.

Når en trafikkilde ikke passer til definisjonen av en av kanalene i en kanalgruppe du ser på i en rapport, vises den som «Ikke tilordnet». Det finnes kanskje ingen forhåndsdefinert regel for å kategorisere en trafikkilde hvis trafikken kommer fra en brukerdefinert kilde eller et brukerdefinert medium, eller hvis den er «(not set)» fordi det mangler informasjon om økten eller brukeridentiteten.

Anbefalte fremgangsmåter for rekkefølgen på tagkode

Følg disse anbefalte fremgangsmåtene for rekkefølgen på tagkode:

Tagtype Veiledning Anbefalte fremgangsmåter

Google-taggen

Konfigurer Google-produkter, og send hendelsesdata

Initialiser Google-taggen før du kaller en hendelsesmetode, inkludert hendelser med utløsere for målgruppe.

Google Tag Manager

Konfigurer Google Tag Manager

Google Tag Manager for nettsider

Om Google Tag Manager

Følg de 4 trinnene for å konfigurere GTM

Tagging på tjenersiden

På tjenersiden – Tag Manager

Ikke glem å angi disse spesifikke taginnstillingene.

Du bør ikke ha både en implementering på tjenersiden og en frittstående implementering på klientsiden på den samme siden for det samme GA4-området. Hvis du bruker sGTM, må du påse at alle de aktive taggene dine er konfigurert til å sende hendelser via beholderen på tjenersiden.

Hvis du ikke kan følge den anbefalte rekkefølgen på hendelser, bør du likevel følge disse to anbefalingene. Hvis ikke kan du forvente problemer med rapporteringen.

  • Oppgi all relevant konfigurasjon for siden som en del av config-kommandoen (for Google-taggen) eller innstillingene for Google-taggen (for Google Tag Manager) så tidlig som mulig på siden og før eventuelle hendelser.
  • Egendefinerte hendelser må ikke utløses før config-kommandoen, ellers blir de samlet i samme gruppe som session_start-hendelsen. config-kommandoen kan påvirke bruker- og øktidentiteten for resten av siden, noe som betyr at sidevisningen og påfølgende hendelser ikke kan knyttes til den tidligere øktstarten og den egendefinerte hendelsen.

Hva skjer hvis hendelsene ikke kommer i riktig rekkefølge?

Når GA4-tagger angis på uventede tidspunkter, for eksempel hvis «config»-kommandoen eller Google-taggen utløses etter andre hendelser på siden, kan det påvirke User-ID-en, økt-ID-en eller begge deler. Dette kan føre til

  • at data vises som «(not set)» i Analytics
  • feil telling av brukere og økter
  • at beregninger på bruker- og øktnivå ikke beregnes på riktig måte
  • feil måling av brukere og økter

Hva kan føre til at hendelser kommer i feil rekkefølge?

Her er noen vanlige årsaker til uventede rekkefølger:

Funksjon Årsak Resultat Anbefalte fremgangsmåter

Tagging på tjenersiden

Innstilling som administreres på tjenersiden (tjeneradministrert klient-ID)

Innstillinger som administreres på klientsiden
(transport_url, first_party_collection, server_container_url)

Det er merket av for «Innstilling som administreres på tjenersiden» i avmerkingsboksen for tagging på tjenersiden. Dette er slått på som standard.

Når GA4-hendelser behandles via en tag på tjenersiden, har brukere en rekke alternativer for å bruke en annen brukeridentitet enn klient-ID-en fra nettaggen.

Hvis du velger «Tjeneradministrert» i rullegardinmenyen øverst, betyr det at taggingen på tjenersiden administrerer en separat klient-ID og bruker den til målinger den behandler. Dette gjør det også mulig å velge hvordan informasjonskapselen skal skrives, og kunder med eksisterende direkte GA-trafikk kan overføre den over tid hvis de ikke ønsker et skarpt skille i målgrupper og rapporter ved å endre alle de besøkendes ID-er på én gang.

Hvis du bruker dette alternativet, må du sørge for at all måling av datastrømmen går via tjenertaggen, og at ingen data sendes direkte til Googles tjenere.

Den enkleste måten å gjøre dette på er å sørge for at Google Tag Manager- eller «config»-kommandoen (Google-taggen) for nettaggen som sender data til tjenerbeholderen, alltid er den første taggen eller kommandoen for den aktuelle beholderen.

Tilpasning av navn på informasjonskapsler
(cookie_prefix)

Denne funksjonen endrer navnet på informasjonskapselen fra førsteparten, som brukes til både klient-ID og øktstatus.

Brukere kan ikke følges gjennom flere økter, og hendelser kan ikke tas med i økter.

Hendelsesberegninger vises som «(not set)» når de analyseres sammen med økt- eller brukerdimensjoner.

Bruk samme prefiks for informasjonskapsler på hele nettstedet. Den anbefalte bruken av prefikset for informasjonskapsler i Analytics er å opprette tilpassede navn på informasjonskapslene, ikke å opprette flere atskilte grupper av informasjonskapsler, som er resultatet hvis du bruker ulike eller inkonsekvente prefikser.

Automatisk sporing over flere domener
(linker)1

Denne innstillingen fører til at taggen behandler og begynner å bruke klient- og øktdata fra den forrige siden hvis disse er tilgjengelige. Når disse sporede dataene tas i bruk for taggen, antas det at økten allerede er startet på den forrige siden.

Hvis sporeren blir initialisert sent og får informasjon om en bruker som spores på tvers av domener, via en sen «config»-kommando, endres brukeridentiteten plutselig på det tidspunktet.

Sene «config»-kommandoer fører som et minimum til korte økter som forkastes når parameterverdiene for sporeren tas i bruk. Eventuelle økt- eller brukerattributter som allerede er sendt på det tidspunktet, kan ikke lenger knyttes til den faktiske økten eller brukeren.

Ikke gjør tilpasninger i klient- eller økt-ID. Det fører til feil antakelser i både tagger og databehandling om hvordan øktene er strukturert, og det kan også føre til problemer.

Manuell sporing over flere domener
(client_id, session_id)

For at kunder skal kunne implementere måling av flere domener manuelt, har GA4-taggen API-er for å hente og angi både klient- og økt-ID-er. Hvis du utilsiktet endrer client_id og session_id fra de automatisk genererte verdiene, påvirker det hvordan GA4-hendelser knyttes til brukere og økter.

Hendelser som er skilt fra de opprinnelige klient- og økt-ID-ene, kan mangle viktig informasjon og føre til uventede attribusjonsproblemer.

Bruk user_id for å oppgi en egendefinert brukeridentitet.

Ikke bruk disse API-ene til å endre eller oppgi egendefinerte klient- eller økt-ID-er. Disse ID-ene skal bare angis manuelt i sjeldne tilfeller der manuell konfigurering av flere domener er nødvendig.

 

1 «linker» er parameteren fra automatisk sporing over flere domener. Du kan velge å angi klient-ID og økt-ID manuelt hvis automatisk sporing over flere domener ikke fungerer på nettstedet ditt. Du må aldri tilpasse disse verdiene. GA4 forventer at verdiene skal ha et bestemt format, og uventede verdier kan føre til feil. Finn ut mer om «linker»-parameteren.

Var dette nyttig for deg?

Hvordan kan vi forbedre den?
Søk
Slett søket
Lukk søkefunksjonen
Hovedmeny
12949835193285687714
true
Søk i brukerstøtte
true
true
true
true
true
69256
false
false
false
false