游戏开发者如何有效“驾驭”数据分析？

　　作为一个独立游戏开发者，数据指标尤为重要。在这个过程中我们经常得出一些新颖的见解，其中一些经常会被我们遗漏，但这仍然是极具挑战性的。在这篇冗长的文章中，我将试着与大家分享关于Sharp Minds这款游戏的一些相关分析来与大家共同探讨。

　　可能在大多数情况下，以上观点并没错（除了简单直白的“胜利”），不过我们的经验与分析表明，这结论似乎太草率了。难道没有让人出乎意料的事情吗？在这个过程中我们经常得出一些新颖的见解，其中一些经常会被我们遗漏，但这仍然是极具挑战性的。在这篇冗长的文章中，我将试着与大家分享关于Sharp Minds这款游戏的一些相关分析来与大家共同探讨。

　　可能在大多数情况下，以上观点并没错（除了简单直白的“胜利”），不过我们的经验与分析表明，这结论似乎太草率了。难道没有让人出乎意料的事情吗？在这个过程中我们经常得出一些新颖的见解，其中一些经常会被我们遗漏，但这仍然是极具挑战性的。在这篇冗长的文章中，我将试着与大家分享关于Sharp Minds这款游戏的一些相关分析来与大家共同探讨。

　　1.“快餐”

　　对于那些没时间阅读整篇文章的朋友们，我在这里先放出一些“快餐”（觉得篇幅过长无心阅读的朋友们-可以直接跳到结论部分）

　　什么是分析

　　严格地说，“分析”是通过数据做出的有意义的见解。通常它是一个需要利用电脑完成的密集型计算过程。有时候，数据集有可能会非常巨大。计算能力的提升允许“分析”越来越多地应用在生活跟工作的各个方面。在这里，我们将专注于游戏分析，特别是手机游戏的分析。

　　在游戏产业中，分析通常是指记录关于玩家行为/游戏的重要数据并对其作出分析，发现在游戏中存在的各种问题及瓶颈。发现问题并通过游戏更新来纠正。而新的数据将会用于验证是否成功地解决了问题。

　　即使纠正问题并不是分析的一部分，我认为对游戏做出“治愈”是分析过程中一个至关重要的环节。没有它，分析几乎是浪费了开发时间。

　　让我们来纠正一些误解：

　　在游戏中进行分析意味着将一些平台的SDK集成到代码中。

　　NO，这只是分析过程中的一个简单步骤，仅仅是在一开始。

　　事件报告是琐碎的，仅在“开始阶段”、“结束阶段”以及一些类似事件发生的时候才发送

　　尽管可以使游戏几乎没有事件报告，然后处理所有计算中产生的数据集，有时候这会省去我们大量的时间以及简化一些工作，并且使报告更智能以及发送一些上下文数据。

　　比如：“开始阶段”事件可以包含关卡的尝试次数。如果没有关于玩家开始关卡的连续计算数据是很难得出结论的，有一点要很清楚，这是一种非常“奢侈”的分析统计计算。一开始在事件计算中就加入关卡尝试次数则会让这一过程简单很多。

　　如果我记录下每个可能在游戏中发生的事件，数据分析平台将会给我一些有价值的见解帮我改进游戏。

　　这可能是一种比较常见的误解。虽然数据分析平台有时会给出一些丰富而又华丽的图表像我们展示游戏中一些看起来比较明显的问题，但大多数是一些并没有什么实际意义的数据。我们很难提取一些可以帮助我们付诸实践的内容。最有挑战性的工作也正是在这里。

　　我并不需要现有的数据分析平台，我可以使用自己的服务器完全控制和处理这些数据。

　　“每件事都自食其力”通常对独立开发者来说是一个很大的问题。数据分析也不例外。数据分析的核心的确不是很复杂。只需通过一个REST API或其他什么方法都系收集一些 关键/有价值 的数据，但是这在细节上要求的深度和广度都是超乎想象的；可行性、缩放比例、误差处理、估算、数据存储、冗余等等这些都是需要考虑在内的，而这将耗费大量的宝贵时间。

　　如果我得到的数据分析和图表是准确的，游戏中的瓶颈和问题将是显而易见的。

　　这的确是数据分析的目标。但是这需要大量的异常数据。下载数越少，数据就越不稳定。如果下载量是10次下载/天，这将是很难实现的，而且会导致一个错误的结果。想象一下如果有一个策略游戏。在策略入门的时候就已经很有特色，这将与那些墨守成规的策略游戏展现出完全不同的行为。每一个外部事件都会影响到数据。这个问题在得到稳定和相对数量级的数据或者新的有效安装方式时会相应减少。

