原文作者：admin 译者：Vivian Xue
谈到这一点，我想最好先给测试发行下个定义。“测试发行”的含义有很多，它可以指一项技术测试、一个最小化可行产品（minimum viable product）、一个垂直截面（vertical slice），或者表示“是的，我们做好准备了”。
我认为测试发行的目的就是测试。测试发行, 用Eric Ries（精益创业运动的发起人）的话来说，就是“走出办公楼”（get out of the building）。尽快地让你的产品（游戏）到达真正的玩家们手中并能在平常的环境下体验它（而非在一个焦点小组里）。
技术测试。如果你是3A级游戏开发者，你可能会称之为“Closed Beta”甚至“Closed Alpha”。这个版本主要是对游戏的技术方面进行检测，这对于有联网需求的游戏尤为重要，比如《炉石传说》（Hearthstone）或者《部落冲突》(Clash of Clans)这样需要匹配的PVP游戏
商业测试。这是人们对测试发行通常的理解。商业测试的关注点主要是用户留存、首次用户体验（first time user experience）关卡完成率以及转化率和平均用户收入这样的盈利指标。它旨在回答一个问题：我的用户的终生价值是否足以证明产品投入市场的合理性？
投入市场。到了这一步，你将开始着手为游戏调动所有的营销支持。利用Google或苹果这样的特色平台，如果你拥有《植物大战僵尸》（Plants versus Zombies）或者《愤怒的小鸟》（Angry Birds）这样的强大的IP,你很容易就能把游戏推广到全球范围内。这就意味着你可以利用游戏进行交叉推广，带动其它游戏的增长，或者在用户获取方面下血本。无论采取什么样的营销手段，你的目的就是最大程度地确保发行的成功。这也是测试发行的关键。
并非所有游戏都需要单独的技术测试。对于很多非多玩家参与的线性游戏来说，在进行商业测试前没必要进行大规模的技术测试，比如《微型摩天塔》（Tiny Tower）或者《辐射避难所》（Fallout Shelter）这样的单机游戏。
事实上，比这更糟糕的是，像登录奖励或者成就这样的元素会掩盖那些真正影响用户留存率的指标。《天天过马路》（Crossy Road）和《飞扬的小鸟》（Flappy Bird）因为自身足够有趣，根本不关注这些用户留存策略。但是即使是像Simpsons Tapped Out或者《辐射避难所》这样的游戏也需要提高游戏的趣味性来吸引玩家，而不是仅靠每日登陆奖励。
我们是否可以在后期加入这个元素，并且不会对游戏的核心体验造成影响？那么去掉它（成就和Game Center关联通常属于这一类 ）
正式发行（The hard launch）
You are putting too many features in your soft launch.
Don’t worry, everyone else is too. But by doing so you are wasting time, spending money you don’t need to and jeopardising the long-term future of your game. Here’s why.
What is the point of a soft launch?
A soft launch exists to answer one question:
Is this game good enough for a marketed launch?
Perhaps at this point, it would be good to have some definitions. People use the phrase “soft launch” to cover a multitude of meanings. It might mean a technical test. It might be a minimum viable product. It might be a vertical slice. It might be a final “yep, we’re ready to go.”
To my mind, the purpose of the soft launch is always to test. You want to use the soft launch to (in the word of Eric Ries, the founder of The Lean Startup movement), to get out of the building. To get your product (in our case, a game) into the hands of real players, using it in a normal circumstances (i.e. not in a moderated focus group), as soon as possible.
I consider there to be three types of launch or test:
A technical test – if you come from AAA development, you might call these a closed Beta, or even a closed Alpha. This launch tests if the technology works. It is particularly important for a game with significant online functionality, such a PvP game with matchmaking like Hearthstone or Clash of Clans.
A commercial test – this is what is often thought of as a soft launch. The commercial test focuses on retention, FTUE (first time user experience) completion rates and monetisation metrics like conversion rates and ARPU. It is designed to answer one question: is the lifetime value of my users good enough to justify a marketed launch?
A marketed launch – this is where you pull the trigger on whatever marketing support you have for your title. It might be a platform feature from Apple or Google. If you have a strong brand like Plants versus Zombies or Angry Birds, it is simply making the game available globally. It might mean cross-promotional support from other titles in your network, or it might mean spending a million dollars on a User Acquisition campaign. Whichever marketing tools you have at your disposal, you want to maximise the chances of a strong, marketed launch. That is the point of the soft launch.
So let’s dig into how to do each of them well.
The technical test
Not all games need a separate technical test. For many linear games with no multiplayer element, there is no need for a large-scale technical test separate to the commercial test. Games like Tiny Tower or Fallout Shelter, which are essentially single player, may not need a separate test.
Games which might need a separate technical test include:
Multiplayer games: can the servers handle enough peak logins? How can we scale if peak concurrent users get too high? How can we fail gracefully?
Matchmaking games: is our matchmaking system robust? What happens if we can’t find a match? How does our matchmaking algorithm work in the real world? How can we minimise the delay between pressing play and starting to play a game?
Online games: any game where the player is required to be online at all times might need a separate technical test to prove that the servers can handle the load without creating unbearable delays for the user.
The key advantage of running a separate technical test is that it might save you lots of money. Many commercial tests take place in Denmark, New Zealand and Canada, for reasons I’ll discuss below. These are high GDP per capita nations and user acquisition costs can be high, not least because of all the soft launches in those territories.
But for a technical test, you don’t care about commercial issues like monetisation. You just want to know if your game can handle 10,000 users, or how much liquidity you need for your matchmaking algorithm. For that reason, many companies choose countries where the user acquisition cost is low for a technical test.
Countries like Indonesia and Philippines have UA costs 1/10 as high as nations with higher GDP per head. They make good candidates for a technical test. It also means that you can practice your UA skills using much smaller amounts of money than you can in, say, New Zealand.
A second advantage, particularly for Europeans, is the time zone. Peak playing time on smart devices continues to be prime time: the evening between 7 and 10 pm, after work. That means that peak playing time in Indonesia happens during the working day in, say, France. So when you are trying to test load balancing and server response times, the peak load occurs when you are working, not after hours.
So if you need to run a technical test, do it in a country where you can acquire a critical mass of users cost effectively.
The commercial test
The commercial test exists to answer the question: Is the lifetime value of my customers good enough to justify spending my scarce marketing resources on this title?
Many developers focus on testing how the FTUE completion rate, retention statistics like D1, D7 and D30 and monetisation metrics like conversion rate and Average Revenue per Paying User (ARPPU).
They also throw in a laundry list of features which have no place in a soft launch.
Sharing to Facebook or posting to Twitter
Dozens of others
There are always exceptions to the rules above, but this is the principle: You want to test the fundamental retention (and, subsequently) monetisation of the game. Features like daily rewards are retention techniques that can work on any game. They are not a big element of risk in your design. You absolutely want them in your game before you spend your marketing resources, but by putting them in your soft launch, you are delaying learning whether the core of the your game has good retention.
Actually, it’s worse than that. By putting in systems like login bonuses or achievements, you can obscure the true retention metrics of your game. A game like Crossy Road or Flappy Bird doesn’t focus on these retention techniques because it is just so fun. But even a game like Simpsons Tapped Out or Fallout Shelter needs to be able to draw users back just because of the intrinsic fun of playing the game, not just because of the extrinsic rewards of getting your login bonus every day.
As you prioritirise your soft launch, this is how to determine what is in or what is out, that should be left out so you get to the commercial test as fast as possible:
Is this retention feature essential to the core loop of the game? If so, it should be IN.
Is this feature new, either to the industry or the team? Are we nervous about it? Is it a risk? If so, it should be IN.
Does the game function perfectly well without this? In which case it should be OUT (a daily login bonus is a great example here)
Can we add this feature to the game at a later stage with no impact on the core experience? OUT (achievement or GameCenter integration often fit this bill)
Do we know how to do it? Then it is a good candidate to be OUT?
Will including it tell us nothing useful to inform our decision to market the game? OUT (this is why Facebook integration is often out at this stage. In a soft launch, you may not want your game to go viral, and with only a small pool of users, it probably won’t go viral anyway. So leave it out.)
Of course, there are exceptions to the rule. If daily quests are at the absolute heart of your game, you need them in. If your game is multiplayer only, then maybe you need Facebook to provide liquidity for your players. Maybe GameCenter leaderboards are the primary motivation for people to play your game, so put them in.
But the basic rule is that if the reason you are putting a feature in is because it’s “best practice”, or because Apple won’t feature you without it, or because everyone else does it, leave it out.
A soft launch is a process, not a moment in time
What happens the day you soft launch? Do you think you’ve gold mastered and can give the team a month’s holiday and a pat on the back for a job well done.
Of course not. A soft launch (whether technical test, commercial test or both) is the first time you get feedback at scale from ordinary users. It’s a time to work really hard to respond to data, to feedback and to tweak the trajectory of your game.
But for the first few weeks, as you wait to get data and then make sense of it, the team can be working on all those features that you are going to add eventually – the daily logins and the achievements and so on. But they are doing it while you are gathering real world data on what your game needs. Some features that seemed like Must Haves move down the priority list because data says they are not needed. Other things suddenly crop up that you hadn’t considered. The schedule gets rearranged, features added and features dropped.
This is the whole point. You shouldn’t get to the soft launch with a game you would be happy to hard launch. You’ve spent too much time, too much money and probably built lots of things that were unnecessary. Early assumptions about what would your game better have now been baked in, and it’s too late to change.
So change your thinking. In a twelve month build, launch after six months. Leave out the F2P bells and whistles that will obscure the data and stop you from knowing if you have a hit on your hands. Add that stuff in later in the process, because it carries low production risk and low design risk. Prioritise the stuff you are unsure of, or are scared of, not the stuff that is easy.
That way you will learn what you need to know faster, you will spend less money and your marketed launch product is likely to be much more successful.
The hard launch
The hard launch is when you use your scarce marketing resources. It’s the moment you open the floodgates and let hundreds of thousands or, hopefully, millions of users into your acquisition funnel.
You might spend money. You might get featured by a platform holder. You might cross-promote your game thoughout your portfolio, or that of your publisher. You might get your YouTuber partners to tweet to 10 million Twitter followers. It’s a big deal.
But if you have spent a long time in soft launch, you have a much better chance of that hard launch being successful. The purpose of this post is not to argue that you won’t need daily login rewards or achievements or social integration in your game. It’s to say that most of these features can easily be added during a six or nine month soft launch process.
So grab a red pen and your feature list, strike out every feature that is not absolutely core to the experience and move your soft launch forward by three months. You will save money and significantly improve your chances of long term success.（source：Gamesbrief ）