Custom Events with Flurry Analytics for Android¶
You can use custom events to 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.
This example is translatable to other actions such as Game Level Played.
For information on how Event data is reported in the Flurry portal, refer to Events & Event Reporting.
Please Note: You must initiate the Flurry session prior to logging any events. Please refer to the information located at the Getting Started page for important details regarding initialization and event recording. Any events logged prior to session initialization will not be recorded.
You can track up to 500 unique Event names for each app. Flurry will send automated emails to the Administrators on your account at 50%, 75%, and 90% of event limit usage. Once your app hits the 500 event limit, no further events would be tracked and an email will be delivered informing your Adminstrators that the limit has been reached. To avoid hitting this limit, read our best practices section down below.
Common Event Problem: In some cases, instrumentation bugs result in event names being created rapidly. This typically happens when a value, such as a GUID or a timestamp, that should have been in a parameter ends up in the event name. When the apps is launched, each recording of the event is unique, and the app quickly hits the limit. Obviously, being careful with your instrumentation is the first line of defense against this, but accidents do happen. In that case, on the Admin > Versions page, your Administrator can “Turn off Event Creation” for a given version. Once this is done, the mistakenly created events can be deleted on the Admin > Events page, and you can release new code with a fix for the instrumentation bug.
Events with Two-Level Structures¶
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 500 unique Event names for each app. There is no limit on the number of times any event can be triggered across time. Once you have added Events to your app, Flurry will automatically build User Paths based on this data. You can also use Events to build conversion funnels and user segments.
There are limitations on the number of events that can be tracked within a given session.
Capture Event Parameters¶
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:
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.
Capture Event Duration¶
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:
Make sure to end the timed event at the appropriate spot in the app. In case the timed event is not explicitly ended, the SDK terminates it when the session is completed (i.e. when the user leaves the app).
Test Your Event Integration¶
Once you have integrated Events into your code, you’ll 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 page.
To navigate to this page:
Select your app in the Flurry portal.
Select Events from the left navigation menu.
Click Event Logs.
The Event Logs page provides a look at the session data prior to any summarization into metrics, such as Active Users or Event Counts. For this reason, this page provides the earliest view of data in the portal.
The Event Logs should update within minutes of your test session, meaning you can use this to debug your event instrumentation with only minor delay. The timestamp of the session, the device it came from, and a list of all the Events (and associated parameters) triggered during the session are listed in the Event Log.
This page only displays sessions where Events were recorded.
For information on Event logs and Event reporting in the Flurry portal, see Events & Event Reporting.
Events Best Practices¶
Make sure to read the long version of our best practice for logging the events. Here are some quick pointers for implementing Events:
Outline your business goals and the questions you want to answer, then map Events to track each action you 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 you can gain valuable information with little effort.
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 app with these Events tagged.
It is a violation of the Flurry TOS to record personally identifiable information such as a user’s UDID, email address, and so on using Flurry. If you have a user login that you wish to associate with your session and event data, you should use the SetUserID function. If you do choose to record a user id of any type within a parameter, you must anonymize the data using a hashing function such as MD5 or SHA256 prior to calling the method.