手游精细化运营第一步：如何搭建一个数据运营系统？

对于中小游戏研发团队来说，选择足够细分的领域，沉心打磨产品，精细化运营，做细分领域的爆款，是一条出路。本文作者姚伟，将和大家聊一聊精细化运营的基础——数据运营系统。

前段时间和好朋友游戏策划K聊天，他疯狂和我吐槽对接的发行运营非常不专业，每次收入不行了就来求爷爷告奶奶，活动内容和数值不会设计，活动效果从来不分析等等。出于职业习惯，我就好奇问到，那你是怎么去分析活动效果的呢？他说我看游戏内排行榜啊！我：what？看排行榜？没有其他数据或者后台吗？他说没有啊，后台啥都看不出来。

对话到这里，其实是比较出乎我的预料的，K的公司可是出过两款非常知名的产品的，没想到对于数据后台的建设还是这么粗放，可想而知其他中小厂的情况，比如下面就是某家研发的数据后台的原型：

基本的数据汇总，再加上PCU/ACU实时监控就构成了一个运营数据系统。这个系统对于分析来说，基本没有任何用。

在以前增量市场的情况下，市场对产品的渴求度高，产品追求的是快速上线，迅速占领市场，不需要精细的打磨就可以取得不错的成绩。现在的情况不同了，市场上的产品非常多。在这样的背景下，对于中小研发来说，想活下去无非几种打法：

1、做买量型产品，自己买量或者依附于渠道，用产品数量堆积起来收入。这种模式风险不低，对于买量能力和现金流要求较高；

2、寻找切入相对蓝海的市场，比如微信小游戏，快速推出产品，迅速迭代；

3、选择足够细分的领域，沉心打磨产品，精细化运营，做细分领域的爆款。

这篇文章就抛砖引玉地谈一谈关于精细化运营的基础——运营数据系统。从基础的开发概念到什么是埋点、埋点的意义、如何做埋点和最后的设计数据报表，希望能对看到这篇文章的人有所帮助。

一、基础概念出发

前端：前端是指直接和用户产生交互的部分，前端控制着APP的输入，可以理解为“看得见”的部分，对于手游来说，安卓的APK和iOS的iPA就属于前端的集合。进入游戏后，游戏内看到的人物、场景、对话框、按钮等都属于前端的内容。

服务端（后端）：后端是指所有隐藏的部分，控制着APP的输出。可以理解为“看不见”的部分，对于手游来说，后端包括业务逻辑的处理和数据层面的处理。

这里以《贪玩蓝月》中的某个场景为例来说明前后端的逻辑：

“古仔控制着法师来打触龙邪神，战斗过程中双方狂甩技能，身上不停爆出红字9999，最后古仔一招‘冰咆哮’打死了触龙邪神，爆了一把屠龙宝刀，古仔美滋滋地捡起屠龙宝刀，存放到自己的仓库，最后到拍卖行以10万的元宝卖出。”

这个场景里面，古仔在操作界面上控制法师的走向、控制技能的释放、控制法师的普通攻击就是在前端的输入，而爆出的红字、技能的特效、触龙邪神的死亡、屠龙宝刀的掉落这些就是后端控制的输出，这些输出在前端控制着展现。

而像触龙邪神的伤害数值、技能的特殊效果、爆装备的概率等等，这些则是后端的业务逻辑。

古仔击杀触龙邪神、获得屠龙宝刀和获得10万元宝，如果后端均有埋点，则会同步到相应的数据库里。

这里需要说明一下，手游绝大部分的业务逻辑是写在服务端的，通过客户端和服务端的双向验证可以一定程度上杜绝外挂。如果古仔的所有信息是记录在本地，服务端不做任何验证，那么破解APK之后可以随意修改古仔的数值，一刀秒杀触龙邪神不是梦。这也是为什么很多单机的手游最终都会被破解的原因。

二、埋点

什么是埋点

对于游戏来说，埋点就是在游戏关键点植入多段代码，统计追踪用户行为，进而作为分析用户行为，建立用户画像，优化提升游戏体验的基础。

埋点的意义

到这里大家可能还是不太明白，埋点到底是怎么来帮助我们优化提升游戏体验的，我这里特别想和大家分享一个关于曹政老师当年在百度的故事，这个故事可以帮大家更好地理解埋点的意义：

