浅谈游戏数据（1）

　　本文主要介绍游戏行业关于数据埋点相关知识和基本方法，以及埋点相关的一些扩展知识。

　　主要讨论点：什么是数据埋点，为什么要数据埋点，分为哪些埋点数据，要怎么埋点，埋点数据操作流程是怎么样的，讨论的过程中，会有一些扩展知识。

1、什么是数据埋点

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

2、为什么要数据埋点

　　游戏行业的数据埋点，核心是服务运营、市场、策划、客户部门。通常不需要服务在线业务，就是说游戏业务，不需要依赖分析结果动态实时调整一些游戏内容（例如通过分析用户行为做一些实时推荐）。不过现在也看到有一些游戏往这一块走了，比如玩家可以快速的查询一些之前自己的操作历史记录；基于分析数据做一些推送。但是对时效性要求普遍不会太高。

　　埋点主要功能：

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

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

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

　　4）、数据审计（支撑内外财务审计、数据合规性审计）；

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

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

　　7）、游戏数据异常修复（部份游戏bug需要根据玩家行为日志去进行修复），技术问题排查支撑（例如玩家网络、APP 异常）;

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

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

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

3.1 业务数据

　　游戏内的玩家信息，例如玩家表、物品表等，一般只能反映当前玩家的属性，当前玩家身上拥有的物品。这种表一般数据量较小，修改频率高。一般存储在 MySQL/SQL Server/MongoDB/Redis等数据库里。

3.2 埋点数据

　　玩家行为操作数据，例如玩家等级变化记录，游戏内资源变化记录等。这种数据一般量比较大，特点是只写入，游戏业务不会查询（量太大）和修改。一般存在 数据库或者按照一定格式存储在本地文件中，或者对接 SDK和 API 之类，把数据直接通过接口上报上去。

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

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

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

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

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

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

4、有哪些数据埋点

　　哪些地方我们需要数据埋点，从一个玩家的生命周期来说。整个过程，玩家看到广告，通过广告点击跳转到我们游戏下载链接，玩家下载游戏，打开游戏，注册游戏，参与游戏。这个过程，我们分为如下埋点。

4.1 广告投放埋点

      这个主要是监测广告投放效果，哪一个素材的广告比较吸量，哪一个渠道的用户质量比较高。都需要在这里去埋点。不过这个，一般都会对接第三方的SDK，例如 Talkingdata，appsflyer，adjust等。这一块比较复杂。主要是涉及：

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

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

　　广告投放埋点，一般我们不需要过多关注，因为基本都是接第三方sdk去做的，我们只是根据第三方sdk去做一些数据上报，第三方有自己一整套采集、分析、可视化体系。这类广告平台，一般会有回调api，他们会把采集的一些数据传回给使用方，一般可以基于他们回传的点击、初始化数据，在关联游戏内数据，做一些深度的渠道分析，比如分析某一个渠道的付费率之类的。

4.2 客户端埋点

　　通过广告下载到我们游戏app后，玩家会打开我们游戏app，这里开始涉及到游戏客户端埋点。从打开app到注册app登入游戏，这里是客户端需要埋的点。

4.2.1 需要关注哪些数据

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

　　有多少人安装了？

　　有多少人打开了？

　　有多少人流失了？

　　为什么这些人流失？

　　这些人在哪个点流失的？

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

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

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

4.2.2 游戏客户端的启动流程

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

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

　　1）、打开 app

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

　　2）、启动过程

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

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

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

　　3）、引导过程

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

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

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

　　4）、游戏过程

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

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

4.3 服务端埋点

　　服务端埋点，这个比较好理解，主要是玩家在游戏内的一些行为的埋点。就是上面的提到的游戏过程埋点。例如 创角、登入、登出、物品变动记录、属性变动记录、资源变动记录、任务变动记录、核心功能模块的一些详细记录，这个尽可能的详细一些。

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

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

5、埋点数据操作流程

　　由于广告埋点数据，我们一般很难很难采集。我们主要关注的是和游戏相关的埋点，客户端埋点和服务端埋点。

