Naming events that outlive the sprint

Event names fail in predictable ways. Someone encodes a screen (“home_v3_cta_tap”). Someone encodes a hope (“user_love”). Someone copies a vendor example (“select_item”) and then spends a year explaining that it fires on a filter chip. The original author always knows what they meant. The contractor in eighteen months does not. App Analytics is mostly written for that contractor.

Our house pattern is dull on purpose: object, action, outcome — in that order — in snake case, in English, without the version of the UI. checkout_started. checkout_payment_failed. route_saved. We keep tense consistent. We do not mix “click” and “tap” to reflect platform pride; the user acted. The property platform can hold iOS or Android. The name should not.

Properties carry the detail that names cannot. An enum for source is better than five events that differ only by entry point. An enum that grows to thirty values is a smell: you probably wanted two events. In Event Schema Craft we print the enum and ask which values a new engineer could invent without asking Slack. If the answer is “most of them,” the taxonomy is a junk drawer.

Deprecation needs a date and an owner, not a strikethrough in a wiki. We keep the old event firing for a documented overlap, then we stop, then we wait a billing cycle before anyone deletes history. Teams that skip the overlap invent a dip and then staff a war room. That war room is more expensive than two extra weeks of dual writing.

The social part is the part vendors cannot ship. A weekly fifteen-minute dictionary review, with the power to reject a name, does more than a tracking-plan tool. If product can add an event without that review, you do not have a taxonomy. You have a log. Logs are useful. They are not App Analytics.