Analytics Event Naming Conventions for Mobile Apps (2026)

Analytics events are easy to add and hard to maintain. Every indie app eventually has the same problem: a sprawl of inconsistent event names from "user_signed_in" to "userLoggedIn" to "auth_success" all meaning the same thing.

This is the working naming convention.

The convention

Pattern: noun_verb

Use noun_verb (snake_case) for all events:

app_opened
onboarding_started
onboarding_completed
paywall_seen
trial_started
subscription_purchased
feature_used
session_ended

Why not verb_noun (e.g., "started_trial")? Both work; pick one and stick with it. noun_verb (subject_action) reads more naturally for analytics queries: "events where the noun is trial" → all trial-related events.

Casing: lowercase snake_case

• ✅ user_signed_up
• ❌ userSignedUp
• ❌ User_Signed_Up
• ❌ user-signed-up

Most analytics tools handle both, but inconsistency in your own dataset is the real problem.

Tense: past tense for completed actions

• ✅ paywall_dismissed
• ✅ feature_viewed
• ❌ paywall_dismiss
• ❌ viewing_feature

Past tense indicates "this happened." Current tense / verb forms confuse aggregation.

The minimum set

If you instrument nothing else, instrument these:

Session events

app_opened
app_backgrounded
session_started
session_ended

Onboarding

onboarding_started
onboarding_step_completed       (with `step_name` property)
onboarding_completed
onboarding_abandoned

First-value actions

first_<feature>_used            (e.g., first_workout_logged, first_note_created)
aha_moment_reached

Engagement events

feature_used                    (with `feature_name` property)
content_viewed                  (with `content_id`, `content_type`)
session_completed

Conversion events

paywall_seen                    (with `paywall_variant`, `trigger`)
paywall_dismissed
trial_started
subscription_purchased          (with `subscription_tier`, `price`)
subscription_renewed
subscription_canceled
subscription_paused

Crash / error events (often handled by Crashlytics / Sentry)

error_occurred                  (with `error_name`, `screen`)
crash_recovered

That's ~25 events. Most indie apps need this set plus 5-10 app-specific events.

User properties

These travel with every event:

Required

user_id
acquisition_source       (organic, search-ads, meta, tiktok, google-ads, referral, etc.)
country
language
app_version
device_type              (iphone, ipad, android-phone, android-tablet)
os_version

Optional but useful

subscription_status      (free, trial, paid, lapsed)
plan_tier                (basic, pro, premium)
days_since_install
total_sessions
first_session_date

Computed / derived

These usually populate from your analytics tool, not your app SDK:

country_tier             (tier-1, tier-2, tier-3)
cohort_week              (the week they installed)
acquisition_channel_group (paid, organic, viral)

What NOT to track

Don't track every tap

Tap-level tracking explodes event volume. Track meaningful actions (paywall_seen) not button presses (paywall_button_tapped).

Don't track PII

• Email addresses
• Phone numbers
• Real names
• Birthdays (unless you really need this for cohort analysis)

PII in analytics violates many privacy frameworks and isn't useful for product decisions anyway.

Don't track high-cardinality fields as event names

• ❌ user_searched_pizza, user_searched_burger, user_searched_sushi (3 events)
• ✅ search_performed with property query="pizza" (1 event, many values)

Event names are cardinal — you don't want thousands.

Property naming

Properties travel with events. Same rules apply:

• screen_name not screenName
• subscription_tier not tier
• paywall_variant not variant

Be specific. "tier" alone is ambiguous; "subscription_tier" tells future-you what it means.

Versioning your taxonomy

When you change event definitions:

Don't rename existing events

Renaming feature_used to feature_used_v2 breaks all historical queries. Instead:

1. Keep old event firing.
2. Add new event with new name.
3. Update queries to use new event.
4. Eventually deprecate old event (after a quarter or two).

Document changes

Maintain a CHANGELOG or shared doc:

2026-05-19: Added `feature_used_with_context` event. New parameter `referrer_screen`. 
2026-05-30: Deprecated `random_event_v1`. Use `random_event` instead.

Sample taxonomy doc

A working template for an indie subscription app:

APP_OPENED
  Properties: launch_source
  
SESSION_STARTED
  Properties: session_id
  
SESSION_ENDED
  Properties: session_id, session_length_seconds, screens_viewed

ONBOARDING_STARTED
ONBOARDING_STEP_COMPLETED
  Properties: step_name, step_number
ONBOARDING_COMPLETED
  Properties: total_steps, total_time_seconds
ONBOARDING_ABANDONED
  Properties: last_step

PAYWALL_SEEN
  Properties: paywall_variant, trigger, source_screen
PAYWALL_DISMISSED
  Properties: paywall_variant
TRIAL_STARTED
  Properties: trial_variant, paywall_variant
SUBSCRIPTION_PURCHASED
  Properties: tier, price, currency, period
SUBSCRIPTION_RENEWED
SUBSCRIPTION_CANCELED
  Properties: cancellation_reason
SUBSCRIPTION_PAUSED

FEATURE_USED
  Properties: feature_name, source_screen
CONTENT_VIEWED
  Properties: content_id, content_type, source

SEARCH_PERFORMED
  Properties: query, results_count

ERROR_OCCURRED
  Properties: error_name, screen, severity

Adapt to your app. The structure is what matters.

How to roll out

For a new app:

1. Write the taxonomy doc first.
2. Implement the minimum set in your first build.
3. Don't add events for 30 days.
4. Audit what events you're actually using.
5. Add only events that answer specific questions.

For an existing app:

1. Audit existing events. List them.
2. Map inconsistent variants to canonical names.
3. Add aliases in a transformation layer (Mixpanel, Amplitude both support this).
4. Don't break historical data.

Common mistakes

• No naming convention. Inconsistency from day 1.
• Tap-level tracking. Event volume explodes.
• PII in events. Privacy + compliance + useless for product.
• High-cardinality event names. "search_pizza", "search_burger" instead of "search_performed" with query property.
• No documentation. New team members can't tell what events mean.
• Mixing tenses. "user_signs_in", "user_signed_up", "user_will_subscribe" — pick one tense.
• No user properties. Can't segment effectively.

Run the audit

Analytics events are only as valuable as your ability to use them. The discipline of naming them well compounds.

See mobile analytics tools comparison for tool choices.

Related reading

• Mobile Analytics Tools Comparison
• DAU, MAU, and Cohort Retention Explained
• Mobile App Onboarding Optimization
• Mobile App Churn and Retention
• Freemium Conversion Rate Optimization

Try the tools

• Ad Analytics Calculator
• Free ASO audit