Beware these soft-launch mistakes

Despite huge potential rewards, working in mobile game development remains challenging for developers and publishers. Crowded app stores and high UA costs mean that carrying out a successful soft launch is more important than ever. Before committing a marketing budget to your next game or pitching for investment, a well executed soft launch will tell you if your game works, can engage players and, most importantly of all, is commercially viable. This is especially true within mobile; the ruthless economics of F2P mean that if you can't prove during soft launch that the cost of acquisition is less than lifetime value, then your game is simply not going to be profitable.

Despite this, it's still all too common for soft launches to go wrong, with time and budget running out before the developer has had a chance to get their title into shape. In some cases, the soft launch period can go on much longer than anticipated, burning cash while the market moves on and trends change.

Whether you're preparing for your first soft launch of a new IP, or simply looking for opportunities to improve your process for your next game, here are the 3 most common soft launch pitfalls you should look to avoid.

Choosing the wrong territory

Deciding what territories to use for your next soft launch might initially seem obvious, and there are some well documented choices that developers tend to gravitate towards. However, before you pull the trigger and start spending on UA, it's worth taking a step back to first think about what you are trying to achieve.

"For commercial tests you want to collect KPIs that are going to be representative of a full global launch, so it's important to select territories that are economically similar to your eventual target market"

Your choice of territory will largely be based on what you are trying to test in any given period of your soft launch phase. Broadly speaking, there are three key points you are trying to prove during soft launch:

The game works technically

You need to know that the game runs successfully on target platforms and, in the case of online and multiplayer games, can handle the necessary volume of concurrent players. For these types of test, player quality is not as important as player volume, and you should seek out territories with a low CPI (cost per install) in order to acquire large volumes of players as cost effectively as possible. Indonesia, the Philippines and Thailand are common choices with low CPIs, typically well under $1.

The game can engage players

It's vital that the core loop is fun and players continue to return to the game regularly. Usually at this stage, your primary concern is retention and engagement - you are more focussed on how players are interacting with your core mechanics, what features are popular/not popular and how long players stay in your game rather than specific revenue metrics. As with a technical test, you can prove these metrics with high-volume, low-cost players in territories where CPI is low.

The game is commercially viable

The game's economy and monetisation model must be effective, profitable, and justify a fully marketed global launch. By now, you've proven that you have a fun, engaging game and are measuring and refining how well your game monetises - how many players convert to payers, at what stage they convert, and how much they spend. For commercial tests you want to collect KPIs that are going to be representative of a full global launch, so it's important to select territories that are economically similar to your eventual target market, which usually means a higher CPI. Australia, New Zealand and Canada are common choices here.

In many cases you are likely to be performing a mix of these tests at once and should therefore try to balance player distribution accordingly as you progress through the soft launch window. However, selecting a territory with a high CPI before your game is stable and bug free can be costly as initial builds are likely to see increased player churn rates and negative store reviews as early bugs are found - it's therefore important to think carefully about where and when you soft launch.

Not collecting enough data

All developers should approach soft launch with an open mind; there's no guarantee that what you think is right for your game will prove a hit with end players. During any soft launch it's vital that personal bias is removed and data alone is used to determine what is and isn't working.

"The goal is to be able to identify the potential underlying causes of poor KPIs as well measuring the actual KPIs themselves"

It's crucial that before you start bringing players into your game you are collecting information that will allow you to make good decisions further down the line. Most analytics tools provide common KPIs such as retention, MAU, ARPDAU, etc. but there are also many game-specific metrics you should collect that will help you answer important questions, including:

The FTUE (first-time user experience) funnel

How many first sessions are going according to your expectations? Are players making it through your tutorial? Are they playing long enough to engage with the game's core mechanics?

Player progression

How quickly are players progressing through your game? Are they accumulating currency or finishing levels too quickly and becoming bored, or are players hitting an unexpected early pinch-point and leaving after becoming frustrated?

Purchase context

After what specific action do players make their first purchase? How far have players progressed in the game before converting? What is the average time to conversion?

The goal is to be able to identify the potential underlying causes of poor KPIs as well measuring the actual KPIs themselves. If you can see that day 30 retention is poor, for example, it's important that you have enough information on player behaviour to make a qualified guess as to why that might be the case, so you can then make the appropriate changes to your game.

As well as making sure you are collecting the right data, you should also have a plan for analysing your data so you can get the answers you need quickly. Different analytics platforms provide different method of doing this and part of your preparations for soft launch should include using data from your development builds and analysing it just as you would with live data. This will ensure that once your game has launched, you don't suddenly realise you are missing key information and have to distribute a new build, potentially having wasted money on acquiring players who have now left your game.

Inability to iterate quickly

The Build, Measure, Learn loop is a product development principle popularized by the book The Lean Startup that emphasises speed of iteration as a key component in product development. When using Build, Measure, Learn, the goal is to release an MVP to market as soon as possible, measure it's performance and then update that product based on user data, repeating the loop as often as required. While the principle is not specific to game development, this is exactly the mindset that developers should adopt when soft launching a new title.

"Prior to soft launch you should ensure that you have the ability to remotely modify as much of your game as possible through server side updates rather than redistributing new builds"

Many teams will work within a fixed budget or timescale for soft launch so the faster you can make updates and changes to your game (in other words, go through a single iteration of the Build, Measure, Learn loop) the more information you will collect. In turn you will learn more about your players and your game will become better and better through each iteration. In many cases, it is also not obvious what specific change will cause the biggest swing in KPIs, so it's important to give yourself as many chances to iterate as possible.

To help you do this quickly, prior to soft launch you should ensure that you have the ability to remotely modify as much of your game as possible through server side updates rather than redistributing new builds. Some of the changes you might want to make through server updates could include:

Purchase prices

Changing what items are shown to the players, the price of each item and item descriptions.

Economy balancing

Starting in game currency values, soft purchase prices, in-game rewards, cool down timers.

General game configuration

Game difficulty, social prompt location and frequency, in game advert frequency, UI prompts and messaging.

Ideally, the server platform you are using to provide updates should also enable you to perform A/B testing - testing different variations of a change on multiple player groups concurrently. This can help you make more efficient use of acquired players by running multiple changes in parallel on groups of players. For example, you might want to try out 2 different versions of your game economy, one that doubles the cost of in-game items and one that halves them, and then see how the changes affects your KPIs.

Of course, it's inevitable you will have to redistribute new builds to fix bugs and add or remove larger features, but the more changes you can make to your game remotely, the faster you'll be able to iterate during soft launch.