Instrumenting every click can seem like a way to avoid losing information. In practice, it often creates schemas that are difficult to maintain, noisy reports, and questions no one can answer with confidence. The problem is not having a lot of data; it is collecting actions without knowing which decision they will help you make.
To decide which events to measure in product analytics, start with a real decision: what would you do differently if the data showed one result rather than another? Then define the behavior that would let you observe it, the context you need, and how you will check that the measurement works. This order helps you build smaller, more useful instrumentation.
Start with the decision, not the event
Before adding an event, be specific about the product or business decision you need to make. You might prioritize an improvement, investigate a drop-off, change a flow, or check whether people are using a new experience. If no possible result would change your next step, the measurement is probably not a priority.
Write the question in a way that supports action. “Is the new feature working?” is too broad: it could refer to discovery, use, understanding, or impact. A more useful question might be: “What proportion of people who discover the feature complete its main action during their first week?” The question already points to the population, behavior, and time period you need to clarify.
It is also useful to note the possible answers and their consequences. If use is low, you might investigate whether the feature is visible; if many people try it but few finish, you might review the flow. Analytics does not make decisions for the team, but it should distinguish between scenarios that lead to different decisions.
Translate questions into observable behaviors
You cannot measure a question directly. You need to turn it into actions the product can record that reasonably represent the behavior you care about. For a question about task completion, for example, you might need to record when the task starts and finishes—not every cursor movement or intermediate click.
Define what counts as each action. “Registration completed” could mean that a form was submitted, that the server accepted the request, or that the account became available. Those moments are not equivalent. Choose the one that represents the outcome you want to study, and specify when it occurs, including error and retry cases.
An event is usually useful when it:
- Represents an action or state change that matters to the product.
- Helps answer a prioritized question rather than merely describing activity.
- Has a defined trigger and can be verified in a test.
- Justifies the cost of instrumentation through its maintenance and use.
Avoid ambiguous names such as “action,” “interaction,” or “success” unless everyone shares a clear definition. A specific, stable name such as “invitation sent” makes it easier for product, analytics, and engineering teams to understand the data in the same way.
Separate events, properties, and context
The event describes what happened. Properties add details about the event, such as the type of item selected or the result of an operation, provided those values help interpret the question. User or session context can help you analyze who performed the action or under what circumstances, but it should not be added by default.
For each property, ask what comparison it enables and whether that comparison could change a decision. A property with free-form, inconsistent, or mostly empty values can add complexity without helping you diagnose anything. Define types and allowed values where appropriate; also clarify whether a value can be missing and what that absence means.
Collect only the context you need. Personal or sensitive data requires particular care: review the purpose, permissions, applicable policies, and who can access it. Do not include identifiable information in event names or properties for convenience. If a category or status is enough, avoid capturing the original value.
A short specification for each event can record its name, purpose, trigger condition, properties, exceptions, owner, and the questions it is intended to answer. You do not need to turn every event into a lengthy document. What matters is that someone else can interpret its meaning without relying on the person who implemented it.
Prioritize by decision value and maintenance cost
The cost of an event does not end when it is released. Someone must maintain its definition when the interface changes, check that it is still being received, and explain its limitations in later analyses. That is why it is better to rank candidates than to instrument everything at once.
- Assess the decision: identify how important the question is and what action its answer would enable.
- Check observability: confirm that the behavior can be detected reliably and at the right point in the system.
- Estimate the cost: consider implementation, validation, permissions, data volume, and future maintenance.
- Start with the minimum that is sufficient: record the events and properties needed to distinguish relevant scenarios.
If a question has high value but cannot be answered with the available instrumentation, document the limitation and decide whether improving it is worthwhile. If the question has little value or no action is associated with it, defer it. This prioritization prevents “it might be useful someday” from becoming the usual reason to add data.
Validate complete journeys and look for signs of noise
Before using data to make decisions, test important journeys under representative conditions. Check that an event appears once when expected, fires after the intended outcome, and has properties that match what happened. Include alternative cases: errors, cancellations, retries, back navigation, and state changes.
An event that is missing on certain devices or paths can lead to biased conclusions. One that fires twice can inflate conversions. It is also a warning sign when different teams use the same name for different things, or when a property changes meaning without its definition being updated.
To find these problems, review event samples alongside real test journeys and compare the data with the expected behavior. When you find a discrepancy, first identify where the problem originates: the definition, implementation, transmission, or interpretation. Do not adjust a figure in a report without addressing the cause, because the same error may appear in other analyses.
Review the schema as the product changes
Instrumentation is not a project you complete once. A change to a flow, permissions, or business model can alter what an event means. Before changing it, review which analyses depend on it and whether keeping the same name would preserve the same meaning. If the behavior represented has changed, document the transition and avoid combining incompatible periods without a clear warning.
Schedule reviews around significant changes and product questions. Retire events that are no longer used, correct outdated definitions, and assign owners to events that support important decisions. The goal is not to have the smallest possible schema at any cost; it is to maintain measurement that is understandable, proportionate, and reliable.
In short, good instrumentation starts with a decision, records observable behaviors, and adds only the context needed to interpret them. Define edge cases, test journeys, and review the schema as the product evolves. That way, every event has a reason to exist, and the data is more useful for taking action.