En GA4-opsætning bliver sjældent rodet på én dag. Den bliver rodet lidt ad gangen: et nyt tag her, et plugin dér og et eventnavn, som virkede oplagt for to år siden.
Så begynder rapporterne at være uenige. Det ene lead tæller to gange, det andet slet ikke, og ingen har lyst til at trykke på Delete.
Det forstår jeg godt. Start ikke med at slette noget.
Begynd med det, du skal kunne stole på
Vælg de tre til fem handlinger, som faktisk har betydning for rapporter, budgetter eller andre beslutninger. Det kan være et køb, en booking, en indsendt formular eller noget helt fjerde. Beskriv hver handling uden at bruge GA4-sprog:
- Hvad skal brugeren konkret have gjort?
- Hvornår må handlingen tælle?
- Må den tælle mere end én gang i samme forløb?
- Hvilket system kan du kontrollere tallet imod?
Kan du ikke give et event en enkel definition, er navnet i GA4 ikke det første problem. Så er definitionen det.
Lav et kort – også over det kedelige
Saml derefter de tekniske oplysninger i ét lille arbejdsark. For hvert vigtigt event bør du kunne se:
- eventnavn og forretningsmæssig betydning
- hvor eventet bliver oprettet: hjemmeside, plugin, GTM eller backend
- hvilke parametre der bliver sendt
- hvilke rapporter, målgrupper og annonceplatforme der bruger det
- hvordan det testes, og hvem der ejer definitionen
Den samme formular kan være målt i både et plugin, en GTM-container og specialkode. Gå derfor efter den faktiske datastrøm. Ikke den opsætning, alle kan huske, at I vist nok har.
Tag de dyre fejl først
Det mest rodede er ikke nødvendigvis det vigtigste. Et lidt mærkeligt navn på et scroll-event er mindre alvorligt end et køb eller lead, der tæller dobbelt.
Jeg ville prioritere fejl i denne rækkefølge:
- Manglende eller dobbelte forretningskritiske events.
- Forkerte eventparametre, beløb eller valutaer.
- Events, der er markeret forkert som key events.
- Samtykkesignaler, intern trafik eller testtrafik, som ændrer tallene.
- Uønskede henvisninger og fejl i måling på tværs af domæner.
- Dubletter og gamle events, som ingen længere bruger.
Google kalder nu de vigtigste hændelser for key events. Markeringen gør ikke et event korrekt; den gør bare eventet vigtigere i rapporteringen. Derfor skal definition og test komme først.
Test før du rydder op
Brug Tag Assistant eller GTM’s preview-tilstand til at følge handlingen fra hjemmesiden, og kontrollér eventnavn og parametre i GA4 DebugView. Test normal brug, gentagelser og de relevante samtykkevalg.
Vær især forsigtig med datafiltre. Når et ekskluderende filter er aktivt, bliver de filtrerede data ikke behandlet og kan ikke hentes frem bagefter. Google har netop en tilstand kaldet Testing. Brug den. Navnet er et vink med en vognstang.
Sammenlign med noget uden for GA4
DebugView kan vise, at et event er sendt. Den kan ikke bevise, at eventet svarer til det, der faktisk skete i forretningen. Sammenlign derfor med ordrer, bookinger, formularmails eller et CRM-system.
Målet er ikke nødvendigvis to identiske tal. Målet er, at du kan forklare forskellen. Kan du ikke det, har du stadig en måleopgave.
Ændr én ting ad gangen
Gem et udgangspunkt, ret én afgrænset del, test igen og skriv datoen ned. Notér også de rapporter og integrationer, som ændringen påvirker. Ellers kan næste måneds analyse ende med at forklare en ændring i målingen som en ændring i kunderne.
GA4’s ændringshistorik viser konto- og propertyændringer fra de seneste to år. Den dokumenterer ikke nødvendigvis ændringer på hjemmesiden, i GTM eller i andre systemer. Du har stadig brug for din egen korte log.
Kommer du fra Universal Analytics?
Historiske UA-data kan ikke importeres i GA4. Har du gemte udtræk, så behandl dem som en særskilt datakilde med deres egne definitioner. Googles migrationssvar beskriver begrænsningen. Forsøg ikke at få GA4 til at ligne UA bare for at få graferne til at hænge pænt sammen.
Hvornår er en GA4-oprydning færdig?
En GA4-oprydning er færdig, når de vigtigste events har en tydelig definition, en kendt teknisk kilde, forventede parametre, en dokumenteret test og en ansvarlig. Ikke når eventlisten ser pæn ud.
Start med de tre vigtigste handlinger. Hvis du kan forklare dem, teste dem og kontrollere dem mod virkeligheden, har du et langt bedre udgangspunkt end en property med 75 events og nul ejere.