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

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

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

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

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

/以下为直播文字实录/

—————————
本次我分享的模块共分为4个:

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

1. 数据采集是什么

许多同学认为数据采集是一件非常困难的事情,埋点的过程不仅需要许多技术知识也需要各类的业务知识。这里我会为大家解析数据采集的本质,告诉大家数据采集其实并没有想象中的那么困难。

2. 数据的来源

这部分会介绍有哪些端口上传的数据,对我们的分析场景有非常大的价值?以及哪些数据可以给我们带来决策上的支持

3. 如何构建相对来说比较完备的数据采集体系

当你知道数据采集的技术内容与业务内容后,就会面临“体系如何搭建”的问题,一个好的体系应当对后续的数据分析工作是高度可用的。

4. 游戏数据采集那些坑

这个部分我会介绍当年做数据采集体系的时候,遇到了那些影响到项目进度、分析工作的分析大坑,为大家梳理常见且容易避免的数据采集误区,以便大家能够不走弯路地搭建出高效可用的数据采集方案。

不过在开始正题前,我们先可以聊一聊:数据分析是什么?

 

数据采集金字塔

我们平时工作会接触许多游戏公司的数据分析师,他们绝大部分的分析工作大致可以分为两步:

1. 向后端同学提数据需求;

2. 等数据到手上后,处理成具有指导意见的报告。

但其实整理下来,我认为数据分析是符合这样的“金字塔”模型:

 

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

 

自用户在游戏中产生行为开始,我们需要对行为数据采集、清洗、存储、计算、可视化、分析,最后数据呈现的形态才能帮助我们完成各类业务层面的指导。

这个过程的本质,是用户行为伴随产生的大量数据我们能够通过“金字塔”模型处理,将用户的行为数据转化为关键维度指标或者用户行为规则,这些数据后续会成为我们项目活动、迭代的客观依据支撑。

但我们会发现,随着“金字塔”模型向上地数据处理,我们的信息量却在逐层向下地不断折损。比如说

        • 数据采集层埋点的不准确,导致用户的许多行为没有捕捉到;

        • 数据计算模型与行为数据的适配不足,导致结果与实际业务产生偏差;

        • 可视化精准度不够,直接影响分析结果的准确性。

每一层的数据遗漏都会导致用户行为数据流在这个“金字塔”模型中不断递减,最终能够为我们提供指导性意见的数据,其实仅占到所有数据中的一小部分。

所以数数科技作为数据服务商,其目标是让客观数据以效率最大化的形式为厂商提供最为准确、客观的指导意见,我们就需要将“金字塔”模型的环节转化率无限逼近100%。这样我们才能指着数据分析结果说:“这是一个非常有科学依据且准确的指导性意见”。

作为“金字塔”模型的最底层,数据采集是数据采集最关键的一步,我们可以先来看看什么是数据采集。


o1数据采集是什么

数据采集的定义

大家对数据采集或多或少都有自己的定义,从我的角度来说,数据采集就是在做一件事情:

 

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

 

  • 触点

触点,是指用户产生各类行为的端口(客户端、服务端、web端等),这是我们做数据分析时最核心的关注点。除客户端、服务端外,触点还包括了第三方平台数据。比如说出海的游戏公司会对接第三方归因平台( AppsFlyer、Adjust等),这些第三方所提供的数据也可以很好地与项目内端口采集到的用户行为数据进行耦合联查。比如说我们希望看某个渠道买来的用户质量,或者分析该批用户更喜欢PVP还是PVE。因此,我们的用户不仅在端口产生数据,在第三方也会产生各种触点。

  • 特定的用户行为

其实我们在数据采集的过程中,并不需要将所有的数据都采集到。比如MOBA游戏项目,如果想要采集鼠标点击次数及角色移动的数据,首先我们需要分析用户这两个行为的数据量。APM(每分钟操作次数)比较高的玩家,可能一秒钟就会产生10次点击。如果我们把这些庞大的移动数据全部记录下来,它们不仅会作为预置存储占用大量磁盘,而且它们为后续分析带来的价值是很小的。所以我们做数据采集的时候需要辨别,到底哪些用户行为是具有采集价值的?其价值起码需要大于我们设计埋点和数据采集存储的成本。

  • 捕捉&发送

