多杰游戏学

活动系统开发与验收

该标准工作流分为活动上线前的开发设计和活动上线后的验收，是游戏活动开发与验收的标准工作流程。（但其中包含的需求模板库是活动与系统通用的）

这个知识体为什么存在？

游戏上线后需要不断推出新的活动，创造新鲜感，定期为玩家提供F+，刺激付费，提升留存。但如果活动设计出现失误，会引起玩家的负性情绪，出现F-。所以我们始终需要一个参照标尺来设计和验收活动设计成果，避免活动上线后产生不可挽回的损失。 每次由我们自己思考活动设计思路，或者听取CP方提供的活动方案后，需要标准化工作流程模型作为理论指导，提升工作效率。每次活动结束后，都需总结当次活动相关数据与经验对该理论模型进行验证或更新。

这个知识体的时空坐标

这个知识体在我们的知识体系中，属于哪个时期的问题。
在实践中，应该在什么时期范围内使用这个知识体。
什么样的时期不适合用这个知识体。

1. 在每一次活动方案设计伊始至活动实装之前，需要这个知识体进行理论指导与成果验收。
2. 在活动运行期，根据知识体指导进行数据收集与埋点分析，反馈实践结果，验证或更新理论模型。

属于产品类系统层中的活动系统模块。

这个知识体适用什么人群？
请描述他们的属性。

• 策划（设计活动）
• 运营（验收成果，调整指标）
• 数据（数据埋点与分析）

结论的模型是怎样的？
{较复杂的知识体建议有以数据层面出发的结构图}

从数据方面，考虑活动的目的是为了赚钱，活跃，还是品牌，或者是三者之间的组合，明确通过哪些指标在多次活动间做出对比，验收合格程度。一般来说，商业目的都是一些相对目标，如“本次付费额目标比上次多8%”或“游戏付费额要与竞品一致”等。商业目的指导设计目的的挑选逻辑。

明确商业目的后，对玩家群体进行用户分群，分析并挑选最大化商业目的的用户需求，并产生对应的n个设计目的，设计一个完整的活动系统框架并用OPF表证明体验的完整性。设计层的目的主要是统筹全局，思考框定需求的上下限，避免犯错。

体验层负责往设计层的框架中填入具体的内容，进行体验验收，检查是否有设计层缺乏考虑导致的错误，对照需求验收表进行活动验收并产出数据埋点方案。

即活动的盈利需求。

• 付费率：每日付费用户占活跃用户的比例。付费率=付费人数/活跃人数
• ARPPU：每付费用户收入，反映每个付费用户的平均付费额度。ARPPU=付费金额/付费人数
• ARPU：每用户平均收入，注重一个时间段内运营商从每个用户处所得到的收入。ARPU= 付费金额/活跃人数

活动需要有一定的活跃需求，不能片面追求盈利而导致大量用户流失，影响以后的收入。简单地说就是“把韭菜留住下次割”。

• 活动流失率：检查活动造成了多少用户流失。活动流失率=（活动上线前一天的在线人数-活动结束后的第一天在线人数)/活动上线前一天的在线人数
• 活动唤醒率：检查活动吸引了多少潜水老玩家上线。活动唤醒率=（活动第一天相比前一天新增在线人数-活动前一天相比活动前两天新增在线人数）/活动上线前一天的在线人数
• 活动留存率：检查活动期间深度参与了活动的玩家占比。活动留存率=（活动上线第二天肝满当日积分限额的用户占比-活动上线第一天肝满当日积分限额的用户占比）/活动上线第一天肝满当日积分限额的用户占比
• 收益流失比：检查新增收入产生的代价是否巨大。流失收益比=活动期间付费总额/（活动结束后的第一天在线人数-活动上线前一天的在线人数)

有些公司并不靠游戏营收生存，而是靠口碑积攒拉投资等，这时候活跃和收入就不是最重要的因素了。各大平台的好评占比与评分、玩家社区的口碑才是最应关注的维度。

