游戏日常运营指标和数据分析 手游运营数据大全

许多游戏
运营朋友可能不知道,其实在埋点和报表之间还存在着一条巨大的鸿沟 。
这个差距就是如何设计系统的埋点,如何把前后端推到地面,然后如何检查验证数据,访问数据,清洗数据,计算数据,最后把数据固化形成报表 。
以这些路径中的埋点为例 。我曾经在上一篇文章中放过一个表格:
实际上,这只是一个简单的字段类型表 。玩游戏时,数据嵌入相当繁琐 。
首先我们需要整理整个系统的事件和事件类型,然后我们需要定义事件的触发时机,然后我们需要定义要交付的参数内容和参数类型 。
比如最简单的登录行为,哪个节点视为开始登录,哪个节点视为成功登录?你需要传递什么样的参数?
像通道登录成功的节点一般都是SDK登录成功,而游戏登录成功可能是创建一个角落后进入游戏,也可能是直接进入游戏,触发时机明显不同,需要具体定义 。
对于游戏运营来说,这整个过程是一个专业性要求很高,非常消耗团队资源的工作 。很难推,不做也很尴尬 。
对于大厂,有专业的数据团队(数据中心)给出了统一的嵌入规范 。作为一个游戏开发团队,只要按照规范交付,就能得到想要的数据和报告 。
并且对于一些个性化的分析需求,比如用户留存系列分析,用户流失系列分析等等,也有专门的数据分析 。
团队来支持 。
对于小工厂来说,数据中心是一个高投入慢产出的工作 。
以前赚快钱的本地老板很难理解这样做的意义,所以要么随便做个粗糙的数据,要么就去网上裸奔(别笑,我以前待过的一个团队就是网上裸奔,根本没有数据,一切靠拍脑袋决定) 。
近年来,第三方数据平台应运而生,其实就是为了解决这样的痛点 。而往往过于标准化的产品只能解决部分问题,部分需求无法满足 。
所以,在这种背景下,与其想办法搞清楚如何埋没系统,不如先搞清楚我们需要什么样的数据报表,然后在此基础上想办法解决数据问题 。
当你有机会要求数据平台的时候,你至少知道自己想要什么吧?至少知道你的决策需要依赖哪些数据?
不客气,我甚至见过很多所谓项目负责人的数据需求乱七八糟 。
那么一个通用的数据操作系统应该是什么样子的呢?
我把一般的数据操作系统分成六个部分:
核心数据
核心数据主要反映游戏的市场情况,运营商或者老板必须看的表是核心日报表和综合运营报表 。
【游戏日常运营指标和数据分析 手游运营数据大全】换个角度说,其实这也是数据分析的一个重要逻辑 。数据异常时,先看市场数据再按渠道或指标拆分数据 。
以实时数据为例,实时数据一般关心的领域有:实时新增数据(累计)、实时在线人数(累计)、实时充值金额(累计)等等 。
例如,如果在线人数为0,则报表参照样式如下:
我随便填的数据,真实时间应该是23: 25,23: 20等 。很抱歉这里用省略号 。
请注意,所有后续报告通常都支持过滤通道和服务器 。
一般实时数据的时间间隔在5-15分钟之间 。如果压缩到5秒左右,对数据库的压力会非常大,5分钟基本可以满足需求 。
有时候光报告看起来不够直观 。负责数据的同学,可能会做一些数据可视化,比如折线图,充分展现数据的趋势和波动 。这里就不展示了 。
核心日报
核心日报的领域和风格并不固定,不需要追求大而全,主要围绕运营需求和老板需求,适可而止 。
比如老板关心dau和营收,运营关心留存和添加,那么这里的报表可以显示这些字段 。
综合运营报告
综合报告反映的是整个市场的数据,主要包括所有用户和新增用户的所有数据 。
一般样式如下:
用户分析
用户分析主要包括六个部分:新用户分析、付费分析、活跃度分析、流失分析、用户培养分析、用户行为路径分析 。
系统分析
该系统由四部分组成:活动分析、经济系统分析、博弈系统分析和其他功能分析 。
区域服务分析
服务分析主要分为五个部分:服务数据概述、服务月份分析、服务留存分析和服务器数据 。
限于篇幅,本文只能展示用户分析、系统分析、区域服务分析的脑图 。详细的报表和内容需要在开头单独说明 。有兴趣的同学可以留言,人多的话会继续更新 。毕竟脑图都写了几个小时了,写下来整个就死了…
其实严格来说GM工具是不应该归入数据体系的,但是考虑到很多公司连GM工具都做不好,所以在下一章会单独说明 。


推荐阅读