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.