What events should I track in Mobile Analytics?

What events should I track in Mobile Analytics?

Setting up event tracking is the single most important part of getting your Mobile Analytics instance up and running. It is imperative that your event tracking strategy be well thought out, as these events will form the foundation for all of your reporting going forward.  This document outlines the process by which you should set up event tracking so you can make the most out of insights from your app.

Table of Contents:

  1. Getting started with Mobile Analytics
  2. Step 1: Map out your app goals and KPIs
  3. Step 2: Identify all events and attributes to track
    • Key things to consider when creating your list of events and attributes
  4. Step 3: Work with your developer to create events in Mobile Analytics
  5. Advanced setup for custom events:
    • Scenario 1: Tracking consistent events across multiple pages or screens
    • Scenario 2: Tracking events that are unique per page
    • Scenario 3: Omit attributes and values entirely

 Getting started with Mobile Analytics

Step 1: Map out your app goals and KPIs

The very first step in setting up your Mobile Analytics solutions is to sit down with key stakeholders and your marketing/analytic teams to map out the Key Performance Indicators (KPI's) for your app.

Note: These goals/KPI’s/reports will vary considerably depending on your vertical and your particular approach. There is no one-size-fits-all solution.

 Step 2: Identify all events and attributes to track

Once you have an understanding of all your app KPIs, you’ll have a much better sense for what information you need to see and measure. Thinking about all the reports that will help you track KPIs, create a list of all the events you need to track  (i.e.: user made a purchase) along with relevant attributes (i.e.: user spent $50).

Key things to consider when creating your list of events and attributes

  • What are the critical parts of the user experience in my app?
  • Where am I losing users? What features need improvement?
  • Does my user base spending a lot of time with one feature? This could mean something is broken and/or a time suck for users... but it could also mean they love the feature and are very engaged. Breaking out the tracking will help you tell the difference.
  • What will I learn by tracking this event?  
  • How is it relevant to my KPI's?
  • What attributes of the event are important?  For example, a Transaction event should at minimum include the value of the transaction and the names or ID's of the item or items purchased, but depending on your monetization model might benefit from other contextual info as well.
  • What events would define a valuable audience?  What sort of segments do you want to push to your media campaigns?
  • What reports will I want to see? What information do I need to collect in order to produce those reports?

 Step 3: Work with your developer to create events in Mobile Analytics

Once you have identified all the events and attributes you want to track, work with you app developer to create these events in Mobile Analytics. Note below that there are some events that will be tracked by default in your Mobile Analytics.

 Creating Events

There are 3 types of events in Mobile Analytics:

  • Default events
  • Standard events
  • Custom events

Most integrations involve all three event types.

 Default Events

Default events are tracked automatically. No further action needed to record the information below.

  • Launch - fired when the app starts
  • First Launch - fired when the app starts for the first time
  • First Launch After Update -fired when the app starts for the first time after a version upgrade
  • Application Opened - fired when your app is opened
  • Session Start - fired when a new session starts.  Sessions are defined as a period of continuous activity so you may have multiple sessions tracked for a single app open if users frequently send your app to the background between uses instead of quitting out of it entirely.
  • Session End - fired when a session ends; includes a Session Length attribute with the session length in seconds

Note: Tracking only default events will be insufficient for virtually every deployment and will cripple your reporting. Per above, you should also be tracking standard and/or custom events that make sense for your particular app’s KPIs.

 Standard Events

To make reporting easier, we have standardized data formatting for a few very common events, these include:

    • Login: Tracks a user login within the app
    • Registration: Records a user registration within the app
    • Facebook connect: Track this when the user allows access to Facebook services
    • Twitter connect: Track this when the user allows access to Twitter services
    • User Info: This event enables you to send user profiles to the backend.  Please do not send us personally identifiable information!
    • Upgrade: Tracks an application version upgrade
    • Trial Upgrade: Tracks an application upgrade from a trial version to a full version
    • Screen View: Basically, a page view, it provides info about that screen
    • Transaction: A purchase
    • Delete Cart
    • Add To Cart
    • Delete From Cart

 Custom Events

You are not limited to these predefined events, and in fact virtually every deployment will have at least a few custom events. The key elements of custom event tracking are:

The Event name or label: this is label that will be used in the Analytics dashboard to refer to your events.  It should be descriptive and give at least basic information about what is happening without being overly precise.  For example, the event name "pageView" is too vague and doesn't provide any useful information about what the user is actually doing.  A better event name would be "productPageView" which tells you that the end user is viewing a product.  

Attribute label: Our mobile analytics dashboard allows you to input custom attributes about your events.  These attributes are typically contextual information that add segmentation options.  So, for example, if I'm tracking a "productPageView" event I might want the attribute label to be "productName"

Attribute values: The values of the attribute will be descriptive and correspond to the selected label.  So if I set the attribute label to "productName" the value could be the actual name or id of the product being viewed.

This combination creates a record for an event named "productPageView" and in Segmentation, Funnels, Retention, and the other various reports I would be able to segment out instances of that productPageView event according to the name of the product being viewed.

Note that the you should never use variables that are unique per user in your naming of events, attributes, or values.  Doing so will break the mobile analytics dashboard.

 Advanced setup for custom events:

Every app is a bit different and so is every company's reporting requirements.  Depending on those requirements you may want to customize your naming conventions for your custom events.  Here are three different scenarios where this could be applicable.

Scenario 1: Tracking consistent events across multiple pages or screens

Do you have a few consistent events that are tracked across multiple pages and want to group your reports based on the action being completed instead of the page it is being completed from?  In this case you might use the following:

Event name: the name of the action being completed

Attribute label: pageName

Attribute value: the name of the page where the user completed the action.

You would be able to generate a report of all the places where people clicked a button (for example) and then segment it by the pages that they did so from.  Depending on the reporting you want, it might be a good thing to be able to lump together all clicks of a common button across multiple pages.  

Scenario 2: Tracking events that are unique per page

If the buttons and interactions on each page are unique, you might instead lump all interactions on a page together in a single event and then segment out the specific events.  

Event name: viewMore

Attribute label: actionsTaken

Attribute value: the name of the actions taken on the view more page.

Scenario 3: Omit attributes and values entirely

This has the advantage of surfacing all the pertinent info at the top level and making reporting setup a bit faster.  The down side is that you would not be able to lump similar events together across pages the  way you can with scenario 1 or lump together sets of events from a single page as in scenario 2.

Event name: Concatenate Page name + event name, so for example "productDetail_addToCart"

Attribute label: none

Attribute value: none

If you are new to Analytics and need a hand figuring this out, please reach out to our Sales Engineering team and we will be happy to help make sure you get the data you need and are able to implement tracking quickly and easily.

Have more questions? Submit a request


Article is closed for comments.
Powered by Zendesk