Observe your user cycles and design around them (not against them)

Summary

The activity patterns of mobile players is largely independent from the specificities of your particular game. In other words, users’ activity patterns share some important similarities, regardless of the game. That means that by observing what those patterns are, you can design your callbacks, appointment mechanisms and live ops in a way that reinforces the natural tendencies of your userbase (instead of trying to get your players to do something they are not naturally inclined to do – which is a much taller order). Some key takeaways from this post are:

1. The hour of day at which users install your game is the hour of day they are most likely to login in the future. Take that into account when designing callbacks or appointment mechanisms
2. Users tend to play your game on a weekly cycle. Try to find a way to reward weekly activity (reward users to give them a reason to login once a week)
3. Games attract more active users on the weekends (Saturday and Sunday). Try to take this into account when designing your live ops

 

—-

 

a) Re-thinking game as service (and thinking about the path of least resistance)

More and more mobile games are self-defined as “game as service”. While that notion usually implies the recurrent and continuous release of new content, one aspect of “service” might at times be overlooked – or at the very least has not been discussed as much. More specifically, the notion of “game as service” cannot only refer to this recurrent and continuous release of new content. At the very heart of the notion of service you’ll find the idea of catering to the customer’s habits and play patterns – of giving them what they want and what’s most convenient to them. A big part of that implies trying to adapt to the audience’s schedule, habits and expectations. That means you cannot consider each feature in a vacuum, independently from the way in which users will integrate your app into their busy lives. It’s easy in an industry defined by on-demand (anytime and anyplace) content consumption and digital distribution to lose sight of the tangible constraints that characterize the userbase’s days or weeks. People have a number of regular and recurrent commitments they organize their days and weeks around – most notably work, meals, sleep, weekends, summer vacations, etc. – and there are certain situations and moments when they are more likely than others to take out their phone and play your game. Your best chance at releasing and managing a successful mobile title is designing with those constraints and predispositions in mind. The broadcasting industry was built around that. It’s easy to forget that mobile games share some very important similarities with the broadcasting industry. Especially when there are more and more live ops and events – which are by definition features that are not “on-demand” for our users, but that are triggered when the game developers decide.

Some play patterns exist across all mobile games, and these are the most important ones you want to be paying attention to for your live ops. The fact that these patterns exist regardless of the game or genre reveals something very interesting and important. They highlight the fact that it’s not only your game features that are driving your KPIs. There are some forces at play that are external to your game, and necessary to its success (although this post is not about that, Marketing/UA remains the n.1 of those humbling forces). Those patterns are found within each game because they don’t depend on the specificities of each mobile game or genre – they are rather the consequence of the way the user’s day to day is organized and structured, and the type of usage patterns mobile devices foster. Those patterns reflect the regularities that characterize the schedules of people playing mobile games. And those regularities are the same, regardless if you’re managing an RPGs, a match-3 or hidden object game. That’s the necessary but not sufficient condition to build a successful mobile title.

Incidentally, this is what Marshal McLuhan – and more broadly the “Toronto School of Communications” – meant by the famous phrase “the medium is the message”. People will interact with a given media in a similar way regardless of what the content is. At a macro-level, television will have the same impact on viewers regardless of what the program is. In a similar vein, the usage patterns will be similar for every person using a mobile smartphone. Those patterns are determined by the fundamental properties of the communication technology, not the specificities of the content. Those imply some basic ergonomic factors – regardless of the program, users will tend to watch TV in their home, in their living room, sitting in a couch, at a certain distance from the TV, etc. – and also macro-sociological factors. Television fostered types of social relations, modes of knowledge production, etc. very different from those that prevailed in the print era: just think at the way television drives a different paradigm in the transmission of news and information. If users are interacting with an app on a mobile phone, then those patterns of behavior are mostly conditioned by the specificities of mobile phones and the types of usage patterns that technology fosters – much more than by the particularities of each app, i.e. their content.