我在百度的时候参加过一个孙云丰主持的产品分享会，会上举了一个例子记忆犹新，说当时百度的首席架构师，晚上没事干什么呢？上服务器看访问日志，看一个用户的搜索行为。为什么要看用户的搜索行为呢？通过搜索行为的跟踪来分析用户的搜索预期，和搜索引擎给出的结果，是否一致，如果存在差异，再通过其他方式来分析到底在哪里出现了差异。

当时讲的例子很有意思，说用户输入了一个关键词——“苹果” 。这时候，你无法知道用户真实目的是什么，因为苹果是个多指向词，是一种水果？是一个数码品牌？还是当时热播的一部电影？用户没有产生有效的点击，而是搜索了第二个词—— “苹果 范冰冰” ，好了，已经知道用户要找的是当时热播的电影苹果，但是用户目的是什么呢，看剧情介绍，看幕后花絮？还是看电影视频呢？依然不知道，但已经知道用户在搜索苹果的时候，没有找到他想要的结果。

然后就看到用户搜索了第三个词——“苹果 范冰冰 XX视频” ，现在终于知道用户的目的了，当然，这种搜索目标是肯定没有结果的，然后这个用户就不断变换关键词，从百度网页搜索到视频搜索，然后再度变换多个关键词，最后，搜了一个关键词——“雅虎”，然后离开了。我们设身处地想一下，用户为什么搜索雅虎，很容易想到用户当时的心理，对百度的搜索结果深深的失望，然后跑去雅虎继续搜索了。但是好玩的是，过了20分钟，这个用户又回来了，还在继续搜索这类关键词，那么，这代表什么呢？雅虎他也没搜到。最后用户终于放弃，但是举这个例子，孙云丰说了一句话，我分享给各位，叫做理解用户的挣扎。

再回到我上面说的话，埋点是如何帮助玩家提升游戏体验的？某次游戏上线测试一看，发现玩家留存不高，然后去细分这些流失玩家，发现在15级这个地方流失陡增。很多研发数据埋点做到这个地方就没了，剩下的就是拍脑袋做改动优化，甚至很多研发连在15级流失这个地方都无法分析出来。如果能找出几十个完整的玩家行为记录拿来看，一条一条的去理解玩家做什么，比如说，过15级有个boss任务，玩家去打，没打过，充钱去打，还是没打过，又试了几次，流失了。回头研究下，玩家在这里挺绝望的，卡了两三天难以寸进，说明这个boss难度太高了。

所以，完整的埋点的意义在于，既能为我们提供建立用户画像，分析用户行为的基础，又能给我们建立多纬度的数据报表，分析游戏整体表现带来帮助。

如何设计埋点

设计游戏内的埋点，需要先梳理清楚基本的埋点思路，也就是制定标准化方案，然后再结合具体的业务场景和业务诉求制定个性化方案。比如MMORPG的埋点和棋牌的埋点就有非常大的差异，但是他们底层的埋点逻辑是一致的。

点击上图，可放大查看

需要说明的是，我这里的客户端投递和服务端投递并不是按照严格意义上的技术层面的投递来的，比如服务端的设备信息投递，实际上是前端投递给服务端，然后服务端存储记录下来的，并不是由服务端投递。这样区分是便于大家更好地理解埋点思路。更严格的划分，有兴趣的朋友可以和研发进行讨论，这里就不再进行赘述了。

以数值货币表为例，需要定义的基础投递字段如下：

表格：基础投递字段

其他类型的表都按照这样的形式定义即可，基本的游戏埋点在产品层面上就已经完成得差不多了，剩下的就是和开发讨论定义每个埋点投递的时机和最后的埋点测试验收，这里就不再赘述了。

埋点全部设计测试验收完成后，接下来就是如何设计报表的问题了。

三、通用数据运营系统

很多游戏运营朋友可能不知道，其实在埋点和报表之间还存在着一条巨大的鸿沟。这条鸿沟就是怎么去设计系统的埋点，怎么去推动前后端落地，再到怎么核对校验数据、取数、清洗数据、数据计算，最后再到数据固化形成报表。

前面的【表格：基础投递字段】，其实只是简单的字段类型表，当真的在做一款游戏的时候，数据埋点工作是相当繁琐。

首先需要梳理整个系统的事件和事件类型，然后要定义事件的触发时机，再去定义需要投递的参数内容和参数类型。

比如最简单的登录行为，什么节点视为开始登录，什么节点视为登录成功？需要投递什么样的参数？

