Naming things: the analytics edition
Event names are an API you publish to your future self. A short field guide to naming events you will not regret in a year.
There are two hard problems in computer science, and product analytics manages to hit the naming one twice: once when you instrument the event, and once a year later when nobody remembers what "clicked_thing_2" meant. Event names are an API you publish to your future self, and future you is a harsher reviewer than any teammate.
The convention we recommend — and enforce in our own codebase — is object_verb in the past tense: signup_completed, invite_sent, funnel_created. The object comes first so the event list sorts into readable clusters; the past tense states a fact rather than an intention. "checkout_clicked" tells you a button existed; "order_placed" tells you money moved. Only one of those survives a redesign.
Resist the lorem-ipsum temptation to encode context into the name. "signup_completed_from_pricing_page_mobile" is four events pretending to be one, and it will fragment your funnel the day a fifth surface ships. Context belongs in properties — source, device, plan — where it can be filtered, grouped, and added to without renaming anything.
Renames are where discipline pays. An event name, once shipped, is load-bearing: dashboards, funnels, and alerts all reference it as a string. Vertex treats renames as aliases rather than rewrites — the old name keeps resolving, the new name becomes canonical, and no chart silently flatlines because someone tidied up dolor sit amet spelling.
The test we apply before shipping any new event: read the name aloud to someone who has never seen the code and ask them what happened. If the answer takes more than one sentence, the name is wrong. Naming things is hard; renaming things in production is harder. Choose your hard.