当触点和行为都设计好了后,我们就剩两步:捕捉&发送。捕捉就是埋点,我们在接口当中用一段代码,将代码所标注的用户行为数据捕捉下来,并打包向上层传输。

完备的数据采集应具备哪些特性

聊完数据采集的定义后,我们可以来看看完备的数据体系应当具备哪些的特性:

 

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

 

  • 完整性

完整性可以分为两个部分:技术向&业务向。业务向的完整性是指,我们所采集的行为、属性是否足够支撑我们后续的分析场景。技术向的完整性是指,我们通过客户端采集的数据,是否能完整地推送到服务器日志、服务器接收端。如果这个过程当中有10%、15%的数据丢失,会对我们后续的工作产生逐层累加的数据偏差

  • 实时性

实时性是大家最为熟悉的数据分析痛点。我希望能够实时采集到用户的行为数据,并立刻传输到数据服务器上。这些数据就能够直接加入到计算流程当中,让报告建议对业务的指导是足够及时的。上面两个是比较常规的特性,而后面两个是大家常常忽略的部分。

  • 可协同

我们为许多公司指导数据采集方案时,最常遇到问题是一个项目中的所有埋点都是各部门分开处理的。客户端的埋点是客户端负责,服务端管服务端的埋点,如果有web端、小程序、app的话,各个组件的开发人员均独自去做埋点工作,以至于项目中没人能够把所有的埋点融合起来,做整合分析。这时候,即使我们的埋点方案非常完备,但数据的不可协同性也会让数据分析缺乏产品的整体视角。

  • 可实施

因为数据分析的优先级是低于业务的,这个时候我们就有一个让步原则:当某个数据采集埋点会有实施难度,我们需要慎重考虑埋点的可行性。

过去经常有客户向我们提出需求:能否展现用户生命周期的指标。即用户在做这个行为的时候,是用户注册进入产品后的第几天?

这个需求的逻辑结构很简单,比如说我1月1日注册,1月2日登录,那登录行为就是我整个用户生命周期的第二天。但是这个需求很难在数据采集层面实现,如果说我们通过客户端去采集这个数据,客户端就需要时刻维护住这个用户的注册时间及该用户的新增行为时间,并实时发送到服务端。这个需求对系统层面来说就是“设计成本>分析价值”的案例。

我们大部分情况下都会让用户放弃这个埋点需求,并将这个需求转嫁到后续的数据处理、ETL、数据分析的过程当中。


o2数据的来源


数据类型

当我们了解完“数据采集”是什么后,就需要开始梳理我们所需要采集的“数据”从何而来。这里主要可以主要分为四部分:

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

 

  • 客户端&服务端

客户端和服务端数据一样,两者都是通过各类组件完成采集、上传。客户端数据会更偏向用户视角,而服务端是业务分析中常用指标的数据来源。

  • 业务数据

游戏用户的各类行为不仅仅会从游戏游玩中产生,客服回访、官网浏览、游戏预约,这些行为所产生的数据均不是来源于APP主体。我们只有将业务数据与产品内部数据去结合分析,才能产生尽量全面的分析结果。

  • 第三方数据

第三方数据包括刚才提到过AppsFlyer、Adjust等归因数据,以及我们第三方爬虫以获取的数据。理论上我们可以将这些数据导入分析系统当中,去做一个更深层次的分析。

客户端采集与服务端采集

这里我们先聊一下客户端&服务端的采集,这也是我们大部分客户会纠结的点:我的这个数据需求到底该从客户端完成采集,还是服务端完成采集?

我这里首先强调一点:这两个端口的采集其实并不矛盾,在同一个项目当中我们可以使用客户端、服务端进行同时采集。两者都有其优劣势,只有两者的相互配合才能将采集效率提升至最大化。

 

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

 

  • 客户端

