Event naming best practices for mobile analytics: Use snake_case with an object_action pattern (e.g., screen_viewed, purchase_completed). Add namespace prefixes to group related events (checkout_, onboarding_). Never embed dynamic values in event names. Document every event in a shared dictionary.
๐ฏ Why Event Naming Matters More Than You Think
In most analytics platforms, event names are one of dozens of fields you can customize. You might spend hours debating what properties to attach, what user attributes to capture, what segments to create.
In minimal-data architecturesโwhere you deliberately limit what you collectโevent names carry all the semantic weight. They're not just labels; they're your entire vocabulary for understanding user behavior.
The 5-Field Reality
When your analytics stores only essential fieldsโevent name, timestamp, session ID, platform, and countryโthe event name becomes critical:
- โข No custom properties to add context later
- โข No user attributes to segment by
- โข No retroactive fixesโbad names stay bad
Get event naming right, and your analytics becomes a clear window into user behavior. Get it wrong, and you're staring at a list of meaningless strings.
๐ The Right Naming Format: snake_case + object_action
After analyzing thousands of event implementations, one pattern consistently produces the cleanest, most maintainable analytics: snake_case with an object_action structure.
| Format | Example | Verdict |
|---|---|---|
| snake_case (recommended) | purchase_completed |
โ Best |
| camelCase | purchaseCompleted |
โ Avoid |
| PascalCase | PurchaseCompleted |
โ Avoid |
| Spaces | Purchase Completed |
โ Never |
| kebab-case | purchase-completed |
โ Avoid |
Why snake_case Wins
- โข Database-friendly: Works in SQL queries without escaping
- โข Sortable: Alphabetical sorting groups related events
- โข Readable: Clear word boundaries at a glance
- โข Universal: Works across iOS, Android, web, and backend systems
The object_action Pattern
Structure your events as what was acted upon, followed by what happened:
โ Good (object_action)
screen_viewedbutton_tappedpurchase_completedform_submittedsearch_performed
โ Avoid (action_object or vague)
viewed_screentapbuysubmituser_action
๐๏ธ Namespace Prefixes for Organization
As your app grows, you'll have dozens of events. Without organization, your event list becomes unmanageable. Namespace prefixes solve this by grouping related events.
| Feature Area | Prefix | Example Events |
|---|---|---|
| Onboarding | onboarding_ |
onboarding_started, onboarding_step_completed, onboarding_finished |
| Checkout | checkout_ |
checkout_started, checkout_payment_entered, checkout_completed |
| Settings | settings_ |
settings_opened, settings_notification_toggled, settings_theme_changed |
| Search | search_ |
search_performed, search_result_tapped, search_filter_applied |
| Profile | profile_ |
profile_viewed, profile_edited, profile_photo_updated |
๐ก Pro Tip: Two-Level Namespaces
For larger apps, use two-level namespaces: checkout_payment_card_entered or onboarding_profile_photo_skipped. This keeps events organized even at scale.
โ ๏ธ 7 Common Event Naming Mistakes
1. Embedding Dynamic Values
Wrong: purchased_blue_widget, viewed_product_12345
Right: item_purchased, product_viewed
Dynamic values create thousands of unique events, making analysis impossible.
2. Inconsistent Tense
Wrong: button_click mixed with purchase_completed
Right: Always use past tense: button_tapped, purchase_completed
Events record what happened, not what's happening.
3. Being Too Granular
Wrong: Separate events for submit_button_tapped, cancel_button_tapped, back_button_tapped
Right: Single button_tapped event (context from screen/flow)
Too many events dilutes your data and makes dashboards unwieldy.
4. Being Too Vague
Wrong: action, event, user_action
Right: checkout_started, article_shared
Vague names require additional context you may not have.
5. Platform-Specific Language
Wrong: viewDidAppear, onActivityCreated
Right: screen_viewed (platform-agnostic)
Use terms that work across iOS, Android, and web.
6. Including PII in Event Names
Wrong: john_smith_logged_in, order_user123_placed
Right: login_completed, order_placed
Never put user identifiers, names, or IDs in event names.
7. No Documentation
Event names without definitions lead to confusion. Does checkout_completed fire before or after payment? When the button is tapped or when the server confirms? Document it.
๐๏ธ Building Your Event Taxonomy
A well-designed event taxonomy answers the questions that drive product decisions. Start with questions, then work backward to events.
Questions โ Events Framework
"Where do users drop off in onboarding?"
onboarding_started, onboarding_step_completed, onboarding_finished
"Which features do people actually use?"
feature_used (one per key feature)
"What's our checkout conversion rate?"
checkout_started, checkout_completed
"Is search useful or broken?"
search_performed, search_result_tapped
๐ Event Templates by App Type
Here are starter templates for common app categories. Adapt to your specific flows.
๐ E-commerce / Shopping App
search_performedcategory_viewedproduct_viewed
cart_item_addedcheckout_startedcheckout_completed
๐ฐ Content / Media App
article_viewedvideo_startedvideo_completed
content_sharedcontent_savedcomment_posted
โก Productivity / SaaS App
signup_completedonboarding_startedonboarding_finished
project_createdtask_completedexport_generated
๐ฎ Gaming App
level_startedlevel_completedachievement_unlocked
store_openedpurchase_startedpurchase_completed
๐ The Event Dictionary: Documentation That Works
An event dictionary is the single source of truth for your analytics. Without it, you'll have inconsistent implementations and unanswerable questions about what events mean.
Event Dictionary Template
| Event Name | When It Fires | Question It Answers |
|---|---|---|
onboarding_started |
User sees first onboarding screen | How many sessions begin onboarding? |
onboarding_finished |
User completes last onboarding step | What's our onboarding completion rate? |
checkout_started |
User taps "Checkout" from cart | How many cart sessions convert? |
checkout_completed |
Server confirms payment success | What's our checkout conversion rate? |
๐ก Keep It Simple
Store your event dictionary in a shared document (Notion, Confluence, even a README). The format matters less than having a single, accessible source of truth that everyone references.
๐ Versioning and Migration
Eventually, you'll need to rename or restructure events. How do you handle this without breaking historical data?
Option 1: Add New, Deprecate Old
The safest approach: add the new event alongside the old one, run both for a transition period, then remove the old event.
Week 1-2: Ship new event checkout_completed alongside old purchase_done
Week 3-4: Update dashboards to use new event
Week 5+: Remove old event from codebase
Option 2: Version Suffixes (Use Sparingly)
For major restructures, version suffixes can help: checkout_completed_v2. But this gets messy fastโprefer Option 1.
Warning: Avoid frequent renaming. Every change requires code updates across iOS, Android, and any other platforms. Get naming right upfront.
๐ก Why Event Naming Matters Even More with Respectlytics
Respectlytics stores only 5 fields per event: event name, timestamp, platform, country, and session ID. There are no custom properties to add context after the fact.
This constraint is intentionalโit's the Return of Avoidance (ROA) approach. But it means your event names must be self-documenting. A well-named event like checkout_payment_failed tells you everything; a vague error tells you nothing.
โ Frequently Asked Questions
What is the best naming convention for analytics events?
Use snake_case with an object_action pattern: screen_viewed, button_tapped, purchase_completed. This format is readable, sortable, and works across all platforms without escaping issues.
How many analytics events should a mobile app track?
Most apps need 15-30 well-designed events. Track key user actions (signup, purchase, feature use), funnel steps (onboarding, checkout), and engagement indicators (content viewed, search performed). More events create noise; fewer miss insights.
Should analytics event names include dynamic values?
No. Never put dynamic values like user IDs, item names, or prices in event names. This creates thousands of unique events and makes analysis impossible. Use a fixed event name like item_purchased rather than purchased_blue_widget_29.99.
How do you organize analytics events by screen or feature?
Use namespace prefixes: onboarding_step_completed, checkout_payment_selected, settings_notification_toggled. This groups related events in alphabetical lists and makes ownership clear.
What are common mistakes in analytics event naming?
Common mistakes: using past tense inconsistently (clicked vs click), embedding dynamic data in names, being too granular (separate events for each button), being too vague (user_action), and not documenting what events mean.
Disclaimer:
This guide provides general best practices for event naming. The right approach depends on your app's specific features, team size, and analytics goals. Test different patterns and adapt to what works for your situation.
Related Resources
- Mobile App Metrics That Matter โ Essential KPIs for mobile apps
- Why We Killed Custom Event Properties โ Why constraints make analytics safer
- How We Auto-Discover Conversion Paths โ Good event names enable automated insights
- SDK Documentation โ Integration guides for Swift, Kotlin, Flutter, React Native