对游戏进行分析以及获取各种指标，以此来为数据驱动做各种决定，这将对游戏的成功造成很大影响。尽管这样的分析并不意味着应当干涉每一个开发决策或者商业决策，但它仍然是对游戏将要如何进行下去十分必要。

虚幻引擎 4 提供了一套优秀的方法来帮你获取玩家数据，既有实现在蓝图中的，也有实现在 C++ 中的，同时正确的设置它们也无需花费太多时间。这里就有充足的文档，Joe 早先也发过一个关于 Apsalar 和 Flurry 在移动平台上相关的帖子。为其他软件实现功能或者自己来搞这么一套也不会太复杂，只要你自己精于编码就行了，或者找个精于编码的人。

这篇客座博文，会来聊一下在设置过程中你可能会忽略的要点，以及其他的贴士和技巧，这些都是我先前逐渐意识到的问题，并且发现它们对你成为分析大师的道路上将会非常有帮助。

从头开始，并再次检查设置

对有些软件来说，比如 Apsalar 而非 Flurry，并不提供实时的分析，通常它需要一天的数据指标才能显示在面板上。所以，小心的多次检查每个设置都已经正确是值得的，避免很多抓耳挠腮的情况。

需要注意的是：尽管 Apsalar 不支持实时的分析，但仍然可以通过 Event Tracking Console 来测试它是否工作。从 App Store 中下载一个名为 “The Identifiers” 的应用以便获取 IDFA 编号。

在各个相关的网页上完成注册后，再次检查在 DefaultEngine.ini 文件中的 API 和密钥是否正确。如果这个信息错误的话，即使其它设置都正确，游戏数据也不会被收集！同时请确保 start session 和 end session 都已经做了，因为有些软件只有在 session 结束的时候才会上传分析数据，并且如果 session 结束过早的话也可能有问题（但并不总是有问题）。

如果你选择蓝图这条路，已经有超过 20 个蓝图节点供你使用，来处理最基础的事件，甚至复杂的如玩家的人工统计学信息。如果你没看到这些功能的话，再次检查在编辑器中是否已经激活了相应的软件插件功能。

最后，一个常见的错误是不将游戏部署到移动设备上就测试数据。大部分移动设备的分析软件都仅在 iOS/Android 的设备上才会工作。

成为分析大师 – 多路，贴士及技巧

有时候，选择使用哪个分析软件工具是个困难的事情。它们在各自的领域都有强项，虚幻引擎 4 有个很酷的功能是可以使用一个多路的工具来将游戏事件发送给多个软件工具。这意味着鱼与熊掌能够兼得。我个人认为 Apsalar 在处理事件跟踪上比较优秀，而 Flurry 对用户留存数据则分析的更好。多路工具非常有用，并且容易设置，这里可以看到它的文档。

如果是通过 C++ 来实现分析功能，为了让编码生活更具可读性并轻松愉快，有这样几件事情可以做。首先，获取分析软件工具的引用总是一个好的开始，使用三元操作符这样能避免大量不受控制的语句。

用数据收集的术语说，其实可以利用组来 “LOD” 分析过程。这个意思是一旦获取了所需数据，就可以关掉一组组的相关事件。不要去记录每一个事件是重要的（虽然我们都尽可能的去记录），原因是这样做的最终结果是得到了很多有趣的数据，然而就没有然后了。

Jeo Graf 建议过，“如果无法通过调整游戏结构来让一个事件更加简单直接的话，那么这样的记录也许是不值得记录的，除非这种事件存在是为了更为长期的研发需求。”在考虑该记录哪些数据时，记住这句话，它会给你带来回报。

当我在为最近的一个虚幻引擎的移动平台项目 Smog Game 做决定要记录哪些信息时候，我们发现最佳的方式是先做一些假设，再使用结果收集来的数据来证明或证伪这些假设。比如，在 Smog Game 中可以获得两种强化道具，一个是双倍得分，另一个是时间减缓。

在发售前，我们预期这两种强化道具的数据是 50:50 对半开。然而意料之外的是数据显示玩家让时间减缓这个强化道具自动消失是双倍得分的两倍！通过和其他数据的结合，我们得到的结论是玩家们认为在游戏早期时间减缓的作用并没有什么用处。

如果我们没有使用这样的游戏分析方式，我们就有可能在完全错误的假设下更新游戏机制，并得到更负面的用户体验的后果。

我们还发现使用 “funnels” 来跟踪用户界面行为不错，这是一个使用一系列事件得到可视化的方式来测量玩家行为，并且将测试帐号和开发账号做独立区分也能保证测试结果不会干扰真实数据（由于数据并不能删除）也是一个很有用的做法。这些应该能为虚幻数据分析大师的起步给了足够的内容了。