Don’t Underestimate the Benefits of Analytics

So far, with 2 apps on the iTunes App Store, I have found the Flurry analytics to be very helpful. Without it, I wouldn’t have insight into how often people are using these apps, or how often. The information provided by iTunes Connect is useful for financials and sales data, but it doesn’t provide insight as to app usage. The Flurry tools aren’t perfect, and one hiccup I’ve encountered is that I can’t run apps from XCode when Flurry is enabled. I have worked around this by having the Flurry calls only included when building for Ad Hoc or the App Store. When I run debug builds, Flurry is disabled.

What Flurry does offer is the ability to know how many times your app has been run, how long the sessions are, and where the app is being used geographically. If you also embed event reporting, you can gain insight into what features are being using in your app. As an example, in the GearBox app, I report a Flurry event each time the user selects one of the 4 tabs in the app. From that, I have been able to gain insight into what features get used the most (the bulk of the users have used the compression ratio calculator the most, followed by the displacement calculator. The displacement conversion gets used the least, by a wide margin.

Unfortunately, none of the tools I’ve seen with iTunes Connect offers this type of data so I can gain these insights. Apple has done a good job on the sales reporting side, and the iAds data is quite thorough. But, without surveying customers directly, there isn’t anything built into the various iOS frameworks to know what people are doing with the app.

Using these analytics also avoids a potential problem with survey responses: skewed results. People will often over- or under-estimate how long they spend doing a task, and don’t accurately report what features they use and how often. By having the software capture this data, I can find out the usage patterns without worrying about getting misleading data (or no data at all if no one answers the survey).

I don’t know what percentage of developers use Flurry or similar tools, but I have spoken with the odd app developer who didn’t bother. In some cases, it may not matter. For some firms, their iPhone app is merely a marketing device because they had to have it, and not a major source of revenue or exposure for their product.

For developers that intend to build a living off of their apps, it is essential to know what people are doing (or not doing), and use that as input into the future evolution of your apps. For myself, I have been quite happy with the Flurry API and the tools they provide. Aside from the inability to run in debug with the library in use, the only other “quirk” is that their website uses Adobe Flash to present the data, so you can’t review your Flurry analytics from your iPhone or iPad. However, I have worked around the XCode/debugger problem, and not seeing my Flurry data on the go is no great hardship. I definitely recommend the Flurry tools.