Usually when I talk about analytics, we are focused on websites or at least apps that live within a browser. Today, I want to look at analytics within mobile apps, specifically for iPhone apps. Although we’ve build iPhone apps before, we didn’t care much about analyzing usage previously, but today we launched a new app, the Latin Recipe Shaker, and because type of app it is and the scope of the advertising around it, we wanted to make sure everything we did was measurable.
The first challenge we faced was the decision on which analytics package to use. We ended up focusing on two main solutions: Flurry and Google Analytics. In looking at both tools from an analysts perspective, I didn’t see much difference in the reporting provided. The way the user’s location is tracked seems to be a bit more robust in Flurry, but since the app isn’t mobile aware, that was not a factor for us.
The second question was about implementation. After having my developers look at both systems, they said the implementation was nearly identical, so there wasn’t any preference on their side. Both systems use an asynchronous processing of data so that every click and swipe isn’t pushed up in real time. Flurry uploads the data from the previous visit when the app starts. Google Analytics lets you set a delay, which defaults to 10 seconds, and then it uploads the data on that interval. Although it uses more pushes, I prefer the Google Analytics route.
Since all things were equal, and since DigiKnow is a Google Analytics Authorized Consultant, we decided to go with Goggle Analytics.
The implementation basically allows for two types of tracking: page views and events. From what I know, you can’t do custom variables yet. We setup page views for each of the main screens and did events for the settings changes, adding/removing on the favorites page and the keyword recipe search.
The only major hiccup that we’ve seen so far is that the Visits data doesn’t seem to be quite right. Somehow a single real-life visit shows up as multiple visits in Google Analytics. This may be related to the asynchronous processing. The other data point that isn’t quite right is geography. Since we didn’t want to use the iPhone GPS, our app just uses IP for location, and every iPhone that is on 3G or Edge looks like it is in Dallas (the home of AT&T).
Overall, the process of implementing analytics was fairly simple and the data coming in is very valuable.
