In short
- Product analytics records events: named actions people take, with details attached.
- A short written tracking plan beats tracking everything. Name events after what the user did.
- Early products need a few things: a funnel for the main workflow, activation, and retention.
- Numbers show what happens. Talking to users explains why. You need both.
Also called: Event tracking, Analytics events, Tracking plan, Funnel analysis, Behavioral analytics.
How event tracking works
Page view counts tell you how many people visited. Product analytics tells you what they did. Each time someone takes an action that matters, the product sends an event with a name and some properties. Signed Up with the plan they chose. Project Created with the template they used. Invoice Paid with the amount.
Each event is tied to a user, so the tool can string events together. That is what turns raw clicks into answers: how many people who signed up last week created a project, how long it took them, and how many came back the week after.
From an action to a decision
- 01User actsCreates their first project
- 02Event sentProject Created, with properties
- 03Analytics toolJoins events into funnels
- 04Team decidesWhat to fix or build next
What to measure first
A new product does not need a dashboard of forty charts. It needs answers to three questions, and each one maps to a standard report.
| Question | Report | Example |
|---|---|---|
| Do people finish the main task? | Funnel | Signed up, then created a project, then shared it |
| Do they reach the moment of value? | Activation rate | Share of sign-ups who share a project within a week |
| Do they come back? | Retention by cohort | Of people who joined in March, how many were active in April |
Everything else, from feature usage to time on page, can wait until these three are working and trusted.
Writing a tracking plan
A tracking plan is a short document, often just a spreadsheet, that lists every event, what triggers it, and its properties. It keeps names consistent between web and mobile, makes the data readable months later, and gives engineers a precise spec.
- Name events after the user's action, in the past tense. Project Created, not button_click_3.
- Track outcomes, not every click. The moment a project is saved matters more than each click in the form.
- Send important events from the server. Payments and sign-ups recorded on the server are not lost to ad blockers or closed tabs.
- Keep personal data out of properties. Use an internal user ID rather than names or email addresses wherever you can.
Start with ten events
Ten well-named events tied to the main workflow are enough for most early products. Add more when there is a question that needs them.
At Choie, the people who design a workflow also write the code that ships it, so event names can be settled while the screens are still being decided, not added after.
Tools and privacy
Common tools include PostHog, Amplitude, Mixpanel, and Google Analytics. Some also offer session recordings, feature flags, and A/B testing. The choice matters less than the tracking plan, since good events can be sent to any of them.
Privacy rules apply. In the EU and UK, analytics that use cookies or similar identifiers generally need consent unless they fall under narrow exemptions, and the data you collect is covered by GDPR. Collect what you will use, say so in your privacy notice, and get advice if you are unsure.
Choie treats measurement as part of launch work: after a product goes live, the team watches what people do and fixes what gets in their way. It is also why every MVP should ship with a few events tied to its core workflow.
Common mistakes
- Tracking everything automatically. Auto-capture produces huge, noisy data that nobody can read without a plan.
- Inconsistent names. signup, Sign Up, and user_registered for the same thing, on three platforms.
- Adding tracking after launch. The first weeks of data are often the most useful, and they are gone if nothing was recorded.
- Vanity numbers. Total sign-ups only go up. Activation and retention show whether the product works.
- Reading numbers without talking to users. A drop in a funnel tells you where to look, not what is wrong.
Common questions
What is the difference between product analytics and web analytics?
Web analytics focuses on traffic: visits, sources, and pages viewed. Product analytics focuses on behavior inside the product: which actions people take, in what order, and whether they come back.
What is an event in analytics?
An event is a record that a user did something, such as signing up or creating a project, with details attached as properties. Events are the raw material for funnels, activation, and retention reports.
Which analytics tool should a startup use?
Any of the mainstream product analytics tools will do for an early product. Pick one with a free tier that fits your privacy needs, and spend the effort on a clear tracking plan instead.
When should we add analytics to our product?
Before launch. Defining the core events while the product is being built costs little, and it means you learn from the first users instead of waiting weeks for data. When Choie scopes a build, the written scope says whether measurement ships in the same release.