Vilka misstag vid uppsättning av händelser kostar team dagar av felsökning? Dubbla händelser som räknar samma handling två gånger. Händelser som är inställda på fel sidor. Parametrar som fångar fel värden. Inkonsekvent namngivning som skapar förvirring. Händelser som utlöses vid fel tidpunkt eller inte alls. De här misstagen är vanliga eftersom händelseuppsättning är komplex. Men misstagen går också att förebygga. Om du förstår vad som går fel kan du undvika det.
Den här artikeln går igenom de vanligaste misstagen och hur du förebygger dem.
Dubbla händelser
Det vanligaste misstaget är att skapa samma händelse två gånger med olika namn. En utvecklare skapar ”purchase”. En annan skapar ”purchase_conversion”. Nu mäter du samma handling två gånger. Rapporterna visar två händelser. Teamen diskuterar vilken som stämmer.
Förebygg dubbletter genom att kolla ditt händelseregister innan du skapar något. Finns händelsen redan? Om ja, använd den som finns. Om nej, skapa den enligt den överenskomna namnregeln.
Om du hittar dubbletter, ta bort den ena direkt. Pågående dubbletter förorenar din data.
Händelser inställda på fel sidor
Du sätter upp en formulärhändelse. Du testar den på kontaktformuläret. Den fungerar. Du går live. Men den utlöses på varje sida, inte bara på kontaktsidor. Händelsens konfiguration är för bred.
Förebygg det genom att testa på flera sidor. Testa sidan där händelsen ska utlösas. Testa sidor där den inte ska det. Kontrollera att den bara utlöses där den ska.
Dokumentera var varje händelse ska utlösas. Om du senare ser att den utlöses någon annanstans har du fångat ett konfigurationsfel.
Parametrar som fångar fel värden
En köphändelse har en parameter som ska fånga köpbeloppet. Men den fångar produktpriset i stället. Närliggande men inte samma sak. Datan blir fel.
Förebygg det genom att testa parametrar med kända värden. Gör ett köp på $50. Kontrollera att parametern visar $50. Inte $45. Inte $55. Exakt $50.
Dokumentera var varje parameter får sin data ifrån. ”Köpbeloppet kommer från fältet purchase_amount i datalagret.” Tydlig dokumentation förhindrar förväxlingar.
Inkonsekventa händelsenamn
En händelse heter ”purchase”. En annan heter ”Purchase”. En tredje heter ”purchase_event”. Samma händelse har tre namn. Rapporterna visar tre separata händelser. Förvirring blir följden.
Förebygg det genom att använda konsekventa namnregler. Alla gemener. Inga mellanslag. Understreck mellan orden. En namnstandard. Använd den för varje händelse.
Dokumentera din namnstandard. Dela den med alla som skapar händelser. Gör konsekvens till regel.
Händelser som inte utlöses
Du konfigurerar en händelse. Du går live. Ingenting händer. Inga händelser i rapporterna. Händelsen utlöses inte alls.
Vanliga orsaker är fel utlösarkonfiguration (händelsen ska utlösas när någon klickar på en viss knapp, men utlösaren letar efter fel element), fel sidkonfiguration (händelsen ska utlösas på en viss sida, men sidans sökväg har ändrats) eller timingproblem (händelsen utlöses innan datalagret är fyllt).
Förebygg det genom att testa noga före lansering. Kontrollera utlösarens konfiguration. Kontrollera sidans sökväg. Kontrollera timingen. Testa i staging. Släpp inte ut otestade händelser.
Händelser som utlöses för ofta
Du konfigurerar en händelse som ska utlösas när någon klickar på en knapp. Men den utlöses tjugo gånger per klick. Dubbel utlösning snedvrider din data.
Vanliga orsaker är flera lyssnare för samma händelse (tagghanteraren och din webbplats skickar båda samma händelse) eller event bubbling (ett klick på ett underordnat element utlöser även det överordnade elementets händelse).
Förebygg det genom att förstå din utlösare. Testa noga. Leta efter dubbletter. Följ hur ofta händelser utlöses. Om siffran är ovanligt hög, undersök det.
Parametervärden som saknas eller är fel
En köphändelse ska fånga köpbeloppet. Men parametern är tom. Eller så fångar den fel värde. Datakvaliteten blir lidande.
Vanliga orsaker är att datalagret inte är fyllt (händelsen utlöses innan datalagret har någon information), fel i parameterkopplingen (parametern letar efter fel fält i datalagret) eller hårdkodade värden (en parameter har ett fast värde i stället för att hämta dynamisk data).
Förebygg det genom att kontrollera att datalagret är fyllt innan händelser utlöses. Testa parametrar med riktig data. Kontrollera att kopplingen är rätt. Använd dynamisk data, inte hårdkodade värden.
Att inte testa i live-miljön
Du testade noga i staging. Händelserna fungerar perfekt. Du går live. Användare rapporterar direkt att händelserna inte fungerar. Staging skiljer sig från live på sätt du inte väntade dig.
Förebygg det genom att testa i live-miljön med en liten andel av trafiken. Börja med 10 %. Håll utkik efter fel. Om allt fungerar, öka till 50 %. Sedan 100 %. Småskalig testning i live-miljön fångar miljöspecifika problem.
Att inte övervaka händelser efter lansering
Du släpper händelserna. Du går vidare till nästa projekt. Tre veckor senare märker någon att en händelse har slutat utlösas. Du har förlorat tre veckors data.
Förebygg det genom att övervaka händelserna kontinuerligt. Ställ in larm. Om en händelse inte utlöses på en timme, larma någon. Kolla hur ofta händelser utlöses varje vecka. Upptäck oväntade förändringar. Fånga problem tidigt.
Vanliga frågor
Hur upptäcker vi dubbla händelser?
Dokumentera alla händelser i ett händelseregister. Kolla registret innan du skapar en händelse. Om något liknande finns, återanvänd det. Regelbundna genomgångar av din händelselista fångar dubbletter du missat. Med WEMASY webbplatsbyggare kan du ställa in det här direkt på din webbplats.
En händelse utlöses men datakvaliteten är dålig. Hur felsöker vi?
Kontrollera varje del. Utlöses händelsen? Använd realtidsrapporter. Är utlösaren rätt? Använd utvecklarverktyg. Fångas parametrarna? Kolla deras värden. Ta reda på vilken del som är fel. Åtgärda den. Testa igen.
Vi har en trasig händelse i live-miljön. Ska vi ta bort den eller inaktivera den?
Inaktivera den, ta inte bort den. Inaktivering behåller historisk data. Borttagning raderar händelsen helt. Du kanske vill analysera data från innan händelsen gick sönder. Behåll datan. Inaktivera bara händelsen framöver.
Hur förebygger vi konfigurationsfel?
Använd standardiserad konfiguration av händelser. Skapa en mall. Varje händelse har samma struktur. Standardisering minskar variationen. Färre variationer ger färre misstag.
Vad är det värsta misstaget vid uppsättning av händelser?
Att släppa ut otestade händelser i live-miljön. Otestade händelser går sönder tyst. Du märker det inte på flera dagar. Då har du förlorat data. Testa alltid före lansering.
Hur återhämtar vi oss från misstag vid uppsättning av händelser?
Agera snabbt. När du märker ett misstag, åtgärda det direkt. Inaktivera den trasiga händelsen. Rätta konfigurationen. Testa. Släpp ut igen. Ju snabbare du agerar, desto mindre dålig data samlar du in.