多杰游戏学

本页面只读。您可以查看源文件，但不能更改它。如果您觉得这是系统错误，请联系管理员。
===== 基本信息 =====

==== 名称 ====

  活动系统开发与验收

==== 简介 ====

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

=====原理=====

====目的(What For)====

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

  这个知识体的时空坐标

===时间(When)===

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

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

===空间(Where)===

  属于产品类系统层中的活动系统模块。
  
===人群(Who_To)===

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

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

====自身结构(What)====

===结论模型===

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

{{:知识库:发行:上线后:课题:pasted:20230817-220201.png}}

===名词解释===

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

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

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

==收入需求==
即活动的盈利需求。

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

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

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

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

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

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

[[https://docs.qq.com/sheet/DZmRGdFpBaEpDRGpt|用户分群表]]

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

[[https://docs.qq.com/sheet/DZld5QnZXSG5uRU5J|需求模板库（需长期维护）]]

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

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

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

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

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

===推导逻辑===

  如何基于需求一步一步分析出结论的。
  
模型总体分为三个大块：商业层、设计层和体验层。

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

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

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

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

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

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

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

=====方法与工具=====

====执行者(Who_From)====

===什么人适合执行这项任务===

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

===执行这项任务的学习等级===

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

本任务属于 “C”学习成本任务
====方法====

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

{{:知识库:发行:上线后:课题:pasted:20230817-220246.png}}

[[https://www.processon.com/view/link/60d08e5b6376892d4912cc8d|模型链接]]

  流程编号解释：

|编号|目标|方法|备注|
|1|得出商业目的及验收指标|数据分析、开会讨论|本次活动付费额较上次提升10%|
|2|用户分群，分析需求|对照用户分群表进行主观分析|又肝又氪的大佬需要有养成反馈和氪金的优越感，偶尔也会需要氪金护肝|
|3|挑选出本次需要实现的需求列表|以最大化商业目的逻辑挑选需求清单|例如本次活动商业目的为提升付费同时控制收益流失比，那么我们的主要考虑人群就是氪度高的人群，同时也要兼顾肝度高的人群，然后挑选这些人群的群体需求进行实现。|
|4|更新需求模板库|若发现需求模板库中存在没考虑到的点，及时反馈更新| |
|5|在需求模板库中挑选设计目的|在库中查阅是否有自己没考虑到的用户需求，结合本次需要实现的需求产生设计目的|有不少基于运营经验的安全需求是很难通过用户需求分析得出的，通过查阅获取这些经验才能在设计活动框架时避免犯错|
|6|生成一个活动系统框架雏形|产出一个有完整体验的活动系统OPF表| |
|7|明确活动验收表|整理清单后在需求模板库中复制粘贴过来| |
|8|系统的具体设计|在框架下的具体化细节化设计|要实现养成反馈的通常手段是有关卡难度梯度，但是具体梯度怎么定，不同的难度梯度怎么划分用户练度等，都需要具体设计|
|9|对照活动验收表进行验收|检查活动设计成果有没有满足设计目的| |
|10|活动上线| | |
|11|收集微观数据进行体验分析|数数上按数据埋点方案拉数据| |
|12|运营事故经验总结|处理运营事故，开会总结，更新需求模板库| |
|13|宏观数据商业验收|参照商业验收维度在游戏后台或数数上拉数据| |
|14|修正下次的商业目的|开会总结分析|1 |


====工作流(How)====

  这个事情如何做。

===流程图===

{{:知识库:发行:上线后:课题:pasted:20230817-220314.png}}

===工作流设计===

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

  活动系统设计工作流

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

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

{{:知识库:发行:上线后:课题:pasted:20230817-220327.png}}

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

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

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


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

==产出验收模板==

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

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

  活动验收工作流

  * 流程图：第④、⑤步

  * 产出
==对照OPF表进行验收==
  * 在这一步的验收过程中，主要参考的是之前产出的OPF表，这个时候的验收角度是从系统设计角度出发考虑，即活动的各个系统设计是否达到了我们对于它的期望与要求，能否提供和产出我们希望它所提供的目标、产出的反馈，让整个系统有一个完整的体验闭环。
    通过对照OPF表进行验收能够帮我们迅速发现那些能够通过文字直接表述出的系统设计上的缺陷与不足。

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

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

====产出====

===产出模板===

  - [[~:某活动系统模板]]

===产出内容清单===

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

===产出A：OPF分析表===

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

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

==验收标准==
最终的系统设计是否满足OPF表的需求

===产出B：设计目的验收表===

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

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

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

===产出C：活动设计模板===
[[SOP2.0_015_灵魂宝戒活动设计模板]]
=====案例库=====

  基于这个知识体的产出内容清单，通常在工作流的结尾有归档阶段，
  会要求执行者将结果归档到这份清单当中。
  
[[SOP2.0_015_灵魂宝戒活动设计模板]]
多杰游戏学

用户工具

站点工具

页面工具
