游戏数据埋点

记录一下在游戏行业关于游戏数据埋点和采集的一些东西。

主要讨论点，游戏埋点数据用来干什么，分为哪些埋点数据，数据流程是怎么样的，和游戏比较相关的客户端和服务器埋点数据应该怎么定义，要关注哪些点，埋点存储在哪里。

1、什么是数据埋点

主要是说说游戏行业的数据埋点，主要是采集玩家在游戏内主动触发的一些行为动作或者游戏客户端打开是一些启动流程。一般是开发在代码中注入。

2、理解游戏业务数据和埋点数据

在游戏行业，一般业务数据和埋点数据是分开存储的。如下一般比较常见的架构：

2.1 业务数据

游戏内的玩家表，物品表等，一般只能反映当前玩家的属性，当前玩家身上拥有的物品，这种表一般数据量较小，修改频率高。

一般存储在 mysql/mongo/redis 里面。

2.2 埋点数据

玩家行为操作操作，比如玩家等级变化记录，游戏内资源变化记录，这种数据一般量比较大，特性是只写入，业务不会查询（量太大）和修改。

一般存在 mysql/或者按照一定格式存储在本地文件中，或者对接 sdk 和 api 之类，把数据直接通过接口上报上去。

2.3 思考一个问题（MySQL/Binlog）

如果业务数据是存在 mysql 里面。我们可以不用埋点日志吗？比如直接解析 binlog，得到数据的操作记录，生成埋点日志。

比如玩家游戏币发生变动，玩家表里面的游戏币字段，会增或减，我们解析 binlog，就能知道玩家的资源发生变动，能解析和记录下来，得出玩家的行为日志；有 binlog，还需要让开发单独再埋点吗？

答案是需要的。主要考虑两点：

1、binlog 没法记录一些变动的原因，binlog 只能解析出发生过变动，但是不知道是因为什么原因变动的；

2、游戏程序一般会实现一个缓存，用于数据合并写入，减小业务数据库压力，比如缓存 5 分钟，5 分钟之类玩家游戏币获得过 10 次，消耗过 5 次，再缓存里面会先经过计算，然后得出一个 15 次变动后的值，直接修改业务库（只是举个例子，一般游戏里面核心资源是不缓存的，是直接刷库的，但是比如升级这种 5 分钟升级 5 次，最终业务库是直接把等级改到最新的等级，不是每次升级都会修改业务库），这种情况如果直接捕获 binlog 去建设埋点日志，是会有玩家行为缺失的；

3、为什么要数据埋点

游戏行业的数据埋点，一般不需要服务在线业务（比如通过分析用户行为做一些实时推荐，但是目前趋势也有一些游戏，往这一块走了，玩家可以快速的查询一些之前自己的操作历史记录），相对来说对时效性要求不会那么高。一般是服务运营、市场、策划、客户部门。

埋点主要功能

1、运营、市场的运营分析系统（玩家的初始化、注册、创角、留存、LTV 之类的）；

2、客服系统，GM 系统（精确查找某一些玩家的用户行为，用于客诉）；

3、策划需求（策划分析某一个功能模块玩家的参与度、某一个新版本上线玩家的活跃度之类的）；

4、数据审计（支撑内部审计）；

5、支撑一些特殊运营活动（比如支撑满足一定条件的老玩家回流活动，这种活动业务库没法支撑，因为需要查询大量的历史数据和关联一些玩家行为，一般只能通过埋点日志分析），一般这种对实时性要求不是那么高；

6、支撑一些需要查询历史数据的游戏功能（比如玩家查看自己的历史订单，同步聊天记录）-- 目前该类功能较少；

7、游戏数据异常修复（有一些 bug 需要玩家行为日志去修复），技术问题排查支撑（比如玩家网络、app 异常）;

8、数据风控（物品产出、消耗、购买的监控，玩家在线、注册的监控）；

4、第三方埋点还是自己埋点

第三方埋点一般需要接入第三方的追踪工具，根据他们定义的格式和规范上报数据，然后他们提供可视化平台。方便运营、市场、策划相关人员查看。

4.1 广告投放埋点

一般都会对接第三方 sdk,比如 Talkingdata，appsflyer，adjust。这一块比较复杂。主要是涉及

1、和广告商核对数据，一般会选一个大家比较认可的第三方平台，担心刷量之类的；

