游戏云之海量游戏日志分析方案

作者：mars13jing 2017-03-29 11:08:36

云计算 如果游戏的设计者并没有数据分析的概念，也没有搜集充足的数据以备分析，那只能拍脑袋制定策略变更。而如果数据分析的思路在设计之初就以部署，那接下来的每一步分析都会有根有据。

[[186940]]

我们将结合案例分析，看看如何利用数据分析来切实地改进游戏。

此次我们举例一款移动端的纸牌类游戏，模拟桌游21点。游戏的大众版本免费，用户在支付一定的费用后可获取无广告和拥有额外功能的版本。问题是，这款21点游戏并没有带来预期收入。期望是解决这个问题、提高用户参与度和消费。

如果游戏的设计者并没有数据分析的概念，也没有搜集充足的数据以备分析，那只能拍脑袋制定策略变更。而如果数据分析的思路在设计之初就以部署，那接下来的每一步分析都会有根有据。

我们假设游戏的设计之初就已考虑数据分析，在阿里云上按照下图的方式部署：

ECS作为游戏服务器;

RDS作为业务数据库，维护事务相关数据，通过阿里云的采云间将需要分析的数据同步至ODPS;

SLS作为日志服务，定期将日志数据导入至ODPS

ODPS作为开放数据处理服务，进行数据分析。

为了找出游戏并未带来预期收入的原因，我们一步一步地排查，并做出相应动作：

1.是否有足够多的人下载该应用?

查看下载总量和游戏的***安装量。下载量和安装量都可以维护在RDS中。

如果没有足够的下载量，需要公关部和市场部围绕产品的知名度展开工作。例如在游戏中加入创造性的元素，和运营方合作推广，采用新的皮肤包装或是诱人标题。在移动浏览器或是搜索客户端方面加大广告投入。

如果数据显示有足够多的用户下载量和***安装量，那说明问题不是出在知名度方面，那也无需额外增加公关方面的投入，而是继续查看步骤2。

2.对于安装游戏的用户，他们在游戏中做的***件事情是什么?所有用户中那些玩过多轮直到完全结束该游戏占多大的百分比?

对于***个问题，我们查看数据库中记录的登陆活动(Entry Event Distribute，EED)，这也可以维护在RDS中。对于第二个问题，我们在每一次用户完成游戏时，自动向服务器发送一条消息来收集该数据。

如果有很多用户进入游戏，但大部分人没有选择升级到付费版本，那可能这款游戏很有趣，吸引人们的注意，却没有很好的货币化。如果是这种情况，需要思考升级的价值，找出它能给用户带来更多价值的点并让用户了解。

如果只有很少的用户完成游戏，或者大部分人在玩游戏初期便退出，那么继续看步骤3.

3. 用户在哪一步退出的?

为了获知该数据，需要在用户执行操作时记录每一步。因为只能基于事件发生前执行的操作来决定退出事件(Exit Event Distribution，EXD)，所以需要在用户执行每一步操作时添加数据点，而且粒度越细越好(数据量哗哗滴)。显然这样的数据不适合放在业务数据库，也就是上图中的RDS里，而使用阿里云的日志服务SLS，可以自动读取产生的日志文件，并自动导入进ODPS中，供后续分析。既不会占用实时业务资源，也便于大量数据的分析处理。

接着，因为不知道用户是否还会回来继续进行游戏，需要筛选出那些在一定的时间段内都不再重新登录的用户。方法是，估算出活跃用户的平均登录间隔，然后再乘以10来判断用户是否永远流失。比方说，如果大部分用户的平均登录间隔是1天，那么对于10天内都未再登录的用户，可以判断其为流失。

这里EXD相应可以有很多分支，比方说，有多少用户完成游戏指南?如果大部分用户是在完成指南之后退出，那指南本身可能有一定的复杂性，需要对游戏指南进一步设计。如果大部分用户没有完成指南，需要考虑在游戏的主页面将指南设置成为可选项，让用户可以跳过游戏指南直接进入游戏。

如果大部分用户完成了游戏指南，那么继续看步骤4。

4.当用户准备开始游戏时，他们是否能成功配对同玩对象?

用户首先选择那一种游戏对象?和另一名玩家对战或是随机选择?独自玩或是与机器对玩?还是与身边的人使用“热座模式”?如果大部分用户首先使用对战按钮来和朋友玩，当他们这样做时，他们使用什么选项来找寻伙伴?现在很多人都会在“微信”中寻找。当选择“微信”导入时，会弹出一个允许页面，询问是否允许该应用的访问。多少用户选择允许应用的访问?

这些数据可以记录在RDS或是用日志的方式由SLS导入ODPS。通过在ODPS里设置map、reduce规则，得到需要的分析数据。

如果“不允许”的比例很高，那说明可能是允许页面的内容吓坏了用户。这样的情况下，可以去掉一些通用的语句比如“随时访问数据”，“打扰我的朋友们”，让页面看起来不会那么地打扰用户。另外，有多少用户是通过这个过程找到朋友然后一起玩游戏的?可以通过查看多少人进入“微信”选项，对比此时开始游戏并且立即进入游戏的人数。如果这个比例很低，那说明在游戏配对处需要改进。当然，这里就需要多一些的数据分析规则。

5. 当用户进入游戏时，他们是否完成该游戏?他们玩了多少回合?

如果在玩了一两个回合后退出，那么如果游戏的对方是人，并且他们之间的回合过长，那么可能是因为回合的持续时长而导致厌烦。这一点可以通过回合间的平均耗时来查询。

如果回合时长看起来合理，但是玩家仍然在一两局之后退出，那需要检查游戏可玩性的问题。

6.对于那些玩过几把游戏但仍然流失了的用户，考虑下面几个问题：

这些玩家是否在自己的游戏回合中总是赢或总是输?如果总是赢或输，可能他们觉得这个游戏太过简单或者太过复杂。如果输赢结果比较随机，那需要更精准的游戏对玩数据来启发。如果游戏对方是他们的朋友，可能能启发的不多。如果游戏对方是机器，那么需要更多的数据收集来进一步研究。

以上的这些步骤只是数据分析对游戏改进的一个简化举例，如文中的图所示，游戏过程中的数据由RDS或SLS导入ODPS，再从ODPS中对大量数据进行分析，帮助指定后续的决策。由此也可见，数据分析在整个过程中对分析问题的默默支持，正是“我愿意，化流沙躺湖堤。只陪你，恭候春夏的轮替。”