Every team that decides to "measure the product" faces the same temptation: tracking everything. Every click, every screen, every scroll. The logic seems solid, it's better to have the data and not need it than to need it and not have it.
It's a trap. Tracking everything does not create clarity; it generates a swamp of events that no one can interpret, with a hidden cost of maintenance, privacy and trust in the data itself. Those who track everything tend to understand little.
Here's a quick guide to doing the opposite: tracking little and tracking right. The central idea is that a good event is what answers a question you actually have, and anything that doesn't answer a question is data debt disguised as prudence.
What is event tracking, in one sentence
Event tracking is the recording of the actions that people take within a product: started a registration, completed a purchase, activated a feature, abandoned a flow.
Unlike aggregate metrics like total users, events capture granular behavior, what each person did, in what order, at what time. It is this granularity that allows us to answer deep questions: where people give up, what distinguishes those who stay from those who disappear, which path leads to value.
The problem is never the lack of events. It's the lack of criteria to choose which ones are worth capturing.
The question comes before the event
The rule that organizes everything else: never define an event without first defining the question it answers.
"How many people complete the registration?" is a question. It justifies tracking the beginning and completion of registration. "Where do people abandon checkout?" is a question. It justifies marking each step of the checkout.
"Let's track all clicks because it might be useful" isn't a question, it's anxiety. And anxiety generates the swamp. When you start from the question, the set of necessary events becomes small, clear and directly linked to the decision.
This is the most valuable shortcut in this guide: if you can't tell what decision an event will inform, don't track that event yet.
Linking events to KPIs without getting lost
Events are the raw material; KPIs are what you get out of it. The link between the two needs to be deliberate.
Think in three quick layers:
- Raw events: the individual actions (clicked, opened, completed).
- Funnels and flows: sequences of events that show a path (registration → activation → first purchase).
- KPIs: the numbers that summarize whether the product is doing well (activation rate, retention, conversion).
The mistake of those in a hurry is to jump straight to the KPI without drawing the events that support it, and then the number becomes fragile, impossible to investigate when something changes. The opposite mistake is getting lost in the raw events without ever moving up to the KPI that matters. The quick guide is: design the KPI, identify the funnel that leads to it, track only the events in that funnel.
There is a little obvious benefit to this discipline. When the KPI drops, well-designed tracking allows you to move down from the aggregate number to the specific event where people started to drop out. Without this chain, you only know that something got worse, not where or why, and investigating becomes blind digging. Tracking with the funnel in mind is, in essence, leaving a map ready for the day something goes wrong.
Properties matter as much as events
Beginners tend to treat an event as a simple “it happened”. But the real value is in the properties that accompany each event, the context that transforms a generic record into something searchable.
A "purchase completed" event alone says little. The same event with properties such as product category, source channel and whether it was the user's first order allows segmentation, comparison and understanding. The difference between a shallow trace and a useful one is almost always in the properties, not the number of events.
The quick caution here: capture the properties that answer questions, not everything that's available on the screen. And never put sensitive data inside a property just because it was easy, event property is one of the places where personal data ends up leaking to systems that shouldn't have it.
Appoint with discipline from day one
A detail that seems minor and expensive: the way you name events. Without a pattern, in a few months you have "purchase_made", "Purchase", "checkout_completed" and "purchase", all meaning the same thing, all getting in the way of analysis.
Correction later is painful, sometimes impossible, because historical data is not renamed for free. Therefore, even in a quick guide, the rule applies: define a naming convention before creating the first event and follow it strictly. Naming consistency is the type of care that is cheap at the beginning and very expensive later.
Tracking comes up against LGPD, and that's quick to say
You can't talk about tracking in Brazil without talking about privacy. Each event that records a person's behavior is the processing of personal data, and this triggers LGPD.
The quick message: track with stated purpose, not for accumulation. Collecting behavior “just in case”, without a legal basis or clear purpose, turns your analytics system into a legal liability. The discipline of only tracking what answers a question already solves a lot of this, because a clear purpose is exactly what the law requires.
Tracking less, therefore, is not only analytically cleaner. It's more legally defensible.
The summary that fits on a card
If you only need to keep the essentials of this guide, there are four ideas:
Define the question before the event. Track only what informs a decision. Name it with a pattern from the beginning. Treat each event as personal data under LGPD.
With this, you avoid the swamp that drowns most teams and build a lean, reliable and useful database. Good tracking isn't what captures the most; It's what captures enough for you to understand the product without drowning in the data itself.
One last mental shortcut that helps those just starting out: Treat each new event as a small maintenance commitment, not a free windfall. Every event needs to be checked, documented and reviewed when the screen changes. Seen this way, the question "is this worth tracking?" gains weight, because you start to see the cost, and not just the apparent benefit. Teams that internalize this vision grow with tracking that remains reliable; Those who see the event as something free end up drowning in what they thought was taken care of.
If your team is setting up or redoing the tracking and suspects that it is collecting too much, it is worth a conversation before instrumenting. On the blog there are other texts about product metrics and data that delve deeper into each of these ideas.