Hur många events bör vi spåra?

Tio till tjugo till att börja med. Utgå från de frågor du redan ställer på produktgenomgångar och instrumentera bara det som besvarar dem; en katalog med tvåhundra event är en katalog ingen kan navigera i och där flera event i tysthet betyder samma sak.

Bör jag använda autocapture eller explicita events?

Båda, för olika uppgifter. Autocapture täcker interaktioner i gränssnittet utan planering, så att data för en oförutsedd fråga redan finns. Explicita event bär en domänbetydelse som ingen klickström kan härleda — ett abonnemang uppgraderat, en provperiod konverterad — och det är dem du rapporterar på.

Vad är en bra namnkonvention för events?

Objektet först, handlingen i preteritum, gemener med understreck: invite_sent, project_created, payment_failed. Namnge utfallet i stället för gränssnittet, så att eventet överlever en redesign, och håll en och samma konvention konsekvent genom hela katalogen.

Vad är event tracking? En praktisk guide till att namnge och välja events

Q: Vad är event tracking?

Att registrera namngivna, meningsfulla handlingar som användare utför i en produkt — ett konto skapat, en rapport exporterad, en betalning misslyckad — så att de kan räknas, jämföras och sättas ihop till trattar. Namngivningen är själva substansen: ett event är den delmängd av allt som hände som du bestämde var värd att agera på.

Ett event är ett beslut du fattat, inte något som hände

Varje produkt avger ett obegränsat antal saker som hände: klick, scrollningar, hovringar, ruttbyten. Ett event är den lilla delmängd du bestämt är värd ett namn, för att den säger dig något du skulle agera på. Det beslutet, inte instrumenteringen, är hela jobbet.

Den praktiska följden är att en tracking-plan är ett produktdokument snarare än ett tekniskt. Om du inte kan säga vad du skulle göra annorlunda beroende på om ett event utlöses eller inte, behöver det inte existera ännu.

Namnge event efter utfall, inte efter gränssnitt

clicked_blue_button slutar stämma i samma stund som designteamet lanserar en ny formgivning. report_exported överlever den, eftersom namnet beskriver vad användaren uppnådde snarare än vad hen rörde vid.

Välj en konvention och håll fast vid den: objekt först, handling i förfluten tid, gemener med understreck — invite_sent, project_created, payment_failed. Konsekvens spelar större roll än vilken konvention du valde, för det är inkonsekventa namn som gör en eventkatalog omöjlig att söka i två kvartal senare.

Tio till tjugo event, inte tvåhundra

Det vanliga misstaget är att spåra allt med tanken att datan kanske blir användbar sedan. Det du får är en katalog ingen kan navigera i, tre event som betyder nästan samma sak och ingen enighet om vilket av dem som gäller.

Utgå från frågorna du redan ställer på genomgångarna — kommer folk igång, kommer de tillbaka, var ger de upp — och instrumentera bara det som besvarar dem. En tracking-plan som får plats på en skärm blir underhållen. En som får plats i ett kalkylark blir det inte.

Egenskaperna bär detaljen, eventet bär verbet

Motstå ett separat event per variant. report_exported_csv, report_exported_pdf och report_exported_xlsx bör vara ett enda event, report_exported, med en format-egenskap. Tumregeln: om du någonsin skulle vilja se siffrorna summerade är det ett event med en egenskap.

Håll egenskapernas värden låga i kardinalitet och stabila. En egenskap som innehåller en rå URL eller en fritextsträng är en kolumn du inte kan gruppera på, vilket gör den till dekoration snarare än data.

Autocapture och explicita event besvarar olika frågor

Autocapture registrerar interaktioner i gränssnittet utan att du behöver planera, vilket är genuint användbart tidigt: det betyder att datan för en fråga du inte hade tänkt på redan finns där, och det tar bort deployen ur loopen. Vad den inte kan är att förstå din domän. Ingenting i en ström av klick vet att en prenumeration uppgraderades.

Den fungerande uppställningen är båda: autocapture för utforskning och för frågorna du ännu inte ställt, plus en kort lista med explicita, välnamngivna domänevent för siffrorna du rapporterar på och sätter mål mot.

Var du börjar den här veckan

Skriv ner de fem ögonblick som betyder mest i din produkt, namnge dem enligt konventionen ovan och instrumentera bara dem. Kontrollera sedan en vecka senare att vart och ett utlöses när du förväntar dig och att egenskaperna är ifyllda — ett event som utlöses på en kodväg ingen använder är sämre än inget event alls, eftersom det kommer att litas på.

Vill du se hur eventen du redan skickar beter sig innan du lägger till fler visar event tracking i PulsePanda varje event, dess volym och dess egenskaper på ett och samma ställe, och matar samma data rakt in i trattar och vägar.