首先客户端采集的最大优势,就是我们可以获取用户设备相关的信息,例如用户iOS IDFV、android ID、网络状态、设备型号、屏幕大小等数据。这些数据都会通过用户客户端去完成采集,以完整地捕捉用户在客户端的行为及属性。这些是服务端完全接收不到的。

举个简单的例子,我上了一个新活动,用户点开了活动页面,但没有参与这个活动,他仅完成了浏览行为。服务器不会知晓交互界面打开的这个行为事件,它不需要服务器对其支撑,否则记录用户频繁打开活动页面只会徒增服务器性能压力。

因此理论上,客户端才能完成采集UI交互等零碎的操作行为。

基于此,客户端的采集劣势也是非常凸显的:数据完整性无法完全保障。

虽然现在大家有各种技术手段去保证客户端的采集准确率,甚至有公司保证数据丢失率仅千分之一。但目前没有任何一家公司能够保证,客户端数据能够100%没有问题。

举个例子,用户激活并打开了我的游戏,但打开过程中他是处于断网的状态,也就是他产生的各种行为是没办法发送到服务端进行上报的。如果因为设备性能问题卡顿太久,用户直接后台划掉并且再也不打开这个App,这个用户的整个生命周期是不存在任何触点可以将采集到的数据发送出来的。

所以理论上来说,客户端的采集是没有办法去保证数据完整性,或者完全100%保证数据的准确性的。

除了刚才提到的痛点外,客户端第二个难点在于,它非常容易受到客户端本地异常状态的影响。

我们处理客户的反馈时常常遇到一个问题,即某个用户把他的客户端本地时间调整了。比如说现在是6月18日,用户为了快速刷新关卡、礼包的计时,就会把本地时间自定义调整。强联网的游戏会有服务端的时间做强校验,但单机游戏就会经常发生这类事情,并且如果客户端没有一个服务端、NTP服务器帮去校准时间,客户端理论上是没有办法确定自己的时间是否是准确时间。

除此之外,还有用户会基于破解客户端给服务端发送一些异常充值的数据包,这个过程当中客户端就会出现非常奇怪的数据:明明这个客户端说自己充了一笔钱,但是服务端一笔钱都没有收到,那么有可能就是客户端已经被用户破解

  • 服务端

再来说到服务端,服务端和客户端的优劣其实是刚好互补的。

服务端最大的优势之一,就是能够保证数据100%的准确度业务数据库中的数据和日志数据,理论上两者是绝对对应的。

第二个优势,是服务端能够捕捉到更加全面的业务数据。

举个例子,某个活动到某一天的24:00会做一个数值结算,第一名获得1万金币,第二名5千金币,第三名1千金币。结算行为只能通过服务端去完成,如果通过客户端结算,只要用户一天不打开App,这个数据就一天无法上报。我们可以认为服务端是一个上帝视角,将业务数据捕捉得更为全面,并且更具深度。

当然服务端也有缺点,最大的问题就是无法以用户为单位的行为流。

比如说某活动页面的入口有三个,我作为用户从第三个入口进入的活动页面。“我从入口三进入活动”就属于单个用户的行为流,我根据单个用户行为的上下门,完成行为属性、用户行为流的判断

服务端就很难实现这一系列的操作,因为服务端同时承载上十万个用户,没有办法微观地处理单个用户行为流,从而寻找用户行为上下门的关联。

这是服务端很大的一个问题。服务端的第二个劣势,是技术部门比较关心的问题,即过于零碎的数据采集任务会带来过大的性能压力。通过服务端完成大量的数据采集,不管是成本还是压力,都会转嫁到逻辑服务器、日志服务器上,所以需要成百上千万的客户端来分担采集压力。

 

多段数据采集场景

我刚才提到过,服务端采集和客户端采集是能够两者互相兼容的,这里我给大家举了两个案例:

  • 场景一

第一个是参与活动到完成充值的场景:当用户打开商城时会看到5块钱的超值礼包,用户点击参与这个活动并完成了这个充值行为。

 

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

 

在这个过程当中,用户打开页面的行为是一个单纯的页面加载行为,我们服务端在这个过程中是没有感知的,于是我们需要客户端的数据采集去捕捉这个行为动作。

