The abundance of data available to us means it’s easy to create a detailed picture of game performance and user behavior. But paradoxically, this availability of data means it’s easy to lose sight of what the user experience of the game actually looks and feels like from the point of view of the player. The way data is structured and insights produced means we are naturally inclined to consider things from the point of view of the game: systems, features, purchases. We don’t naturally consider things from the point of view of the player. At what time of day do users play the game, what day of the week, are they playing in the bus, on a couch, in bed? (I’m going to assume most of us still don’t have data on some of those…)
All the above questions are important for the insights they produce, but even more for the type of perspective they require from us. When your point of reference is the game, that literally means the game is the center of everything. But the reality of mobile games – as an entertainment product users consume – is much different. By and large, any mobile game is a part of people’s lives. It’s not at the center of people’s lives. People don’t organize and structure their schedule around your game. People launch your app when it suits their schedule.
So being modest – and trying to fit into people’s lives – is key to being successful. That should be one of the key meanings of game as service – cater to the users’ needs, desires and schedule. Knowing when users are most predisposed to play your game (or your competitor’s – if yours doesn’t provide them with what they want) can in turn provide you with key insights to build features and systems that capitalize on those predispositions.
For example, having various appointment mechanisms that can reinforce your players’ natural predisposition to launch and play your game can help maintain engagement throughout time. You should aim to make it easy for players to play your game. Don’t just think about the ways a feature intersects with another feature in the game. Think about ways a feature can intersect with your player’s daily lives.
All the timestamps in your database are probably in UTC. And even is they are not, all timestamps reflect the time in one given timezone. That’s one example of what I mean by “we don’t naturally consider things from the point of view of the player”. If you look at the time installs occur – at the local time of your user – then you will probably notice the same pattern regardless of the game. In other words, don’t look at things from the perspective of your time zone. Look at time of install from the perspective of the user. Here CONVERT_TIMEZONE is your friend. You can for example look at what time most installs occur – at what “local time” (if you run the query, you can choose to look only at organics – to minimize the impact of UA).
Regardless of the game, most installs occur in the afternoon (after school/work is over). Peak installs occur between 6-9 pm, and few users install in the middle of the night. If you add the day of the week dimension to this, you see that more users install on the weekend, and that users installing on the weekends install in a more spread out way during the day. Many users installing on the weekend install in the afternoon – not just after 7:00pm.
That’s when you look at installs. And when you look at engagement – not when users install, but when they play – you can observe the same patterns. That’s because users are more likely to return to a game they’ve installed on a 24-hour cycle. That’s pretty much one universal pattern regardless of the game. Users engage with your game on a 24-hour cycle starting at the moment of install.
All that is pretty obvious when you think about it. Most users won’t install games during business hours (where most are working). The install window on weekends isn’t as small – people install games when they have some leisure time. And most of the time, users’ leisure time occurs at the same time every day, and on the same days every week.
But when you don’t think about it, you can forget how important that natural daily and weekly cycle is. Most games totally ignore that “hour-of-day” dimension of user cycle (less so for the weekly one) and pretty much operate in a time-agnostic way. But properly leveraging that user cycle can provide an additional advantage and help improve your engagement rates.
All this might not seem immediately actionable at first – but it can be, depending on how creatively you want to look at things. Not designing a specific feature with this cyclical/time of day aspect in mind won’t doom your title. Many successful games don’t have those features – and your daily login bonus is a rudimentary way to leverage this 24-hour cycle (even though it ignores the time-of-day aspect). But designing a specific feature with this cyclical/time of day aspect in mind can provide a marginal boost to your users’ engagement with the game and your next day return rate.
Having users engage with your game is a necessary (but not sufficient) condition for success. What that means is that you need to get your users playing and returning to your game. And one of the best ways to succeed at that is by making it easy for your users to come back. Knowing about this cycle and designing around it can provide an additional opportunity to leverage this natural tendency – and make it easier for users to return to your game. Having a targeted call to action that occurs at the right time of day can also be more effective that having an “always available” daily login bonus. In that respect, the “come collect your energy within the next hour” call to action in Heroes Charge like games is a great illustration of this.
This 24-hour cycle is a very valuable component of user behavior. Basically, users are telling you at what time they are most likely to be available and inclined to come play your game. What you need to do in that case is implement features that reinforce those inclinations. Think about it as a way users are auto-identifying the time of day (and day of the week) they are most likely to be available to come play your day. A bit like Facebook users auto-identify their preferences through the content they consume – which in turn allows for better targeting. This is not about creating a desired user behavior – about making your users do something they are reluctant to do. In the grand scheme of things, you should assume users will only do what they are predisposed to do (and what requires minimum effort). You can choose to do nothing about this. But knowing about this natural engagement cycyle can help you design a feature that naturally builds upon and reinforces that tendency. Acting upon this standard behavior pattern can be a low-cost way to increase the engagement with your game and enable users to integrate your game in their day-to-day routine for extended periods of time.
Alexandre Macmillan 