The good news is, you don’t really need to be considering the socio-political implications of mobile devices to manage your game. You just need to be looking for the output – namely the recurring play patterns that you can observe – and try to ensure the features you offer in your mobile game fit within those patterns. The first step to do that is to observe what those patterns are and find a design that accomplishes your monetization/KPI goals while fitting into those patterns. When designing a feature, don’t think about what you want users to do. Start by looking at what users are most predisposed to do and try to design something that will fit into those modes of consumption of mobile content. The path of least resistance is likely to be the one that will yield the most successful outcomes.

That’s because, simply stated, users won’t reorder their day or sacrifice prior obligations to play your mobile game. Now if you have a large enough userbase (and it doesn’t have to be that large for what I’m about to say to apply), chances are any design/feature you put out there will drive a group of individuals to modify their behavior to engage with your feature on your terms (“the way it should be played”). But if you think about it, that’s probably the segment of your users you least ought to base your design on – those users are willing to engage with your game regardless of the inconveniences of the experience (and those users will validate any design choice you make). Consider yourself lucky enough to have a pool of engaged users who like your title and want to engage with it despite the difficulties they face. They would certainly keep engaging with your title if things were easier for them. The reality is, there probably is a much larger segment of your userbase that will not do any efforts – let alone change their day to day – to play your game. That means the best ROI for your dev time and resources will consist in a) making your most enthusiastic users happier and b) lowering the barrier of entry for the more moderately engaged users. If the Super Bowl took place a Tuesday at 9:30 am you would have some people watching it – only much less than if it were on a Sunday evening. Broadcasters take that into account when deciding the schedule of a program. Do you take that into account when designing your live ops?

 

b) 3 levels of user cycle

There seems to be 3 main patterns/cycles occurring on a live game. Everything points to these patterns being relatively universal – you should find those patterns regardless of the game or the genre. That means they have little to do with the specificities of each game. Rather, they seem to point to the patterns mentioned above that characterize the way users interact with mobile entertainment products. Also in a general manner, non-payers are much more sensitive to these patterns. Customers tend to engage with your title much more – spending in your game will usually make your users more committed.

These 3 patterns are: a) daily – the patterns that occur within a 24 hour cycle; b) weekly – the patterns that occur within a 7 day cycle; and c) seasonal – the patterns that occur throughout the year. Keeping those patterns in mind can help you design your live ops. It won’t necessarily make your live ops good (you still need to monetize those users), but it will put you in the best position to leverage the highest userbase possible. The more you let users engage with a game on their terms (I am talking here in terms of schedule, not in terms of content, pricing or in-game offers), the more likely you are to design something that’s easy to come back to.

 

• Cycle within a day

The more granular you get, the more numerous patterns you’ll encounter. That means the more granular you get, the more difficult it will be to extrapolate general action items from your findings. One aspect of the daily/hour cycle seems interesting, inasmuch as it illustrates one of the main points above. Namely, user interaction with an app is user-centric (as in, not 100% driven by game features – internal factors) and follow patterns that are independent from any game content. It is organized around a 24-hour cycle.

Look at activity patterns based on hours since installs. Chances are, very consistently – even 30 days after installs – you will see regular spikes in activity at 24-hour intervals. You can easily check your own database, and you should be seeing something like below (this and all graphs shown here are idealized visualizations for illustration purposes only).

By in large – and regardless of the day of the week or the time of day install occurred – users play with the app most at the same time they installed it. And that makes sense. Very prosaically (or in a Darwinian manner), the user had an availability window to download your game when s/he did (or else s/he would not have downloaded it to begin with). And because your users’ lives are characterized by a pretty standard routine, that availability window will most likely be the same every day. So, if your user was available at 3:00 am to download your game, chances are high s/he will be available a few days later at 3:00 am to play it (incidentally, this pattern will probably be stronger for someone installing at 5:00 pm than for someone installing at 4:00 am. But in both cases, you should find the cyclical 24-hour trend).

