Flurry Analytics is a data collector for mobile applications, which allows developers to track aggregate data about users behavior and experience in the application and proved to be a great help for startuppers developing applications or videogames. Why? Valerio and Roberto from Interactive Project explain: “We developed an ad-hoc tool to monitor behaviors in our first game; however there are tools which help monitoring the application and to have feedback in order to adapt the application to the needs of the final users. We tried Flurry Analytics with our last game OverVolt: crazy slot cars, and found it very useful and rather easy to implement!”  

Needs for marketing researches on application/game

Every application producer and, more than ever, every game developer and publisher needs to take into consideration what is the user experience and behavior inside its application in order to improve user experience and monetization. More traditional marketing data collection might result in obsolete and incomplete data in an environment like the application and videogame market; a market where, on average, users try the application/game for free and decide whether to run/play it or not and (later) to come back and pay for full version/premium/extra contents in a matter of seconds. One click more, one word not rightly placed might result in a huge amount of users/gamer losses and negative word of mouth.

The new tools to monitor applications/games and adapt it to users requirements without having to invest huge amount of money into marketing research are getting every-day more complex to use; but they are able to guarantee efficient marketing insights at basically no cost.

We, from Interactive Project, decided to try Flurry Analytics after our experience on MyGPTeam Turbo with an internally developed tool, to have feedback about our users’ behavior on our last game OverVolt: crazy slot cars. Here our experience on how to set up and use Flurry Analytics.


How to install

1.       Register to Flurry;

2.       Create an application (one for every platform);

3.      Add “set-up calls” to API of Flurry Analytics plug-in (you can find Flurry’s “how to” to understand how to set them up);

4.       Add calls for custom events.



After setting up “set-up calls” from Flurry plug-in, Flurry will automatically give back data about some metrics; this means that you will not have to spend time programming yourself main metrics like retention, MAU, DAU. Moreover it gives the nation and the language of the users. These are very useful metrics, both because of the easy implementation of “calls” and, because, they are the main metrics that any developer has to check-out in order to understand how successful is the title released. It is very interesting the section dedicated by Flurry to the “Retention”, which analyzes all the aspects of retention (from single day to rolling) and which is a first look on whether the application is successful and users like to come back and use it again or not.


Custom events

Apart from “set-up calls” the real advantage of using Flurry consist in the possibility to generate a series of custom calls which aims at analyzing exactly what is deemed worth of notice for our game (or application).

Custom calls on Flurry might be of two types: single or time events. For both typologies, it is possible to specify some parameters useful to define the contest and the specificities of the same event or for tracking purposes.

When setting up time events it is important to call the end-event API; this because, in absence of the call, Flurry will register the event as a single event.

In total Flurry allows to set-up a max of 300 events for application with at most 10 parameters. Every parameter might have 1000 different values.

Flurry Analytics allows great freedom when setting up custom events; because of this it is important to be sure on which are the best event to monitor. The best way to understand which they are is to create a document that gives the “navigation flux” throughout your application, thus picking the most relevant metrics for your business. Usually setting up calls for “button pressed” or “page visited” is almost irrelevant; the goal to have in mind when programming Flurry is that it is important to understand the “status” of the users and of the application when the event happens. This “status” is registered by the parameters given to the single events.

Using this event-parameter monitoring strategy allows to create a great tool to track users behaviors inside the application. It is in fact possible to put the single events might in a logic sequence through Flurry’s “Users Paths”. A flux diagram showing the consequentiality of the event helps to generate an “average behavior” of the users.

To give you some examples in our business (we develop and publish videogames) we track tens of events:

·         “Game started” and “game finished”, using the game mode (single or multiplayer) and character used as parameters;

·         “Game length”, to understand how long a single play lasts, we use as parameter a value to identify the game level;

·         “Power UPs bought”, with parameters such as typology of Power UP and when the object has been acquired (before a race or from the store);

·         “Store interaction”, basically time spent in the store and interaction with the various object;

·         “Purchase”, using as parameter the possibility to understand whether the purchase was spontaneous or proposed by the game.

Monitoring those events and parameters resulted very useful for us. For example, thanks to the event “Power UPs bought”, we understood that the fact that the users had to go back to the shop to buy Power UPs was reducing the amount of money spent on such virtual items. Putting them right before a race increased of a lot the amount on virtual money spent on Power UPs thus helping us also to monetize better on the sales of virtual money. From an average of 1500 Power UPs bough daily to 4500 the day after and over 6900 two days after. Increasing the virtual credits spent on Power UPs from 340.000 to over 1.400.000 in two days only.

We had a similar experience also with the multiplayer section. The initial multiplayer races were asynchronous and in the absence of the “opponent car” during the races developed through a tournament of three races. We understood from the analysis of data that many tournaments were abandoned at the first race and only 4% of races received a response from other player which got involved in the tournament. Thanks to the feedback on completed races we changed multiplayer tournaments to single races matches. The day after the release number of multiplayer matches rose 4 times with a level of challenged responded of over 60%; a great success thanks to reports and feedback from users experiences.

Here some links to examples on how to implement custom events for some different applications:

In order to better understand what the user does the first time he/she uses our application we inserted a “firstRun” parameter to every event, in order to differentiate those events generated the first time a user opens the application from the following usages. We also introduced parameter “step”, to help us understand the event timeline when the users launch the application. Flurry’s backdrop is that it is not possible to combine the various parameters of the same event. If in “Game started” event we used parameters circuit level and character used, Flurry will be able to specify us the occurrence of the single parameters but will be unable to combine the event happened with (e.g.) “level 5 character Tommy”. If we need to do this it is possible to use Flurry Analytics’s API REST (csv file are of little use given the huge quantity of data available; they also tend to get hard to be managed as the quantity of data grows), which allows us to download registered data of our application and to aggregate them with an ad-hoc developed software.   Conclusions We deem that Flurry Analytics is a very useful tool, even though it requires a bit of work in order to run smoothly and a deep study behind which are the most useful and relevant events to track. Once those data are collected it is easy to read and understand them and get ready to plan an upgrade of the application to match users’ needs and preferences.  

Useful resources

Some links to Flurry’s plug-in for Unity (Android / iOS):

·         https://github.com/mikito/unity-flurry-plugin

·         https://github.com/faizann/unity3d_flurry

·         https://github.com/bearprada/flurry-unity-plugin