第7期(下):游戏行业数据采集体系&避坑指南

数数课堂 | 第14期:《游戏活动运营体系&付费提升点》

6月18日,数数科技联合创始人陈琦开启了数数课堂第七期的知识分享。

在为众多游戏公司服务的过程当中,陈琦及其团队积攒了许多游戏行业的数据采集方案,并在摸石头过河的过程中积攒了不少避坑经验。此次课程他将与大家分享:

《游戏行业数据采集体系&避坑指南》(下)

/以下为直播文字实录/

 

—————————

 

上半部分课程我简单介绍了数据“金字塔”模型、数据采集的定义,并给大家分析了各个端SDK数据来源的特点优劣。为大家对数据采集建立了一个初步的认识:数据的集方法&采集数据的价值。

此次下半部分课程便集中讲解:当你有了这些基本知识后,应当如何构建出一套相对完备的数据采集系统,从而为后续的数据分析工作做一个很好的支撑。

 

数数课堂 | 第7期(下):《游戏行业数据采集体系&避坑指南》

o3如何构建完备的数据采集体系

 

用户行为分析要采集什么——4W1H

 

我们可能听过很多数据分析方法论,比如著名的5W2H。其实在这里我也可以介绍一个属于数据分析的4W1H,分别是:

数数课堂 | 第7期(下):《游戏行业数据采集体系&避坑指南》

 

  • WHO-谁

代表某个角色、账号。这里还包括了用户的社会属性,例如性别、身份证、年龄、地域、籍贯等一切可采集到的属性。

 

  • WHEN-什么时候

这里的时间有两层含义:第一个指用户做该行为的物理时间,第二个指用户触发埋点的时机,例如战斗触发的时机就是用户点击开始战斗的时候。

 

  • WHERE-在哪里

用户的地域位置、设备、网络,用过什么样的屏幕对产品进行了游玩行为。

 

  • WHAT-做了什么事情

这里是大家最容易理解的,比如用户充值、开始战斗、登录等行为。

 

  • HOW-怎么做的

这里HOW的层级位于上述4W的向下细分领域,是描述事件属性的部分。比如说用户产生充值事件后,该事件下的充值金额、订单号、充值渠道等信息。

 

数据采集三要素

其实我们可以去繁从简地,从4W1H框架中提取出数据采集的3个核心,即:

 

数数课堂 | 第7期(下):《游戏行业数据采集体系&避坑指南》

 

  • 事件与属性

数数课堂 | 第7期(下):《游戏行业数据采集体系&避坑指南》

 

很多项目组在埋点的时候,最常出现的设计思路如图左边案例所示。

这个案例的错误之处,在于将事件和属性杂糅成了一条。这样的埋点也并非不可行,因为当下的游戏内容可能就是这么多。但是这样只聚焦于当下功能的埋点思路,缺乏面向未来的拓展性,假如未来充值金额增加12元、24元、128元时我们就这么挨个往上增加吗?过去端游的充值模式,是用户可以自定义充值金额的形式,这种又该如何设计埋点呢?

在后续的数据分析时,这样“事件+属性”的捆绑行为会让工作变得越来越繁杂,而且做数据对比或者累加参活用户时,数据分析工作会变得异常困难。

基于刚才的错误案例,我们做一个清晰区分事件和属性的处理示范:

      • 用户事件是充值,充值描述符“充值金额”,充值金额=6。
      • 用户事件是浏览网页,而网页描述符”页面名“,页面名=首页。

同理,下方两条信息也是做这样的拆分处理,这样我们的事件和属性就变得非常清晰了。

我们可以看到用户在本次活动完成了充值、浏览页面、参与活动、完成成就等行为,下次活动或版本中,业务人员只需要改变属性的value,描述符基于该层事件就能够完成整个埋点的横向扩展,而不影响到事件本身的结构。

 

属性是数据采集的关键

 

从刚才的过程中我们会发现,属性才是我们重点采集的对象。

行为事件其实是不怎么会被遗漏的部分,我们可以直接向策划、产品要一份功能清单,这些清单就是数据采集埋点时所有需要关注的事件。我们也可以找技术询问,这个产品有什么技术接口、逻辑接口,这些接口也是通过功能所展开的。

 

数数课堂 | 第7期(下):《游戏行业数据采集体系&避坑指南》

 

如图所示,左边是大家最常见的指标和事件,而右边的属性采集是最为容易被忽略的。举个最简单的例子,当我需要知道各个关卡的通关时间的中位数,我做了个关卡胜利的事件后,我该在这个事件下补充什么相关属性。

这个过程当中,我们不需要过分关注事件如何采集,而是需要关注事件的下一层级的相关属性应该如何做的更加完备,从而为后续的数据分析做一个更好的支撑。

 

触发时机

触发时机是大家最容易被忽略的埋点要素。