I would argue the number one value of this insight lies in its potential to change outlooks. A large portion of the way users engage with your app is out of your control – the regularity of the spikes every 24 hours, even 30 days after install, clearly illustrates that. That’s a great incentive to see what those patterns driven by external factors are and leverage them to design a successful product.

On a more practical level, the install hour indicates the time of day it will potentially be easiest to get your user to engage with your game. It doesn’t mean any feature you will implement at that moment will be a slam dunk. But if you were to put a punctual or recurrent daily event, chances are it would perform best (at least marginally) at install hour. If you were to create only one daily appointment or send only one push notification a day, everything points to the hour at which install initially occurred to be the best time. So maybe the daily bonus doesn’t need to be available at midnight in the user’s time zone – you can just implement a daily cycle that resets at the hour the user installed. Ultimately, the feature you build around this depends on your own goals and targets. When users install your game, it’s as if they auto-identified themselves as most likely to play your game at that time of day.

If there were one type of game for which this might be particularly insightful, it might be games that follow the Heroes’ Charge model. In those games, there is a daily limit on a number of actions or times a user can engage with a game mode. So, determining when a day resets is something that must be implemented (even if it’s probably not game-changing KPI-wise). What the above suggests is that anchoring a user day on the user’s install moment would be at least as effective as grounding it in his/her time zone. And it’s maybe cheaper to implement – and a better use of your limited dev resources. It might not be very crucial to invest into a system to track the user’s time zone or a feature that allows to change the user’s daily cycle.

On a side note, this attention to time of day can be very interesting to come up with contextually relevant offers. First, generally speaking, the higher the exposure to the offer, the better you should expect it to perform. Second, being sensitive to the way users interact with your app and make it part of their daily lives can help you make them offers (IAP or not) that are the most relevant to them and the moment they are playing your game. Episodes’ “Bedtime Bundle” is the best (and only) example of this I remember having come across (even if it’s based on the time of day rather than the 24-hour cycle mentioned here). If you are playing/reading Episodes at night in bed before going to sleep, then this can clearly be a tempting offer. You can continue reading unimpeded at a quiet time in your day. This offer is not relevant from an internal/systems point of view. But it’s relevant for the user from the point of view of what his/her life looks like at that moment. Taking these extrinsic factors into account when designing your contingent monetization strategies will help you add value to everything you design.

Ultimately, there will always be value in considering the extrinsic factors that are required to make your game successful. It can be very easy and tempting to think of your game as a closed system whose performance is mostly attributed to internal factors – read, feature-based. And a lot of organizational dynamics in mobile game studios – i.e. who is part of the development team and the way people on the team interact and coordinate – can contribute to this emphasis on internal factors. Thinking in terms of an expanded understanding of “game-as-a-service” can help emphasize the fact that our games don’t exist in a vacuum but aspire to become a part of our userbase’s day-to-day lives. And a large part of our userbase’s day to day lives has nothing to do with our games (and our games are not that high on their list of priorities).

 

• Cycle within a week

One trend that appears when looking at hourly activity is that users are mostly active at 24-hour intervals since install – even 30 days after install. Another trend that can be observed is that there are always (slight) jumps in hourly activity on the 24-hour mark for days 7, 14, 21, etc. This denotes the way a user’s life is structured at a week level – i.e. on a 7-day cycle. It also is something you can observe when looking directly at daily retention: you should expect to observe these slight jumps on days 7, 14, 21, 28 etc. So just in the same way the install hour reflects the time of day the user is most likely to be available and drawn to play your game, the weekday the user installed your game reflects the day of the week s/he is most likely to be available and drawn to play your game.

