Custom Events: Set-up
STEP 2: Custom Events
Events track specific actions that users take within your app – for example, making a purchase, playing a song, or sharing on Facebook. This helps you understand how users interact with your app. This page will show you how to easily capture this information by walking through a hypothetical Article Read event (note: this example is translatable to other actions such as Game Level Played). For information on how Event data is reported in the Flurry portal, please click here.
Events have a two-level structure. The highest level is the specific action, in this case the reading of an article. For this example, we are naming this Event “Article Read.” By tracking this Event, you will be able to measure how many users are reading articles, how often, and so on.
Only 1 line of code is required to track this Event:
You can track up to 300 Events for each application. Once you have added Events to your application, we will automatically build User Paths based on this data so you can see how a user navigates through your application. You can also use Events to build conversion funnels and user segments.
The second level in the Event structure is the Event parameter – these are characteristics of the Event itself or the user performing it. For instance, a characteristic of the Article Read event is the author of the article. A characteristic of the user is their status (i.e. registered or anonymous). Parameters let you easily view the distribution of Event characteristics so you can answer questions such as who is most read author or what percentage of users reading articles are registered?
You can capture Event parameters (which include the Event itself) with two lines of code:
NSDictionary *articleParams = [NSDictionary dictionaryWithObjectsAndKeys: @"John Q", @"Author", // Capture author info @"Registered", @"User_Status", // Capture user status nil]; [Flurry logEvent:@"Article_Read" withParameters:articleParams];
Each Event can have up to 10 parameters, and each parameter can have an infinite number of values associated with it. For example, for the ‘Author’ parameter, there may be 1,000 possible authors who wrote an article. We can keep track of each author via this single parameter.
You can also add the dimension of time to any Event that you track. Flurry will automatically record the duration of the Event and provide you metrics on average Event length overall, by session and by user.
You can capture Event duration (along with the Event and its parameters) with a single log following this pattern:
NSDictionary *articleParams = [NSDictionary dictionaryWithObjectsAndKeys: @"John Q", @"Author", // Capture author info @"Registered", @"User_Status", // Capture user status nil]; [Flurry logEvent:@"Article_Read" withParameters:articleParams timed:YES]; // In a function that captures when a user navigates away from article [Flurry endTimedEvent:@"Article_Read" withParameters:nil]; // You can pass in additional //params or update existing ones here as well
Testing Your Event Integration
Once you have integrated Events into your code, you’ll of course want to test that they are firing properly.
The first place to check in the Flurry portal for Event data in your testing sessions is the Event Logs. To go to this section, select your app in the Flurry portal and select “Events” from the left navigation menu, then click “Event Logs”. Session data hits this section first and subsequently populates in the associated charts in the portal.
Event Logs should update within minutes of your test session. You will see the timestamp of the session, the device it came from, and a list of all the Events (and associated parameters) triggered during the session.
For more information on Event Logs and Event reporting in the Flurry portal, click here.
Events Best Practices
We have put together example Events for a few app categories based on our experience. Each Event and parameter listed may not be relevant to your application, but they will give you a sense for the types of actions you should consider tracking:
Here are a few additional best practices when implementing Events:
- Outline your business goals and the questions you would like to answer, then map Events to track each action you will need to measure
- Name your Events for easy identification and categorization. If you have more than one application that has similar Events, name them the same across apps so you can more easily compare performance
- Add Event parameters on every Event wherever applicable.
- Use timed Events wherever relevant. Flurry automatically breaks up usage into time buckets, so it's very little effort to gain very valuable information.
- You can always add more Events to your app. However, it will require a resubmission to your platform’s app store so that your users have a version of the application with these Events tagged.
Finally, under no circumstances should you track personally identifiable information through Flurry, such as UDID, email address, etc. Flurry is intended to identify actionable trends in the usage of your app such that you may increase the engagement and monetization of your offering.
Final Step: Configure Advanced Features in Flurry Analytics.