游戏日志分析1:概览

本文涉及的产品
对象存储 OSS,20GB 3个月
对象存储 OSS,内容安全 1000次 1年
对象存储 OSS,恶意文件检测 1000次 1年
简介: 介绍如何进行游戏日志处理与分析

系列文章:

  • 游戏日志分析(1):概览
  • 游戏日志分析(2):全方位数据采集
  • 游戏日志分析(3):程序日志规范与埋点
  • 游戏日志分析(4):线上问题定位与排查
  • 游戏日志分析(5):数据库与日志关联分析
  • 游戏日志分析(6):CDN/对象存储日志分析
  • 游戏日志分析(7):网络日志查询与分析
  • 游戏日志分析(8):数据库日志分析
  • 游戏日志分析(9):安全日志分析
  • 游戏日志分析(10):数据可视化与报表
  • 游戏日志分析(11):数仓建设
  • 游戏日志分析(12):实时数据处理与流计算

游戏挑战与机遇

我们先看一张图,这张图是应用市场的一个报告:统计了最近4年中,一款游戏从上架到达到90%下载量持续的时间长度(生命周期),横轴代表的是年份,纵轴代表的是持续的周数。在2012年,一款游戏平均可以持续180周(也就是说到了2014年仍有人下载),但这个比例每年在持续下滑,到2015年该区间已经到了24周,进入快餐式消费时代。

不管背后原因是什么,从整个趋势来看游戏行业已经从卖方市场(20年前游戏卡带相互借阅,一卡难求),到现在的买方市场。

image

第二个趋势是:云计算改变了行业,一个显著特征是游戏部署、上线时间缩短了。原先繁重运维工作进一步地减轻,传统意义上运维转向了运营。这是时代的挑战,也是全栈工程师的幸运。

刚才两点更多是共同面对的问题,第三点就是大数据制造的机遇了。我们把2015年24周打开看一下,机会在哪里?从图表中可以看到,游戏一般有4个阶段:研发、增长、成熟、衰退。在增长阶段我们会遇到模仿者,抢占市场份额。怎么去应对模仿者?少犯错、离用户更近一些,实时更改自己的运营策略。

image

游戏运作规律

虽然市场很激烈,但20多年来用户的习惯仍然不变。我们可以看下ongamesdata在的一副漫画。面对一款新的游戏时:

  • 用户首先会尝试下载demo
  • 之后会喜欢上游戏,和游戏朝夕相处
  • 某些热爱的玩家会在facebook/twitter等传播游戏、引入更多的玩家
  • 为游戏付费

客观上看游戏用户并没有因为市场竞争激烈而减少,相反移动互联网的出现让用户在闲暇时间可以享受游戏,社交媒体使得好的游戏更容易传播,用户也越来越舍得花钱,市场的机会还是存在的。

image

为洞察用户,团队需要做什么?

为了能够让用户爱上我们的游戏,能够长时间参与,最好的方法就是数字化整个过程。在一个团队中,不同的人在不同的方面关注游戏运行的状态,让我们来看一些例子,不同的人会关注什么?

A 总监

总监需要对整体状况有一个客观、宏观的衡量,并能够快速分析出原因,制定宏观战略。例如FarmVille(开心农场)DAU变化举例:

image

除此之外,我们可以通过用户特征、历史行为记录,反复参与程度等预测一个游戏可能的欢迎欢迎程度。例如我们可以根据观察到的数据(A、B、C)去预测一个结果(例如30天留存率),例如样本1就有很大概率会留存。

指标 含义 样本1 样本2
A 用户一周玩的时间 4​ 0​.5
B 用户在游戏成长速度 3​.5 1​
C 用户在游戏中购买道具数目 25 0
预测30天留存率 95% 5%

其他重要指标包括:

  • DNU(Daily New Users): 每日游戏中的新登入用户数量
  • AU(Active Users):活跃用户,统计周期内,登录过游戏的用户数。相应的,根据统计周期,有DAU(日活跃用户),WAU(周活跃用户),MAU(月活跃用户)等。
  • PU ( Paying User):付费用户
  • APA(Active Payment Account):活跃付费用户数。这里我们要注意“用户”和“付费用户”的区分,这也将影响收入的计算。
    ARPU(Average Revenue Per User) :平均每用户收入,即可通过 总收入/AU 计算得出。
  • ARPPU (Average Revenue Per Paying User): 平均每付费用户收入,可通过 总收入/APA 计算得出。
  • PUR(Pay User Rate):付费比率,可通过 APA/AU 计算得出。
  • LTV(Lift Time Value):生命周期价值,即平均一个用户在首次登录游戏到最后一次登录游戏内,为该游戏创造的收入总计

