Product analytics decays in a predictable way. A tool is installed, events are added as features ship, and eighteen months later there are hundreds of event types with inconsistent names, overlapping meanings and unknown reliability. When someone finally asks a straightforward question - what share of signups complete onboarding - the honest answer is that the data cannot support it.
The cause is instrumenting bottom-up: adding an event whenever something happens. The alternative is to start from the questions. Write down the ten things the business will actually want to know, work out which events answer them, and instrument exactly those. Ten well-defined events answer more questions than four hundred arbitrary ones, and they can be maintained.
Then impose a naming convention before the first event ships. Object-action in a consistent tense - order_completed, invoice_downloaded, trial_started - applied without exception. Without a convention you end up with clicked_signup, SignupClick and signup_button_pressed as three separate events meaning the same thing, recorded by three different developers over two years, and every analysis has to know all three exist.
Keep properties on events rather than proliferating event types. One checkout_completed event with properties for payment method, currency and item count is analysable; separate events for each payment method is not, because every new method requires updating every query. The general rule is that the event says what happened and the properties say the details.
Maintain a tracking plan as a document with an owner - event name, when it fires, its properties and their types, and who to ask. Review new events against it in code review. This is unglamorous and it is the entire difference between analytics that is trusted and analytics that everyone quietly stops using because the numbers never quite match.
Two obligations that come with the territory. Test that events actually fire, in a staging environment, because analytics code is not covered by your test suite and breaks silently - the first sign is usually a metric that flatlines and gets noticed weeks later. And treat what you collect as personal data, because it is: identifiers, behaviour and device information in a third-party tool are within the scope of DPDP and GDPR, they need a lawful basis and a retention policy, and they must be deletable when a user asks.