大家对触发时机的理解大多是这样的:开始战斗就是开始战斗的时候触发,结束战斗就是战斗结算的时候触发,其实这个概念会非常深度地影响到我们后续的数据分析逻辑。

 

数数课堂 | 第7期(下):《游戏行业数据采集体系&避坑指南》

 

  • 统计口径

首先触发时机会影响到统计口径。比如说,当我们判断参与活动的用户人数时,我们应当从用户浏览这个页面的时候去触发,还是活动达成的时候触发

当用户浏览这个页面,说明用户知晓了这个活动,他可能会为这个活动的某个目标进行努力,例如截图所示的“参与三局对战”。那么活动参与人数,就是浏览了这个活动页面的人数。

但如果我希望将用户达成了这个目标并领取奖励的时候,才判定为参与了活动,那么它的触发时机口径就与刚才那个思路是完全不一样的。

所以我们在后面做埋点的时候,一定要为后端、技术说明清楚,这个埋点方案的设计到底应该是在一个什么样的时机。

 

  • 数据完整性

几乎所有的游戏都会有PVE关卡的概念,关卡通常会嵌套一些子关卡,例如说关卡A有A-1、A-2,子关卡打完后就会有关卡的胜负属性。

很多用户问我们,能不能做一个总的关卡结果埋点,用户在A-1和A-2的行为包含在整个A关卡的结果中再推送回来。

我们这边非常明确地告知,如果你特别在意数据量和数据存储的话可以这么做,但是这么做有很大的风险。整个关卡的触发时机是在关卡结束的那一刻产生,如果用户进入A-1因为打不过就直接将进程划掉退出了,你这次用户进入关卡的数据就无法从客户端完成采集。

所以我们建议数据采集的时候,在用户产生行为的那一刻落地为对应的埋点。

继续说刚才这个事件,首先用户进入关卡一的时候,有一个关卡ID=A的事件。当玩家进入关卡A-1时,我们有一个开始战斗的事件叫做“用户进入关卡ID=A,ID=A-1”,进入A-2、A-3均同理埋点,而当最后一个子关卡结束时,便判定关卡ID=A对局胜利。

这样的过程中,用户每做一个行为都会触发一个埋点,理论上来说不管用户在A-1划掉还是A-2划掉,我们都可以完成完整的数据捕捉,而不会因为仅存在最后节点的数据捕捉,便影响到整个数据完整性。

刚刚我们提到过数据分析体系的框架与核心,这些只是数据采集体系的“骨”,大家还不知道如何制定事件和属性的结构,以形成一个完备的采集体系。

这里我们可以给大家提供简单的思路,首先第一个就是业务目标角度。

 

业务目标角度

在你规划埋点之前,你先问自己:我要什么。

之前我也提到过了数据埋点考验的不是技术能力,而是业务能力和数据思维。技术在埋点的逻辑框架中占比非常小,技术只是达成埋点框架落实的手段而已。

举个例子,我现在有一个业务目标,我想分析一下用户在新手期的体验,我们会将这个目标分拆为如图所示的业务目标、关键维度、关键事件三个板块:

 

数数课堂 | 第7期(下):《游戏行业数据采集体系&避坑指南》

 

这个分层逻辑就是我先知道我要什么,然后我再对这些事件和属性做下层搭配。具体细分的思路上面内容提过,这里不再赘述。

除了关键属性,我们也需要记录游戏中的通用属性,比如渠道、服务器、职业等属性,这些属性和我们大部分事件都是有关联的,我们可以将这一个部分单独抽取出来,在所有的事件和埋点中添加进去。它们展示了用户在产生这个行为时,所处的关键状态或者字段。

大家可能会说:“我现在不知道我将来的分析工作会需要什么指标,如果按照目前的需求来埋点的话,很可能我埋点的缺失导致我未来想要回过来做历史数据处理的时候,没有对应的埋点”。

那么我们可以从第二个角度完成补充,即从用户角度触发。

 

用户角度——主动事件

我们可以简单地想一下我们的数据分析做了什么事情,其实只有两件。

第一件是用户主动事件。

用户点击竞技场挑战的原因是什么?是因为什么决策环境导致了用户点击竞技场?我们称之为主动事件。用户通过你的UI设计、自己产品使用习惯,他做出了一个决策。

第二件是用户被动事件。

这个用户身上发生了什么?他做了什么?这个行为又给了他什么反馈?

  • 主动事件

面对如图所示的竞技场,我们会这么设计:

 

数数课堂 | 第7期(下):《游戏行业数据采集体系&避坑指南》

 

其中我们需要关注一下显性的玩法相关属性。

显性属性即界面中能够看到的玩法相关的属性,这些属性是他做这些决策之前,系统对用户的输入。用户正式被这些属性输入后,他才会做出“我要挑战这个玩家”的决策。所以我们后续分析用户为什么玩竞技场?为什么喜欢玩竞技场?那当他从竞技场流失的时候,我们就可以将当时让他决定进入这个玩法的现场保留下来。

