Sponsored By

How We Selected our Mobile Analytics Package For 'Chip Chain'

Many companies provide mobile analytics. Our most important features were Low cost, Revenue tracking, Real time, post data collection analysis, and easy to view the data. We ended up using Flurry and our own custom tracker using Amazon SimpleDB.

Aaron Isaksen, Blogger

November 19, 2012

5 Min Read

I think the best way to get started is to discuss how which tracking package we use for our F2P iOS title Chip Chain.  There are a TON of companies out there that do mobile analytics, and we looked at a lot of them.  Some of the things that we thought were important to us were the following. 

  • Low cost - it would be a real shame to have a popular game that had millions of tracking events, but very little revenue, and you end up spending all your money on tracking.  We had no idea how many users we were going to end up with, but based on conversations with other indies, we estimated somewhere between 10K and 100K users per day from our potential iOS feature, and guessed an average of 10 tracking events per user, so we came up with a ballpark of (50K users * 10 events * 30 days) = 15 million events per month.  So any company that was going to charge us if we had a lot of events was definitely out.  It turns out we have about 200K tracking events per day right now, as our daily active user estimates were too high, but at least we were in the right ballpark.

  • Revenue tracking - From lots of pre-release play testing, we knew our game was sticky, so the most important thing for us to track with real data was if our game was converting, what people actually wanted to buy, and all those boring metrics that get thrown around like ARPU and ARPPU and ARPDAU.  However, we soon realized that piracy was a big issue with our IAP.  We were getting many more purchase events than Apple reported, so clearly our data was a bit corrupted.  This seems like a good topic to explore in a future post, as if you are making decisions about how profitable your game is, without paying attention to piracy or segmenting your data by country, you are going to get bad results.

  • Real time - we wanted to be able to see our data in real time, so we could see exactly what was happening on day 1.  In hindsight, it turns out this actually isn't that important for us.  It's a pain to monitor, it was stressful to be constantly looking at our numbers, and it's not clear that reacting that fast is even a good idea.  But it is very useful for error tracking - we wanted a way to get any crashes or errors sent to us so we could fix them ASAP, without having to wait for a couple people to email us with their issues.

  • Post data collection analysis - we wanted to be able to analyze the data AFTER we collected it, since we know we don't know too much about analytics and wanted to learn as we went.  Our goal was to collect a bunch of data, and then over the next couple of weeks after launch, build the tools and learn what metrics actually mattered to us.  We didn't want to have to setup cohorts and funnels before we launched as we didn't have the time to learn what all those things meant.  But we did make sure to bake in the possibility of doing those things when we did our analysis.

  • Easy to view the data - we all know that games that look good are more fun to play, and the same goes for exploring data.  Having a nice way to explore the data visually would make us use it more.

  • Cross platform - whatever solution we went with should support iOS and Android, either via native plug-ins or via a REST HTTPS API.  Just about every provider does this, but its definitely something to watch out for.


We looked at over 10 providers, and realized that there isn't a company that can do this all.

So we decided to go with two solutions, and use them both at the same time. 

First, we use Flurry, which gets us Low cost (free), Post data collection analysis, cross platform, and it's Easy to view the data.  It's a pretty awesome product, and so far it's been great for our needs.  They don't have Revenue Tracking (You can do it by tracking events, but they don't do any revenue metrics for you) and they aren't real time, but it's actually close enough for what we needed.


Then, we built our own tracker using Amazon SimpleDB and custom tracking code we wrote for Corona.  This gets us the ability to pull all the data and analyze it in any way we want.  It's really ugly as we haven't written any good tools to analyze the data visually, but we can get histograms and pull out whatever data we need.  We'll use this data to figure out what our piracy rates are.  Keep in mind this does cost us some money, its not free to use SimpleDB, but at our scale its about $1 per day.


None of our tracking uses the depreciated UDID, or any user information to tie it to a specific person or device.  We generate a unique identifier for each install, but we can't tie it back to a specific phone, device, or game center account.  This protects our users privacy, and it's also not information that we need or want to be responsible for.  Since we only have one game so far, this is fine for us to not be able to compare users across apps.


If people are interested, I can do a more technical post on exactly our methods used in our own tracker.

Read more about:

2012Featured Blogs
Daily news, dev blogs, and stories from Game Developer straight to your inbox

You May Also Like