Using login velocity to anticipate churn (and act upon it)

When is churn?

Churn is a tricky notion in mobile games – despite it being discussed so widely. If you are a cable service provider or telecommunications company, then churn refers to a very clear and unambiguous action: the cancellation of a contract. In a contract/subscription model, the “default” behavior, the state of inertia is remaining in your contract (and paying beyond death). The essence of the subscription model is “auto-renew”. User action consists in putting an end to the subscription – that’s churning.

Things are reversed in the mobile free-to-play landscape. The “default behavior is not returning to the game – it’s ignoring the game. The key action where user agency expresses itself is returning. So, technically churn does not exist in mobile free to play – users were never bound by any commitment to begin with. In mobile games you need to be proactively driving your users to keep coming back in your game day after day – ideally for years.  This is not to say telecommunications companies don’t need to give good service – but they need to avoid driving people to the point they want to discontinue the service.

So, the first point to keep in mind is that technically it’s not churn. Users don’t churn: they are not returning. And this difference, while subtle in appearance, accompanies a radical difference in perspective and outlook. But at this point “churn” is common terminology so let’s just go with it.

Churning is never irreversible in mobile games – I haven’t logged into Boom Beach for 2 years, but as long as the game servers are up and running I can go back and play it (and now that I think about it I probably will). So that means the first step consists in determining the time frame which you need before considering a user churned. This is something that will greatly depend on the type of game you manage and the level of uncertainty you’re comfortable with. The relevant timeframe might not be the same If you’re managing a hyper-casual game or an RPG or an RTS base-builder.

Determining the time is takes to consider a user as churned is ultimately a judgment call. There are a few different ways to go about. You can look at the time between different sessions. If you see that 99% of sessions made by users occur within 14 days of each other, then you can confidently assume a user who hasn’t returned within 15 days has churned. Another potential way to look at it is to frame thing from the perspective of users – and in this case the picture might be slightly different. If you look at the % of users who have “successfully lapsed” different periods of time (the % of users who eventually returned after a period of inactivity), then you might see that lapsing is something relatively common. More importantly here, lapsing for relatively long periods of time is not uncommon. In the example below, you see that 50% of installs have returned to the game after a period of inactivity of 3 days or more. And 35% of installs had a lapse of 14 days or more at some point and ended up returning to the game after that lapse. These are sample values, but ballpark this is what you should expect to see.

lapse.png

While those “successful lapses” cover a great amount of time and concern a significant portion of users, they don’t occur often. In other words, 35% of users might have experience a lapse of 14 or more days at some point – but they only experience such a long lapse once.

times_lapsed.png

So, if you consider a user has churned after 14 days of inactivity you will be including users who will eventually come back. But you won’t be including them often. Once you’ve determined the time frame you’re comfortable with to define churn, you can start to see how tracking users’ login velocity can help you anticipate at-risk behavior.

Churn and (previous 7 days) login velocity

If you want to have an impact on user behavior, then your users need to be in the game. You maybe have a few different “out of game” options at hand such as lifecycle marketing or push notifications. But ultimately, you’ll be most successful at impacting user behavior while they are in your app. That leads to the paradox that you need to act on churn while the user is active in your game. So, you need to act preemptively while the user is still within reach. You don’t want to wait for the user to flatline and try to bring him/her back. That’s going to be much harder than trying to avoid having your user churn in the first place.

Login velocity on a given week is a good indicator of following week return rate. A user who plays 6 or 7 days on a given week is much more likely to return to the game the following week than a user who only logged in once.

next_week_per_days

But looking at things this way – in a weekly way – is not the best way to act upon churn. You can’t look at login behavior over the course of an entire week to evaluate the risk of churn. If a user logs in on Monday, you can’t wait for the week to be over to observe s/he actually only logged in once – and simply realize that user’s risk of churning is high with little recourse at hand. If you do nothing on Monday, you might not have another chance to influence that user into returning.

That’s why in order to preemptively address churn you need to assess the risk of churn on a daily level. You need to be like the cop who measures the speed at which the car is going – except in this case you measure the login velocity of the user. Specifically, every time a user logs in the game (crosses the odometer), you want to be measuring the number of days logged in in the previous 7 calendar days (measure the car’s speed). If the user has not been logging in frequently enough, then you have a sense that user is at risk and you should do something to reduce the propensity to churn.

When you look at things this way, it will be much easier to identify who you need to target. Very consistently, the less a user has logged in in the previous 7 days, the higher the chance s/he will not show up in the following 14 days (don’t forget the graph below will be more meaningful if you look at users who installed more than 7 days ago).

churn_of_actives_prev

You can then start evaluating the degree of risk you are willing to take. You’ll be pretty safe if you target users who have not logged in the previous week or who only logged in once. You probably don’t need to go out of your way too much to prevent a user who logged in 5, 6 or 7 of the last 7 days from churn. Ultimately, you’ll need to make a judgment call on when the risk of churn becomes too high (is it 5% or 10%, or more?). But this judgment call needs to take into account what it’s costing you to prevent the user from churning. [As a side not, while “cannibalization” can clearly be a thing, I’ve found more often than not the risks of giving bonus rewards to users are greatly overestimated – especially if you don’t give resources]

Looking at the number of days a user logged in during the previous 7 calendar days makes it easier to identify who you must target with this “anti-churn action”. But you still need to determine what this action will be. The specific actions you take to keep the user in your game will vary greatly from one game to another. What do users value? What is the biggest time investment? What are the challenges a user is likely to face (and what can you give him/her to overcome that challenge)? Ideally, you want to provide something that is both rewarding and that will require a time investment from your user. If you’re in an RPG game, then perhaps giving your users a high strength character – that needs a long time investment to level up and develop to its full potential. You give something to your at-risk user and hope it will be enough to keep him/her in your game a bit longer.

User life and login ratio

Looking at the number of days an active user logged into the game in the previous 7 days also provides interesting insights into a user’s lifecycle in the game. If you were to retrospectively map the lifetime login patterns of a churned user, you would probably come across a very clear pattern – regardless of the game. Users start playing the game very frequently. Login velocity then slightly decreases and finally sharply decreases until the user never returns to the game. Users don’t quit your game and suddenly disappear out of the blue. They gradually login less and less often until they don’t log in anymore.

Say for example you want to look at the login pattern of a user who has churned, and who has logged in a total of 30 distinct days in his/her “game lifetime”. For every day the user logged in, you want to look at the average days logged in during the previous 7 calendar days.

lifecycle_prev7.png

In the example above it doesn’t matter if the 9th day logged in occurs 9 or 90 calendar days after install. This is only looking at the occurrences where the user actually logs into the game. After the 9th day played, login velocity starts to gradually decrease. It drops shortly before the user churns (his/her last day). You can look at users who played 30 days before churning, or 90, or 112. The pattern is consistently the same. And you also see that pretty consistently, when engaged users are only logging in 3 of the previous 7 days, they are only a few logins away from churning.

lifecycle_all

And for good measure – because login velocity is an average, and average times can be tricky – you can look at the median days logged in the previous 7. The decay you should observe is not an artefact of the game’s lifetime (where a large number of lapsed users with 0 days played in the previous 7 return to the game), but rather a pattern common to the majority of users.

median_days_logged

3 comments

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s