What a soft launch actually tells you (and what it doesn't)

Soft launching in a smaller market before going global has become routine in mobile games. The intent is sound: ship to a population that's representative enough to test the game, small enough that mistakes are recoverable, and similar enough to your target market that the metrics will transfer.

The problem is that the lessons most studios actually draw from soft launches are often the wrong ones. Revenue numbers get treated as predictive when they aren't. Retention numbers get treated as final when the player mix is unrepresentative. Bugs and crashes get found, which is real value, but the larger commercial questions soft launches are supposed to answer often come back with answers that don't survive the move to a global release.

The issue isn't soft launches themselves — they remain useful. The issue is misreading what they actually tell you.

What a soft launch is actually testing

A soft launch is genuinely good at answering four kinds of questions.

It tests whether the build is stable enough to scale. Crashes, performance issues, server load behaviour, and infrastructure cost all become visible when real players hit the game at real scale, in a way they don't during internal testing. This part of the soft launch is essentially a load test for everything that touches actual players.

It tests whether the core loop is comprehensible. If new players in your soft launch market can't figure out what the game is asking them to do, that finding will transfer to your global launch population. The specifics of which moment confuses them are useful, and the fix usually applies cross-market.

It tests whether your onboarding flow is paced correctly. Drop-off at specific tutorial steps, time spent on initial decisions, and the rate at which players reach the first meaningful gameplay moment are reasonably stable signals across markets, because they're driven by the game's design rather than the market's economics.

It tests whether the technical analytics pipeline works end to end. Whether events fire correctly, whether the right data lands in the right place, whether dashboards reflect reality. This is unglamorous but important — discovering that your event schema has a bug after global launch is much worse than discovering it during a soft launch.

Why market choice changes what you measure

The mistake studios make is using soft launch data to answer questions it can't answer well. Three categories of metric are particularly unreliable across markets.

Revenue per player is the most obvious. Average revenue per daily active user in a soft launch market is a function of that market's spending norms, payment infrastructure, and pricing tier structure. A game that earns one number in the Philippines or Vietnam will earn a different number in Canada or Germany, and a third number in the United States — even if every player behaves identically inside the game. Treating your soft launch ARPU as a forecast for your global launch ARPU produces predictions that miss by large multiples.

Retention is more subtle but also unreliable. Different markets show structurally different retention curves driven by different mobile habits, competing entertainment options, and even network reliability. A soft launch in a market with cheaper data and longer commutes shows different session patterns than one in a market with expensive data and shorter idle moments. The shape of your retention curve in the soft launch tells you something about your game, but the absolute numbers don't transfer cleanly.

Acquisition cost is the third. Cost per install in a soft launch market is almost always lower than in your target launch market, because the audience is less contested. Building a global launch plan around the cost per install you saw in Indonesia or the Philippines leads to a budget that disintegrates the moment you start bidding for US installs.

The signals that transfer (and the ones that don't)

A useful way to separate the soft launch signals worth acting on from the ones to set aside is to ask: is this metric driven mostly by the game, or mostly by the market?

Metrics driven mostly by the game tend to transfer. Session length, depth of progression in the first session, completion rate of specific tutorial steps, drop-off at specific gameplay moments, the share of players who hit a particular wall, the bug report rate per thousand sessions — these are properties of the build, and they show up similarly across markets once the build doesn't change.

Metrics driven mostly by the market don't transfer. ARPU, conversion rate, average bundle size, willingness to spend on the top price tier, response rate to push notifications, organic install rate, App Store featuring response — these are properties of the player population, and the soft launch population is structurally different from your launch population in ways that matter.

The trap is that the easy-to-headline metrics — revenue, conversion, install volume — are mostly in the second group. The unglamorous metrics — drop-off at step 4, session length distribution, percentage of players who reach the core mechanic — are mostly in the first group. Studios that focus their soft launch on the second set get clean answers they can use. Studios that focus on the first set get noisy data they over-interpret.

When to extend the soft launch and when to stop

A common pattern is to extend a soft launch repeatedly, hoping that "one more tuning cycle" will improve the metrics before global. Sometimes this is right — there are real things you can still learn. But extension has a real cost: every additional week is a week of marketing window lost, and the team is operating under the constraint of a half-launched game rather than a finished one.

The signal to keep extending is that you're still making changes that move game-property metrics in the soft launch — drop-off at a specific point, session length, depth of progression. If those numbers are still responding to design changes, you're still learning.

The signal to stop is that your iterations are moving the market-property metrics — ARPU, conversion — and you're starting to optimise for the soft launch population rather than your launch population. At that point, additional time in the soft launch is producing diminishing real returns and increasing the risk of building a game tuned for the wrong audience.

What "ready to launch" actually means

The most useful frame for ending a soft launch is not "the numbers look good" — it's "we've answered the questions the soft launch can answer, and the remaining questions can only be answered by launching."

If your build is stable, your funnel is clear, your onboarding works, and your analytics are reliable, the soft launch has done its job. The commercial questions — how much will real players in your real launch markets actually pay, how will retention behave at scale, how will paid acquisition perform at real cost — only have real answers after you launch. No amount of additional time in a soft launch market produces those answers in a form you can trust.

See how we use early signals to plan a launch →

Soft launches are valuable. They just aren't crystal balls. Reading them as the signal they actually are — a load test plus a design test, with the commercial test deferred to launch — gives you a cleaner basis for deciding when to go live.

Talk to us about turning soft launch data into launch decisions →