DebugView i GA4: kontrollera att händelser kommer fram

DebugView visar händelser och parametrar som GA4 tar emot från en enhet i felsökningsläge. Där kan du följa ett formulärinskick eller ett köp steg för steg och kontrollera namn, antal och värden. Anslut din testenhet via Tag Assistant och utför sedan handlingen på webbplatsen.

Vyn visar händelser och deras uppgifter nära insamlingstillfället. Du behöver aktivera felsökningsläget och välja rätt enhet. Det är enklare att följa ett eget test än att försöka hitta rätt bland många personers samtidiga aktivitet.

Följ ett formulärtest i DebugView

Förbered rätt GA4-egendom, webbström och ett formulär som går att testa. Anteckna förväntat händelsenamn och parametrar. I exemplet ska ett lyckat inskick ge en generate_lead med form_id=kontakt, medan ett felaktigt inskick inte ska ge samma framgångshändelse. Kontrollera att webbplatsens mätning är inställd för det beteendet.

Anslut din testenhet

Öppna rätt webbbehållare i Google Tag Manager och välj Förhandsgranska. I Tag Assistant anger du webbplatsens adress och väljer att ansluta. Behåll den anslutna webbläsarsidan öppen när du testar. Om mätningen inte använder GTM kan du ansluta via Tag Assistant enligt Googles guide för felsökningsläge.

Gå sedan till GA4 → Administratör → Datavisning → DebugView. Välj din enhet i enhetsväljaren om fler testare är aktiva. Utför handlingen på den anslutna webbplatsen, inte i en annan webbläsarprofil. Det minskar risken att du läser någon annans händelser.

Läs tidslinjen och öppna själva händelsen

Mittvyn visar händelser från den senaste minuten. Minutvyn ger en längre överblick över den senaste halvtimmen. Välj testets tidpunkt och öppna generate_lead. Kontrollera att form_id har värdet kontakt och att inga oväntade uppgifter skickats med.

Gör en ny testhandling först när du har kunnat skilja den första från övrig aktivitet. Två likadana namn i listan kan vara två separata tester, två formulärsignaler eller dubbla taggar. Jämför tidpunkt och antal med vad du faktiskt gjorde.

När händelsen saknas

1. Rätt destination? Jämför webbtaggens mät-ID med den webbström och egendom du har öppnat.
2. Rätt testläge? Kontrollera Tag Assistant-anslutningen och att du använder rätt enhet och webbläsarfönster.
3. Rätt samtycke? Google anger att händelser kan saknas i DebugView vid tillämpade integritetskontroller eller nekat Analytics-samtycke. Kontrollera vilket samtycke som gäller för testet innan du felsöker vidare.
4. Skickar webbplatsen signalen? Leta efter exempelvis lead_success i GTM:s händelselista.
5. Körs taggen? Öppna signalen och kontrollera utlösarvillkor, variabler och blockerade taggar.

Om taggen körs men mottagningen fortfarande saknas kan utvecklarverktygens nätverksvy behövas. Kontrollera destination och svar för mätanropet. Ett bortblockerat anrop, fel domän eller en servercontainer på vägen kräver en annan felsökning än en saknad formulärsignal.

När värdet eller antalet är fel

Gå tillbaka till samma händelse i Tag Assistant och jämför vad datalagret innehöll när taggen kördes. Om GA4 får form_id=undefined eller en felaktig tjänstekategori kan felet ligga i fältnamnet, källvärdet eller tidpunkten då taggen läser det. Att ändra rapportdimensionens visningsnamn rättar inte ett felaktigt skickat värde.

Om antalet är dubbelt granskar du andra taggar och installationer. Ett vanligt formulär bör inte räknas både vid knapptryck och bekräftat inskick under samma namn. För köp behöver även transaktions-ID och upprepade anrop undersökas; lösningen är inte att gömma ena raden i rapporten.

Avsluta testet och verifiera den publicerade lösningen

Spara testdatum, egendom, testenhet, handling och förväntat respektive faktiskt resultat. Skilj en fungerande förhandsgranskning från en publicerad version. När ändringen publicerats testar du samma handling igen och följer den avsedda rapporten när data bearbetats.

Om debug_mode lagts in tillfälligt i konfigurationen tar du bort parametern. Att sätta den till false stänger enligt Google inte av läget. Ska utvecklartrafik hållas utanför ordinarie rapporter behöver det hanteras med avsedda datafilter; debugmarkeringen utesluter inte i sig testtrafiken från rapporterna.

Kontrollera även upprepade köp och relevanta samtyckesval. Frånvaron av data efter ett nekande kan vara det avsedda beteendet.

Kontrollera även rapporterna

Efter testet kontrollerar du händelsen i den rapport där den ska följas upp. Stäm också av köp eller förfrågningar mot order- eller formulärsystemet.

Spara testdatum, enhet, förutsättningar och förväntat utfall. Ta bort tillfälliga felsökningsinställningar där de inte ska vara kvar. När nästa ändring görs kan samma testfall köras igen, med samma förutsättningar.

Källor och dokumentation

• Googles dokumentation
• Dokumentation för arbetsgången