Event names that survive a product rebuild

Event names are easy to treat as plumbing until the product changes. Then a button gets renamed, a modal becomes a page, a step becomes optional, and the analytics plan starts lying in small ways.

The problem is usually not tracking. The problem is naming events after the interface instead of the behavior.

If the event is called clicked_blue_button, the event expires the moment the button changes color or the flow gets redesigned. If the event is checkout_started, the event can survive several interface versions because it describes a product moment.

Name the user moment

I like event names that follow a plain pattern: object plus action. Cart opened. Checkout started. Payment failed. Invite sent. Report exported.

The object should be something the business and product team understand. The action should describe a meaningful transition. Avoid names that encode the component: drawer_opened, modal_submitted, card_clicked. Those can be properties if they matter, but they should not be the event's identity.

This creates continuity. A cart can open from an icon, a sticky bar, a recommendation, or a keyboard shortcut. The event is still cart_opened because the user moment is the same.

Properties carry the context

When teams try to put every detail in the event name, taxonomy gets noisy fast. checkout_started_from_cart_drawer_mobile_discount_applied is not a durable event. It is a sentence pretending to be a key.

Use properties for context:

track("checkout_started", {
  source: "cart_drawer",
  device_class: "mobile",
  discount_state: "applied",
  cart_value: 8400,
});

This keeps the event stable while still allowing useful analysis.

Decide what should not be tracked

Tracking everything sounds safe, but it usually creates a warehouse full of low-signal events nobody trusts.

I start with questions. Where do people abandon onboarding? Which checkout errors are recoverable? Do users who invite teammates retain better? Which report exports lead to decisions? The event plan should answer those questions first.

If an event cannot support a decision, a product review, an experiment, support debugging, or compliance, it probably does not need to exist.

Version carefully

Sometimes a product rebuild changes the meaning of an event. Maybe checkout_started used to mean the first step loaded, but now it means the user confirmed shipping and payment options are available. That should not quietly reuse the old event.

There are two reasonable paths. Keep the same event and add a schema_version property when the meaning is close enough. Or create a new event when the meaning truly changes. The important part is making the change explicit before dashboards combine incompatible data.

Write the dictionary while the product is fresh

The event dictionary is not a documentation chore for later. It is the product contract.

For each event, document:

• What user or system moment triggers it.
• Which properties are required.
• Which properties are optional.
• Whether it can fire more than once per session.
• What questions the event is meant to answer.
• Which events it should be analyzed with.

That last line prevents lonely metrics. checkout_started matters with checkout_completed, payment_failed, shipping_option_selected, and cart_updated. Events become useful as a system.

The rebuild test

Before shipping a redesign, ask whether the event names still make sense if the UI changes again. If the answer is yes, the taxonomy is probably grounded in product behavior. If the answer is no, the team is tracking pixels instead of moments.

Good analytics naming is not about sounding tidy. It is about preserving meaning long enough for the team to learn from it.