पाठशाला Pathshala · उत्पाद Utpād, The product · Lesson 15 · Build
Instrumenting the product: the twelve events that matter
Early analytics is usually nothing or everything. Twelve named, owned and tested events answer the questions that decide a young company, and keep the data trustworthy as it grows.
Pathshala, The Founder Library · 11 October 2026 · 7 min read
Most young companies have one of two analytics problems. Either nothing is tracked and every product argument is settled by whoever speaks last, or everything is tracked by an autocapture script and nobody trusts any chart because three events mean the same thing and one of them broke in May. Twelve events, chosen on purpose, beat both.
This lesson starts from the questions a founder needs answered, maps them to about twelve events across five stages, sets the naming and identity rules that keep the data clean, decides where each event should fire, and ends with a one-page tracking plan and a weekly check that keeps it honest. The figure gives a starting plan for three kinds of product.
Questions before events
An event is worth tracking when someone will make a decision from it. For a company before Series A the decisions come from five questions. Where do people arrive from? Do they reach the moment the product is for, the activation milestone in the [activation lesson](/library/activation-first-session-that-decides)? Do they keep coming back, which is the [retention curve](/library/retention-curves-and-flattening-test)? Do they pay, and how much? When they leave, why? Every event in the first plan should answer one of those, and most should feed the input tree under the [north star metric](/library/north-star-metric-and-its-input-tree).
Mixpanel’s guidance on tracking plans makes the same point from the vendor’s side: prioritise the most critical data based on your strategy and KPIs, then iterate, and note that tracking everything a user can do leads to unnecessary development effort. The cost is not only engineering. Every extra event is one more thing that can silently break and one more name a new analyst has to learn.
Twelve events across five stages
Arrive: two events, the account created with the channel it came from, and the first piece of setup that shows intent, a workspace, an address, an install from a campaign. Activate: three events that bracket the aha moment: the step before it, the moment itself flagged as the first, and the action that spreads it, such as inviting a teammate. Use: three events for the repeated core action and the habits around it; these are what the retention curve is drawn from. Pay: two events, the moment a user meets the price and the moment money moves. Leave: two events, cancellation with a reason and deletion of the account.
Twelve is not magic; it is the size at which one engineer can own the whole plan, test every event before each release and explain every chart. A company with two products or a two-sided marketplace may need sixteen. A company with sixty has stopped choosing.
Autocapture, the script that records every tap and page view without anyone naming anything, still has a place. It answers questions nobody thought to ask in advance: which screen people abandon, which button they tap that does nothing. Treat it as a search tool, not as the source of truth. The twelve named events are what the board deck, the cohort chart and the activation rate are built from, and they should never depend on a CSS class name that a designer changes on a Tuesday.
Switch between the three products and notice how little changes in shape. The names differ but every plan has an activation event flagged as the first of its kind, a repeated core action, a payment event with an amount, and a leaving event with a reason. Those four are what investors ask about in the [weekly metrics review](/library/weekly-metrics-review-one-page-one-hour) and what the cohort charts are made of.
Names, properties and identity
Twilio Segment’s naming guide recommends an object-action framework, Product Viewed or Application Installed, and states a preference for Proper Case event names with snake_case properties. Its first rule matters more than the choice itself: pick a single naming framework and stick with it. PostHog’s best practices prefer snake_case throughout and present-tense verbs. Both are fine. Mixing them is not, because every analytics tool treats Invoice Sent and invoice_sent as two different events.
Never put a variable value in an event name. Segment’s example is an email address inside the name of a sign-up event; the value belongs in a property, and the guide warns that dynamic event names will also make analytics bills get out of control. Put amounts in rupees as numbers, not formatted strings. Use a small fixed list of values for any property you will group by, such as reason or plan, so that “too costly” and “too expensive” do not become two reasons.
Identity is where most early data quietly breaks. PostHog warns that if identify is not called at the right time, events from before login will not be connected to the user who logged in, and that an ID formatted two ways creates two people. Call it at sign-up and every sign-in, with the same internal user ID across web, Android and the server.
Where each event should fire
Events that change money or state, a subscription started, a payment completed, a booking confirmed, an account deleted, should be sent from your server when the change is committed. PostHog notes that ad blockers can stop events from the browser and recommends backend tracking where accurate counts matter. On a budget Android phone with a patchy connection the loss is worse: the app may be closed before the event is sent. Events that exist only in the interface, such as a paywall viewed or a report opened, fire from the client because the server never sees them.
When a flow changes enough that old and new numbers are not comparable, give the event a new version rather than redefining it. PostHog’s example is a registration_v2 prefix; the effect is that last quarter’s chart still means what it meant.
The tracking plan and its owner
Amplitude’s documentation defines a tracking plan as the document that defines every event and property you collect, why you collect each one and which source emits it. For twelve events that is one page: event name, stage, the question it answers, the properties and their allowed values, client or server, and the engineer who owns it. Agree names before implementation, so that the product lead, the engineers and whoever analyses the data use one schema.
Make instrumentation part of the definition of done. A feature’s spec names the event that will show whether it worked, as the [spec lesson](/library/product-spec-engineers-want-to-read) asks, and the feature does not ship until that event fires correctly in staging. One engineer owns the plan. Adding an event means adding a row with its question; an event without a question does not get added.
Privacy belongs in the same document. Under the Digital Personal Data Protection Act, analytics on identifiable users is processing of personal data; the [DPDP lesson](/library/dpdp-act-what-it-requires-of-your-product) sets out notice, consent, retention and deletion. In the plan that means no phone numbers, names, Aadhaar or PAN in any property, an internal ID instead, a stated retention period, and an Account Deleted event that triggers deletion in the analytics tool as well as in the database.
A worked example: the week activation fell
A Hindi-first learning app in Jaipur defines activation as Lesson Completed with is_first true inside the first day. In one week the rate falls from 38 to 29 per cent and the team spends two days redesigning onboarding before anyone checks the event. The cause is mundane. A release added a short celebration animation after the first lesson, the event fired when the animation ended, and users who closed the app as soon as the lesson finished were never counted. Nothing about learning had changed; the measurement had.
Three changes follow. Lesson Completed moves to the server and fires when the lesson’s last answer is saved. The tracking plan gets a column saying which code path fires each event, so a release that touches it is flagged in review. And the weekly health check gains a rule: any core event that moves by more than a quarter in a week is investigated as a tracking fault before it is discussed as a product result. Activation, recomputed from the server event, turns out to have been 37 per cent all along.
An event without a question does not get tracked. A question without an event does not get answered.
The weekly event health check
Every Monday, ten minutes, the owner looks at three things. Volume: each of the twelve events against last week, and any that moved by more than a quarter without a launch to explain it, because a sudden drop is usually a broken event rather than a broken business. Integrity: the count of events with a missing property or an unknown value in a fixed list. Strays: any event name that is not in the plan, which means someone shipped tracking without a row. Fix what broke this week. Once a quarter read the plan from the top, delete events nobody has looked at, and add the one question the team kept failing to answer.
The three plans are starting points to adapt, not standards, and the Jaipur example is illustrative. Nothing here is legal advice; read the DPDP lesson and its sources before collecting personal data.