我们需要定义玩家群体，进行用户分群以分析不同的群体需求。为了避免遗漏某些用户群体，我们通过三个用户属性参数排列组合进行分群：肝度、氪度、练度

• 肝度：肝度属于用户个人属性，分为两种参数：愿意肝（1）和不愿意肝（0）
• 氪度：氪度即区分大中小R的参数，故在此分三档：大R（2）、中R（1）、小R（0）
• 练度：练度带有时间因素，属于客观事实属性，这里分为三个参数（可对应活动难度设计的难度梯度）：大佬（2），普通（1），萌新（0）

用户分群表

常见的需求数据库，通常来源于当次活动商业需求推导出的群体需求、基于知识推导的需求（例如其他游戏的经验）和基于自身运营经验的安全需求，在需求模板数据库中基于最大化商业目的的逻辑挑选出设计层所需要的设计目的。

需求模板库（需长期维护）

对系统框架结构进行验收，检查设计目的有没有得到实现。注意，这时活动还未上线实装，验收标准不涉及具体指标，只验收维度。活动验收表是从需求模板库中抽取挑选出来的。

对详细设计进行验收，用OPF表检查系统是否有完整的体验。

体验层设计完成后，要明确本次活动需要得到哪些数据，然后对一些活动环节进行数据埋点，在活动运行期收集相关的微观数据进行体验分析，在活动结束后收集相关的宏观数据进行商业验收与总结。

与玩家体验有关，一般精确每天每个关卡，例如关卡留存漏斗、活跃玩家平均游戏时长等。

与商业目的有关，只关心活动期间的总体宏观数据。

如何基于需求一步一步分析出结论的。

模型总体分为三个大块：商业层、设计层和体验层。

首先，一个活动的出发点应是商业层面的需求，要明确这次活动到底是为了赚钱，还是活跃，还是口碑，亦或是其他。不管是什么需求，都有个确切的目标，然后分析这个目标有多少维度可分析，方便数据进行埋点。

明确了这一需求后，我们需要对我们的活动参与者（即玩家）进行分析。玩家群体非常庞大，哪种人都有，主观划分很可能遗漏一部分玩家群体。所以我们对玩家群体进行参数化划分，设置三个参数：肝度、氪度、练度。这样就能清晰地划分玩家群体，精准分析群体需求，然后根据最大化商业目的的逻辑挑选出此次需要实现的需求列表。

为了提高以后的产出效率，我们需要设置需求模型库，方便日后反复更新和使用。需求模型库的来源除了当次需求分析推导，还来源于外部知识的输入，例如基于其他游戏的现成知识进行推导产生的需求，和基于运营经验（成就或事故）产生的安全需求。然后在需求模板库内，挑选出最大化商业目的的需求产生设计目的。

然后，基于多条设计目的设计出一个活动系统框架雏形，进入体验层，首先用opf表验证这个框架可以给玩家提供完整的体验，这时就需要有一个标准判断这个体验是否达到设计目的，那就需要有活动验收表。然后在这个系统框架内填入具体内容，产出数据埋点方案以便验收分析。

验收无误后，活动上线期间就需要根据埋点方案监测数据进行玩家的体验分析，积累经验教训。

活动结束，也需要进行数据总结，评估是否达到商业目的，活动验收是否合格，整个模型就形成了一个有生命力的闭环。

通过建立这个模型，我们以后推新活动的时候能迅速找到思路，通过标准化模块化流程进行活动设计和验收，提高工作效率。

• 需要设计活动的产品。
• 需要验收活动的运营。
• 需要分析活动数据的运营。

“0”学习成本任务，可直接执行。
“1”学习成本任务，需要进行一次示范即可独立执行。
“C”学习成本任务，需要进行培训，考试合格后方可执行任务。

本任务属于 “C”学习成本任务

