获取正确的数据
数据采集只能告诉你，什么时候一个事件被触发了。例如有多少人进入一个场景。一个能被记录在客户端或服务器端的事件是个非常有用的行为。通常它具有与它相关的一些参数，比如哪一个玩家，游戏的会话是什么，什么日期或时间，他们有多少体力，多少分，什么场景，哪一个刷怪点。
也有一系列的数据点我们不需要采集,如场景的布局,因为它并没有改变或者从其他数据可以推断出来。但是什么事件是需要采集的呢?这将取决于许多因素。你们在服务器、存储、带宽和数据分析软件上有多少预算?什么级别的细节才是真的有用的?当一个动作发生时候要记录每一个脚步还是只需要XYZ的位置就足够了?
对于我来说，有一种技术叫危害分析和关键控制点(HACCP)，它能帮助我有效的分析出我需要采集的数据类型。它是一项由Pilsbury研发的食品安全的技术(这是我在第一份工作中用于食品行业的软件)，用于美国航天局和美国陆军实验室为阿波罗登月计划提供食物。这是一个对可能会造成危险的关键点进行测试的模型。
第一步是了解潜在危险以及如何避免。对于游戏(尤其是服务)我们想知道玩家玩到什么地方离开了游戏。所以我们必须得知道哪个地方可能让玩家放弃或者变得沮丧以及采取什么行动能让玩家继续回来玩。
通过第一次用户体验可以帮助我们了解其中的一些点。用事件描述这个过程,所以当我们发现玩家离开了游戏,一段时间之后又回来了，这是一个好的开始。但也许我们需要在他们离开之前就知道更多的关于他们所经历的情况。
我们正在识别的这些事件是我们的关键控制点，第二步我们就要识别它们。游戏中存在的问题，尤其是对于客户端/服务器应用程序，在这里你可以得到最好的数据，特别是如果你想要你的游戏可玩离线。问题是，你通常不能得到一个“结束”事件。当我们为PlayStation Home(街机) 做数据采集的时候这是一个不得不解决的问题。
如果一个玩家按下了手柄上的PS按钮，他们离开了游戏，再也没有数据发送到服务器。我们只知道他们离开是因为服务器断开连接而无法知道这是自愿的还是外部的问题。因此你必须得清楚你能收集和获取什么数据。比如，为了解决我们在PSHome这个游戏中遇到的这个问题，我们可以在本地存储历史数据，当玩家再次上线后 再把缓存的数据发送给服务器。
玩家“第一次”的经历是重要的分析点，确保你采集这种数据，开始和结束你游戏的每一级(每个场景)，以及关键动作。比如和一个物体交互、战斗、伤害等等。这些停止可以告诉你发生了什么事。
理解玩家行为
第三步是确定每个关键节点的阙值，要做到这点，我们先要确定怎样才算是正常的行为。不能像求平均一样找出其均值，因为不同的玩家群体可能有各自的“正常行为”。找到极限值的工作对于评估玩家行为的变化具有重要意义，在游戏中，未来也要根据玩家真实的行为修正这些值。评估什么是正常有许多事情需要考虑，比如某项统计的.意义，行为的相关性和因果关系，这也正是分析师的价值所在。
第四步是建立监测模型，我们需要定义事件，参数，数据库表和指标说明，以便我们搞清楚分析报告在讲什么。报表展示方式也很重要，例如，漏斗对于分析每个阶段的流失百分比非常直观。还有就是一些常用的业务数据，比如ARPU，ARPDAU，K系数，当然，对我来说，各阶段的流失比也是相当有用的。
我一直认为比较时应该采用生命周期，或者是游戏里的实际天数，而不是自然天数。也可以尝试使用一些更复杂比如聚类分析，A/B测试，好吧，要说清这个就需要另写一篇文章了。
第五步是建立纠错程序，你需要在发布之前迅速的解决数据反映的问题，越快越好。要尽可能避免打断这个过程，除非你遇到一些真正需要停下来思考的问题，是否真正的理解了这些数据，然后拿出一个好方案。
很容易认为问题出在那些数据不好的节点，但往往问题在更早的地方，且不是那些玩家强烈抱怨的地方。不仅仅要找出那些负面的数据，也需要找出积极的数据。玩家有把他们的成就和游戏视频分享到网络吗?审查所有的相关点有助于我们发现真正的问题。我们的工作就是尽可能的理解他们，并确定如何突出正面影响，排除负面影响。
步骤六和七是关于审查过程本身，并确保我们分别有一个记录保存流程。这些都是重要的，因为我们必须确保我们从创建我们的数据采集过程中学习，我们通过它识别有关玩家与我们的游戏的交互方式是什么，这些对于我们长远未来是至关重要的东西。特别是如果我们想避免重复犯错误。
数据采集必须要回答设计的问题才具有价值，只是简单的看报表只会带领我们走上错误的道路，并削弱我们的游戏的生命周期价值。游戏就是娱乐，就是与玩家的对话，作为一个设计师，你需要了解你的玩家想要什么，否则，你能怎么做呢?
1.
2.
3.
4.
5.
6.
7.
8.