- 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.
So we decided to go with two solutions, and use them both at the same time.