还有一部分看不见的属性同样可以影响到用户决策,这就是隐性的相关属性。例如例子中就没有展现角色自己的战力值,但是用户大概知道自己战力值是多少,以及参与竞技场的话,自己的英雄出场顺序。

基于以上的逻辑判断,我们统一起来后就可以完整地描述用户点击挑战时的决策因素。

 

  • 被动事件

第二个是被动事件,被动事件就是系统触发,由用户主动行为所触发的反馈。这里简单地可以分为如图三种:

 

数数课堂 | 第7期(下):《游戏行业数据采集体系&避坑指南》

 

基于这一类被动事件,分析人员除图中的通用属性外,最好还要关注一下通信协议属性。

比如某个用户点击了充值,服务端收到了信息。当这个用户充值成功后,服务端就会反馈充值成功信息与服务单号。这些信息都会随着通信协议发送到用户客户端,告诉用户在你身上发生了这些事情,客户端会随着这个协议信息完成相应的匹配,然后在一个页面展示出来。

在一个被动事件当中,我们其实可以关注一下服务器和客户端的通信过程当中,到底传输了什么信息,这些内容就可以作为被动事件内容的关键业务属性。

 

两种方式的对比

因为各个角度有自己的优劣势,我们可以通过取长补短的方式来完善埋点方案,他们各自的优劣势如图所示:

数数课堂 | 第7期(下):《游戏行业数据采集体系&避坑指南》

像业务目标切入的时候,因为其可扩展交叉性,容易出现历史数据属性的缺失,但是我可以保证每一次埋点上传的数据都是高效可用的,而不像用户角度切入的埋点所带来的庞大工作量,且会有许多莫名的资源消耗。

这个时候业务和用户角度就可以进行很好的结合,就是以我的业务目标去确认重点分析的模块。比如说我需要对用户的新手期进行分析,那我就会关注新手指导、关卡、玩法、事件,然后配合用户用户新手期的关卡关键字段等用户角度信息,来构建成双维度的分析体系。

同时我们可以关注用户做这个关卡行为的时候,到底是什么导致了他的这个行为决策,这一点可以与刚才主动事件所说的分析方法一样,我们可以对显性属性和隐性属性做一个记录,然后和我们刚才提到的关键属性做一个合并,形成一个相对较为完备的埋点方案。

这样可以很好地补充业务&用户角度切入埋点彼此的劣势,埋点不仅立刻可用,也避免了因为没有预测后面的埋点需求,导致埋点不够充足的情况。

 

o4数据游戏采集那些坑

 

对数据分析的认知偏差

我们对接处理众多企业时,不少数数课堂 | 第7期(下):《游戏行业数据采集体系&避坑指南》项目组让我们头疼的第一个问题,就是许多业务人员对数据分析的认知很差。

 

 

 

 

我们平时做服务时最怕听到这个问题:我需要一个这样的指标,这个指标可以告诉我当前的服务器的环境怎么样?当前用户喜不喜欢我这个版本?流失用户的流失原因是什么?

其实现在的各种指标已经被提炼到非常成熟的状态,就比如LTV、ROI、ARPU、二阶登陆比、次日留存等指标,他们都已经从方方面面将游戏的新增、留存、活跃、付费诠释清楚了。

但是很多公司仅停留在“重视这些指标”,而没有完成数据分析基础建设的工作。

指标是用来表征你的游戏是否好,而你的功能好不好?玩法好不好?用户是否足够喜欢你的某一个特定功能?你的玩法改进点在哪里?其实这些都是由玩法埋点,或者基于玩法、特性的指标去搭建而成的所以我们如果只关注宏观运营指标,你只能得出这个游戏好不好的结论,你永远无法知道你的游戏为什么好。

 

没有整体规划

第二个是没有整体的规划,我们之前做数据采集的时候,可能今天想做这个分析就埋一个点,明天想分析那个就再埋一个。针对这种没有长期规划思路的埋点,我这里给大家三个建议:

数数课堂 | 第7期(下):《游戏行业数据采集体系&避坑指南》

 

  • 自上而下的数据思维

这里的自上而下不是领导、分析师、实习生的公司层级,而是指从研发到业务,从开发到使用人员,大家都需要对数据有一个统一的认识,这样才能在后续做一个很好的协作,形成一个很好的规划。

  • 明确的数据采集负责人

我们经常会遇到项目组将所有数据采集的工作,都直接扔给了技术人员。

刚才我也提到过了,数据采集其实是一个高业务向的问题,真正数据采集的负责人应当是一个业务人员,他们才知道我游戏当中有哪些需要关注的点,将来产品需要产生哪些指标去指导运营工作或者产品迭代。