像渠道的登录成功的节点一般是SDK登录成功，而游戏的登录成功可能是创角之后进入游戏，也可能是直接进入游戏，触发时机就明显不一样，需要特别定义清楚。

对于游戏运营来说，这整套流程是一个专业度要求较高，并且又非常耗费团队资源的工作。很难推动，不做又十分尴尬。

对于大厂来说，已经有专业的数据团队（数据中台）给出统一的埋点规范，作为游戏开发团队，只要按照规范投递即可获取想要的数据和报表。

并且对于一些个性化的分析需求，比如用户留存系列分析，用户流失系列分析等，还有专门的数据分析团队来支持。

对于小厂来说，数据中台是一个高投入，产出见效慢的工作。

以前习惯了赚快钱的老板很难理解做这件事的意义，所以要么就胡乱做一个简陋的数据，要么就上线裸奔（别笑，我以前待过的某团队就是上线裸奔状态，什么数据都没有，决策全靠拍脑袋）。

近几年的第三方数据平台应运而生，实际上就是想解决这样的痛点。但是往往太过标准化的产品只能解决一部分问题，还有一部分需求满足不了。

所以在这种背景下游戏运营与其去费力理解怎么做系统埋点，不如先搞清楚什么样的数据报表是我们所需要的，在此基础之上再想办法解决数据的问题。

当你有机会提数据平台的需求的时候，你至少要知道你想要什么吧？至少要知道你的决策需要依赖哪些数据吧？

不客气地说，我甚至见过不少所谓的项目负责人提出的数据需求都乱七八糟的。

那么一个通用的数据运营系统应该是什么样的？

我把通用的的数据运营系统分成六个部分：

核心数据

核心数据主要是反映游戏的大盘状况，作为运营负责人或者老板必看的表就是核心日报和综合运营报表。

多说一句，其实这也是数据分析的一个重要逻辑，数据异常时，先看大盘数据然后再分渠道或者分指标去拆分数据看。

以实时数据为例，实时数据一般关心的字段有：实时新增数据（累计）、实时在线人数（累计）、实时充值金额（累计）等。

比如在线人数为，报表参考样式如下：

数据是我随手填的，真实的时间应该还有23：25，23：20等等，我这里嫌麻烦用省略号了。

注意，后续的所有报表一般都要支持筛选渠道和服务器。

一般实时数据的时间间隔在5-15分钟之间，如果要压缩到比如5秒左右的话，对于数据库的压力会非常大，5分钟基本能满足需求。

有的时候光报表看起来不够直观，负责数据的同学可能会做一些数据的可视化，比如折线图等，这样能充分显示出数据的趋势和波动。这里就不再展示了。

核心日报

核心日报的字段和样式不固定，这里不必追求大而全，主要是围绕运营需求和老板需求来，够用就好。

比如老板关心DAU和收入，运营关心留存和新增，那这里的报表展示这些字段即可。

运营综合报表

运营综合报表反映的就是整个的大盘数据，主要包括全部用户和新用户的全部数据。

大致样式如图：

用户分析

用户分析主要包括六个部分：新增用户分析、付费分析、活跃分析、流失分析、用户养成分析、用户行为路径分析。

系统分析

系统分析主要四个部分：活动分析、经济系统分析、玩法系统分析、其他功能分析。

区服分析

区服分析主要分5个部分：开服数据概览、开服月分析、开服留存分析、服务器数据。

四、结语

限于篇幅原因，本篇只能展示用户分析、系统分析和区服分析的脑图，详细报表形式和内容需要单独开篇进行讲解，有兴趣的同学可以留言，人多的话会继续更新，毕竟脑图就写了几个小时，完整一篇写下来要死了...

GM工具其实严格来说不应该归类于数据系统中，但是考虑到很多公司连GM工具都做不好，后续也会单独开篇进行讲解。

以上内容如果能做成运营后台，基本能满足80%的运营和迭代需求，其余20%的个性化需求需要单独由数据分析师进行取数计算分析。

大厂和不少第三方数据平台现在实际上也是支持定制计算的（主要是不少运营不会写SQL语句），但是效果一言难尽。所以这里就不再赘述了。

这次游戏数据运营系统的文章加脑图写了差不多七八个小时，如果看的人多的话会更新成一个系列。

本文转自微信公众号独立出海联合体（ID：gameunited），未经许可，禁止转载。