Rekommenderade metoder för taggning för att undvika problem med otilldelad trafik, (not set) och direkt trafik

Google Analytics-taggar har flera konfigurationsalternativ som kan påverka sessions- och användaridentitet. Om de inte är korrekt konfigurerade kan det leda till att trafikkällor inte kan identifieras eller kategoriseras och till andra problem i rapporterna. Med rätt konfiguration kan du skapa korrekta rapporter och förhindra att rader i rapporternas kanalgrupper inte tilldelas, värden av typen (not set) och att en oväntat stor del av trafiken kategoriseras som direkt.

Raden Inte tilldelad visas i Google Analytics-rapporter när Analytics inte kan kategorisera trafikkällan. Analytics kategoriserar trafikkällor i kanaler baserat på fasta regler. Kanalen Organisk sökning inkluderar till exempel trafik från alla sökmotorer. Kanalerna är ordnade i kanalgrupper. Om du använder standardkanalgrupperna kan du granska den specifika logiken som kategoriserar trafik i Standardkanaldefinitioner. Kanalgrupper kan visas på användar-, sessions- eller händelsenivå.

När en trafikkälla inte passar in i definitionen av någon av kanalerna i en kanalgrupp som du visar i en rapport visas den som Inte tilldelad. Det kanske inte finns någon fördefinierad regel för att kategorisera en trafikkälla om trafiken kommer från en användardefinierad källa eller ett användardefinierat medium eller om den anges som (not set) för att information om session eller användaridentitet saknas.

Rekommenderade metoder för taggkodsordning

Följ de här tipsen för taggkodsordning:

Taggtyp	Anvisningar	Bästa metoder
Google-tagg	Konfigurera Google-produkter och skicka händelsedata	Initiera Google-taggen innan du anropar en händelsemetod, inklusive målgruppsutlösta händelser.
Google Taggstyrning	Ställa in Google Taggstyrning Google Taggstyrning för webbsidor Om Google Taggstyrning	Följ de här fyra stegen för att konfigurera GTM
Taggning på serversidan	På serversidan – Taggstyrning	Se till att du inte hoppar över dessa specifika tagginställningar. Du bör inte ha både en implementering på serversidan och en fristående implementering på klientsidan på samma sida för samma Google Analytics-egendom. Om du använder sGTM ska du se till att alla aktiva taggar är konfigurerade för att skicka händelser via behållaren på serversidan.

Om du inte kan följa den rekommenderade ordningen för händelser bör du ändå följa dessa två rekommendationer. Om du inte gör det kan det uppstå problem med rapporteringen.

• Utför all relevant konfiguration för sidan som en del av kommandot config (för Google-taggen) eller i inställningarna för Google-taggen (för Google Taggstyrning) så tidigt som möjligt på sidan och före eventuella händelser.
• Undvik att aktivera anpassade händelser före kommandot config, annars läggs de till i en grupp med händelsen session_start. Kommandot config kan påverka användar- och sessionsidentiteten för resten av sidan. Det innebär att sidvisningen och senare händelser inte kan kopplas till den tidigare sessionsstarten och den anpassade händelsen.

Vad händer om mina händelser inte är ordnade korrekt?

När Google Analytics-taggar ställs in vid oväntade tidpunkter kan det påverka användar-id, sessions-id eller båda. Om kommandot config eller Google-taggen till exempel aktiveras efter andra händelser på sidan kan det leda till felaktiga rapporter. Detta kan leda till

• att data visas som (not set) i Analytics
• felaktiga användar- och sessionsantal
• att mätvärden på användar- och sessionsnivå inte beräknas på rätt sätt
• felaktig användar- och sessionsmätning.

Vad kan få händelserna att ordnas felaktigt?

Vanliga orsaker till oväntad tidsordning är:

Funktion	Orsak	Resultat	Bästa metoder
Taggning på serversidan Serverhanterad inställning (serverhanterat klient-id) Inställningar som hanteras av klienten (transport_url, first_party_collection, server_container_url)	Markera rutan för taggning på serversidan för Serverhanterad inställning. Den är markerad som standard. När Google Analytics-händelser behandlas via en servertagg har användarna ett antal olika alternativ för att använda en annan användaridentitet än det kund-id som används av webbtaggen.	Om du väljer Serverhantering i rullgardinsmenyn högst upp hanterar taggning på serversidan ett separat klient-id och ersätter det för de mätningar som bearbetas. Det finns även flera alternativ för hur cookien skrivs och ett alternativ för migrering över tid för kunder som har befintlig GA-direkttrafik och inte vill ha en skarp avbrott i målgrupper och rapporter genom att plötsligt ändra alla besökares id:n samtidigt.	Om du använder detta alternativ måste du se till att alla mätningar för din stream flödar genom din servertagg och att inga skickas direkt till Googles servrar. Det enklaste sättet att göra detta är att se till att Google Taggstyrning- eller config-kommandot (Google-taggen) för webbtaggen som skickar data till serverbehållaren alltid är den första taggen eller det första kommandot för behållaren.
Anpassning av cookienamn (cookie_prefix)	Detta ändrar namnet på förstapartscookien som används för både klient-id och sessionsstatus.	Användare kan inte kopplas samman mellan sessioner och händelser kan inte inkluderas i sessioner. Händelsemätvärden visas som (not set) när de analyseras med sessions- eller användardimensioner.	Använd samma cookieprefix på hela webbplatsen. Vi rekommenderar att du använder cookieprefixet i Analytics för att skapa ett anpassat namn på en cookie, inte för att skapa flera olika cookiesilor, vilket är vad som händer om du använder olika eller inkonsekventa prefix.
Automatisk länkning över flera domäner (linker)1	Denna inställning anger att taggen ska bearbeta och börja använda klient- och sessionsdata från föregående sida, om en sådan finns. När den länkade datan används förutsätter taggen att sessionen redan har startats på föregående sida.	Om linkern initieras sent och upptäcker en användare som är länkad över flera domäner via ett sent konfigurationskommando ändras användaridentiteten plötsligt vid det tillfället. Sena konfigurationskommandon resulterar som ett minimum i korta sessioner som kasseras när värdena för länkarparametern används. Eventuella sessions- eller användarattribut som redan har skickats vid den tidpunkten kan inte längre kopplas till den verkliga sessionen eller användaren.	Anpassa inte klient- eller sessions-id eftersom det leder till felaktiga antaganden i både taggar och behandling om hur sessioner ska struktureras. Det kan även leda till problem.
Manuell domänlänkare (client_id, session_id)	För att kunderna ska kunna implementera mätning över flera domäner manuellt har Google Analytics-taggen API:er för att hämta och ange både klient- och sessions-id:n. Om du av misstag ändrar client_id eller session_id från deras automatiskt genererade värden påverkar det hur Google Analytics-händelser kopplas till användare och sessioner.	Händelser som är frikopplade från sina ursprungliga klient- och sessions-id:n kan sakna viktig information och orsaka oväntade attributionsproblem.	Använd user_id för att ange en anpassad användaridentitet. Använd inte dessa API:er för att modifiera eller tillhandahålla anpassade klient- eller sessions-id:n. Dessa id:n ska endast anges manuellt i sällsynta fall när manuell konfiguration över flera domäner krävs.

¹ linker är parametern från den automatiska länkningen över flera domäner. Det finns ett alternativ för att ange klient-id och sessions-id manuellt om automatisk länkning över flera domäner inte fungerar för din webbplats. Anpassa aldrig dessa värden. Google Analytics förväntar sig värden i ett visst format, och oväntade värden kan leda till fel. Läs mer om länkarparametern.