最近半年一直跟进版本简报的事情，想写些东西记录游戏版本简报的过程和感受。
公司游戏的版本更替是每周一次，半年前开始，我所跟进的游戏版本改动内容增加不少。很多内容更新程度超过我们的想象，而产品也迫切想从数据方面得到支持，判断版本改动的影响与好坏，而不至于盲目修改。于是与产品沟通后，我们开始做游戏版本简报的需求。
首先，我们需要提前了解版本改动的内容。因此，阅读产品的开发日志和更新公告成了我们日常工作的一部分。通过这些文档，了解哪些游戏内容做了改动，哪些修改可以得到数据验证（例如玩法可以得到参与和完成的数据对比），哪些修改无法验证（例如一般没有游戏界面的日志，游戏界面做了修改，我们也无法有数据支持）。然后对需要进行数据检验的内容进行排序，方便下一步的游戏日志处理。这个过程，与策划的沟通以及熟悉游戏是不可缺少的。例如新的玩法推出，策划最熟悉结构，可以提前告诉我们很多不知道的事情，避免信息不对称造成的误差。熟悉游戏，可以举一反三，找出关联的系统，例如减少某项道具的投放，可能引起对应玩法的参与率下降。如果不熟悉游戏，只统计道具前后的投放数量，信息量就不够多和完整。
接下来，就需要到了数据处理的方面。一些内容，可以有直接的数据进行计算；一些内容，没有直接的数据，却可以通过其他线索进行换算。这过程有两点需要注意的地方。1）如果一些版本改动内容很重要，却没有相关日志记录，就需要跟程序提需求记录log。2）版本简报不同于日常的数据监控。日常的数据监控指标很少变化，代码可以很固定和优化。而版本简报由于每周的版本改动不同，相应的数据指标计算也经常变化，所以保持代码的灵活性比较重要。
最后，整理计算后的数据指标，做成简单的excel报告，给出一些分析结论和建议，并且与产品沟通讨论这些结论和建议。注意的是，与产品讨论结论和建议不可缺少。一方面，产品对版本改动可能有另外的考虑。例如某项玩法的参与率持续下降，我们可能得出坏的结论，但策划确认为这是他们合理接受的范围，因为他们想玩家逐渐淡忘这个旧玩法，更多去参与新的内容。另一方面，与产品的持续沟通。可以更深入了解和挖掘产品的需求，保证我们不断把游戏版本简报做得更好。
半年下来，产品的反馈不错。有时候，刚刚外放版本，就问我们数据表现如何了，但这时候外服的数据还没有搜集够呢:)。当然凡事有利也有弊，完成一份数据简报大概需要消耗1~2人天的时间，会导致其它一些事情无法完成。因此，一些版本内容，可以在数据平台上直接查阅相关指标的，我们都尽量让策划产品动手去获取，提高大家的效率。