Skip to main content

Why Event Naming Matters

Inconsistent event names make your analytics confusing and hard to query. Imagine trying to find all signup-related events when they’re named:
  • signup_clicked
  • button_signup_click
  • user_registered
  • sign_up_button
A systematic naming convention solves this by making events:
  • Clear: Anyone can understand what happened
  • Consistent: Similar actions follow the same pattern
  • Queryable: Easy to filter and group on the backend

The Convention: Hierarchical Naming

Use this format for custom events:
Example: user_signup_clicked
  • Category: user_ (what domain)
  • Object: signup (what thing)
  • Action: clicked (what happened)
This hierarchical structure enables powerful wildcard queries:
  • All user events: user_*
  • All signup actions: *_signup_*
  • All clicks: *_clicked

Categories

Choose the category that best describes the domain of the event:
Can’t find the right category? Use the most specific domain that fits. For edge cases, prioritize clarity over perfect categorization.

Actions

Use standard action verbs that clearly indicate what happened:

Interaction Actions

  • clicked - User clicked/tapped an element
  • submitted - User submitted a form
  • opened - User opened a modal, menu, or expandable
  • closed - User closed a modal, menu, or expandable
  • toggled - User toggled a switch or option

CRUD Actions

  • added - Item added to collection
  • removed - Item removed from collection
  • updated - Item modified
  • deleted - Item permanently removed

Progress Actions

  • started - User began a process
  • completed - User finished a process
  • failed - Action failed
  • cancelled - User cancelled an action

View Actions

  • viewed - User saw a page or section
  • scrolled - User scrolled to a section
  • hovered - User hovered over an element

Complete Examples

E-commerce Site

SaaS Platform

Content Site

Quick Reference Decision Tree

Integration with Template Events

Template events (provided by the SDK) use simple names and should NOT be renamed:
System events (starting with _grain_) are internal and managed by the SDK:
  • _grain_session_start
  • _grain_session_end
  • _grain_heartbeat
  • _grain_consent_granted
Never create custom events starting with _grain_ - this prefix is reserved for internal SDK events.

Query Benefits

The hierarchical naming convention makes your analytics more organized and discoverable:

Event Discovery

When you list all events in your dashboard, hierarchical names group logically:
Events naturally sort alphabetically by category, making it easy to find related events.

Query Specific Events

Query individual events with clear, descriptive names:

Build Conversion Funnels

Create clear, logical funnels with consistent naming:

Dashboard Organization

Group related events in your analytics dashboard:

Filter Event Lists

When displaying events in UI, the hierarchical structure helps filter by category:

Common Patterns

Multi-step Flows

For processes with multiple steps, use consistent object names:

Errors and Failures

Include failure states for debugging:

CTA Tracking

Track calls-to-action with their location context:

A/B Testing

Include variant information:

Migration Guide

Adopting the Convention

If you have existing events with different naming:
  1. Map old events to new convention:
  2. Track both during transition:
  3. Update queries and dashboards to use new event names
  4. Deprecate old events after migration period (30-90 days)

Backward Compatibility

The SDK supports all event names, so existing events continue to work. Migrate at your own pace:
  • Option 1: Migrate all at once (small codebases)
  • Option 2: Migrate feature-by-feature (large codebases)
  • Option 3: New events use convention, legacy events remain
Use the Query API’s event list endpoint to audit your current event names and plan your migration strategy.

Edge Cases

When the Convention Doesn’t Fit

The convention covers 90% of use cases, but when it doesn’t fit: Option 1 - Be specific with object:
Option 2 - Use descriptive custom name:

Very Long Event Names

Keep names under 50 characters when possible. If a name is too long, abbreviate the object:

Mobile App Events

The convention works for mobile apps too:

Best Practices Summary

  • Use {category}_{object}_{action} format for custom events
  • Choose the most specific category that fits
  • Use standard action verbs (clicked, viewed, submitted)
  • Include context in properties, not in the event name
  • Keep names under 50 characters
  • Use past tense for actions
  • Test event names in queries before deploying
  • Don’t rename template events (login, signup, purchase)
  • Don’t create events starting with _grain_
  • Don’t encode data in event names (product_123_viewed ❌)
  • Don’t use ambiguous verbs (process, handle, do)
  • Don’t mix naming styles in the same app
  • Don’t create redundant events with slight variations
  • Don’t include timestamps or IDs in event names

Event Name Checklist

Before tracking a custom event, verify:
  • Does it follow {category}_{object}_{action} format?
  • Is the category from the standard list?
  • Is the action verb clear and standard?
  • Is the name under 50 characters?
  • Does it avoid conflicts with template events?
  • Will it group well with related events in queries?
  • Can someone else understand it without context?

Next Steps

Event Properties

Learn what properties to include with events

Template Events

Use pre-built events for common actions

Query API

Query events using the naming convention

Examples

See the convention in real applications

Need Help?

Questions about event naming?