很多游戏运营朋友可能不知道，其实在埋点和报表之间还存在着一条巨大的鸿沟。
这条鸿沟就是怎么去设计系统的埋点，怎么去推动前后端落地，再到怎么核对校验数据、取数、清洗数据、数据计算，最后再到数据固化形成报表。
以这些路径里面的埋点为例，我在前文曾经放过一张表：
这个其实只是简单的字段类型表，当真的在做一款游戏的时候，数据埋点工作是相当繁琐。
首先需要梳理整个系统的事件和事件类型，然后要定义事件的触发时机，再去定义需要投递的参数内容和参数类型。
比如最简单的登录行为，什么节点视为开始登录，什么节点视为登录成功？需要投递什么样的参数？
像渠道的登录成功的节点一般是SDK登录成功，而游戏的登录成功可能是创角之后进入游戏，也可能是直接进入游戏，触发时机就明显不一样，需要特别定义清楚。
对于游戏运营来说，这整套流程是一个专业度要求较高，并且又非常耗费团队资源的工作。很难推动，不做又十分尴尬。
对于大厂来说，已经有专业的数据团队（数据中台）给出统一的埋点规范，作为游戏开发团队，只要按照规范投递即可获取想要的数据和报表。
并且对于一些个性化的分析需求，比如用户留存系列分析，用户流失系列分析等，还有专门的数据分析团队来支持。
对于小厂来说，数据中台是一个高投入，产出见效慢的工作。
以前习惯了赚快钱的土老板很难理解做这件事的意义，所以要么就胡乱做一个简陋的数据，要么就上线裸奔（别笑，我以前待过的某团队就是上线裸奔状态，什么数据都没有，决策全靠拍脑袋）。
近几年的第三方数据平台应运而生，实际上就是想解决这样的痛点。但是往往太过标准化的产品只能解决一部分问题，还有一部分需求满足不了。
所以在这种背景下游戏运营与其去费力理解怎么做系统埋点，不如先搞清楚什么样的数据报表是我们所需要的，在此基础之上再想办法解决数据的问题。
当你有机会提数据平台的需求的时候，你至少要知道你想要什么吧？至少要知道你的决策需要依赖哪些数据吧？
不客气地说，我甚至见过不少所谓的项目负责人提出的数据需求都乱七八糟的。
那么一个通用的数据运营系统应该是什么样的？
我把通用的的数据运营系统分成六个部分：
???核心数据
核心数据主要是反映游戏的大盘状况，作为运营负责人或者老板必看的表就是核心日报和综合运营报表。
多说一句，其实这也是数据分析的一个重要逻辑，数据异常时，先看大盘数据然后再分渠道或者分指标去拆分数据看。
以实时数据为例，实时数据一般关心的字段有：实时新增数据（累计）、实时在线人数（累计）、实时充值金额（累计）等。
比如在线人数为，报表参考样式如下：
???数据是我随手填的，真实的时间应该还有23：25，23：20等等，我这里嫌麻烦用省略号了。
注意，后续的所有报表一般都要支持筛选渠道和服务器。
一般实时数据的时间间隔在5-15分钟之间，如果要压缩到比如5秒左右的话，对于数据库的压力会非常大，5分钟基本能满足需求。
有的时候光报表看起来不够直观，负责数据的同学可能会做一些数据的可视化，比如折线图等，这样能充分显示出数据的趋势和波动。这里就不再展示了。
核心日报
核心日报的字段和样式不固定，这里不必追求大而全，主要是围绕运营需求和老板需求来，够用就好。
比如老板关心dau和收入，运营关心留存和新增，那这里的报表展示这些字段即可。
综合运营报表
运营综合报表反映的就是整个的大盘数据，主要包括全部用户和新用户的全部数据。
大致样式如图：
???用户分析
???用户分析主要包括六个部分：新增用户分析、付费分析、活跃分析、流失分析、用户养成分析、用户行为路径分析。
系统分析
???系统分析主要四个部分：活动分析、经济系统分析、玩法系统分析、其他功能分析。
区服分析
???区服分析主要分5个部分：开服数据概览、开服月分析、开服留存分析、服务器数据
限于篇幅原因，本篇只能展示用户分析、系统分析和区服分析的脑图，详细报表形式和内容需要单独开篇进行讲解，有兴趣的同学可以留言，人多的话会继续更新，毕竟脑图就写了几个小时，完整一篇写下来要死了…
???GM工具其实严格来说不应该归类于数据系统中，但是考虑到很多公司连GM工具都做不好，后续也会单独开篇进行讲解。
以上内容如果能做成运营后台，基本能满足80%的运营和迭代需求，其余20%的个性化需求需要单独由数据分析师进行取数计算分析。
大厂和不少第三方数据平台现在实际上也是支持定制计算的（主要是不少运营不会写SQL语句），但是效果一言难尽。所以这里就不再赘述了。
这次游戏数据运营系统的文章加脑图写了差不多七八个小时，如果看的人多的话会更新成一个系列。关注我的互联网领域的朋友放心，我后续还是会写互联网的产品运营方法论的。