For my latest app I wanted to collect some analytics to see which screens and content included in the app are the most useful to users.  In evaluating my mobile analytics options, Flurry’s free of charge service and easy to use API made the decision to go with them over Google Analytics and Mixpanel an easy one.

Integrating Flurry analytics into your app is pretty easy but there is a small amount of setup to be done prior.  You will need to grab the iPhone SDK from Flurry and also register your application with them to get an API key.  The API key is unique to your application and provides Flurry a way to know who is sending events and notifications back to them to log.  The SDK includes a couple header files and the Objective-C libraries you’ll need to include and link against in your MonoTouch projects.  Once the Flurry libraries and the MonoTouch bindings have been obtained and an API key has been generated, we can integrate them into MonoTouch application and start collecting data.

Initiating data collection is as simple as calling the StartSession method with the application’s API key.  That is all it takes to start collecting basic information about your app like the amount of times it has been launched, the number of different users using it, and other bits of info like hardware version and service provider.

Here is some code showing how to turn analytics on.

using System;
using MonoTouch.Foundation;
using MonoTouch.UIKit;
using Flurry; // include the MonoTouch binding lib

namespace Foo
{
    [Register ("AppDelegate")]
    public class AppDelegate : UIApplicationDelegate
    {
        public const string FlurryApiKey ="...";

        public override bool FinishedLaunching (UIApplication app, NSDictionary options)
        {
            // 1 liner to kick the session off
            Flurry.FlurryAPI.StartSession(FlurryApiKey);

            // Do you app thing here...
        }
    }
}

If more detailed analytics are desired, there are additional methods available to help you glean whatever meaningful information you need from your application.  The example below shows how you can automatically track the changes in navigation within a tab bar.  When you pass a UINavigationController or a UITabBarController to the CurrentPageViews method, each navigation action as you move from one view or tab to another gets tracked.  This is ideal for seeing which parts of your app users are interacting with the most.

using System;
using MonoTouch.Foundation;
using MonoTouch.UIKit;
using Flurry; // include the MonoTouch binding lib

namespace Foo
{
    [Register ("AppDelegate")]
    public class AppDelegate : UIApplicationDelegate
    {
        public const string FlurryApiKey ="...";

        public override bool FinishedLaunching (UIApplication app, NSDictionary options)
        {
            // 1 liner to kick the session off
            FlurryAPI.StartSession(FlurryApiKey);

            // create a navigatable controller to watch...
            UITabBarController tabBarController = new UITabBarController();

            // ...and pass it to CurrentPageViews.
            FlurryAPI.CurrentPageViews(tabBarController);

            // Do you app thing here...
        }
    }
}

I am touching on just a few things that you can do with Flurry.  The SDK docs describe a number of other things you can do like creating and logging custom events and tracking how much time is spent performing activities.  I’d recommend checking them out after you download the libraries.

I’ve just started collecting analytics during beta testing and things appear to working smoothly.  If you find any issues with the MonoTouch bindings please let me know.  Enjoy!

Overall Themes

Two main themes that emerged during the sessions: the future of mobile is web-based apps rather than device specific apps, and the road to mobile riches probably doesn’t run through an app store.

Multi-platform development is hard

Certainly scenarios exist where multi-platform apps make sense, but it is imperative that the risk/reward ratio be in your favor to have a chance to be successful.  Don’t underestimate the amount of effort and headaches that developing and supporting multi-platform apps will create.  Going the mobile web app route has it’s limitations, but it is the closest thing to “write once, run anywhere” that mobile has.

Cool Tools

Really cool tools like PhoneGap and jQTouch are out there that help lower the barriers to making apps and, in the case of PhoneGap, multi-platform apps.  Both tools have been released under MIT licenses and are free to use.

One Man’s Secret Sauce for Success

David Whatley gave a funny presentation that provided a lot of laughs and some great insights into how the iPhone app store works.  Even better was his ability to back up what he was saying with some real sales data and numbers.  His secret sauce for success:  PR, code re-use, and playing to your strengths.

App stores are glorified catalogs

Standing out or even being noticed amongst all the other apps is extremely difficult.  Relying only on the app catalog to drive sales is effectively a “post and pray” strategy akin to trying to win the lottery.  Try to find a niche and solve a problem.  Focus on creating value for markets not just an app for it.  Mark Murphy described many ways to make money in mobile other than direct app sales during his talk and in a series of blog posts about Android Business Models.

Links

• PhoneGap
• jQTouch
• iPhone Dev Depot
• Mobile Web Development Tips and Tricks (Slides)
• Making Money at Mobile (Slides)
• http://github.com/mikelaurence/CoreResource (Cool iPhone library)

Books Recommended During the Conference

• Aiming at Amazon
• The Dip
• The Whuffie Factor

Overall, the signal-to-noise ratio at the conference was good but not great.  I did manage to glean at least one or two new ideas from most of the sessions I attended, and it was great to see the enthusiasm that the Chicago tech community has for events like this.