Tracking user actions

Events are used to describe interesting actions that happen within your app. Unlike the default metrics Localytics collects, such as sessions, new users, or phone model, events are custom to each app and supplied by you. Events give insight to the specific in-app actions users take such as article reading or posting to a social network. Additionally, events are used in Funnels to determine drop off and conversion rates toward specific goals.

Events are also used to define User Segments that help identify different usage patterns and answer questions like “which readers this week have watched a video but never commented on a story?” Events are a critical component of identifying users to target with relevant and specific in-app messaging.

You tag specific events in an application using a string describing the event. This is particularly useful for answering business questions and design questions such as:

• What options do users prefer?
• What level in a game do users tend to get to?

Tagging events is the most important component of a successful analytics integration. While your first impulse might be to tag every action in the application, that approach will make it difficult to find the answers to specific questions.Instead, Localytics strongly encourages the following approach:

1. Consider the primary purpose for your application. Why did you create the app in the first place, and how does it fit within the company vision? Consider what metrics and conversion events are most important to measuring the success of this purpose.
2. Identify the different user actions that lead to those conversion metrics. You will want as much insight into each step of the funnel as possible in order to identify optimization opportunities.
3. Consider any remaining user actions of your app that best measure engaged and active users. You will want to keep track of the overall trends of your app’s usage.
4. Consider all the functional aspects of your app that are important to keep track of, even if they are not directly relatable to user actions. This includes items such as application crashes, user setting choices, failed background downloads, or syncing errors.
5. Describe all funnels you wish to follow. Maybe this isn't just conversion funnels. Think about any important process, like user signups or the process of sharing an article. Make sure every step in that funnel has an event.

Now you have a great starting point for events to track. You will find that many requirements can be covered in just a single event. Many well-tagged apps have less than 30 different event names.

When tagging events, use constant strings defined at compile time. This is advantageous because it avoids the risk of collecting personally identifiable information, it is more efficient, and it guarantees that the charts in the dashboard won’t have too many events to be actionable. In some cases it is acceptable to create these strings dynamically. For example, consider a game with an infinite number of levels. It might be appropriate to record an event named START_LEVEL_X (where X is the current level) every time a user reaches a new level.

Naming events

Your event names have a big impact on the Dashboard experience. If it's hard to find specific events, then it's hard to answer specific questions. We recommend the following naming conventions.

• Make event names as short as possible
• Events should always be named after actions the user takes in the app, such as "Article Shared," "Product Viewed," or "Settings Changed"
• Capital case helps distinguish events from attributes
• Similar events should have the same prefix so they group themselves in the UI, such as "Article Viewed," "Article Shared," "Article Comment," or "Article Favorited"

Best practices for tagging events

To make tagging work for you, keep the following points in mind:

• Tag events as late as possible. Rather than record five different events to summarize an action, using one event recorded at the end of the action puts all the analytics coding in one place and makes the Dashboard experience very easy. This approach is most successful when attributes are heavily utilized to capture every nuance of the event. Common examples of this approach include:

  • Recording one "Video Play" event instead of "Video Start," "Video Stop," and "Video Pause" events.
  • Recording one "Article View" event instead of "Article Open," "Article Comment," and "Article Finish" events.
  • Recording one "Settings Changed" event instead of one event for each setting.
• Avoid tagging events in a loop. This can cause enough data to be collected as to impact the user.
• Tags are only useful if they are comparable across sessions. To guarantee this, make sure the string you pass to the tagEvent API is a constant.
• If you wish to compare behaviors across versions it will be necessary to keep the tag names the same. So choose names that are not version specific.
• If a tag exists in a code path, make sure all code paths are covered. If an event can be reached in multiple ways, and only some of the ways are tagging the event the data will be skewed.
• Consider when to use Event Attributes while tagging. For example, determining which options are on in an settings screen a user selected is best done by having a single event which is uploaded when the user closes the screen which captures each specific option as an attribute.

Tagging screens as events

Localytics provides a separate tagScreen() call to help you identify users’ flow through the app. Typically it is best to treat screens and events as separate concepts. However, sometimes screens do need to be tagged as events so they may be used in funnel analysis or to help product teams understand screen layout and interaction. In these cases, it is still best to tag the event at screen exit with as much information as possible. But do not just tag every screen as an event, as it is redundant information already captured in the tagScreen() call.