B 游戏运营者

游戏总监和规划主要focus在宏观战略层面做出决策,运营则需要在各个阶段打精细化之战。以我们提到的游戏四个阶段为例子:
在游戏投入市场后,需要在短时间内积累足够的用户数,我们会在广告和推广上下功夫。例如我们可以从页面埋点获得有多少用户看到广告、点击了游戏下载,输入了账号。

在游戏的试玩阶段,我们要从玩家的角度去衡量“参与度”。以FPS和页游为案例,我们可以把用户分成几个阶段,衡量每个阶段玩家的数目,耗费的时间及转化率。

image

运营主要关心的指标有

  • CVR (Click Value Rate): 转化率,衡量CPA广告效果的指标
  • CTR (Click Through Rate): 点击率
  • CPC (Cost Per Click): 按点击计费
  • CPA (Cost Per Action): 按成果数计费
  • CPM (Cost Per Mille): 按千次展现计费

C 游戏开发者

这里说的开发者是偏向运营的开发人员,这类角色需要不断游戏的参数以确保平衡性与用户体验。例如以“今晚吃鸡”的FPS游戏为例,需要统计各道具的平衡性,以及关卡的难度设定:

  • 程序员通过不同Kill事件统计武器的平衡性
  • 通过地图可视化,调整关卡的难度与设置

image

除此之外,一般关心的数据有:

  • EED:Enter Event 进入事件
  • XED:Exit Event 最后退出事件

D 开发运维人员

开发运维人员(DevOps)最关注的是游戏的SLA、稳定性、用户使用的体验(延时、顺畅性)以及成本。另外如何对线上进行快速排查也是至关重要的,主要考虑点有:

  • CDN的质量是否符合预期,全国各地的用户是怎么来访问的?
  • 游戏各个服务器分布位置与用户增长分布
  • 游戏客户端的卡顿率,崩溃率,使用模式等
  • 服务端访问的延时、质量等
  • 线上程序的日志查询、Debug,问题定位

E 客服人员

客服主要进行用户的咨询、问题的排查与诊断。例如

  • 有用户丢失道具、如何排查
  • 分析用户行为,是否有作弊等出现
  • 登录失败、充值失败、下载失败、无法连接服务器等问题排查

收集用户行为、优化游戏整个过程

为了拿到以上结果,游戏团队需要做什么事情?我们可以大致拆分成三个过程:

  1. 在游戏开发阶段埋点
  2. 在各个渠道收集数据
  3. 对数据进行多维度的分析,拿到结果采取行动

在整个过程中串起用户端和服务端最重要的点就是日志数据。

image

运行两种状态:切片(Snapshot)状态和增量日志

为了更好理解日志和游戏的关系,让我们来看下什么是日志数据,和游戏之间是什么关系:

游戏在用户端看起来是两个行为交替:行动、绘图。当移动鼠标、点击键盘时我们改变了主人公位置和状态,之后渲染引擎进行了绘图。我们可以在一个时间点上对游戏的状态进行采样,例如10:06分,游戏中所有主人公的位置、金钱和手持武器如下,状态反映一个时间点下系统的全貌。

日志是状态与状态之间的变化量。例如10点-10点06分这个时间上用户做了哪些操作?日志相比状态最大的好处是,能够记录整个细节。

image

状态数据一般会保存在数据库(DB 或 NoSQL)中,数据量在几百G一下。

日志其他作用

除了刚才提到的帮助运营、渠道更高效地运作,日志对游戏还有什么作用?

  1. 帮助用户:

    • 找寻丢失:装备掉了
    • 修复数据:机器当机数据丢失了,可以通过日志来进行还原
  2. 定位异常:

    • 找到偷盗、作弊等行为
  3. 广告;

    • 没有打赢Boss:缺少什么道具
    • 用户画像:年龄、性别、什么是你的菜?
  4. 日志可以帮助运维

    • 用户反映卡,在什么环节
    • 登陆失败,背后是什么原因

日志处理几个挑战

日志有那么多的作用,那处理起来有哪些挑战呢?

第一个挑战和产生相关,游戏涉及到方方面面的合作。例如涉及游戏发行商、移动端、网页端、服务器端等。因此要从多个维度、多个渠道来收集日志,对于每一种日志有独特处理方法:例如为了分析渠道我们需要在网页埋点;为了拿到用户的行为,我们需要从移动设备、服务端等记录玩家轨迹;为了分析服务的稳定性,我们需要观察请求的延时等特点。

在这里我们需要使用一个统一的数据模型,支持各个渠道的数据通道来完成统一大事。