2、有较高的技术门槛，涉及到广告追踪，核心是一个玩家通过一个落地广告跳转到官方下载，一般这个追踪有难度；且现在比如苹果对隐私的保护，设备唯一性定义也比较复杂；

4.2 游戏内玩家行为埋点

我们讲的主要是这类埋点。

一般自己埋点的多，也有一些接第三方，比如数数、神策。目前游戏行业，做的比较好的是数数。

用第三方平台，一般是对接第三方 sdk，开发根据第三方的格式上报，能快速做一些数据产出，通用性指标比较多，如果要灵活提取一些数据，会比较难。一般这类平台，成本会高一些，但是比较省心。

自己搭建数据中心，这个比较难评估，想做好，成本也不低，灵活度高，后面的扩展性会强。我们主要说一下自己搭建的一些思路。

5、数据流程

不管用第三方平台还是自己搭建数据中心，都需要走下面的流程。用第三方的，就数据采集到可视化，第三方帮你做了。

5.1 定义埋点规范

定义埋点规范谁来定义？

前面的埋点主要功能能看出，这里涉及到 运营 、 数据分析 、 投放 、 策划 、 客服 、 技术，大家都会用到这份埋点日志，一般建议由数据部门的产品经理，去收集每个部门的需求，给出定义规范，大家评估。

5.2 技术埋点

开发根据定义的埋点规范开始埋点。

埋点数据的存储方式决定了采集方式。核心的存储方式有下面几种：

1、本地文件

最高效、靠谱的方式，对业务基本没有侵入性，唯一担心的就是服务器坏掉，数据还没采集完这种情况。但是存储本地文件，如果没有完备的采集和存储机制，是比较难分析的。

2、MySQL

比较主流的方式，数据量小的时候，也比较方便分析，注意如果是写 mysql 的话，所有表都需要加一个自增主键，后面做数据集成的时候，方便根据自增主键增量去抽取数据。存储在 mysql 也要担心一个问题，如果数据库挂了，日志怎么处理，直接丢掉不影响业务/阻塞业务等待/先缓存到本地等数据库恢复再写入到数据库，这是一个需要考虑的问题。就是丢数据和服务可用性的问题。一般我们建议开发实现第三个方案。

3、SDK/API

接入 sdk/api 要注意以下问题

（1）侵入性

这个只要根据第三方的规范埋点就好了，需要开发对接 SDK 或者 API，对业务具有侵入性。

（2）高并发

这个对 API 后面的接收服务，在高可用和高并发方面，都有比较高的要求，假设 100 个游戏区，10W 活跃，平均每个玩家每秒产生一条日志，并发就 10 几万了，如果多接几个游戏，并发是非常高的。

（3）高可用

游戏服务一般也是要求 7*24 小时提供服务的，如果上线的地区比较多，很难有全部业务停机维护窗口，对服务的高可用也有比较高的要求。

（4）数据缓存

缓存主要是解决数据丢失和上报性能问题，比如 app 崩溃，数据还没上报完怎么办；来一条数据上报一条吗，对性能和网络开销影响又比较大，数据需要合并吗；上报量大的时候数据堆积怎么办。

这一块设计起来也是比较复杂。一般对接 sdk 的话，是 sdk 那边需要解决的，即游戏开发只管往 sdk 抛数据，数据上报是 sdk 去做的事。但是如果是对接 http api 的话，这个一般是游戏开发需要去考虑和实现的问题。

5.3 数据采集

数据采集根据埋点数据存储方式不同，采集方式也不同。

比如存储在数据中，我们可以通过 binlog/kettle 之类的去抽取；

存储在文件里面可以通过 filebeat/flume 之类的去抽取；

对接 sdk/api,就不用关心采集了；

数据采集是一个比较复杂的事件，涉及到作业调度，可配置，重复抽取，数据清洗，采集质量 相关知识，这个可以单独讲。

5.4 数据存储

数据存储数据存储选择比较丰富，主要是现在云厂商的解决方案太多了。

主流的还是把数据集成到 hadoop 体系/云厂商的对象存储上（OSS/COS）/一些云厂商的原生 BI 数据库（ADB/GP）之类的。

主要看公司的技术选型和人员储备了。后面也会讨论一下这个。

5.5 数据建模

数据存储好之后，可以基于这些数据去建模，建设 BI 体系，数据分层。

这个也比较复杂，主要就是 ODS -> DW ->DM 的建设。

