第一章手游运营VS端游运营同不同？

为何手游的运营要有动态运营的概念，这里就先抛出一个问题，到底手游运营和端游运营的区别在哪里？

第一点，载体不同。

端游的载体就是电脑，而电脑的形态通常是台式机与笔记本，并且操作系统是以Windows为主，很少有网游会针对Mac去做版本的打造；看电脑的决定性因素就是看配置、CPU、内存以及显卡。如果去推一款产品，要看最主流的机型配置是什么，做好相关调试，确保它能够在最主流人群的机器上顺利跑动。

手游的载体就是手机。首先，各款手机的操作系统是完全不同的，IOS和安卓完全是不同的系统；其次，市面上有大量的不同品牌的手机，因为机型、性能、尺寸等个体差异的不同，需要做各种适配。所以这个过程中，所要面对的挑战和应对的困难相比之前更多了。

第二点，操作不同。

端游操作上，键鼠结合，可以打出很多高难度的复杂操作。不同于端游的按键操作响应时间短，手机上操作就很难“秀起来”。因为手机基本上是触屏操作，这就决定了很难做复杂的操作组合，一是手机的功能不允许，另外屏幕的响应速度也跟不上，所以手游需要设计更多策略要素设计在玩法中。

第三，使用场景及时间投入不同。

端游时代，玩家一般都是在家、网吧之类的场所。但是用手机打游戏，就可以在各种场景下实现。从长度上来说，端游的游戏时间是相对固定的而手游却是不受限制的，时长也相对短。跨度上来说端游和手游在一年周期的游戏时间分布也是完全不同的，端游时间消耗是连续的、集中的，手游则是碎片化的，可长可短。

第四，社交目的不同。

那么除了时间，这两种游戏产品所处的时代背景是不同的，所以用户最终获取的社交目的也是不相同的。端游的风靡是从2000年开始的，因为那时没有太多的娱乐方式可以选择并且网络刚刚开始普及，所以那个年代用户的社交行为所追求的是过程而并非结果。而现今，微信、QQ等社交软件普及度高，用户并不缺少社交平台，所以对手游的社交需求较低，而选择与熟人进行互动；同时用户玩游戏时的目的性更加明确，反而不那么在乎过程。

第五，社交形式的不同。

基于时代背景的不同也演变出了社交形式的差异。以往的社交，更多是基于发帖子、秀文采的文字形式。而手游由于是触屏操作，屏幕较小，打字不方便，所以用户会倾向于用语音甚至开视频。手游社交中很多人是通过录视频、直播、语聊、视频聊等方式以及在社交平台上记录生活的点点滴滴，这都是大家热衷或者喜欢的社交形式。

总结一下，从形态、年代、时间，包括用户需求，在端游和手游的运营上都发生了明显的改变。如果我们还是按照之前传统的逻辑、理念和设计原则去做产品和运营，显然是不能够与用户需求相匹配的。当然，既然它是一个需要改变和挑战的东西，也就为手游的动态运营创造了新机会。

第二章手游动态运营的新机会

动态运营是根据以往端游、页游包括手游运营的一些经验，整理出的运营方法论。它的定义是我们对运营指标采取即时反应，通过不同运营手段，基于数据不断优化产品的一种运营方法。这里有三个关键点：

第一，即时反应。不能像以往的运营方法一样，而是以版本来进行运营行为的发起；

第二，不再是以月、季度、半年这样的时间来看结果，而是要以小时；

第三，要准备更多的备案。在游戏本身要增加更多的机制，方便运营针对用户的需求做快速的应对和改变。

当然，核心目标在于能够通过观测到的数据和人为的干预，快速及时的反应，最终能够改变数据，达成运营的目标。

让我们来举个例子，将开一家糖炒栗子实体店与游戏上线运营进行对标，出现的问题如何能够用动态运营的定义来做一些响应和应对。首先在开店之前，肯定要解决两方面的问题：

第一，可以理解为上线前的问题。比如，需要准备什么内容，在什么地方开，卖哪里的栗子会比较好，用手工去炒还是买机器来炒，自己是单干还是去加盟一个品牌。这就直接映射到游戏本身的业务，在产品上线之前所做的各种准备，包括签什么样的产品、为什么这个产品能爆、用户群体大概有多大，它可能是一个什么品类的产品，包括它的本地化、商业化到底怎么做。

第二，上线之后的挑战。这就是真正的运营需要面临的挑战，栗子店诞生之后没有人气怎么办？不好吃怎么办？淡季怎么办？如何增加收入？回到游戏，也是面临一样的问题，游戏上线新进不够怎么办？用户流失怎么办？活跃指数下滑，在线时长缩短怎么办？