这样设计工作流的思路。
原理中的逻辑是事务本身的规律，这里的方法论考虑到使用者的现实情况，面向执行者。

模型链接

流程编号解释：

这个事情如何做。

设计的工作流

分为活动系统设计工作流和活动验收工作流。

活动系统设计工作流

• 流程图：第①、②、③步。

• 产出

OPF表通过对一个最终目标进行下属子闭环的拆分细化，最终得出每一个闭环的循环模式。

【腾讯文档】混沌之域 OPF表 https://docs.qq.com/sheet/DSFJkS0JuQUJZenlz

上图只是整个OPF表中的一个闭环，目的在于展示OPF表的结构。组成该闭环的子闭环仍可根据需要，依照该结构进行拆分，直到拆解到最底层的闭环。 在闭环的拆封中，我们一般只考虑拆分此次活动中新设计的系统闭环，而不考虑那些已经存在的系统中的闭环。

验收表的验收条目出资需求模板库，这些验收条目绝大部分都是经过探索型任务的知识体、也就是以往的活动系统开发中得到的；如果有需要补充的条目，则是通过本次活动系统开发的活动目的、面向的用户群体、需求列表来决定。

【腾讯文档】设计目的验收表 https://docs.qq.com/sheet/DZUdmR2lNTUhQaVhO

该文档是整个活动系统开发与验收的总结文档，记录了包括产出OPF表和验收表，活动中各个系统的具体设计，以及后期验收与体验分析的全部内容。 但是在活动系统设计阶段阶段，该验收模板主要用于记录活动中各个系统的具体设计模式。

【腾讯文档】验收模板 https://docs.qq.com/doc/DZVhkcWVCelhMWGpz

活动验收工作流

• 流程图：第④、⑤步

• 产出

• 在这一步的验收过程中，主要参考的是之前产出的OPF表，这个时候的验收角度是从系统设计角度出发考虑，即活动的各个系统设计是否达到了我们对于它的期望与要求，能否提供和产出我们希望它所提供的目标、产出的反馈，让整个系统有一个完整的体验闭环。

通过对照OPF表进行验收能够帮我们迅速发现那些能够通过文字直接表述出的系统设计上的缺陷与不足。

• 在这一步的验收过程中，主要参考的是之前产出的验收表。验收表的验收条目都是通过需求模板库所提取出的，这些验收条目已经在以往的活动系统开发流程中被验证过，证明了其必要性。此时的验收角度是从用户体验角度出发考虑，即活动中的每一个系统设计是否有满足每一条验收条目，以及是如何满足的；那些未满足的部分是否是需要更改修正的。

通过对照验收表，能够帮助我们从维度上分析系统设计的框架结构是否能够满足需求。

• 这一步在活动结束后才进行实施。通过系统设计中进行数据埋点所得到的微观数据与活动整体统计的宏观数据对本次活动设计进行全面分析。微观数据用于分析用户体验，宏观数据则用于考量本次活动系统设计是否有重大缺陷导致出现运营问题。在体验分析完毕后，将验收模板进行补全，产出一个完整的活动设计模板。

1. 某活动系统模板

知识体的执行产出了什么结果？

通过设计目的得出的系统设计OPF分析表

【腾讯文档】混沌之域 OPF表 https://docs.qq.com/sheet/DSFJkS0JuQUJZenlz

最终的系统设计是否满足OPF表的需求

对通过活动目的与需求模板库提炼出的设计目的进行验收的表格

【腾讯文档】设计目的验收表 https://docs.qq.com/sheet/DZUdmR2lNTUhQaVhO

设计目的是否有被满足，以及是被系统中的哪部分设计所满足的。

SOP2.0_015_灵魂宝戒活动设计模板

基于这个知识体的产出内容清单，通常在工作流的结尾有归档阶段，
会要求执行者将结果归档到这份清单当中。

SOP2.0_015_灵魂宝戒活动设计模板