　　当我解释这些例外情况的时候，剩下的分析数据将会给我一个明确的信息接下来要做什么。

　　并不一定。发现一个问题和知道造成这个问题的原因（因此能够想出适当的解决方案）之间还是存在一定的差距，我们不得不做出一些思考和猜测来弥补这个差距。比如，如果游戏中很多玩家在第四关的时候开始流失，很明显在这个关卡存在一个用户体验的问题。而我们仍然不知道这是什么造成的。现在如果我们去挖掘更深层次的原因，结果发现玩家们在几次尝试失败之后依然会流失。现在我们回头来看第四关的问题可能是因为难度太大或者这关的引导不能让玩家清晰的认识到该怎么做。当更深层次的挖掘不再是最优解的时候，我们只能靠猜，解决方案将基于我们最好的猜测，让我们在下一个版本里看看会发生什么。

　　报表数据中寻找信息是一个离散的计算过程

　　这不是我们应该关心的。数据分析主要是是关于统计学和或然率。我们不关心有多少玩家（或者百分比）在第四关的时候离开游戏。无论是80%还是75%-85%的信息，不要纠结于细枝末节的数字。我们要在数据分析和报告中找出来的是错误，而不是一个可能变化或者指数增长的不准确的数字结果。

　　2.选择平台

　　要面对的第一件事就是选择一个数据分析平台。这里有几件事要考虑：

　　a.易于集成（SDK库）

　　这一标准是我首要考虑的。我仍然不确定这是否完全正确，但从长远的角度来看这是有问题的。我们应该着重分析那些本地支持的游戏目标平台或者建立一个完整的库。如果是针对多平台，那么这一点就相当重要了。我们不想惊讶于某些平台只支持安卓系统却不支持iOS系统，反之亦然。我开始使用Unity的时候，因为之前有使用Prime31本地插件的经验，所以我选择了Flurry和Localytics。许多分析平台也竭尽全力地做到易于集成，很多都可以通过Unity3D支持（比如Google移动分析就有Unity 3D插件）并且没有要求用到少量的本机代码集成。

　　b.价格

　　定价是一个很棘手的问题。以Localytics为例，它免费提供10000 MAU（月活跃用户）的分析。乍一看感觉似乎很不错，因为MAU一旦超过10000，一般情况下营收都会不错。但在我们的例子中并非如此。Sharp Minds始终免费，在营收超过一定数量后，我们不得不面对Localytics每月200美金的最低定价。尽管从我们的数据上来看，我们的确有接近10000的MAU。

　　无论如何，Localytics看起来非常专业，所以我们并没有因为它的最低定价而取消使用。Flurry和Google是免费的。Google分析向来是业界翘楚，因它可以通过其现有的强大的网络分析平台的自然扩张做到全面的分析。而Flurry并非如此，它并没有这种能力，所以其一直保持免费。

　　c.API功能

　　乍一看的时候，在我看来没有一个平台提供的报表能满足我们的分析需求，所以我决定通过原始数据访问来自己处理这些数据。

　　有趣的事情是，当时Localytics网站的广告上说他们提供原始API访问，但当我询问关于API的使用细节时，他们给我的答复却是“这是机密”。给出这种答案让我们如何选择？难道有人会来窃取我们的API参数？这非常奇怪，并且不可思议，最终我将Localytics从我的选择列表中剔除了。

　　Flurry通过输出文档提供一个比较粗糙的原始数据访问，这样我可以得知如何正确地使用它。Google并没有解决这个问题，我误认为这是一个缺陷，最终选择了Flurry。

　　经验教训：

　　避免访问和处理原始数据如果你能帮到它。你可能会创造奇迹，但是不久之后，有两件事会打破你的如意算盘：

　　a) 原始数据的数据量将会非常庞大。当然，10000MAU以下可能还比较好办，但当我们着眼于一个全球范围的成功游戏时就很棘手了，我们糟糕的代码和免费的云存储不能处理原始数据。Google似乎更胜一筹，它仅仅是处理一些原始数据的样本，但足具代表性，同时还能保持速度与功能。

　　b) 当我们需要添加功能和优化时，代码将会增长，最终整个子项目将会耗费大量的开发时间。

　　d.报表功能/定制

　　Localytics似乎很擅长这方面，同时他们对API保密的很好。Flurry有着像样的内置报告，但其他类型的自定义查询非常有限，过程需要花费大量时间。幸运的是，与此同时，Yahoo收购Flurry之后，添加了一个目前处于Beta测试的功能“Explorer”—一个非常炫酷的实时、特别的分析报告。

