Skip to main content
Docs·Concepts·Events

Naming events that won't bite you in 6 months

Conventions from teams that learned the hard way — so you don't have to.

📖 3 min read·🎬 90s watch

Six months in, your event log is the most-queried table you have. Naming matters. Here's the convention that holds up under real load.

Rule 1: snake_case, past tense, subject_verbed

  • Good: user_signed_up, checkout_completed, video_finished, invite_accepted.
  • Bad: Signup, signupEvent, SignUp_v2, CheckoutFlow_StepThree_Completed_Final.

Rule 2: status goes in a property, not the name

One event: payment_attempted with a property { outcome: "succeeded" | "failed" | "pending" }. Not three events: payment_succeeded, payment_failed, payment_pending. The query "how often does payment fail?" gets answerable in one line instead of three.

Rule 3: never put IDs or timestamps in the name

user_signed_up_v2 is fine (you'll have a v3 eventually). user_signed_up_user_12345 is a debugging mess. Always put the IDs in properties.

Rule 4: page_viewed is a system event, not yours

Sheepit auto-captures page views, clicks, and sessions. Don't ship your own. (And if you do, you'll fight us in queries forever — there will be two columns called "page" and they'll mean different things.)