Back to notes

October 14, 2026 · 4 min read

Event Naming Bikeshedding Costs More Than It Saves

I've sat in hour-long meetings about whether an event should be called add_to_cart or cart_add. The naming convention mattered less than everyone thought.

GA4Process

I sat through a 50-minute meeting once about whether a signup event should be called sign_up, signup, or user_registered. Three stakeholders had opinions. Nobody asked whether the parameters on that event were actually going to be populated correctly, which turned out to be the thing that broke two weeks later.

Naming conventions matter, but they matter at the level of 'pick one convention and apply it consistently,' not at the level of which specific words win. I've seen snake_case teams and camelCase teams both ship clean, reliable tracking, and I've seen teams with a beautifully bikeshedded naming doc ship events with missing required parameters because all the review time went into the name instead of the payload.

The actual cost of the bikeshedding

  • Time spent debating names is time not spent validating parameter completeness and types, which is where real bugs live.
  • Long naming meetings create false confidence — people leave thinking the tracking plan is 'done' because the names are settled.
  • Over-customized naming conventions make GA4's recommended-event auto-insights and benchmarking less useful, for no real gain.
  • Every naming exception agreed to 'just this once' becomes technical debt the next person has to reverse-engineer.
Nobody has ever lost a reporting accurate insight because an event was called sign_up instead of user_registered. Plenty of people have lost one because the event didn't fire at all.

What I actually enforce

Use GA4's recommended event names wherever your use case matches one — it's free alignment with Google's own benchmarking and reporting templates, and arguing against it for stylistic reasons is spending capital on nothing. For custom events, snake_case, lowercase, verb_noun structure, done. That's the whole decision, made once, in about five minutes, and then never revisited.

The time that debate would have taken goes instead into a parameter-by-parameter validation pass in DebugView, checking that every required field actually populates under every condition it's supposed to fire in. That's the review that catches real bugs. The naming review mostly just makes people feel like they contributed.