菜鸟学分析：如何做好数据埋点

传统的报表：运营提出数据需求，由技术人员进行数据清洗以及整理后，直接以表格或者图标的形式表现出来。

   

其实与之称之为埋点，我认为更加可以称之为简单报表。因为对于很多公司来讲，这个报表有时候做的非常简陋，并且其可变性也比较低。

   

如下图所示，一般后台报表有做的有：访问量，注册量，关卡流失转化，资源消耗，玩家宠物，资源变动等，在此基础上，可以再增加纬度，例如渠道，新鲜度等。

                              

优点：简单，快速，所有的表格都会经过一次处理，在读取的时候不需要经过运算。

缺点：需要需求提出者有比较强的预见性，提出的需求能囊括全部，灵活性较差，假如某些数据在报表中没有体现，那么需要另外再需求。

为何要做更加细致的埋点？

   

埋点是为数据分析而服务，正所谓：巧妇难为无米之炊。而随着时代的进步，导量成本的增加，现在越来越大的错误成本。导致了很多的拍脑袋，更多的像赌博，而我们能够尝试的错误次数也越来越少，在抉择的时候，没有经过详细数据分析而盲目拍脑袋而下决定是非常具有赌博性的一项决定。有时候，我们选择用户调研等方式来决定，但是在很多游戏中沉默的永远是大多数，所以我们需要更加详细的数据来对玩家进行数据分析。

基本表格：

1、用户激活信息表（用户启动客户端时上传用户信息），在热更新、注册/登录前面

2、用户注册信息表：用户完成注册时记录用户注册信息-

3、用户登录信息表：用户完成登录时记录用户信息（登录不包含注册用户数据）

4、用户登出信息表：用户完成登出动作时记录用户信息

5、订单信息表：订单完成时记录订单信息

6、资源变化信息表：产生资源变化时记录

7、重要事件触发监控数据：触发指定事件时（无资源变化时）记录该事件数据

8、个人信息表：用户当天最后状态的个人信息（活跃用户：当天0点在线用户 + 当天0点前离线的用户

可增加表格：

关卡通过失败表；

玩家死亡原因信息表；

玩家各属性战斗力组成表：记录玩家每一次战斗力改变的时候记录，包括每一个玩家战斗力的组成，时间等信息

等等。。。

   

总之，从需求方讲，表格需要覆盖到全部的基本需求，并且能够按照需求方面来进行进一步的扩展，例如：注册人数中某个关卡通过与否与流失的关系，充值2W以上玩家在某个坑的战斗力是不是都填满了等等。

我们的选择是全埋点：即对于玩家的所有操作都做埋点，但是根据个人经验和需求来进行埋点的深度的取舍。

以开始按钮为例，某个点击事件触发的时候：

   

首先客户端开始缓存日志，日志中首先会附上一个通用字段，通用字段包括玩家的UID，渠道，持有金币量，然后后面跟上事件ID与几个我们需要的一些根据业务场景所需要的埋点，例如在充值中继承上一个界面的ID，总之来说，在设计埋点的时候就建立好分析模型，然后视分析需求来做不同埋点深度。

   

这样全埋点的好处是，在转化流程中每一步，并且能够记录，玩家到底在哪一步流失了，玩家出现什么事件不开心了。就不会出现玩家流失在哪一步，需要运营人员靠猜的情况。并且模型以外的数据依然也能把握到，虽然可能不会太深度，但是可以在后续的版本中继续迭代。

   

当然，大家可能会担心这种数据会不会过多，会不会阻碍玩家的正常游戏，这就需要在设计的时候，尽量保证数据的简洁性与上传时机的掌握了。这一点不再阐述，大家可以向开发了解这一点。

   

用户行为数据可以分为服务端和客户端，比较通俗的说：其中客户端记录玩家绝大部分的操作过程，服务端则记录玩家的信息改变过程与结果。

   

一般说，只要有服务端参与的事件，其实都是可以记录的，但是随着前端技术的发展，各种缓存，用户的很多客户端操作并不会跟服务端有通讯，例如：翻页，点击但是未确定进入等。假设我们需要使用这些数据，那么这些玩家的用户行为放到客户端是一个比较好的选择，而服务端数据则作为一个精准的对照组，作为一个标杆来验证。

  

那么问题来了，记录这些用户行为数据有什么用呢？

  

到底怎么用？对产品有什么样的好处呢？

  

下面举几个比较简单的例子来讲一下这个有什么用处：

从客户端用户行为中可以将玩家分为几类，

   

例如某个玩家在购买礼包的时候，点击查看多次，并且后来又看了商城中的物品，最终玩家购买了性价比很高的高额礼包，我们可以将这个玩家分类为购买犹豫者，其行为为精细化购买。

   

而那些被击杀后，立马就买了一个同样的高额礼包，毫无犹豫的，可以称之为愤怒者，其消费行为为突发性，并且是不理智的。

   

这样对于购买同一个礼包的人，其实他们却有截然不同行为。

当然咯，对于这些分类，你也可以使用你的标准，但是从客户端玩家行为来进行深度的用户行为分析，确实是要比服务端数据来的更加细致，并且更加明白玩家的内心在想什么。

而大家也可以根据这些玩家分类完后，再给这些玩家推出不同的活动（例如礼包什么的）。

玩家首先点击了支付按钮，①玩家点击确定支付，然后②客户端准备拉取了渠道支付SDK，②拉取成功后（是的！你不用怀疑，很多渠道的SDK有时候因为需要帐号登录等这一步都会失败，而失败后很多支付SDK也会有返回码，我们可以用来判断玩家是为何失败的！），④弹出支付宝（或者微信）的界面，这里⑤玩家可以选择支付或者取消关闭支付，然后⑥支付SDK会给我们的服务端返回信息，是成功还是失败。

这样我们就可以做一个转化率的流程图如下图所示：

对于渠道的SDK来讲，有多少玩家是因为网络状况等原因而被迫取消了支付，许许多多的大的渠道在这一块确实已经做的相当不错了了，他们的在支付界面点击确定——最终支付成功这一块成功率相差无几，出现错误的几率非常小，但是对于小渠道来讲，他们因为本身技术问题，而导致SDK的效率问题，这一块确实会差一些，这方面渠道方面会对这个数据非常感兴趣。

优化性能：例如开发比较关心的热更成功率，界面打开速度等。

BUG修复：例如出现的报错，记录玩家出现问题的步骤等

例如新功能的转化效率，新注册用户的不同行为转化等