第二个挑战来自规模、性能和稳定性:举一个直观例子,假设每秒钟我们需要收集一个用户1KB数据,在100W玩家同时在线的情况下,这个数字就是100MB/S处理流量,这个量挑战不小。如何在数据规模增长的情况下,保持性能的稳定性,是工程师需要关注的。

第三个挑战来自于需求,在之前我们提到了游戏团队中不同人对于需求的产出是不同的。比如对访问日志,运营的需求是统计活跃人数比例,运维关系的是延迟和访问状态,开发关心的点是哪些资源是热点,需要进行优化。因此我们需要对一份数据,支持多种处理、统计的方法。

阿里云日志服务

阿里云的日志服务(log service)是针对日志类数据的一站式服务,2013年研发,有5年多线上运行经验,经历双十一、新春红包等考验。对应的Agent运行在100W+机器上,为万级别应用提供服务。主要特点点如下:

image

日志服务主要包括 实时采集与消费、数据投递、查询与实时分析 等功能,接下来我们介绍下如何利用日志服务进行游戏日志处理与分析。

image

相关实践学习
日志服务之使用Nginx模式采集日志
本文介绍如何通过日志服务控制台创建Nginx模式的Logtail配置快速采集Nginx日志并进行多维度分析。
目录
相关文章
|
6月前
|
机器学习/深度学习 数据采集 自然语言处理
【2023 - 探索】博0到博1,游戏新地图的探索日志
【2023 - 探索】博0到博1,游戏新地图的探索日志
65 0
|
10天前
|
存储 人工智能 关系型数据库
拥抱Data+AI|玩家去哪儿了?解码Data+AI如何助力游戏日志智能分析
本文为阿里云瑶池数据库「拥抱Data+AI」系列连载第2篇,基于真实客户案例和最佳实践,探讨如何利用阿里云Data+AI解决方案应对游戏行业挑战,通过AI为游戏行业注入新的活力。文章详细介绍了日志数据的实时接入、高效查询、开源开放及AI场景落地,展示了完整的Data+AI解决方案及其实际应用效果。
|
11天前
|
存储 人工智能 关系型数据库
拥抱Data+AI|玩家去哪儿了?解码Data+AI如何助力游戏日志智能分析
「拥抱Data+AI」系列第2篇:阿里云DMS+AnalyticDB助力游戏日志数据分析与预测
拥抱Data+AI|玩家去哪儿了?解码Data+AI如何助力游戏日志智能分析
|
2月前
|
监控
莉莉丝-游戏用户日志分析
莉莉丝游戏用户日志分析案例图
|
6月前
|
Java 计算机视觉 Python
我的自描外挂制作日志——FPS类游戏的自瞄【优化改进1】
我的自描外挂制作日志——FPS类游戏的自瞄【优化改进1】
125 1
|
6月前
|
人工智能 算法 计算机视觉
我的自描外挂制作日志——FPS类游戏的自瞄【构思准备】
我的自描外挂制作日志——FPS类游戏的自瞄【构思准备】
245 0
|
6月前
|
计算机视觉
我的自描外挂制作日志——FPS类游戏的自瞄【验证猜想】
我的自描外挂制作日志——FPS类游戏的自瞄【验证猜想】
77 1
|
6月前
|
Java 计算机视觉
我的自描外挂制作日志——FPS类游戏的自瞄【优化改进2】
我的自描外挂制作日志——FPS类游戏的自瞄【优化改进2】
79 0
|
存储 运维 监控
游戏日志分析准备:如何对游戏业务日志关联云数据库Redis做富化加工
随着移动互联网的发展,游戏几乎是进入快餐式消费时代,游戏公司也会面临方方面面的挑战,为了获得最佳的游戏运营方案,游戏公司希望将用户游戏日志与用户元数据进行联合分析。
231 0
游戏日志分析准备:如何对游戏业务日志关联云数据库Redis做富化加工
|
IDE Java 应用服务中间件
从零开始实现放置游戏(五)——实现后台管理系统(3)实现切面日志
 上一章,我们初步实现了后台管理系统的增删查改功能。然而还有很多功能不完善。这一章,我们先把系统日志搭建起来,不管是生产问题排查,还是方便开发调试,日志都是必不可少的核心功能。所谓切面日志,比如说,我们想把每个方法的入参都记录日志,那需要在每个方法里都写一行记录参数的语句,非常繁琐。所以需要提取出切面“方法执行前”,“方法执行后”等等,然后在这个切面里进行编程,记录入参的语句只需要写一次。
从零开始实现放置游戏(五)——实现后台管理系统(3)实现切面日志

相关产品

  • 日志服务
  • 下一篇
    无影云桌面