Events are the raw material
Every funnel, retention chart, and user flow is built from events: discrete actions like a page
view, a click, or a custom signup. An event carries properties (which plan, which
page, how much) and is tied to a person. Get event tracking right and the reports take care of
themselves; get it wrong and no dashboard can save you.
Autocapture plus manual events
The pragmatic approach combines two modes. Autocapture records common interactions, page views,
clicks, scrolls, form submits, and frustration signals like rage and dead clicks, automatically after one
init(). That gives you data on day one. Then you add a small number of manual track() calls for the domain events that carry real business meaning: signup,
checkout_started, subscription_started. You get breadth for free and depth where it
counts.
Tie events to people
An event is far more useful when it belongs to a person. Before sign-in, events accrue to an anonymous ID; calling
identify(userId) merges that history into one profile. From then on, traits like plan or email filter
every report, and you can follow a single user across sessions and devices. This identity model is the heart of
product analytics.
Write a tracking plan
Consistency is what separates useful event data from noise. A tracking plan is simply an agreed
list of event names and their properties, so the whole team sends checkout_started: not
CheckoutStart, begin_checkout, and checkout. Decide names up front, keep
properties consistent, and flag anything that carries personal data. If it helps, our
event tracking plan generator produces a starter plan from
well-known events you can export and adapt.
Why open source
Event data is a precise record of user behavior, which is exactly why where it lives matters. Open-source event tracking lets you self-host so events stay in your own database, read the code to see how they’re processed, and avoid per-event pricing as you scale. For developers, the developer guide covers the SDKs and API that make this concrete.