5.6 可视化

数据可视化。小团队可以选择一些开源的工具，比如 superset/metabase 之类的，大一点的团队，都是产品经理直接规划好。

比如这个是基于 superset 做的一些可视化。

6、客户端数据埋点

主要是针对手游。主要是一些定义规范的讨论。

6.1 需要关注哪些数据

先想一想，打开一个 app，登入一个 app，我们会关注哪些点。

有多少人安装了？

有多少人打开了？

有多少人流失了？

为什么这些人流失？

这些人在哪个点流失的？

app 打开运行过程有没有一些报错？

客户端到服务器网络如何？

这里面有一些运营关注的点，有一些技术关注的点。关注的点，就是要埋的点。

6.2 游戏的启动流程

一个游戏 app 首次启动过程（启动新手引导应该是游戏特有的）：

通过上图，我们知道一个游戏 app 启动分为打开 app、启动过程、引导过程、游戏过程，理解这几个过程，比较关键。下面详细说一下：

（1）打开 app

这个就是简单打开 app，触发 app 启动。

（2）启动过程

启动过程，玩家是无感知的。但是这里需要做很多事情，程序会自动触发很多操作，比如从网络上请求一些版本文件，下载一些资源，解压资源。

这些操作有些是要和网络交互的（比如下载资源），有些是在本地操作的（必须解压资源）。和网络交互的，我们需要知道网络情况，本地操作的，我们也需要知道结果。在埋点的时候，这些都需要考虑进去。

这部分的埋点数据，一般是客户端技术比较关注的。用来排查问题居多。

（3）引导过程

引导过程，游戏一般有一个引导设计，主要是用于玩家对游戏核心玩法的一些操作引导，和用于评判玩家对该类型游戏的一个接受度。简单来说就是告诉玩家怎么玩这个游戏，看看玩家对这个游戏类型感不感兴趣。

引导过程一般是客户端实现的，不用和服务端交互（服务端不用校验任何数据），所以一般在客户端进行埋点。

这部分埋点，主要是提供给策划做分析的，还有客户端技术用来排查一些问题。

（4）游戏过程

玩家通过新手引导过程，一般就是创角进入游戏过程。玩家参与游戏的功能，会对自身属性发生一些变更（等级、经验之类的），比如获得一些游戏物品，参与一些游戏任务，体验游戏的核心玩法，这部分数据，都是需要和服务端交互的，服务端也需要对这些数据做校验和存储。所以一般游戏过程的埋点，都是服务端这边来做。但是也有少部分不需要服务器校验存储的操作，客户端可以埋点做更细力度的分析。

这部分埋点，是后面的核心埋点，上面的数据核心支撑，也是通过这部分埋点来支撑的。

6.3 埋点定义

知道我们需要关注哪些数据，了解游戏 app 的大致启动流程，我们能大概知道需要定义哪些埋点。

一般我们会定义一些通用字段，比如设备 id、设备型号、设备语言、设备时间、设备版本、app 版本、设备网络、触发动作；有些特定动作可能会有一些特定属性，比如请求资源，成功还是失败，请求资源的地址，花费的时间,这些字段是这个动作特有的属性；

客户端埋点，我们可以形成一个这样的数据，每一个动作有开始有结束，然后还有异常捕获，有网络连接的时候，最好上报一个 ping 的时延，方便检测客户端到服务端的网络质量。

举例：

网络情况（一般在需要和服务端网络交互的时候 ping 几次上报一个均值）异常捕获（一般在触发异常的时候捕获上报）

7、服务端数据埋点

服务器埋点，这个比较好理解，主要是玩家在游戏内的一些行为的埋点。就是上面的提到的游戏过程埋点。

比如 创角、登入、登出、物品变动记录、属性变动记录、资源变动记录、任务变动记录、核心功能模块的一些详细记录，这个尽可能的详细一些。

有几个需要注意，一般服务器埋点，相对来说更不关注设备信息，比较关注游戏内的一些玩法、留存之类的信息。但是我们一般建议，在涉及注册、登入、登出、重置的几个埋点里面，需要让客户端把设备详情（客户端埋点通用字段）上报过来，记录一下。对分析很有帮助。

在项目前期，不管客户端还是服务端，我们尽可能埋点力度细一些，对于我们前期分析会有很大帮助。

8、下一步做什么

数据埋点定义好了，下一步数据集成（采集和存储）。