许多游戏运营朋友可能不知道，其实在埋点和报表之间还存在着一条巨大的鸿沟。

这条鸿沟便是如何去设计系统的埋点，如何去推动前后端落地，再到如何核查校验数据、取数、清洗数据、数据测算，最终再到数据固化产生报表。

以这些途径里边的埋点为例，我在前文曾经放过一张表：

这个其实只是单纯的字段类型表，当真的在做一款游戏的时候，数据埋点工作是非常繁杂。

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

例如最简单的登录行为，哪些节点视作开始登录，哪些节点视作登录成功？需要投递怎么样的参数？

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

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

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

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

对于小厂而言，数据中台是一个高投入，产出效果慢工作。

之前习惯了赚快钱的土老板无法理解做这件事的意义，因此要么就随意做一个简陋的数据，要么就上线裸奔（别笑，我之前待过某团队便是上线裸奔情况，哪些数据也没有，决策全凭拍脑袋）。

近些年的第三方数据平台应时而生，实际上就是想处理这样的痛点。但是往往过于规范化的商品只能处理一部分难题，还有一部分需求满足不了。

因此在这种环境下游戏运营与其去费劲了解怎么做系统埋点，不如先弄清楚怎么样的数据报表是我们所需的，在此基础之上再想办法解决数据的问题。

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

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

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

我将通用的数据运营系统分为六个部分：

关键数据

关键数据通常是体现游戏的大盘情况，做为运营负责人或是老总必看的表便是关键日报和综合运营报表。

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

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

例如在线人数为，报表参照款式如下：

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

注意，后续的全部报表一般都要支持挑选渠道和服务器。

一般即时数据的时间间隔在5-15分钟之间，如果想压缩到例如5秒上下的话，对于数据库的压力会非常大，5分钟基本能满足需求。

有些时候光报表看上去不够直观，承担数据的同学可能会做一些数据的可视化，例如折线图等，这样能充分显现出数据的趋势和起伏。这里就不再展现了。

关键日报

关键日报的字段和款式不规律，这里无须追求专而精，通常是围绕运营需求跟老板需求来，足够就好。

例如老总关注dau收入，运营关注保留和新增，那这儿的报表展现这些字段即可。

综合运营报表

运营综合报表反映的便是整个的大盘数据，主要包含全部用户和新客户的所有数据。

大致款式如图：

客户分析

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

系统分析

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

大区分析

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

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

GM工具其实严格来说不应该分类于数据系统内，但是考虑到很多企业连GM工具都做不好，后续也会独立开场进行讲解。

本篇文章如果能制成运营后台，基本能满足80%的经营和迭代需求，其他20%的个性化需求需要独立由数据分析师开展取数测算分析。

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

这次游戏数据运营系统的帖子加脑图写了差不多七八个小时，如果看的人多的话会更新成一个系列。关注我的互联网领域的朋友安心，我后续还是会写互联网的商品运营方法论的。