　　市场上有一些第三方的关于埋点的解决方案，直接对接第三方SDK，开发根据第三方的格式上报，能快速做一些数据产出，通用性指标比较多，如果要灵活提取一些数据，会比较难。通常这类平台，成本会高一些，但是比较省心。
     目前针对埋点日志的采集和存储，一些云厂商也提供了一些解决方案，也有一些开源的解决方案，或者把开源工具和云厂商的解决方案做一些结合，自己搭建类似的数据中心，灵活度高，后面的扩展性会强。

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

5.1 定义埋点规范

　　埋点规范谁来定义？

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

5.2 客户端数据埋点技术要点

　　如果是做全球游戏的，客户端数据埋点有个很难绕过的问题。用户的网络问题，我们要有一个共识，客户端数据埋点做不到100%不丢失，只能尽量不丢失。例如游戏上架全球，在全球每个洲都有用户，并且游戏有一定的活跃度，我们要怎么去部署这个数据接入点？是全球多地部署，让玩家上报到就近的接入点，还是单点部署，在通过一些网络加速方案优化？试想一下全球10W在线用户数据同时上报，这是一个并发较大且比较复杂的系统。在网络优化和高并发这一块需要考虑很多东西。

　　客户端埋点上报一般建议接第三方，例如阿里云的SLS，支持SDK和Web Tracking的方式，然后结合云厂商的一些全球加速策略，可以比较好的解决这个问题，把数据采集到我们自己可控的数据中心里面。

5.3 服务端数据埋点技术要点

　　服务端技术埋点相对来说就是简单成熟一些，没有客户端的那种网络问题，并发问题也稍微小一些，主要是看使用的存储方案。

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

　　1）、本地文件

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

　　2）、MySQL

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

　　3）、SDK/API

　　接入 SDK/API要注意以下问题

　　a）侵入性

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

　　b）高并发

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

　　c）高可用

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

　　d）数据缓存

　　缓存主要是解决数据丢失和上报性能问题，例如APP崩溃，数据还没上报完怎么办？如果来一条数据上报一条，则对性能和网络开销影响比较大，如果数据需要合并，上报量大的时候数据堆积如何处理？

　　这一块设计起来也是比较复杂。一般对接SDK的话，是由SDK提供商解决，即游戏开发只管往SDK抛数据，数据上报是SDK去做的事。但是如果是对接 HTTP API，则需要游戏开发去考虑和实现。

5.4 数据采集

      客户端的数据一般由客户端直接到数据中心（或者数据接入点）,不存在太大的调度采集问题。这里主要说服务端的数据采集。

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

　　例如存储在数据库中，我们可以通过 Binlog/Kettle 之类的去抽取；存储在文件里面可以通过 filebeat/flume 之类的去抽取；对接 SDK/API,就不用关心采集了。

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

5.5 数据存储

　　数据存储数据存储选择比较丰富，主要是现在云厂商的解决方案太多了。主流的还是把数据集成到 Hadoop 体系、云厂商的对象存储上（OSS/COS）、部份云厂商的原生 BI 数据库（ADB/GP）之类的。这主要看公司的技术选型和人员储备了。后面也会讨论一下这个。

5.6 数据建模

　　数据存储好之后，可以基于这些数据去建模，建设 BI 体系，数据分层。这个也比较复杂，主要就是 ODS -> DW ->DM 的建设。

5.7 可视化

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

　　例如以下是基于 superset 做的一些可视化：

下集预告：《浅谈游戏数据（2）-埋点规范》

长按下图二维码关注，您将第一时间接收到最新的数据库相关的文章。

相关知识

浅谈游戏数据（1）
浅谈游戏数据（2）
浅谈游戏引擎
小学生竞赛性体育游戏有效组织策略浅谈
浅谈游戏行业未来会有的一些新道路1
自在门】《逆水寒》浅谈PVP技术进阶个人心得
三国游戏之三国霸业 经典时刻回忆、浅谈 已推荐
游戏数据分析——解读LTV
浅谈数字媒体环境下的手机游戏UI设计
浅谈策略类型游戏

网址: 浅谈游戏数据（1） http://www.hyxgl.com/newsview366618.html