So, been a while since we did a developer diary, and I thought I’d add one.
This one is about analytics.
Analytics, analytics, analytics.
So what exactly are Analytics? Analytics are you game or app reporting back to a remote server the state of your game/app. What the user is doing, events that happen and other information, possibly the device stats you are running on, memory consumption, frame rate, etc.
This is all stored in a big old database, per game session, and then the developer can run queries on that database to get information about who is playing your game and how. For example, if you have reported the right analytics, you might ask the analytics data base “How many people, who first installed the game last month, have finished level 3?” and then you ask “How many people signed up last month?” and that gives you a percentage of people who signed up and who have actually finished level 3. Or the tutorial. Or spent more than X time on screen Y. Or bought something. Or whatever.
The point of analytics is to report how users interact with your game, so you can make business decisions on the future of that game. E.g. “We just dropped IAP number 3, what percentage of people who bought IAP number 2 have bought it? Oh, only 15%? Hmm… we may have priced it too much then! Lets drop the price and see what happens!”
Which brings us to A/B testing. This idea is that you might recognize either something is wrong – users aren’t buying what you want, or doing the things you want, so you make changes to the game. How do you know the changes you made are actually having the effect you want, versus some outside influence that may impact the users interacting with the game?
Well, the idea is that for 50% of your users, you leave the game as it is, warts and all. And for 50%, you make those changes, and they see them. So all your code or content changes have a flag on them, that turns them on for some people and turns them off for others. You have two streams of analytics coming at you know, from people in Group A, who don’t see the changes, and people in Group B, who do. And then you can compare.
If both groups go down in terms of the tracking information, then you know some external environmental issue is changing how people use the game. Maybe apple changed something in ISO 27 that makes text input worse than it used to be, or maybe some new OS dialog keeps popping up. Suffice to say if both groups drop, then you know it’s not your changes affecting things.
But if Group B starts doing better than Group A, then you know your changes are good, and you should push them out to everyone! If Group B doesn’t do any better, well, then the changes probably aren’t great. Unless they are preparation for new content, probably better to turn them off.
(Note, doing this with pricing, in terms of actual currency that people spend to buy in game products or virtual currency, is a no no. You can’t have Joe paying more than Harry if they live next door to each other. You can do this with things bought with Virtual Currency, but not real money. It’s ok for a hat costs Joe 20 Lassen Dollars, and Harry 25 Lassen Dollars, but you can’t have Joe being charge $0.99 for 50 Lassen Dollars and Harry being charged $1.99 for 50 Lassen Dollars.)
So you can see how analytics matter, particularly for games that are considered GaaS (Games As A Service – a game that receives support after the game is released, beyond just bug fixes. If you are releasing new content for it, upgrading the features, doing live events, or any of the previous, then your game is a GaaS.) It’s vitally important, for example, that you get players successfully through the tutorial, so they know how to play your game properly. Analytics show you how far people are getting, what they might be having problems with, features they use in game, and features they do not (which might be because the feature is too complicated, or they don’t understand it’s usage case and where it’s appropriate to use it.)
The other things that analytics give you is data mining. Yeah, that kind of data mining. You can watch trends happen – oh, look, when people get up in Spain, they spend more time on the game. So we need to push sales to Spain at this time of the morning. Oh look, post The Superbowl, people buy a lot more card packs – we need some special card packs to be ready to push on Superbowl Sunday, so they have something new to buy. Etc etc.
Some of the largest companies have more data scientists – people who spend all the time analyzing the trends of how people are playing the game, with a view to determining how to make the game more sticky, and how to get them to spend more on IAP – than they do actual developers. Candy Crush Saga has so many data scientists, creating specific sales events that are targeted at specific kinds of players, who they divine by looking at their playing trends, than anyone. You wonder why it makes so much money? Because King spends a LOT of time looking at their data, working out who is likely to buy what, and under what circumstances, and creating sales that are ready to be targeted to that player the moment they trip the conditions that King thinks they will buy. And it’s not just King that does this – all the big GaaS games do this – Tencent has entire divisions of people dedicated to this kind of analysis and recommendations.
It’s worth pointing out that companies will tell you that they track your game playing trends to ‘make the game better’, which strictly speaking is true. They want to increase player time, and broaden the appeal – make the game as easy to get into as possible, all to make the IP worth more by having more regular players. But that’s right next to making it possible to make as much money from players as possible. Lets not sugar coat it here – game companies are in it to make money and they will do whatever they can to accelerate and increase that, and all analytic analysis will have this aim at heart.
So, what do you actually track?
Well, that’s the rub. Some games instrument (that’s what adding analytics is called – “instrumenting the code”) everything. Like everything. How long you spend pressing a button. How long you spend on every screen. Every button press you make, every interaction you have. The more data you send, the more they can mine it later to see what is going on. The answer to any question about how players interact can be worked out given enough data to mine and to draw conclusions on.
But that’s not realistic for most smaller companies. Larger companies, like Seriously or Big Fish, have their own back end database systems, with dashboards that allow employees to query the data. But smaller outfits, like us, use a 3rd party offering to track analytics – DataDog, Game Analytics, even Unity has their own somewhat limited offering. And in those cases, you pay by the amount of traffic your game is generating. You want to instrument everything? You pay for it.
So you need to determine what you are tracking carefully. And to work that out, you need to think about the kind of questions you are going to be asking once the game is out. What are you going to want to know? What things are you going to be able to influence easily, based on what the data tells you? Basic things, like logging in or out, session duration and so on, tend to be handled by the system automatically, but then you start getting into game specific stuff. Can you buy things? If so, you need to track that. Can you award currency? You need to track that. How long people are playing, what they are doing, what screens they are on, if they are awarded achievements, if they create an account, if they chat with people, what settings they set for their usage case on the game, all of these things need to be tracked.
What’s really interesting is that when you get into the nitty gritty of what you are tracking, all sorts of unexpected issues can arise. Tracking amount spent by players, for example. Most tracking systems want to be able to track per local currency – so if you buy something while in France, you are using Euros, and the tracking software wants to be able to know that. That way you can tell if you selling things in France over Italy or anywhere else. But… most platform back ends report what is bought and the currency used different.
For example, Steam gives you a real number. If you spent $1.99 on something, Steam reports it in the lowest possible currency type – in this case pennies – so it’ll give you a number of 199. But Apple reports that as 1.99, as a decimal number. If your analytics software requires a whole number, this means you have to multiply the number you get from Apple by 100, to get a real number.
Except, that’s not all. Because did you know there are several currencies out there that actually have 3 levels of decimal place, not just 2? And some have no decimal places at all. So you have to know WHAT the currency type is that was used to purchase, in order to know what to multiply the amount spent you get from Apple to get a real number that is appropriate.
So if the currency is US Dollars (USD), you multiply by 100. If it’s Jordanian Dinar (JOD), then because it’s 3 places, you have to multiply by 1000, and if it’s Paraguay Guarani (PYG), then you multiply by 1, since there is no decimal place for that currency.
It’s all quite fiddly and not as obvious as you might think, when you come to implement it.
But once it’s done, it’s done. And one of the good things about GaaS games is they update regularly, so if there is a value you need to keep track of that you didn’t implement immediately, it’s not that hard to add it later.
Either way, we are done implementing basic analytics in Lassen’s Loop now, onto the Tutorial!
