A measurement plan often begins tidy and becomes difficult to trust as an app grows. The problem is rarely the number of events alone. It is the absence of shared rules for why events exist, how they are named, and who keeps them healthy.
Start with decisions
Write down the product decisions the data should support. A decision such as “which onboarding step deserves redesign?” creates a clearer tracking requirement than “track onboarding.” Each event should connect to a known question or operational need.
Name the user action, preserve the context
Stable event names describe an observable action. Properties carry the changing context: source, plan, screen, content type, or experiment assignment. This prevents a separate event from appearing for every interface variation.
Treat ownership as part of the schema
Document the producing surface, accountable team, expected properties, and validation status. Review changes during product delivery, not months later during an analysis. A short governance habit protects more value than a large one-off cleanup.
Every app has its own cadence, user intent, and technical constraints. Apply these ideas as a starting framework, then test the definitions against your product context.