Händelser i GA4: planera vad du ska mäta
Händelser i GA4 visar vad besökarna gör på webbplatsen, från sidvisningar till köp och förfrågningar. Händelsenamnet beskriver handlingen och parametrarna ger mer information, till exempel vilket formulär som användes. Planera båda delarna så att uppgifterna går att använda i rapporterna.
Det är lätt att samla in mycket och ändå sakna svaret på en enkel fråga. Om tre formulär skickar samma otydliga händelse utan formulär-ID kan ni exempelvis se att något hände men inte vilken kontaktväg som fungerade.
Vad ska du spåra i GA4?
Google skiljer mellan automatiskt insamlade händelser, förbättrad mätning, rekommenderade händelser och egna händelser. Börja med att kontrollera vad som redan samlas in. Välj ett rekommenderat namn när det beskriver handlingen, i stället för att hitta på en egen variant av samma sak.
| Behov | Exempel | Vad behöver definieras? |
|---|---|---|
| Följa köp | purchase | Transaktion, belopp, valuta och varor |
| Följa en förfrågan | generate_lead | När förfrågan räknas som mottagen |
| Följa en särskild funktion | Eget tydligt namn | Handling och avsedd analys |
Kontrollera vilka parametrar Google kräver och rekommenderar för händelsen. Ett köp behöver exempelvis mer information än bara händelsenamnet.
Skilj händelsen från dess egenskaper
Händelsen beskriver vad som skedde. Parametrar beskriver sammanhanget. Om en offertförfrågan skickas kan ni behöva ett formulär-ID eller en tjänstekategori. Använd inte besökarens fritextmeddelande som en praktisk genväg för att få mer detaljer.
En parameter som samlas in behöver inte automatiskt finnas som en valbar dimension i alla rapporter. Planera därför både insamlingen och hur uppgiften ska användas. Undvik hög detaljnivå som ger mängder av unika värden utan att hjälpa något beslut.
Dokumentera händelserna
- Namn och syfte.
- Vilken handling som utlöser händelsen.
- Parametrar och förväntade värden.
- Vilka rapporter som ska använda den.
- Om händelsen är ett viktigt affärsresultat.
- Ansvarig och datum för senaste kontroll.
Anta att ni vill jämföra två kontaktformulär. Använd samma händelse för lyckade inskick och en parameter som skiljer formulären åt. Då kan samma typ av handling jämföras utan att ni skapar nya namn för varje sida. Kontrollera att formulärfelet inte skickar samma händelse.
Arbetsgång: bygg en händelse som går att analysera
Här använder vi en lyckad offertförfrågan som exempel. Målet är att kunna jämföra olika tjänstekategorier utan att skapa ett nytt händelsenamn för varje formulär eller sida. Du behöver tillgång till webbplatsens implementation, GTM om det används och redigerarbehörighet i rätt GA4-egendom för egna definitioner.
1. Kontrollera vad som redan samlas in
Testa formuläret och granska Tag Assistant och DebugView innan du lägger till något. Förbättrad mätning kan redan skicka formulärrelaterade händelser, men en sådan signal ska inte utan test likställas med en mottagen affärsförfrågan. Dokumentera vilka befintliga händelser som är användbara och vilka som svarar på en annan fråga.
Välj det rekommenderade namnet generate_lead när det motsvarar handlingen. Kontrollera Googles lista för andra behov, exempelvis purchase för köp. Använd egna namn när det saknas en passande rekommenderad händelse, och behåll konsekvent stavning.
2. Definiera parametrar och tillåtna värden
För samma typ av förfrågan kan form_id identifiera kontaktvägen och den egna parametern service_category skilja exempelvis seo från google_ads. Använd en kort bestämd värdelista. Ett fält med obegränsad fritext skapar både onödig detaljrikedom och risk att fel uppgifter hamnar i mätningen.
Bestäm också när ett fält ska vara tomt och om en händelse med saknade nyckeluppgifter ska stoppas eller hanteras separat. Skapa inte ett enda generellt event som samlar allt från lästa artiklar till vunna affärer. Då blir även ett tekniskt korrekt antal svårt att tolka.
3. Skicka och verifiera händelsen
I ett GTM-upplägg kan webbplatsen först skicka den interna signalen lead_success via datalayer. En anpassad utlösare aktiverar sedan GA4-händelsetaggen generate_lead, där parametrarna hämtas från datalagervariabler. Se kodexemplet och datalagrets överenskommelse.
Testa en lyckad inskickning i DebugView och öppna just den händelsen. Kontrollera stavning, antal och parametervärden. Testa därefter ett valideringsfel och en omladdning. Testa med det riktiga formuläret. En händelse som skickas manuellt från webbläsarkonsolen visar bara att taggen kan ta emot den.
4. Gör den egna parametern till en rapportdimension
Kontrollera först om det redan finns en färdig dimension för uppgiften. För den egna parametern service_category går du i GA4 till Administratör → Datavisning → Anpassade definitioner. Välj fliken för anpassade dimensioner och skapa en dimension.
- Namn: ett begripligt rapportnamn, exempelvis ”Tjänstekategori”.
- Omfattning: händelse, eftersom värdet hör till just denna handling.
- Händelseparameter: exakt
service_category, som den skickas av taggen. - Beskrivning: vad värdena betyder och var de kommer ifrån.
Efter att dimensionen skapats och nya uppgifter samlats in behöver data bearbetas innan de kan användas i rapporterna. Google anger att det normalt tar 24 till 48 timmar innan uppgifterna kan användas i rapporterna. Dimensionen fyller inte på tidigare historik.
5. Bygg och kontrollera analysen
Skapa en fri utforskning i Utforska. Importera dimensionerna Händelsenamn och Tjänstekategori samt mätvärdet Händelseantal. Lägg Tjänstekategori på rader, Händelseantal som värde och ett filter för generate_lead. Välj en period efter att dimensionen började fungera.
Kontrollera tabellen mot de testfall och faktiska förfrågningar som går att stämma av. ”(not set)” kan bero på att parametern saknats, fått fel namn eller ännu inte är tillgänglig för perioden. Tjugo händelser betyder inte automatiskt tjugo unika personer eller kvalificerade leads. Skriv i rapporten vad ni räknar som en förfrågan.
Markera inte allt som viktigt
En viktig händelse i GA4 ska representera något som verksamheten särskilt vill följa. Om nästan varje sidbesök omedelbart innehåller en sådan händelse blir flera analyser mindre meningsfulla. Det kan också påverka hur avvisningsfrekvensen ska tolkas.
Bestäm separat om händelsen ska användas som konvertering i Google Ads. Ett beteende kan vara användbart för analys utan att vara ett lämpligt mål för budgivning. Läs mer om konverteringsspårning när systemen kopplas ihop.
Kontrollera mätningen före publicering
Testa namn, antal och parametrar i DebugView. Kontrollera sedan hur uppgifterna syns i den avsedda rapporten efter bearbetning. Jämför köp med ordersystemet och leads med faktiska mottagna förfrågningar. En dokumenterad testhandling är ett bättre underlag än att bara konstatera att händelsen förekommer någonstans i gränssnittet.
Läs även Googles guide till händelseparametrar för fält och installationsdetaljer.
Källor och dokumentation
”*” anger obligatoriska fält
