I have employed the use of an analytics service in many of the iOS apps I’ve been involved in and as such, have learned to appreciate the overwhelming value of doing so. Recently, I came across yet another new way to use analytics that excited me enough to write a post outlining some of the things I’ve learned. This post is not an in-depth comparison of various services, but rather a high-level list of tips and suggestions to help you ease into using analytics and make the most of your chosen service.
Choose a service
The first step in your journey towards making use of analytics is to choose a service. There are many options, below is a list of the most notable:
These services are all fine choices, my personal preference is Flurry due to the fact that all of it’s features, including the more advanced, are free.
Wrap it up
Once you’ve chosen an analytics service, you’ll be provided with instructions on how to integrate the SDK into your app. You’ll also be provided with code examples that demonstrate how to interact with the SDK to log events. Do not add these interactions directly to your application logic, rather, create a wrapper service that delegates any analytics related calls to the underlying SDK of your choice. This wrapper service is also a good place to perform any other SDK-specific interactions such as initialization and defining uncaught exception handlers. The wrapper service should be the only class in your entire application that knows anything about the specific analytics service you are using (i.e. this should be the only place where you declare imports of the SDK headers). Protecting your application code from SDK-specific details will give you a great deal of flexibility, allowing you to easily adjust every aspect of how you interact with the analytics service,or even to swap it out for an entirely different service. These services are adding new features frequently and you don’t want to be changing thousands of lines of boilerplate API calls should you decide to switch to a different provider.
Track your screens
One common use of analytics is to determine how a user is interacting with your app at a per-screen level. What path are they taking through your app on each session, how long are they spending on each screen, etc. If your app consists of many views, this can result in lots of repetitive code. Mitigate this by creating a base subclass of UIViewController. In this class, you can start a timed analytics event in “viewDidAppear:” and end that event in “viewDidDisappear:”, passing the class name as the event identifier. Now simply determine which of your app’s view controllers you want to track, and configure them to extend this new base class. You can use a similar strategy for tracking things like button taps, but do remember that most analytics services limit the amount of unique events you can track.
Every app, no matter how polished, will encounter problems once it’s out in the wild. Code that needs to respond to error conditions via NSError or any other error mechanism can present those errors to the user, but the vast majority of users will not know what to do in such a situation and are very unlikely to notify you of problems. Worse still, if they do decide to report a problem, they have likely already dismissed the error message and won’t remember details about it. Don’t rely on your users to report errors, rely on your analytic service. Recover from errors as gracefully as possible, show the user a generic alert if you see fit, and log as much detail to your analytics as possible. This way, if a user does report a problem, you’ll instantly have access to as much detail as you need to fix the problem. Moreover, you can keep a close eye on the error events that are coming in so that you can proactively solve problems that users may not even report.
Debug and tune
I recently encountered an issue in an app I work on regarding accurate acquisition of a user’s current location via CLLocationManager. The problem was only occurring for certain users in certain places, particularly where the GPS signal was spotty. After extensive reading around the various switches and levers on CLLocationManager, I was confident that I had to start tweaking various parameters. I added a copious amount of event tracking to my location acquisition code, built the app for my device, and spent a few days testing the app in a variety of locations/situations. After analyzing the data, I was able to quickly adjust the parameters to sensible values and the result was better tuned location code than any I could find online to date. The take away here is, if you yourself, or your users, are running into inconsistent or mysterious behavior that only seems to surface at random times, be liberal with event logging around suspected trouble areas in your code and you’ll be able to use the resulting data to very effectively isolate and solve these problems. Likewise, if there is a piece of code in your app that you’d like to tune based on real world data, analytics are the perfect solution to gather the relevant data.
Analytics are one of the best ways to acquire data about how users are interacting with your app. I have had a very positive experience using them in my own apps and hope that these tips and suggestions will help you adopt the use of them in your own. If you have any additional tips, tricks, or suggestions around mobile analytics, drop a comment below. For more content like this, you can subscribe to this blog or follow me (@nickbona) on Twitter.