　　我瞄了一眼Google那边，这一切似乎有太多的障碍。有大量的我不能理解的关于API的问题，并且分析控制平台上的自定义报告似乎还需要及其复杂的配置。

　　经验教训：

　　抛开Flurry的“Explorer”功能不谈，我认为我选择Google的初衷是基于一个错误的观点。即使有了Flurry的“Explorer”，Google的分析方法和心态似乎任然更胜一筹，。Flurry仍然是一个不错的选择，但是在下一次选择的时候，我依然会首先选择Google Analytics，我依然坚信它将是我的长期选择。

　　除了以上三个我们提到的分析平台之外，还有大量的分析创业公司可供我们选择。对于Unity 3D的用户来说，Unity同样推出了它自己的分析平台。尽管现在看起来仍有些稚嫩，但是我相信它会很快成长起来。

　　3.分析过程

　　目前仍缺少更好的术语来描述，我们将“分析过程”的一系列步骤充分应用到分析游戏的开发生命周期中，使其充分受益。区分这过程中的每一步很重要：将分析工具集成到代码中。虽然它自身无足轻重，但是这一步是要强制性执行的。

　　如果只打算仅做这一步，我强烈建议不要纠结于分析，因为仅仅这样并不会使我们从中受益。还不如将宝贵的开发时间用于别的地方。

　　下面以一款休闲益智游戏”Sharp Minds“为例，探讨一下其中的问题及缺点。

　　a.决定想分析的关键案例游戏（难度：10/100）

　　如果明确查询的数据维度，会更容易建立数据报告模型。然而，事实经常事与愿违。数据报告要体现其专业性。在质问自己(和数据)的时候得出新的想法。最好使用详尽而又一致的报告。报告尽可能多的关于游戏核心机制。

　　不必同时报告多个事件（例如，两个或三个连续事件描述一个逻辑），它们将很难被处理和查询。

　　构造事件，使其尽可能采用相同的参数数据（考虑基类和继承）。使得不同的事件类型更容易查询。

　　关于事件的时间戳、玩家ID、应用版本（尤其重要）以及会话。大多数平台会自动为你提供简单的方法。玩家ID应该采用匿名ID的形式并只允许储存在报告中。可以使用目标平台提供的ID或者创建一个自有账号。

　　b.选择服务供应商并将分析工具集成到代码中（难度：10/100）

　　在上文提到过，在ios和安卓系统上选择了一些分析工具，以及使用Flurry Analytics和Prime31本地插件的例子。有一些可能比较昂贵（50美元），但是Prime31在更新节奏和清晰简洁的分析维度方面表现的确不错。要知道，开发时间是极其宝贵的，我们很有可能要花几个小时甚至数天去处理那些诡异的原代码。如果不能编译或者没时间编译，那就选择一款合适的分析工具。

　　我认为在游戏中创建一个独立平台代码层是很有必要的。游戏知道怎样在代码中集成来进行分析，报告都是隐藏在相应的接口中—供应商（或其他相同的服务提供模式）。这就使一些有用的东西得到了充分的利用。例如, 出于测试目的，可以很容易地编写文本日志,或无需修改事件代码就切换到另一个分析平台。

　　c. 过程分析报告度量以及提取可操作的信息(难度:60/100)

　　对我们来说,在开发周期中这是迄今为止最困难的部分。很多是因为我们选择了自己去处理数据报告中所需要的原始数据的。即使没有自己处理,仍然是过程中最具挑战性的一部分,往往能带来最大的惊喜。

　　现在很有可能你在问自己“他在说什么?所有重要的图表已经可以在平台上看到。“如果你是这么认为的,那么你完全错了。分析平台可以为我们提供基本数据，比如，每日会话、月活跃用户、日活跃用户及各种形式的留存数据。任何深层次的问题都是一个巨大的挑战。在我解释之前,让我先告诉你一个很酷的东西….漏斗

　　harp Minds是一款休闲益智游戏。玩法很简单，一关一关地破解谜题，在每个关卡中赚取1,2,3颗星。漏斗模型可以看做是每个用户试图通过的一系列连续的选取标准(步骤)。漏斗模型的例子是:

　　第一步：玩家在1-9关失败

　　第二步：玩家完成1-9关并获得3星

　　L1-9的意思是第1章中的第9关。我们将用这个方式表示关卡。

