Analytics-konfiguration er de regler, der afgør, hvad dit system måler, hvordan det navngiver data, og hvem der ser hvilke rapporter. Er den i orden, virker beslutningerne oplagte. Er den ikke, bliver hvert dashboard til en diskussion om, hvorvidt tallene er rigtige.
Forskellen på erfarne teams og teams, der har det svært, er sjældent værktøjerne. Det er disciplin. Erfarne teams skriver deres standarder ned, tester ændringer og gennemgår opsætningen efter en fast plan. Teams, der har det svært, ser opsætning som en engangsopgave og undrer sig over, at data skrider.
God praksis for konfiguration, der holder
Start med en skriftlig målingsplan
Beskriv forretningsspørgsmålene, før du definerer events. Hvert tal skal høre til en beslutning, som nogen skal træffe. Hvis ingen beslutning afhænger af et tal, så mål det ikke endnu. Når du holder omfanget nede, er opsætningen nem at vedligeholde.
Brug ens navne overalt
Eventnavne, parametre, kampagnemærker og navne på dashboards bør følge én nedskrevet standard. Blandede navne splitter rapporterne uden, at nogen opdager det. Nye medarbejdere bør lære navnene af en navneguide, ikke ved at gætte, hvad tidligere kolleger mente.
Hold miljøerne adskilt
Udvikling, test og produktion bør have hver sin ejendom eller sine egne filtre. Testtrafik må aldrig forurene ledelsens rapporter. Udelukkelse af interne IP-adresser og filtre på værtsnavn er de helt basale værn, som alle opsætninger har brug for.
Test før og efter hver ændring
Behandl ændringer i konfigurationen som kodeudgivelser. Se på effekten på forhånd. Udgiv. Kontrollér med realtidstjek og sammenlign med kendte nøgletal. En plan for at rulle tilbage er ikke valgfri, når ændringen berører konverteringer.
Giv én person ansvaret
Én person ejer målingsplanen. Én person godkender nye tags og events. Én person gennemgår data hver måned. Delt ansvar betyder tit, at ingen har ansvaret.
Almindelige fejl, der ødelægger dine analytics-data
At spore alt uden en strategi
Teams tilføjer events til hvert eneste klik på en knap, og så vedligeholder ingen dem. Rapporterne fyldes med tal, som ingen bruger. De vigtige signaler drukner i støj. Mål færre ting med et klart formål.
Dobbelte tags og tags, der modsiger hinanden
Hvis flere tags sender det samme event, bliver konverteringer talt dobbelt. Filtre, der modsiger hinanden, fjerner gyldig trafik. Hvis du gennemgår dine tags hvert kvartal, finder du dubletter, som er kommet ind via ændringer fra et bureau eller kopier af skabeloner.
Rodet eller ufuldstændig brug af UTM
Uens kampagneparametre får betalt trafik og trafik fra e-mail til at se ud som direkte trafik eller henvisninger. Marketing kan ikke optimere det, som attribution mærker forkert. Gør UTM-skabeloner til et krav, når linket laves, ikke når rapporten bygges.
For hård filtrering af bots og intern trafik
Filtrering fjerner støj, men kan også fjerne rigtige besøgende, hvis reglerne er for brede. Skriv formålet ned for hvert filter, og gennemgå hver måned, hvor meget der udelukkes. Et pludseligt fald i trafikken kan skyldes en ændring i et filter og ikke en ændring på markedet.
At glemme mobil og andre browsere
En opsætning, der kun er testet på Chrome på computer, overser fejl i Safari og i mobilens indbyggede browsere. Test konverteringsforløb på mindst tre kombinationer af browser og enhed, før du erklærer opsætningen for færdig.
At sætte det op og glemme det
Hjemmesider ændrer sig. Nye landingssider, redesign af checkout og CMS-plugins ændrer alle sporingen. Konfiguration uden løbende gennemgang forfalder. Planlæg en gennemgang hvert kvartal sammen med dine gennemgange af overvågning af ydeevne.
Tilpas konfigurationen til dine rapporter
Sæt data op med den endelige rapport for øje. Læser ledelsen ugentlige kanaldashboards, skal dine definitioner af kilder og dine konverteringsvinduer passe til det tempo. Hvis opslagsvinduerne er forskellige, passer tendenserne på dashboardet ikke med visningerne i kampagneværktøjet.
Byg først dashboards til rapportering, når den grundlæggende konfiguration er stabil. Dashboards bygget på definitioner, der ændrer sig, forvirrer interessenterne og æder tilliden hurtigere, end hvis du slet ikke havde et dashboard.
Sådan kommer du videre, når fejlene allerede er sket
Opdager du en fejl i konfigurationen, så find ud af omfanget, før du retter den. Find datoen, hvor fejlen startede, og hvilke tal den påvirkede. Fortæl klart til interessenterne, at de historiske data for den periode ikke er til at stole på i bestemte rapporter.
Ret først fremad. Ret konfigurationen, og kontrollér, at nye data er rene. Vurdér derefter, om du kan genopbygge de historiske data. Det er ikke altid umagen værd, hvis perioden er kort, eller tallet ikke har stor betydning.
Ofte stillede spørgsmål
Hvad er den mest skadelige fejl i konfigurationen?
Dobbelte konverterings-tags, der pumper resultaterne op. Teams træffer budgetbeslutninger ud fra fordoblede tal, indtil en gennemgang afslører fejlen. Med WEMASYs hjemmesidebygger kan du bruge én ens sporingsopsætning på alle sideskabeloner.
Hvordan dokumenterer vi vores standarder for konfiguration?
Hold et levende dokument med eventnavne, parameterdefinitioner, filterregler, UTM-skabeloner og kontaktpersoner. Link til det fra jeres interne wiki, og opdatér det ved hver ændring i konfigurationen, ikke først efter en fejl.
Skal kolleger uden teknisk baggrund ændre analytics-indstillinger?
Giv dem styret adgang til rapporter og kampagneparametre, ikke ubegrænset adgang til konfigurationen. Marketing kan styre UTM-links. Udviklere styrer tags og events. Når rollerne er delt, undgår I utilsigtede ændringer i filtre, som får trafikken til at falde.
Hvornår skal vi bygge dashboards i forhold til arbejdet med konfigurationen?
Når de vigtigste events, filtre og konverteringsdefinitioner er testet i produktion. Dashboards, der bygges for tidligt, bygger på dårlige antagelser. Vores guide til dashboards til rapportering går ud fra, at konfigurationen er stabil.
Hvordan undgår vi, at konfigurationen skrider over tid?
Planlæg gennemgang af tags, filtre og events hvert kvartal. Tjek også ydeevnen ved hver gennemgang, så hastighed og nøjagtighed følges ad, mens sitet udvikler sig.
Kan vi rette dårlige historiske data efter en fejl i konfigurationen?
Nogle gange. Findes de rå eventlogs, kan du måske genopbygge rapporter med rettede regler. Ofte er den praktiske løsning at markere den berørte periode og gå videre med en ren konfiguration. Åbenhed er bedre end stille rettelser.