Redeposits part 1: How to look at your redepositing users?

Is “redeposit” a KPI?

A colleague of mine recently reminded me of something that’s very easy to lose sight of: there should only be a few Key Performance Metrics (emphasis on Key). If you are dealing with 50 metrics, then they are not (all) key. With the increased availability of data, you can easily end up in a situation where you have so many metrics it becomes difficult to provide a clear and coherent evaluation of your title’s performance. More specifically, it’s this multiplication of metrics that makes it harder to have a single, straightforward and coherent diagnostic. In fairness, this multiplication of metrics is often warranted by the reality of the situation. Things are rarely black or white; they are always a specific nuance of grey. And perhaps paradoxically, it’s when things are the fuzziest (read: greyest) that you need the most data to make sense of things. And it’s precisely when things are the greyest that is becomes harder to simply rely on a small set of key indicators to assess a situation…

This weeks’ post is not about how to embrace ambiguity in the analysis of mass social behavior (but this is definitely something I want to tackle in the future). It’s about monetization, conversion, and more specifically redeposits (the act of making another purchase). If you work on a free-to-play game in which the monetization strategy is predominantly IAP-based, then conversion rate – the proportion of your installs that has made an IAP – is a true Key Performance Indicator. Redeposit is a metric that is critically important, but it doesn’t always have the “Key” status it deserves.

Looking at conversions is clearly important. But one thing that is pretty much guaranteed is that all payers don’t contribute equally to your title’s overall revenue. That means that simply being a payer is not enough to say a group of users will have a strong impact on your revenue. One exercise that can help put that into perspective is grouping your paying users per LTV percentile buckets and seeing how much of your title’s lifetime revenue comes from users in that bucket. What I mean by that is: distribute your users according to their actual LTV (for example, bottom 50th percentile, 50th to 74th percentile, 75th to 90th percentile, etc.), and see how much total revenue is coming from payers in that LTV percentile bracket. It’s better to classify your users per LTV percentile rather than an absolute threshold (for example: users with an LTV of $200 or more) because that way, you are classifying your payers dynamically relative to a) your own game, and b) the amount of time your title has been live.

a) Having an LTV of $200 doesn’t mean the same thing in a match-3 and in an RPG

b) If someone has an LTV of $200 3 days after your worldwide launch (out of a handful), it’s not the same thing as having an LTV of $200 3 years after your worldwide launch (there will hopefully be much more paying users with a similar LTV at that point)

I’m not even addressing here the usage of sea animal typologies which I find both counterproductive from a product/data perspective and oddly demeaning of our own work. To my knowledge, no other branch of the entertainment industry has formalized a derogatory term for people who engage the most and are the most passionate about their products (if there is, I would be curious to hear about it).

So, if you look at your payerbase this way, there is a good chance that your bottom 50% payers account for less than 5% of your title’s revenue, and even that your “bottom” 75% payers account for less than 10% of your lifetime revenue. Said otherwise, 75% of your payers (so users who have converted) might not even have accounted for 10% of your total revenue. Conversely, you might be in a situation where your top 5% payers account for 50 to 60% of overall revenue. So, while being a payer (having converted) is a necessary condition to make a contribution to your revenue, simply having converted by no means guarantees a significant contribution.

Now you can do a similar experiment and distribute your payers according to the number of IAP transactions they have done. This will highlight just how important redeposits are, and also give you a sense of how many redeposits you actually need to be thinking about. If you were to graph this you should be looking at something comparable to the below graph:

tr_per_payer

 

This way to categorize your payers and the source of your game’s revenue emphasizes how redeposits – paying after the first IAP transaction – are key for the sustainability of your game and its financial success. If you see that users who do 5 or less IAP transactions account for 30% of your overall revenue, then that can also help you set a tangible and measurable goal in terms of monetization.

 

How to look at redeposits?

There are 3 important ways to look at redeposit: cohorted redeposit rate, payers redepositing, and redeposit patterns. These 3 perspectives combined can help you evaluate the performance of your game, track its evolution over time, and compare the monetization patterns of your game with other titles.

 

