Hvilke fejl i event-opsætning koster teams dagevis af fejlfinding? Dobbelte events, der tæller den samme handling to gange. Events sat op til de forkerte sider. Parametre, der fanger de forkerte værdier. Uens navne, der skaber forvirring. Events, der sendes på det forkerte tidspunkt eller slet ikke. Fejlene er almindelige, fordi event-opsætning er indviklet. Men fejlene kan også forebygges. Når du ved, hvad der går galt, kan du undgå det.
Her gennemgår vi de mest almindelige fejl og hvordan du forebygger dem.
Dobbelte events
Den mest almindelige fejl er at oprette det samme event to gange med forskellige navne. En udvikler opretter "purchase". En anden opretter "purchase_conversion". Nu sporer du den samme handling to gange. Rapporterne viser to events. Teamet diskuterer, hvilket der er rigtigt.
Forebyg dubletter ved at tjekke din eventoversigt, før du opretter noget. Findes eventet allerede? Hvis ja, så brug det eksisterende. Hvis nej, så opret det med den aftalte navngivning.
Hvis du opdager dubletter, så slet den ene med det samme. Dubletter, der kører, forurener dine data.
Events sat op til de forkerte sider
Du sætter et event op til indsendte formularer. Du tester det på kontaktformularen. Det virker. Du går live. Men det sendes på alle sider, ikke kun på kontaktsiderne. Opsætningen af eventet er for bred.
Forebyg det ved at teste på flere sider. Test siden, hvor eventet skal sendes. Test sider, hvor det ikke skal. Tjek, at det kun sendes, hvor det er meningen.
Skriv ned, hvor hvert event skal sendes. Hvis du senere ser det sendt andre steder, har du fanget en fejl i opsætningen.
Parametre, der fanger forkerte værdier
Et købsevent har en parameter, der skal fange købsbeløbet. Men den fanger i stedet produktets pris. Det ligner hinanden, men er ikke det samme. Dataene er forkerte.
Forebyg det ved at teste parametre med kendte værdier. Lav et køb på $50. Tjek, at parameteren viser $50. Ikke $45. Ikke $55. Præcis $50.
Skriv ned, hvor hver parameter får sine data fra. "Købsbeløbet kommer fra feltet purchase_amount i data layeret." Tydelig dokumentation forhindrer forveksling.
Uens eventnavne
Et event hedder "purchase". Et andet hedder "Purchase". Et tredje hedder "purchase_event". Det samme event har tre navne. Rapporterne viser tre separate events. Det skaber forvirring.
Forebyg det ved at bruge faste regler for navne. Alt med små bogstaver. Ingen mellemrum. Understreger mellem ordene. Én standard for navne. Brug den på hvert event.
Skriv din standard for navne ned. Del den med alle, der opretter events. Gør ensartethed til reglen.
Events, der ikke bliver sendt
Du sætter et event op. Du går live. Der sker ingenting. Ingen events i rapporterne. Eventet bliver slet ikke sendt.
Almindelige årsager er forkert opsætning af udløseren (eventet skal sendes, når nogen klikker på en bestemt knap, men udløseren leder efter det forkerte element), forkert opsætning af siden (eventet skal sendes på en bestemt side, men sidens sti er ændret) eller problemer med timing (eventet sendes, før data layeret er udfyldt).
Forebyg det ved at teste grundigt før lancering. Tjek udløserens opsætning. Tjek sidens sti. Tjek timingen. Test i testmiljøet. Send ikke utestede events live.
Events, der sendes for ofte
Du sætter et event op til at blive sendt, når nogen klikker på en knap. Men det sendes tyve gange pr. klik. Dobbelt afsendelse skæver dine data.
Almindelige årsager er flere lyttere til det samme event (tag manageren og din hjemmeside sender begge det samme event) eller event bubbling (et klik på et underelement udløser også det overordnede elements event).
Forebyg det ved at forstå din udløser. Test omhyggeligt. Tjek for dubletter. Hold øje med, hvor ofte eventet sendes. Hvis det er usædvanligt højt, så undersøg det.
Manglende eller forkerte parameterværdier
Et købsevent skal fange købsbeløbet. Men parameteren er tom. Eller den fanger den forkerte værdi. Datakvaliteten lider.
Almindelige årsager er et data layer, der ikke er udfyldt (eventet sendes, før data layeret har oplysningerne), fejl i koblingen af parameteren (parameteren leder efter det forkerte felt i data layeret) eller faste værdier (en parameter har en fast værdi i stedet for at hente dynamiske data).
Forebyg det ved at tjekke, at data layeret er udfyldt, før events sendes. Test parametre med rigtige data. Tjek, at koblingen er rigtig. Brug dynamiske data, ikke faste værdier.
Ingen test i produktion
Du testede grundigt i testmiljøet. Events virker perfekt. Du går i produktion. Brugerne siger med det samme, at events ikke virker. Testmiljøet er anderledes end produktion på måder, du ikke havde forventet.
Forebyg det ved at teste i produktion med en lille del af trafikken. Start med 10%. Hold øje med fejl. Hvis alt virker, så øg til 50%. Så 100%. Test i lille skala i produktion fanger fejl, der hører til miljøet.
Ingen overvågning af events efter lancering
Du går live med events. Du går videre til næste projekt. Tre uger senere opdager nogen, at et event er holdt op med at blive sendt. Du har mistet tre ugers data.
Forebyg det ved at overvåge events hele tiden. Sæt advarsler op. Hvis et event ikke sendes i en time, så giv nogen besked. Tjek, hvor ofte events sendes, hver uge. Opdag uventede ændringer. Fang problemer tidligt.
Ofte stillede spørgsmål
Hvordan finder vi dobbelte events?
Skriv alle events ned i en eventoversigt. Før du opretter et event, så tjek oversigten. Hvis noget lignende findes, så brug det. Faste gennemgange af din eventliste fanger dubletter, du overså. Med WEMASY's hjemmesidebygger kan du sætte det op direkte på din hjemmeside.
Et event sendes, men datakvaliteten er dårlig. Hvordan finder vi fejlen?
Tjek hver del. Bliver eventet sendt? Brug realtidsrapporter. Er udløseren rigtig? Brug udviklerværktøjer. Bliver parametrene fanget? Tjek deres værdier. Find ud af, hvilken del der er forkert. Ret den. Test igen.
Vi har et ødelagt event i produktion. Skal vi slette det eller slå det fra?
Slå det fra, slet det ikke. Når du slår det fra, beholder du de historiske data. Hvis du sletter, fjerner du hele eventet. Du vil måske analysere data fra før, eventet gik i stykker. Behold dataene. Slå bare eventet fra fremover.
Hvordan forebygger vi fejl i opsætningen?
Brug en ensartet opsætning af events. Lav en skabelon. Hvert event har den samme opbygning. Ensartethed giver færre forskelle. Færre forskelle giver færre fejl.
Hvad er den værste fejl i event-opsætning?
At sende utestede events live. Utestede events går i stykker uden at larme. Du opdager det ikke i flere dage. Så har du mistet data. Test altid, før du går i produktion.
Hvordan kommer vi videre efter fejl i opsætningen?
Reager hurtigt. Når du opdager en fejl, så ret den med det samme. Slå det ødelagte event fra. Ret opsætningen. Test. Send det live igen. Jo hurtigere du reagerer, jo færre dårlige data samler du.