在正式开始之前我先提出一个问题：“当你拥有一个强大到足够给你带来工作效率质变的数据中台时，你作为一个游戏运营人，能否在此基础上建立起全新的数据运营方法论？”

这个问题其实拆解开来都是些老生常谈的东西，但当我们迭代升级团队的数据思维时，是必须要面对的难题。我认为可以从 3 个角度来考虑这个问题：

1. 速度价值

大家使用 TA 系统时就能够很直观地感受到，以往需要一周或者更长的时间才能获取的数据，现在只要 5 分钟就能建一个报表、模型就解决了。这是最为常见的价值体现。

TA 系统能够做到的不仅仅是完成一个简单的业务数据需求。那么我们其实可以把这个思路应用到更加广阔的数据工作当中，以优化整个数据获取流程。

2. 深度价值

以往我们工作中主要使用 BI 报表统计或者简单的 SQL，现在我们能够通过 TA 系统的简单操作就完全实现了，根本不需要专门学习 SQL，甚至一些刚毕业的实习生都可以用这一套界面画的操作去解决问题了。

但基于这种数据中台，以前我们默认无法解决数据层面的问题，现在通过这套 TA 系统我们能不能去解决它了？以前我们挖掘的数据深度，可能只到了第 1、2 层，现在通过这一套系统，我们能不能挖掘到第 5、6 层。

3. 监控价值

TA 这套系统是能够监控我们一些日常比较细微的数据，那么我们同样可以扩展这个思路，去考虑产品各个方面的内容，有没有必要把一些比较关键的指标纳入我们的监控范围。这是希望各位在课程结束之后考虑一下这套系统，它是否有可以进一步挖掘的深度。

我之所以能给大家提供接下来案例，前提条件是我们公司的数据工作进行了比较大的更新，更新后我们才能和 TA 系统较为完美的契合，而非单纯接入一个系统就 OK 的。下图是传统的数据分析流程，分析师以前多通过比较固化的 BI 报表、同类型的项目，甚至不同类的项目生成需求，将这些需求写在 excel 里，然后写一个表头就结束。这个表头被交到执行部门，分析师就不再关注过程，只负责第四步的验收。

红色虚线的位置割裂了整个数据实现的过程，我们其实并不了解其实现的方式。如果我们以旧的逻辑使用 TA，也会妨碍 TA 系统的应用。在几年的摸索中，我们公司逐步形成了一套和TA系统较为吻合、整体工作效率较高的流程。

1. 理清需求要做数据对接的产品都有哪些模块？每个模块预计会产生什么样的数据需求？我们想要得到怎样的分析结论？它是怎么进行分析的？
2. 收束思维这些报表是否能满足我们全部的数据需求？这是游戏产品模块向数据模块转化的过程，即数据化。

3. 需求归纳我们给研发、BI技术部门提出的需求是什么样的？它可能只有十到二十个报表，但囊括了我们需要的数百个指标。
4. 需求验证如果我们能掌握所有的过程如何进行、每个指标怎样实现，验收阶段的工作效率也会提高。我们以旧方法对接一个项目可能需要两三个月时间，更新了流程后，我带着一个应届实习生，2 人只用了 20天 的时间就处理完了 3 款产品的数据对接、上报、和研发的配合工作。这在我们公司是一个前所未有的突破。谈完了基本理念，接下来开始给大家分享一些具体的操作方法。

 

01

联合模块精确计算玩法活动参与率

 

联合模块精确计算玩法活动参与率是分析师经常遇到的课题，通常大家做起来较为繁琐。例如卡牌、SLG、MMO等稍微大型点的游戏，玩法活动繁多，若为每个玩法单独建立一套数据模型，将极大占用分析师的工作时间和精力。

我们优化的思路是：

1. 拆解行为流程

 

图中的四个点大家都能理解。

（1）是否开启

无论什么玩法、活动、副本，或其他游戏内容，最开始要判断的数据指标就是玩家是否开启了这项功能。如很多副本都为条件进入型，我们就先要判断有资格参加这个活动、副本的玩家都有哪些，以推进下一次的精确计算。

一般来讲我们会有一种比较粗略的计算方法，即活动参与人数除以当天的DAU。这种方式最简单，也最不准确。

（2）判断活跃人数

开启活动的玩家不一定在当天登陆了游戏或者活动，要同时满足这两点指标，数据才能更加精准。如果将一些具有参与资格但没登录的玩家也算进来，数据依旧会产生很大的偏差。

（3）判断实际参与

即更进一步判断用户是否真的参与了活动，还是说只完成了一些表面的活动。很多时候观察活动数据时，只要玩家完成第三步的实际参与便可，但参与的过程中，完成与没完成也需要单独计算。

 

2. 判断完成参与

完成指标定义的阶段要将前一阶段的问题进一步深入思考，大家也可以用简单的问自己几个问题，什么叫参与？什么叫完成？

完成参与有这么几种模式：

（1）解锁或触达

它取决于推送的目的和机制，比如玩家解锁是最终目的，还是说活动本身就不是一个玩法，而是一个宣传？是否是玩家看到这些页面就OK了？是否活动本身就是一种告知性内容？如果是，有没有强制的跳转内容？