Cohorted redeposit rate

Just like you can have a day x conversion rate – which tracks the % of your installs who has made one transaction – it can be very useful to look at day x redeposit rate. In order to determine day x conversion, you presumably look at the % of baked installs who have performed an IAP transaction by that point (a user is baked at day 15 if s/he installed 15 or more days ago – you don’t want to be considering the day 30 conversion rate of your cohorts who installed 12 days ago). In a similar vein, you can track day x redeposit by looking the % of your installs that has made 2 or more IAP transactions by that point. If you were to graph it, you should get something like this:

conv_redeposit_d30

 

Having redeposit rate as a KPI alongside the usual suspects – retention, conversion and LTV – can be a practical addition to track the health of your game. Especially if you are sensitive to the fact that conversion is a means to an end and not an end in itself. Tracking redeposit rate will put you in a better position to quickly assess the health and changes occurring in your game. For example, you might introduce an offer that helps increase conversion but makes redeposit drop (because it anchors value perception at too low a price point and deters payers from redepositing on default bundles; or because it is not a good value proposition and leads to a disappointing experience). You need to track redeposit rate to keep an eye on one of the monetization patterns that matters the most.

 

Payers redepositing

Whereas redeposit rate considers redeposits from the perspective of your cohort (looking at everything from the perspective of your install base), when you look at payers redepositing you are considering things from the perspective of your payer base. For example, from a cohorted point of view your day 30 conversion is 2.5% and your day 30 redeposit rate is 1.5%. That means that 60% of your payers converting within 30 days of install have redeposited.

When looking at the number of IAP transactions done by payers, it’s interesting to view the spending process as a funnel: how many payers do purchase number 1, number 2, number 3 etc.

transaction_dropoff

 

The “% of payers” part of the graph is relevant because the IAP transaction axis is not mutually exclusive (that is not the case for the above graph “Payers and Revenue”). So it’s easier to see what % of payers have done 2, 3 or 10 transactions. In the above graph, 100% of payers have done 1 transaction, 55% have done a second one, 40% have done a third purchase, etc. Looking at things from this perspective also allows you to look at “transaction dropoff”. Namely, the percent of payers doing purchase n that goes on to make purchase n+1. The dropoff rate gradually decreases – until the point at which it stabilizes. It’s going to be highest after the first IAP transaction. This has practical applications – specifically, identifying when the dropoff point stabilizes provides a good indication of when your payers are “on rails”. That can provide you with a tangible goal you should aim for.

 

Redeposit patterns (how often and at what price point?)

The third way consists in looking at the purchases themselves: how long between transactions, and at what price point? This will help you assess the pace at which spending occurs – and also the “intensity” of spending. The most likely scenario is that a majority of your redepositing users are spending every 24 or 48 hours at relatively low price points (if not your lowest price point). What this means is that your biggest spenders make a small purchase on a daily basis – they don’t make infrequent bulk payments (that’s why your payer retention is crucial).
You want to be looking at things from the perspective of the number of transactions. How long does it take a payer to make his 3rd purchase, his 4th, his 5th, etc. In a similar way, what is the amount spent by a user on his/her 1st transaction, 2nd, 3rd, etc. If you were to map it out, you should expect to see something like this.

time_since_previous_transaction

purchase_price_point

 

As far as time to redeposit goes, the median time to redeposit is usually always within the 24 to 36 hours range. As users make more purchases, this time to redeposit decreases and eventually plateaus – keeping in mind that each additional purchase is accompanied by additional payer dropoff, and that you are left with fewer and fewer payers (your most engaged) at each transaction number. For the price point of each transaction, the median price points you will see will greatly depend on the specifics and contingencies of your in-game pricing and IAP offering. Usually the median price point will start close to your lower price point (that is, unless you have a very successful and highly priced conversion offer), and slightly increase – then plateau.

 

Next part 2: how to leverage these metrics to optimize your title’s performance

6 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