Just like you would want to base your daily callbacks on the install hour, ideally you would want to base your weekly callbacks on the install day of the week. Designing a specific callback that is personalized for each user based in his/her install days or the week (and install hour while we’re at it) is an option. Another simpler option would be to try to capitalize on the existence of this natural tendency to log in weekly cycles – e.g. not providing a reward for engagement on any specific day of the week, but simply rewarding engaging with the game once a week (agnostic to the day of the week). Finding a way to reward users for login in once a week can be a cheap way to build upon this existing tendency in the hopes of improving your following week retention. For example, you can give users one free gacha pull per week – on the first day of the week they log in. Or instead of having a monthly login calendar you can have a weekly one – and have the first reward be valuable and desirable (and the last one too – you still want to encourage and reward users for logging in every day of the week). Or have a low commitment event run every week which tracks basic participation (and just participating once gives you something worthwhile). The list of potential features is infinite. Generally speaking, if there is a weekly cycle of engagement with your game (and there most likely is), then designing a feature that builds upon this by rewarding users for simply displaying a heart beat once a week can be worth investigating. And this can increase the chances of even your less engaged users coming back week after week So if an event were to be active for a 7-day period – rather than a fraction of a week or overlapping across multiple weeks – you should try to design your event in such a way to reward simple participation. That would effectively be the lowest barrier of entry possible: events last a week, simply participating in the event for one mission/action provides you with a valuable reward.

If you switch the perspective from days since install to day of the week, you also notice consistent patterns. Users who install on the weekends tend to have a lower retention – but you’re likely to have more users installing (you can look at organics only if you want to exclude any effect due to your UA). Incidentally, while the retention rate is lower, the fact that your installs are higher means you might be walking away with more users retained D1 – so that’s still a net gain for you.

How can you leverage this? As usual it’s up to you and what your goals are. But would you benefit from having more valuable day 0 offers in your game on weekends [incidentally, good value is not necessarily synonymous with low price point]? If you expect a smaller % of your weekend installs to return to the game – and if you observe that your weekend installs have lower conversion numbers – then you might be justified in having more generous conversion offers on day 0 (i.e. starter packs) for users installing on Saturdays and Sundays. Can you capitalize on the weekend increase in installs, while not cannibalizing future IAPs (because you might convert some users who might not even come back anyways)? Those are just some examples.

Switching your perspective from days since install to day of the week has the potential to generate more actionable insights for your live ops, especially events. One defining aspect of events is that it applies to all your userbase – or all your userbase that meets a specific requirement such as game level, tenure, etc. – in the same way. So, you’re limited in your ability to craft a personalized experience for all your users. Rather, this is more in broadcasting territory. On any live game, DAU will fluctuate depending on the day of the week. Specifically, you should be seeing spikes in your DAU on Saturdays and Sundays. Going back to the extrinsic factors, that makes sense. Users have more free time on the weekends to install or play your game.

By extension, if you look at next day return rate (the live ops counterpart to the cohort-level retention ), then you should unsurprisingly see that users playing on the weekends are less likely to come back and play the following day [the cleanest way to look at this is probably to only consider users that have a tenure of 7+ days].

Now, there are a number of different ways you can build your live ops or events around this. What clearly appears is that you will have a larger DAU on weekends, but those weekend users will probably be less engaged – or the least inclined to play the following day. Furthermore, not only is that DAU larger, it probably has a higher % of non-payers. So that means it might be harder to monetize your Sunday userbase.

The big question is how will you build your events around this? This is probably an area where there will not be any general conclusions to help you guide your live ops design. Ultimately, you have to use your best judgment and consider the specificities of your live ops/events and monetization strategy. This is because usually live ops are used as a way to maximize monetization. And monetization is much more dependent on contingent factors than engagement. Monetization is highly dependent on the specificities of your game, your features, and the IAP offers you have. So, having a userbase participating in your live ops is a necessary condition for its success, but not a sufficient condition. The key to running successful events lies in creating an environment where you can offer a relevant and compelling value proposition and maximize your available participants. We’ll be focusing here on how to maximize engagement and discuss monetization in a later post.

Although there are no general conclusions there can be general questions that you can answer to balance your event and find the best moment to start and end your live ops in order to maximize the volume of your participating userbase. If one of the conditions for your live ops to be successful is to have a large portion of users engaging with it, then considering your weekly fluctuations in users can be a good starting point. How can you leverage those natural tendencies to ensure you maximize the % of your DAU engaging in the event?

