How many events should we track?

Ten to twenty to begin with. Start from the questions you already ask in product reviews and instrument only what answers them; a catalogue of two hundred events is one nobody can navigate and where several events quietly mean the same thing.

Should I use autocapture or explicit events?

Both, for different jobs. Autocapture covers interface interactions without planning, so the data for an unanticipated question already exists. Explicit events carry domain meaning that no click stream can infer — a plan upgraded, a trial converted — and those are the ones you report on.

What is a good event naming convention?

Object first, action in the past tense, lowercase with underscores: invite_sent, project_created, payment_failed. Name the outcome rather than the interface, so the event survives a redesign, and hold one convention consistently across the whole catalogue.

What is event tracking? A practical guide to naming and choosing events

Q: What is event tracking?

Recording named, meaningful actions users take in a product — an account created, a report exported, a payment failed — so they can be counted, compared and assembled into funnels. The naming is the substance: an event is the subset of everything that happened which you decided was worth acting on.

An event is a decision you made, not a thing that happened

Every product emits an unlimited number of things that happened: clicks, scrolls, hovers, route changes. An event is the small subset you decided is worth a name, because it tells you something you would act on. That decision, not the instrumentation, is the whole job.

The practical consequence is that a tracking plan is a product document rather than an engineering one. If you cannot say what you would do differently depending on whether an event fires, it does not need to exist yet.

Name events after outcomes, not interfaces

clicked_blue_button stops being true the moment design ships a redesign. report_exported survives it, because it names what the user achieved rather than what they touched.

Pick one convention and hold it: object first, action in the past tense, lowercase with underscores — invite_sent, project_created, payment_failed. Consistency matters more than which convention you picked, because inconsistent names are what make an event catalogue unsearchable two quarters in.

Ten to twenty events, not two hundred

The common failure is tracking everything on the theory that data might be useful later. What you get is a catalogue nobody can navigate, three events that mean nearly the same thing, and no agreement about which one is authoritative.

Start from the questions you already ask in reviews — are people getting set up, are they coming back, where do they give up — and instrument only what answers them. A tracking plan that fits on one screen gets maintained. One that fits in a spreadsheet does not.

Properties carry the detail; events carry the verb

Resist a separate event per variant. report_exported_csv, report_exported_pdf and report_exported_xlsx should be one event, report_exported, with a format property. The rule of thumb: if you would ever want to see the numbers added together, it is one event with a property.

Keep property values low-cardinality and stable. A property holding a raw URL or a free-text string is a column you cannot group by, which makes it decoration rather than data.

Autocapture and explicit events answer different questions

Autocapture records interface interactions without asking you to plan, which is genuinely useful early: it means the data for a question you had not thought of yet is already there, and it removes the deploy from the loop. What it cannot do is know your domain. Nothing in a click stream knows that a subscription was upgraded.

The workable arrangement is both: autocapture for exploration and for the questions you have not asked yet, a short list of explicit, well-named domain events for the numbers you report on and set goals against.

Where to start this week

Write down the five moments that matter most in your product, name them with the convention above, and instrument only those. Then check a week later that each one fires when you expect and that its properties are populated — an event that fires on a code path nobody uses is worse than no event, because it will be trusted.

If you want to see how the events you already send are behaving before adding more, event tracking in PulsePanda shows every event, its volume and its properties in one place, and feeds the same data straight into funnels and paths.