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.
En namnkonvention du kan kopiera
De flesta team behöver inte hitta på en konvention, bara skriva ner en. Den här är kort nog att komma ihåg och strikt nog för att hålla en katalog sökbar:
| Regel | Gör | Gör inte |
|---|---|---|
| Objektet först, sedan handlingen | invite_sent | sent_invite |
| Dåtid, eftersom det redan har hänt | project_created | create_project |
| Gemener med understreck | plan_upgraded | PlanUpgraded, plan-upgraded |
| Namnge resultatet, inte kontrollen | report_exported | export_button_clicked |
| Varianter hör hemma i egenskaper | report_exported med format: csv | report_exported_csv |
| Inga personuppgifter i namn eller värden | plan: team | email: ana@acme.com |
Lägg konventionen överst i spårningsplanen och granska nya event mot den på samma sätt som du granskar kod mot en stilguide. Ett dåligt namn får betalas varje gång någon letar efter eventet och inte hittar det.
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.
Ett genomarbetat exempel: en spårningsplan för en B2B-SaaS-app
Så här ser tolv event ut för en typisk teambaserad SaaS-produkt. Vart och ett finns för att det besvarar en fråga som någon redan ställer på ett veckomöte.
| Event | Utlöses när | Viktiga egenskaper | Frågan det besvarar |
|---|---|---|---|
signup_completed | Kontot finns, inte när formuläret skickas | source | Vilka kanaler ger personer som faktiskt slutför? |
workspace_created | Den första arbetsytan sparas | team_size | Hur många registreringar kommer så långt som till uppsättningen? |
teammate_invited | En inbjudan skickas | role | Sprider sig kontot bortom en person? |
invite_accepted | Den inbjudna personen går med | role | Blir inbjudningar till kollegor? |
integration_connected | En anslutning lyckas | integration | Vilka integrationer använder de team som stannar? |
project_created | Ett projekt sparas | template | Skapas kärnobjektet över huvud taget? |
report_viewed | En rapport har renderats klart | report_type | Vad kommer folk tillbaka för att titta på? |
report_exported | Filen genereras | format | Lämnar resultatet produkten? |
plan_upgraded | Faktureringen bekräftar ändringen | from_plan, to_plan | Vad händer precis innan folk betalar mer? |
payment_failed | Betalleverantören rapporterar ett misslyckande | reason | Hur mycket av churnen är ofrivillig? |
subscription_cancelled | Uppsägningen träder i kraft | reason | Varför lämnar team? |
feedback_submitted | Feedbackformuläret skickas | category | Vad ber användarna om, med sina egna ord? |
Två saker är värda att lägga märke till. De flesta av dessa utlöses av ett resultat, inte av ett klick: en inbjudan kan klickas på och ändå misslyckas. Och faktureringseventen sker inte i webbläsaren alls. De kommer från betalleverantörens webhooks, så analys som bara bygger på webbläsaren kommer aldrig att se dem. Det är okej så länge ingen behandlar ett klick på ”Uppgradera” som intäkt.
Aktivering är oftast en kombination av dessa snarare än något enskilt av dem, till exempel en skapad arbetsyta och en inbjuden kollega under den första veckan. Välj den definitionen medvetet; riktmärken för aktiveringstratten går igenom hur.
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.
Misstag i event tracking som i tysthet förstör rapporter
- Att utlösa på klicket i stället för på resultatet. Ett klick på ”Exportera” är ingen export. Om förfrågan misslyckas har eventet redan ljugit. Skicka resultatevent när saken har lyckats.
- Dubbla utlösningar i single page-appar. En komponent som renderas om eller en route som monteras två gånger kan skicka samma event två gånger. Kontrollera några sessioner för hand innan du litar på en siffra.
- Personuppgifter i egenskaper. E-postadresser, namn och URL:er med tokens i frågesträngen hamnar i varje rapport och varje export. Skicka ett ID eller en kategori i stället.
- Att spåra före samtycke. Där GDPR gäller ska analysen inte starta förrän besökaren har samtyckt. Det är en egenskap hos din uppsättning snarare än hos varje event, så lös det en gång, med en cookie-samtyckeshanterare som håller tillbaka spårningen till dess.
- Att ändra vad ett event betyder utan att byta namn. Om
project_createdbörjar räkna duplicerade projekt går alla diagram före och efter ändringen isär och ingen kan säga varför. En ny betydelse får ett nytt namn, eller en egenskap som skiljer de två åt. - Event utan ägare. Varje event i planen behöver en person som märker när det slutar utlösas. Ägarlösa event förfaller först och litas på längst.
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.
Att definiera event i efterhand
Automatisk insamling ändrar frågan från ”kom vi ihåg att instrumentera det här?” till ”kan vi hitta det i det som samlades in?”. PulsePanda registrerar varje klick med elementets id, klasser, synliga text, tagg och position på sidan, så ett event kan definieras senare utifrån dem, och definitionen gäller klick som samlades in innan den fanns. En fråga som ställs på torsdagen kan besvaras med måndagens data.
Det som gör det pålitligt är en stabil krok i koden. Klasser ändras med varje omdesign och synlig text med varje textändring och översättning. Ett id på den handfull kontroller som spelar roll ändras bara när någon bestämmer att det ska:
<button id="export-report">Export</button>
<button id="invite-teammate">Invite</button>
<a id="upgrade-plan" href="/sv/billing">Upgrade</a>Ett event som definieras som klick på #export-report överlever en omdesign, och ett klick på ikonen eller etiketten inuti knappen räknas fortfarande, eftersom den registrerade sökvägen går upp till närmaste element med ett id.
Ett definierat event är fortfarande ett klick, med den begränsning som beskrivs ovan: det säger att någon försökte, inte att det fungerade. För resultat är den ärligaste signalen ofta sidan som ett lyckat försök leder till. Ett trattsteg ”nådde /onboarding” efter ”nådde /signup” räknar slutförda registreringar utan något event alls.
Så kontrollerar du ett event innan du litar på det
- Utlös det själv och hitta din egen session. Eventet ska synas en gång, med alla egenskaper ifyllda.
- Jämför antalet med en sanningskälla. Om databasen säger att 140 projekt skapades förra veckan och analysen säger 95, hitta glappet innan någon bygger ett diagram på det. Annonsblockerare, samtycke och misslyckade förfrågningar gör alla att webbläsarens siffror blir lägre än serverns. Glappet ska vara stabilt, inte en överraskning.
- Titta på en session replay där det utlöstes. En siffra säger att det hände; en inspelning säger att det hände när du tror att det gjorde det.
- Lägg det i en tratt. Ett event som dyker upp utan steget som måste komma före det utlöses från fel ställe.
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.