动态运营相比之前的传统运营，最大不同就是必须快速响应。如果不能够快速做应对，可能整个数据目标就无法达成。当然，在目前的场景里面，也许我们还不需要在所有的场景下都要快速响应。但是在特定场景下，比如生死攸关的重要公测阶段，或者新开服的场景下，大家都会快速响应。第二点则是口碑。口碑不好就会带来很大的负面效应，这种效应如果没有快速地加以控制，首先增加大家的压力，二则负面效应持续扩散，引发大量的用户开始流失。

这里举一个例子，日本手游与中国手游在实际产品的操作运营层面，是有很大的不同。日本的手游产品不是像现今腾讯或者国内其他产商的普遍做法，把一个产品拿到之后，不断地去调优、打磨、测试。完善到一定的程度之后，再去做正式的上线，他们往往在一个产品原型被开发出来之后，就会正式上线。这个过程中给它做一些小规模的引流，把一些用户导入，并且开始进行商业化了。

日本手游上线后的运营模式有两个特点：首先是高效的更新频率，以周为单位来迭代内容。再者就是有效的运营活动，基于这一步，有比较实际的两个手段：第一，实时积分的一个排行。第二，通过活动来推动整个游戏内容的迭代和用户对于游戏的付费。

例如全服积分的排行。比如这个游戏在周一的时候推出一个活动，玩家只要顺利击杀BOSS就会获得积分，排行榜会有一个总的激励池，它可能会把整个服务器80%以上的用户全包含在里面。前期可能是一个无意识的击杀行为，玩家就很容易地参与到这个活动里面来了。在门槛极低的参与条件下，玩家一旦看到自己的排名在往上走，就有动力让自己的排名更高，这时候就会开始自主地参与到这个活动。当到了一些周期性的关键点，比如到了周三的时候，就会出现一些超级的BOSS，击杀能拿到更多的分。在这个过程中，会推出一个更强的道具，可以给你更高的效率，在这个过程中还有一些小的有趣设计。其中一个设计就是社交机制，抱大腿社交。在这个活动中，玩家去组队的过程中，可以分享队友的分数。所以高玩也会成为玩家更有动力的因素。到了周末就会出现超级的终极BOSS，在这个时候，全程参与的玩家，以及处于中游的玩家基本上都会争夺这个超级BOSS的积分奖励。

所以，看似是一个比较简单的活动，但它可以帮助运营团队去评估通过这样的一个活动机制是否可以刺激带动玩家在游戏里面的活跃度。所以日本的整个游戏是以“周”为单位，一旦第一周能够顺利达成活跃目标，那对应下来，第二周的活动力度就不用那么强，相对于第二周就是一个福利周，帮助更多玩家在这个过程中去推动游戏进程。

日本在游戏的运营过程中与我们最大的不同是一旦步入正轨之后，会同时有两个研发的团队在做版本。首先是有一个计划，去制定一个版本，另外把版本投放到游戏里去执行。执行之后，迅速去查看单周的目标达成，并基于此在接下来的周期进行快速地修正。通过这样的玩法迭代，帮助更多的用户在这个游戏里面存活下去。总结一下，他们整个运营逻辑就不再是以“版本”，而是以“周”为单位去做切割，再通过每一周的活动去快速验证目标的一个达成性。

相应的我们来通过几个案例，来看下国内一些游戏上线后会遇到的一些情况：第一，发现问题不够及时。碰到运营事故时，如果不能即时地调整和响应，就有可能导致负面的舆论口碑了。第二，版本的更新时间太窄所导致的潜在问题。这两种情况都体现了持续进行版本更新的挑战性，主要有两个风险，一是研发时间成本与内容和用户需求之间的偏差，二是版本迭代周期短导致的产品质量缺陷，例如玩家发现漏洞到运营响应，研发整改之间的时间差。到这个时候，我们如果还寄希望于版本，就会很被动。基于这两个问题，相应的动态运营策略便是解决之道。

而要做好动态运营，以下便是我所总结出来的经验：

第一，重新定义运营人员的职责；

第二，做好游戏内机动内容的准备；

第三，做更多数据的记录；

第四，做好相关工具的准备；

第五，拆解KPI，把KPI拆解得更细；

第六，需要建立一种新的激励机制，做一些快速的动态运营之后，团队和人员在过程中也能有一些成就感和收获。

第三章手游动态运营实战分享

1 机动内容规划

首先，机动内容，如果要进行快速的响应，最好是能够把版本50%的内容做预留，也就是在开发的过程中，要有意识地去预留一部分的内容在运营的手上。其次是在游戏本身的部分去提供对应的工具和机制，允许运营的人员和团队能够快速地去开启这些内容。最后还要有对应的目标，目标必须拆解得很细致，这样才能基于需求做快速的应对。

