Firebase Event Naming Guide

Why Event Naming Matters

Let’s be blunt:

• You name events however you want → data inconsistency
• Devs use different names across iOS and Android → attribution breaks
• You track 300 different variations of signup_success, userSignedUp, and completed_signup → no-one trusts the data

Firebase doesn’t care what you name events. But your reports do. Want clean funnels? Consistent metrics? Long-term scalability?

Firebase’s Rules for Custom Event Names

Firebase lets you create custom events, but it enforces some rules. Break them, and you’re left shouting into the void:

• Max length: 40 characters
• Only alphanumeric + underscores (e.g., button_click, not button-click)
• Must start with a letter
• Cannot use reserved names (like ad_click, app_update, first_open)

Now let’s talk actual naming strategy.

✅ The Golden Rules of Firebase Event Naming

1. Be Verb-First

Start with the action, not the object. This isn’t poetry.

Bad: product_view
Good: view_product

Bad: video_start
Good: start_video

This keeps the list alphabetised by user intent, not asset type.

2. Be Consistent Across Platforms

If Android fires submit_form and iOS fires form_submit, Firebase sees two events. Your reports fracture.

Fix: Maintain a shared event dictionary. One name, one meaning, one result.

3. Don’t Encode Parameters into Event Names

Stop doing this:

viewed_product_red_shoes_large


Instead:

logEvent('view_product', {
 product_name: 'Red Shoes',
 size: 'Large'
});


Use parameters for details, not your event name.

4. CamelCase or snake_case - Pick One

Don’t mix:

loginSuccess  // camelCase
login_success // snake_case


Firebase doesn’t care. Your team will.

Example: Clean Event Naming for a Shopping App

Event: view_product

Parameters: product_id, product_name, category

Event: sign_up

Parameters: method

The pattern is simple:
Action_Object, with parameters doing the heavy lifting.

Debugging Tip: Use DebugView Before You Regret It

Before you push events live, test in DebugView:

adb shell setprop debug.firebase.analytics.app your.package.name

This shows you exactly what Firebase is receiving, no surprises later.

⚠️ Naming Mistakes That Will Haunt You

1. Duplicate events with different names → can't build funnels
2. No naming convention → analytics team quits
3. Parameters instead of events (or vice versa) → messy data
4. Tracking too many one-off events → sampling, quota issues
5. No shared dictionary → tribal knowledge = chaos

Pro Tip: Create an Event Naming Convention Doc

Make a living doc. Include:

• Allowed event names (with descriptions)
• Parameters required/optional
• Example payloads
• Platform consistency checks

Pin it to your Slack. Lock it in your onboarding.

Final Words: Name Like a Pro, Track Like a Boss

Firebase doesn’t forgive stupidity. If your event naming is a mess, your whole analytics layer is rotten.

So set rules. Enforce consistency. Track intentionally.