Een event is een keuze die jij maakte, niet iets wat er gebeurde
Elk product zendt een onbeperkt aantal dingen uit die er gebeuren: klikken, scrollbewegingen, hovers, routewijzigingen. Een event is het kleine deel daarvan waarvan jij besloot dat het een naam waard is, omdat het je iets vertelt waar je naar zou handelen. Die keuze, en niet het instrumenteren, is het eigenlijke werk.
Het praktische gevolg is dat een trackingplan een productdocument is en geen engineeringdocument. Als je niet kunt zeggen wat je anders zou doen afhankelijk van of een event afgaat, hoeft het nog niet te bestaan.
Noem events naar uitkomsten, niet naar interfaces
clicked_blue_button klopt niet meer op het moment dat design een redesign uitbrengt. report_exported overleeft dat wel, omdat het benoemt wat de gebruiker bereikte in plaats van waar hij op klikte.
Kies één conventie en houd je eraan: eerst het object, de actie in de verleden tijd, kleine letters met underscores — invite_sent, project_created, payment_failed. Consistentie telt zwaarder dan welke conventie je koos, want het zijn inconsistente namen die een eventcatalogus twee kwartalen later ondoorzoekbaar maken.
Tien tot twintig events, geen tweehonderd
De veelvoorkomende misser is alles tracken vanuit de gedachte dat data later nog van pas kan komen. Wat je krijgt is een catalogus waarin niemand de weg vindt, drie events die vrijwel hetzelfde betekenen, en geen enkele overeenstemming over welke daarvan leidend is.
Begin bij de vragen die je toch al stelt in evaluaties — komen mensen goed op weg, komen ze terug, waar geven ze het op — en instrumenteer alleen wat die vragen beantwoordt. Een trackingplan dat op één scherm past, wordt onderhouden. Een dat een heel spreadsheet vult, niet.
Properties dragen het detail; events dragen het werkwoord
Weersta de neiging om per variant een apart event te maken. report_exported_csv, report_exported_pdf en report_exported_xlsx zouden één event moeten zijn, report_exported, met format als property. De vuistregel: als je de cijfers ooit bij elkaar opgeteld zou willen zien, is het één event met een property.
Houd de waarden van properties laag in cardinaliteit en stabiel. Een property met een kale URL of een vrije tekst erin is een kolom waarop je niet kunt groeperen, en daarmee is het versiering en geen data.
Autocapture en expliciete events beantwoorden verschillende vragen
Autocapture registreert interacties met de interface zonder dat je iets hoeft te plannen, en dat is in het begin echt nuttig: het betekent dat de data voor een vraag die je nog niet had bedacht er al is, en het haalt de deploy uit de cyclus. Wat het niet kan, is jouw domein kennen. Niets in een klikstroom weet dat een abonnement is opgewaardeerd.
De werkbare opzet is allebei: autocapture voor verkennen en voor de vragen die je nog niet hebt gesteld, en een korte lijst expliciete, goed benoemde domeinevents voor de cijfers waarover je rapporteert en waarop je doelen zet.
Waar je deze week begint
Schrijf de vijf momenten op die er in jouw product het meest toe doen, geef ze een naam volgens de conventie hierboven, en instrumenteer alleen die. Controleer een week later of elk event afgaat wanneer je dat verwacht en of de properties gevuld zijn — een event dat afgaat op een codepad dat niemand gebruikt is erger dan geen event, want er zal op vertrouwd worden.
Wil je zien hoe de events die je al verstuurt zich gedragen voordat je er meer toevoegt, dan laat event tracking in PulsePanda elk event, het volume en de properties op één plek zien, en voert dezelfde data rechtstreeks door naar funnels en paden.