　　这个漏斗模型将会检查那些一开始在L1-9关失败的玩家，也会检查那些之后3星通过的玩家。像漏斗一样，筛选处理实际通过的玩家数量及通过的标准。如果过滤出的数据报告中只有那些在关卡L1-9失败的玩家（过滤就足够了，并不需要漏斗模型中的第1个标准），并用于上述的漏斗模型中，我们将会得到一个结果，在L1-9关卡中失败和3星通过的玩家百分比。

　　我们可以利用漏斗模型做一些很酷的东西。比如，如果需要评估关卡1-10之后的用户，可以将漏斗模型定义如下：

　　漏斗模型1：

　　第一步：玩家完成L1-10关并获得1星

　　第二步：玩家对游戏的接受程度

　　漏斗模型2：

　　第一步：玩家完成L1-10关并获得3星

　　第二步：玩家对游戏的接受程度

　　漏斗之间玩家数量的差值将给我们一个明确的信息，通过关卡并获得多少数量的星将影响到玩家对游戏的评估。

　　大多数分析平台都会支持某种形式的漏斗。像往常一样，取决于细节。比如，我们开始进行分析工作之后，Flurry也有一些漏斗模型，但它们不支持自定义参数。所以基本上，所有的关卡完成事件都被视为相同的（我们不能插入一个标准来检查特定关卡 ）。Flurry为不同事件的数量做出限制，使得每个关卡制定不同的事件也变得无法实现。

　　在此期间，Flurry增加了前文提到的Explorer Beta版,将支持参数漏斗模型的各步骤。考虑一个实际的问题:“有多少玩家完成关卡L1-5到 L1-8并且期间没有一次失败 ?”。漏斗模型看起来会像这样:

　　第一步：玩家完成关卡L1-5

　　第二步：玩家没有失败

　　第三步：玩家完成关卡L1-6

　　为此,漏斗必须支持标准的否定。据我所知，Flurry目前并不支持。基于一些初步研究，Google Analytics貌似支持。再考虑一个实际的问题”玩家们在第几关开始流失“或者“玩家离开游戏前最后玩过的关卡前十排名“。

　　这个问题至关重要,因为它会给我们很多具体的信息，关卡是太难或太无聊,导致多数玩家流失。没有关于玩家流失的事件是一个大问题。我不知道如何具体表达这种漏斗模型的标准。即使我可以，仍然有其他各种各样的问题导致玩家流失。我并不想统计那些没有关于玩家最后停留关卡的流失数据。

　　我敢肯定,大多数分析平台不支持这个 查询/漏斗模型 和更多复杂的我们能想到的功能(可能Google Analytics会有，但是我还没来得及彻底研究)。不幸的是,这些分析过程恰恰能给我们带来极大的好处。

　　所有这一切背后的原因是原始数据导入和定制处理。游戏产业内的一些大咖可以基于类似的原因做自己的分析模型。我有一个自定义顺序处理器来计算我们的游戏事件中的所有重要指标。报告迅速、功能强大，但仔细想想，这对独立开发者来说成本太高。

　　d. 基于提取信息实现游戏的更新(难度:20/100)

　　当有一个点对点的分析出现在合适的地方,接下来要做的就是向报告系统提出许多问题,寻找一些看起来比较可疑的数据。这些数据不符合正常或预期的分布。分析可以使我们通过更新纠正很多问题，比如，游戏前十关的玩家流失导致了近40%的玩家流失。这不是一个好消息—在这些关卡中明显存在一些问题。在10个关卡中，其中一个有着极高的流失率。

　　所以我们讨论为什么会这样。导致流失较高的关卡有L1-4、L1-5和L1-6，我们的结论是不可能是难度的问题，因为这些关卡的难度并不是很高。剩下的唯一的结论是,我们的引导很烂,玩家流失,是因为他们不知道如何玩这个游戏。

　　我们也对游戏做出了一些优化，调整了一些关卡在游戏中的难度水平。

　　4.结论

　　不要低估分析的强大作用！

　　如果仅仅只是想追踪会话、日活跃用户和月活跃用户，这基本上所有的分析平台都可以做。如果想做点对点查询并深入挖掘数据, 我们应该仔细选择工具,在确定选择分析平台之前多做研究。

　　认真地对待客户端事件报告，因为良好的事件设计和事件附加数据可以为我们在处理分析报告的时候节省大量的时间。如果想只花几个小时在分析上,我建议完全跳过它,因为这样不会得到任何有价值的东西。不要做自己做数据收集和处理,因为这些工作的代价十分昂贵。

　　希望我们做出的好或坏的决定经验，可以帮助大家更好地分析,不断优化自己的游戏。

科普：移动游戏开发者做好ASO的7个步骤

责任编辑：黑色幽默