为了便于理解，这里举了一些案例。比如在游戏中放置隐藏的NPC。其实NPC在正常版本里处于隐藏状态，但在版本研发的空隙期，可以开启NPC来承接对应的一些新副本和新活动的内容，并通过这样的方式让玩家在游戏里有更多活跃度的提升。

2 运营数据模型假设

对于数据模型的假设，我们对游戏行业的KPI拆分为两个板块：一是在产品未上线前的收入预测。二是在上线后的商业化测试中去修订之前预测的数值。即便在上线首月，KPI的数据也都是“天”为单位的，这种数据模型在我看来是粗糙的。至少，上线首月必须以“小时”来切割目标。当然，万事开头难，你需要建立模型的过程。一开始可能只是一个预判值，但是基于这个预判的数字，运营在实际上线看到用户的反馈和验证之后，以小时为单位去实时观测并修正这个数字。这种行为可以在商业化测试阶段的P2阶段就开始执行，只有把颗粒度切得足够细，才能迅速警醒，从而做出反应。另外，建议以服务器为单位，每一个服务器作为单独的一个单位来计量，每个服务器的生态不同，因此统合来看便不能及时发现问题。服务器有生命周期，玩家也有生命周期。当有的玩家并没有走完生命周期就卸载了游戏，这个时候就有可能是服务器或是游戏机制等方面的问题。这时细分后台数据便可以得到很多更用户对游戏的反馈和生态的表现，带来一些不一样的启发和警示。

3 关键运营指标实时记录

那么上述的数据要如何去统计？统一的记录下后台许多细部数据较难反馈出来，因此需要将游戏的指标细化出来。

第一，记录用户每天的活跃情况，比如玩家喜欢对游戏的各项玩法的喜爱度，便于快速地发现很多的问题点以及进行后续的产品优化。第二，游戏本身的监测也非常重要。关注于具象的数据：例如登陆频率、登陆时间、在线时间，来判断线上是否有BUG或者异常，及时地优化用户的游戏体验。以下是一些具体的做法，例如用户在游戏内活动的参与率不够也会有相关预警。如果要做到动态运营，机制的建立和后台数据的完善是非常关键的一点。

4 运营工具

运营也需要工具，如果要把很多的机动内容做投放，最后比较良好的投放模式是让玩家通过任务的形式激活新内容。这样的机制需要在上线之前考虑清楚机制并且准备好活动的工具和后台，第一种是定向活动，第二种是自由活动的配置。

5 动态运营岗位职责

这是做动态运营比较难的一点，也是国内许多运营团队都无法落实这个策略的原因。它相比我们目前运营岗位的职责定义会有很大的不同。现在更多的岗位分工都是根据模块，做本地化、商业化、白板管理来做切割，但是，回到动态运营指标的拆解，如果要达成目标，需要把大家的工作更加具像化到所服务的一些玩家身上。因为切得足够细，一些在细部单独服务器上的问题才能够被发现。第二点，很多从大数据上看，发现不了的问题或者关注不到的玩家，才能被关注。由于每一个服务器的生态不同，区服与系统的不同，玩家的活跃程度和停留周期都有不同，所以就需要做定制化的问题解决，不能一刀切。

设定好一个目标之后，也要有相关的更具像的职责划分，部分的职责也要切得更加明细，有人专门负责活动部分的，有人负责其他的一些社区推送的。同时，有一个关键点在于赋予一线运营更大的权利。因为很多的行为，如果都要通过逐级请示批准得有一个周期，可能在长时间的等待中，部分用户就会流失。所以，动态运营就是要改变一种思维模式，把服务器的目标设定好之后，通过给予运营人员相关的权利，鼓励他们在一线运营操作过程中做很多灵活应变的处理。

6 周边辅助系统准备

周边的辅助系统也很重要，如果要做一些动态运营，除了自己能够做一些内容部分的响应，其实也需要把一些东西告知于玩家，所以这也需要准备相关的工具。

7 核心原则和指标

回顾手游动态运营的核心原则：准备阶段要让研发团队提供运营操控的产品植入机制，同时作为运营要有很清晰的资源投放目标，以及自己的预判。实战阶段就需要以“小时”为单位去切割KPI，以服务器为单位来设定一些具像的目标，同时建立生命周期的产品模型。要特别关注点击转化率，包括角色创建流失率、用戶的流失率、持续登陆这样一些关键的数值。通过这样的方式和关注点，可以帮助我们更加有针对性地去发现用户的一些潜在需求，快速排除游戏里面的问题。

结语

最后的总结，从2016年-2018年，游戏市场发生了新的变化。时代发展决定了用户的游戏经验增多，从而对游戏品质有了更高的要求。而当这些需求不能够纯粹靠研发版本来满足，靠开发商的产品开发来满足，作为运营就需要主动出击，针对用户的需求变化，配合相应的投放机制，做出快速的应对和调整，应用动态运营的策略来优化用戶的游戏体验。