（2）进入活动空间

通常活动玩法都有一个活动空间和入口，玩家到入口就足够，还是说必须要进入其中，这是需要拆分和确认细节。

（3）完成特定行为

很多玩法可能是副本模式，玩家是参与战斗还是具体到需要有一个战斗的结果？是否有对于战斗时长、次数、积分、组队有细致要求？这些内容能否作为判断指标存在，这也是大家需要去考虑的点。

（4）系统反馈

反馈不仅是获得资源、领奖，也不仅是玩家觉得战胜某个BOSS、对手就结束的体验，还有很多有价值的内容，比如玩家拿到奖励后是否感受到从活动中获得了其他东西等。

 

 

3. 计算公式

实际参与人数/当天的可参与人数

我们完成上述步骤后，我们还需要重新定义分子分母，什么是实际参与人数？什么是可参与人数？包括各个报表记录的数据是否就是我们所需要的东西？

4. 建立模型

我们在做玩法参与度分析时，通常会在如何判断玩家获得了参与副本的权限的环节上产生巨大的工作量。判断登陆游戏的玩家中有多少人能参与副本是最难的，每个副本的条件不同，我们不可能用同一个标准去衡量玩家。

那么是否要通过TA给每个条件做一个分群？

我们可以利用标签功能，将把每天触发解锁某个玩法的玩家统计出来，把握每天究竟有多少玩家有权利进入这个副本。

这样做标签的好处是，我们有时候能将同类型的副本都做在一个标签里，并且以条件触发的方式，利用小标签的基本规则来简化工作量。通过标签的特性，我们能够用迂回的方法解决条件变化的问题。

这张图是我们计算玩法参与的实际模型，为了计算更精准，我加入了很多判断条件。

爬塔副本一般会有解锁条件,我将玩家开启爬塔的标签挂在属性筛选上，让初始条件与结束条件都在该限定范围内。

之后我们可以将前面图中每天解锁副本的人数代入进去，并且还能嫁接其他标签，比如四天都活跃的用户等。

而ID排序，意味在类型3的副本中，包括的不仅是爬塔副本，还有其他副本，这里可以通过区间ID把其他副本排排除掉。

最后我们分析的时候，可能选取的是多天时间，我们通过多天的时间来判断，在这个时间段内，有多少玩家开启并参与了这个副本，相对比原来用DAU计算的方式更准确一些。

通过这个模型计算的结果是怎样的呢？我用excel模仿TA系统产出的数据制作了一张表格，其中有几个重要的点需要大家注意。

如表格所示，9月23日，有65个玩家解锁了这个副本，因为这个副本在游戏中是强制引导，开启之后就必须要去打，当天有65个玩家参与了这个副本，参与比例是100%；第四列的“第1日”表头代表的是23号65个参与副本的用户，在24日即副本开启后的第一日的参与的情况，后续同理。

在参与人数一栏可以看到，在第一天可参与人数和参与人数都是65人，第二天为什会变成170人参与和175人可参与呢？是因为第二天有110人解锁副本，但同时第一天解锁的用户中有60人再次参与了副本，后续数据同理。

所以做个总结，我们使用TA系统将模型的建立过程简化，TA运作起来相当于一个自动化的过程，我们不再需要在过程中将数据导出，用excel进行调整和手动计算，相对流程更快，且更准。

 

 

02

玩法、副本周期进度计算模型

 

首先要明确的是，养成进度不等于养成参与。

后者指用户触发养成行为，养成进度则是指玩家某个时间将武器升到多少级、装备升到多少级、升级到什么品质的进度结果。

这里第一步和活动参与逻辑类似：

 

1. 流程拆解

到底什么叫养成？

养成的判断条件打点应该在哪？是有消耗才算养成，还是有属性变动就算是养成？升级或者其他形式的增长，是否才是某个养成线的最终养成结果？

如果有消耗算养成，但是切换天赋一类的行为，消耗了资源是否能判定为养成？有属性变动算养成，那切换职业算不算养成？有升级算养成，那么洗练是随机属性切换，攻击洗练成防御算不算升级增长？这些都需要大家去判断。

 

2. 系统反馈阶段

通过养成，获取游戏的关卡突破，是否可以作为延伸性的判断结果，因为玩家养成一般是有目的的。

 

3. 公式解决

即我们定义一个公式，分子分母如何解释？如何统计数据？数据来源等。

 

4. 建立模型

这个模型和之前的没有变化太多，只是增加了一些判断条件，比如我们要求必须养成等级大于0。因为有些游戏数据中，养成上报的等级包括0级，也就是没养成状态，这些干扰数据需要去除。

大家注意第一行的养成等级最大值，既然我们算的是进度，就一定看的是最新等级的刷新结果，一般游戏中，等级养成是单向向上不可逆的，所以最大值就一定代表最新的进度。

不过这个模型有一个限制，它只适合单向不可逆的养成线。最终这个模型反馈出来的数据结果如下图。需要解释的是，比如其中有一个数字217，对应的是五级的人数，它指的217个人已经完成前几级的养成，但前几级没有包括217，是因为这里采用的是分布算法的基本规则。

 

