Yahoo Mobile Audiences Custom Events
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.
Note that this example is translatable to other actions such as Game Level Played.
You can track up to 500 unique event names for each app. Automated emails will be sent 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 will 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, User Paths will automatically be built based on this data, so you can see how a user navigates through your app. You can also use events to build conversion funnels and user segments.
Note that 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 the 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. The duration of the event will automatically be recorded and you will be provided with 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. 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.
Note that 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. Yahoo Mobile Audiences 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.
Important: It is a violation of Yahoo Mobile Audiences’ TOS to record personally identifiable information, such as a user’s UDID or email address, using Yahoo Mobile Audiences. 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.