所以我们经常强调的就是,一定是要一个运营人员作为数据采集、数据分析的领头人,这样的效果才是最好的。

  • 可继承的、完备的数据采集文档

完备性可以看上图右侧的表格,这是我们提供给客户的埋点文档案例,里面有事件、属性、触发时机等内容。这样的设计首先是让大家从一个完全对等平面上交流,我们会有对应的文档告诉开发,在这样的触发时机应该采集什么事件,这个事件下方会有什么样的具体属性。

可继承性对整个项目组更多提供了良性发展的基础,我们过去经常遇到项目负责人一走,新来的负责人拿到之前的埋点文档满头包。所以我们会提供可继承且非常完备的埋点文档,其中包含了我们数据采集会遇到的各种各样的要素。即使负责人更换,项目也不会因此断档。

 

埋点主次

常有客户会问,能不能一下子把系统中的所有数据全部采集过来,我们的回答是没有必要。

其实数据采集的过程可以是一个不断迭代、完善的过程,我们需要把用户在游戏当中的所有行为分成三六九等,我们可以在不同的阶段去做不同的埋点。

如图所示,我们就做了三种部分:

 

数数课堂 | 第7期(下):《游戏行业数据采集体系&避坑指南》

 

  • 一级埋点

一级埋点就是不管你的需求是什么,我们第一批埋点计划是必须要完成的内容。图中的注册、登录、充值所对应的就是新增、活跃、付费三个大指标。

  • 二级埋点

二级埋点就是生态行为,包含了用户参与活动、核心玩法、资源变动等数据变化。新增、活跃、付费都是一个结果数值,这些结果是因为用户在你的核心玩法、活动中产生一系列生态行为后,才导致的一个关键结果。所以我希望大家能够建立起对生态行为的关注。

  • 三级埋点

三级埋点即边缘行为,比如刚才我们提到Adjust之类第三方平台接入的数据。三级埋点是作为补充信息,对一二级埋点完成更完整的内容解释。

 

 

业务层面的坑

因为今天时间有限,今天给大家总结几个最严重的业务层面的坑:

 

数数课堂 | 第7期(下):《游戏行业数据采集体系&避坑指南》

 

  • 开始时间与结束事件的计时匹配

我举例一个简单场景,比如说我们希望去统计用户的在线时长。我们会上传登陆事件和登出事件,两个事件的记录时间相减获取在线时长,然后我们将所有用户的在线时长做一个均值、中位数的统计,从而得到我游戏用户对我的游戏产品的黏性如何?

虽然从逻辑上来看是一个很简单的事情,但是在实际处理过程当中,我们会强烈建议在结束事件的时候,采集端就完成开始时间和结束时间的采集,而不是最后在计算层面进行统计。

计算层面的统计不仅会给性能带来过大的压力,而且还有开始事件没有捕捉到,单个结束事件因为匹配失败,而产生一些脏数据的情况。

但是如果在结束事件就完成了计时匹配,就不存在以上问题。我打开APP的时候开一个时钟,结束APP的时候关闭这个时钟,然后我们将时钟记录的时间作为用户登录时长,同理可以应用到玩法、活动的计时。

  • 合理评估数据价值

我在上半部分提到过的MOBA游戏用户点击次数的统计,他们如果真的要记录也是可行的,用特定格式不用一行行的数据去编辑存储,可以避免这一批数据对存储器的过量存储。但是这个记录其实更多是面向用户的操作回放,而不是面向分析师的。所以我们会建议,这一批数据不作为常规的数据采集去记录。

  • 抓住项目内的通用属性

通用属性是第一批埋点的时候就会设计的部分,它是游戏当中反映玩家产生某事件行为时的状态,以及产生该行为的决定性字段。比如玩家的等级,等级决定了玩法的投放,它反映用户是处在新手期、活跃期,还是衰弱期。放在SLG中就是大本营的等级,SLG的玩法随着大本营的等级而不断增加。

所以包括等级、渠道、服务器、角色名等通用属性,我们可以做统一的采集,避免我们在后续的分析数据时有这样的遗失。

 

o5结语

 

以上为本次的课程内容,最后一些话:

如果你在数据采集的时候只能做到80%,那你的最后数据决策也会因为你第一步的遗漏,而存在20%缺失。所以我们希望在第一步数据采集就搭建得足够完备,从而让你后续的工作可以完成更深层次数据分析。

数数课堂 | 第7期(上):《游戏行业数据采集体系&避坑指南》

「数数课堂 」是数数科技2020年推出的知识服务子品牌,围绕“数据分析”提供知识共享。我们推出的第一个项目为100堂游戏数据分析课,学习是一个漫长的过程,用100堂课的时间,我们希望让更多人掌握游戏数据分析技能,让数据价值触手可及。

热门文章