03

养成进度算法模型活用

 

这里主要需要计算用户推进关卡的最大值，因而可以直接将前面计算养成等级最大值的模型进行套用。不过有一个问题是有时候研发、策划写关卡ID的时候比较混乱，它无法按照大小排列，因而我们单独写了一个排序ID，把它用虚拟属性方法建立了一套可排序的数字。

下图也是模型活用的方式之一，其中只变了一个条件“养成对象名称去重数”，这个指标是为了专门应对一些比较特殊的养成玩法。比如天赋养成，我们只想知道每个玩家到底解锁了多少个天赋，便可通过这个模型来计算，最终得出来的结果就变成了解锁需求数量天赋玩家的分布。这样我们就不需要再用事件工具，制作很多筛选条件来计算玩家解锁天赋的情况。

 

04

漏斗工具统计礼包购买选择

 

主要的原理是用TA漏斗工具筛选玩家是否购买了很多不同的礼包，我们把三个不同的礼包按照一定的顺序挂在漏斗上，能够观测到用户购买礼包到什么阶段。不过这种方式有一定的局限性，即我们需要判断礼包是否按照这个逻辑推进的。此处代表的是玩家购买完礼包1，才能购买礼包2的递进逻辑，而不是多选的并列逻辑。

 

05

玩法失败与留存关系

 

我们通常能看出来玩家在某个活动中因为失败而流失的情况，但是无法确定具体是哪个关卡失败。为了更加明确失败流失关卡，我们同样可以使用标签工具。

如图所示，我们可以在红箭头的位置把关卡ID编辑进去，把有失败记录的玩家作为小标签部署在大标签中，将现在要统计的标签拖至首位。比如要统计10206的关卡，统计结束之后，只需要把后面的关卡标签拖至10206的位置替换，这样回到模型中就可以直接计算，而不用建立很多分群解决问题。

接下来是维度字典、虚拟字段、List字段的功能活用分享。

 

06

用list字段实现十连抽精细化统计

 

此案例中，我们活用了list字段计算十连抽卡。我们想要知道玩家通过了多少次十连抽到SSR之类的数据，可以建立一个新的抽卡报表。抽卡表的特点和消耗表一样，唯一的差别在于我们让研发将一次十连中出现的所有内容都写在同一行的数据里。

如图所示的“卡池产出道具”源字段（文本），我们用它生成一个虚拟字段（列表），相当于把原来的文本拆开变为列表数据，而最后两行是以列表格式呈现的辅助字段。

此外就是我们过去上报的格式一般都是数字或者英文字母，我们想要知道它的中文是什么，只需要添加一个维度字典就可，同时，我们也可以通过维度字典为卡牌备注稀有度。

这样，我们就能统计到每张卡持有量、持有比例，针对玩家抽取到较少的卡牌，可以考虑以活动的方式提高抽取率，或者说是玩家比较希望获得，可以作为付费点等。下图是十连抽卡模型的执行过程，在生成虚拟字段的时候，可以键入转换代码split(“gacha_lists”,’_’) ，这是一个split函数，后面加一个括号引号，写到原始字段的名称，后面我为了好看加了一些符号进行间隔。

 

07

利用虚拟字段实现“缝合怪”

 

我们可以利用虚拟字段解决一些实际操作中麻烦的小问题。我们统计数据的时候，通常很多消耗型数据，其消耗途径、消耗道具ID很多，我们在进行拆分、多列组合的时候容易出现一些问题，如图示黄色的部分，1和3任务类型不同，但他们的任务ID相同，而TA系统默认维度字典的逻辑是，只要ID一样，那么在配置不同报表时，就会把相同的内容默认应用到每一个同样的字段中。

面对这样的问题，可以用缝合怪的方式解决，即将两排数据进行组合，既然1002是重复的，就为他们建立虚拟字段，让1002这组数字和前面的任务类型相加，将其变为11002，而第二个就变成31002，自然就分成了两个ID，此时做维度字典或者判断就不再需要进行具体的筛选了。

而其函数主要运用的是concat函数和里面的cast函数，来将两个虚拟字段进行组合，比如我将mission_type和event_id组合起来，可以得到7412。不过在显示的结果上会变成74.012，这是因为字段在写成数值格式时，会默认加入“.0”，想把这个东西去掉需要再在concat函数中调用一个split_part函数，这样就可以显示出7412了。

这是利用虚拟字段将相同的ID区分开来的方式，反过来我们也能利用它合并一些不同报表中的相同字段。

图中主线任务掉落出现了两次，分别在任务表和消耗表中，但他们的任务ID不同，本来按照TA系统的逻辑，这二者会算作两个不同的解释，但我们可以反向利用虚拟字段，将其合并为一个解释。

因为这个表中出现的核心问题是主线任务掉落和商店购买字段ID相同，因而可以先建立前者的虚拟字段A，而后建立后者的虚拟字段B，为这两个字段建立单独的维度字典，就能解决ID相同，实际定义不同的问题。