First, how do you leverage this to tune your event? You can expect more users to be active on the weekends. If your event is competitive (even if it’s not a zero-sum game among users where they compete for a spot on the leaderboard, they will be competing against the clock), then you should find a way to provide a competitive advantage to your weekend users to further incentivize them to engage with the event. The most straightforward way can be to have a points multiplier – if an action provides 5 points during the week, the same action can provide 10 during the weekend (and while you’re at it, it can always be worth having a monetization offer that users will clearly be able to associate to a better performance in the event).

Second, how do you leverage this to determine the start and end point of your event? This one is trickier – and probably will depend more on the specificities of your event and your monetization strategy. Intuitively, a weekend only event is likely to be the one fostering the biggest engagement – in terms of % of unique users during the event participating every day of the event. And that can be tested and checked easily. The thing is, if you chose to go this route you are not monetizing through events for 5 out of 7 days of the week. That can be problematic for your bottom line, especially since there is a higher customer concentration during weekdays (topic 3), and there might be a higher pressure to compete among your most valuable users with the highest propensity to spend. So as far as duration goes, trial and error seems like the only way to determine what’s best for your game.

As mentioned above, if this approach does not provide you already made answers, it might at least provide a framework to ask the right questions. This is especially the case to determine the start or end point of your event. If you know there is a higher DAU on weekends, how does playing on the first day or last day of an event impact participation throughout the week? Is it better to end an event on a weekend or start it on a weekend? Or maybe, you can have weekly events start on Sundays and end on Saturdays – to try to keep your userbase engaged in your events week after week. But it provides you with the tools to answer questions in regard to the specificities of your game.

 

• Cycle within a year

The last cycle you should be able to observe in your game is a yearly cycle. Namely, those consistent jumps in DAU on Saturdays and Sundays flatten out in the summer months.

That makes sense. During the summer, a bigger portion of our users are on vacation. And specifically, that means their week is not structured around their main activity (work or school). So, all the weekly regularities you observe throughout the year kind of fly out the window. Users play more whenever they like, and don’t gravitate as much around the install hour or day of the week.

This is where on a methodological level it’s a bit challenging to do anything with this. There have been few years (and summers) in the mobile F2P era – regardless of when you chose to make it start. So very little to build any generalization on. Furthermore, there have been so many changes in the mobile landscape in the last few years that there maybe is less to learn from 5 years-old patterns than we’d like to believe. Data from the World Bank shows that the number of mobile cellular subscriptions in the US – which can act in this case as a proxy for mobile phone penetration – had a 34% jump between 2013 and 2016. So the yearly cycle is maybe one of the best cases which highlights the limits of our available data, and the necessity to combine data with a more socio-cultural understanding of our userbase. Despite these changes in mobile penetration, the fact that the way work or school structures people’s daily activities has not changed much would lead me to believe this pattern will be relatively consistent in the years to come.

 

Thinking about the parallels with broadcasting: what is TV programing like in the summer (for those who still remember TV)? I personally find it rather boring. More objectively, TV in the summer is much more “non-committal”. There are much fewer weekly shows – much less weekly appointments. People’s schedule is much more volatile in the summer, and it’s harder to make them come back at a fixed appointment. By extension, what is the parallel for a mobile game. First, maybe the long-term event format is not what is best for the summer months. If it’s harder to get users to return to the game at regular intervals, maybe we should focus more on making the most of it when users actually do log in. Maybe during the summer months events should be self-contained – i.e. start and end on the same day. Or at the very least run over a shorter course of days. Maybe you should have a variety of offers always available during the summer. Those are just a series of random suggestions. The main takeaway from this is: if users are more volatile in the summer, how can you leverage the existing specificities of your game (or design specific features) to make the most of this volatility? Or better yet capitalize on it.