用户打开页面后点击参与活动,服务端可以通过弹出付费界面或者结算处理,以知到参与活动的行为。但是“点击参与活动”在我们的日常分析过程中并非一个关键事件,关键事件包括新增、活跃、充值等宏观指标,因此点击事件大部分会选择客户端采集。

参与活动后,部分用户会点击充值。“完成充值”这个关键事件必须保证数据的正确性,它会直接影响到我们的收入评估、渠道评估、第三方数据对账等内容,所以这个数据我们最好通过服务端完成采集。

  • 场景二

第二个案例与前一个相似,我们会有进入竞技场、开启战斗的流程,每到24:00结束的时候系统会启动周期性自动结算服务,我们会按照排名给玩家发放相应的道具与奖励。

 

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

 

这个过程当中,我们就无法通过客户端去采集每日竞技场结算的事件,因为这是服务端定时批量生成的事件,我们也只能通过服务端采集。

 

多段采集的注意点

我们采集游戏数据时,有很多的场景需要客户端与服务端进行配合,才能保证整个用户行为路径得到完全捕捉的,与此同时我们会在流程中遇到非常多的注意点。

 

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

 

  • 用户体系的打通

一般客户端的分析很多是基于android ID、iOS IDFA。而服务器的分析会更多聚焦于业务ID,例如账号ID、角色ID等数据。

我们经常会发现某个用户同时接入了服务端与客户端数据,测试就会问设备A和用户A明明是同一个用户,为什么还是两条数据?

我们站在测试角度来看的的确匪夷所思,但如果站着数据分析系统角度来说,设备A和用户A的确是两条独立的数据。所以我们就需要关注多端的用户体系是否打通,以规整我们的数据分析。

我会建议有一个自己维护的业务ID标准,以打通各个数据端的用户体系。这里的各个端也包括了web端、小程序端、APP端。

  • 时间连续性

时间连续性是多端接入时,很容易发生的问题。

我们经常会被客户问到:我发现有一个用户在创造角色之前,就已经产生战斗了。我们从业务逻辑上分析,当然觉得这根本不可能发生。在RPG游戏中,玩家应该是先创建角色,然后才能进行其他的玩法行为。

但是这个过程当中我们忽略了一个问题,那就是客户端的时间轴和服务端的时间轴可能不在统一的时间轴上面,他们之间存在时间差,有时候甚至多个登录网关、逻辑服务器、支付网关三者之间也有时间差。

所以为了避免这样的情况,我们就需要服务器或者NTP服务器的时间完成对齐的动作。这样的话才能保证用户的整个行为流是正确的。

  • 避免多端数据冗余

举个例子,我们在数据采集的时候会使用客户端与服务端,同时捕捉用户开始战斗的动作。数据分析师就需要去辨别到底哪个端的数据是准确的,比如说充值的数据采用服务端采集就行,客户端就不要介入,同理客户端的场景就不需要服务端来参与。

 

其他业务数据

刚刚我提到除两端的数据,我们还可以接入其他的各类数据。首先我们游戏的官网预约数据,或者不通过入口进入官网的用户数据,这些信息都会直接影响到后续用户付费潜力、活跃度的表现。

 

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

 

其次是客服回访的数据。客服经常会关怀游戏的大R,大R的充值数据是否在回访后就上去了,这是对客服工作质量评估的思考方向。

 

第三方数据

此外,我们客户还会加入一些第三方数据来验证内部数据。

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

首先就是之前提到过的广告归因数据。产品只要出海,基本都会使用AppsFlyer或者Adjust的数据,我们也可以将海外归因数据和我们自己的数据做一个打通,可以更加翔实地了解不同广告位带来的用户质量,而不仅仅是局限于这些用户的留存、活跃、新增比较浅层、宏观的数据维度。

爬虫数据可能在游戏行业用的不是太多,但是换到外卖、电商行业,我们可能说某团外卖或者某度外卖会去互相爬取对方的业务数据,来完成自己的竞品分析。

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

热门文章