刚刚毕业时，以为公司存储的数据log跟大学接触到的差距很小，都是标准的记录与字段，只需做些简单处理，就可以做些分析、挖掘等工作。但实际工作中面对的数据log是各式各样的，个人分类如下：
不同游戏的底层技术不一样，另外不同程序员的编码习惯也不尽相同。部分游戏是文本日志log，部分游戏则是数据库。以玩家参与任务为例子，文本格式存储的记录可能为[2012-01-01 23:45:45] task_id=师门任务 type=完成 used_time=120；而数据库/表格的字段格式则可能为 time, task_id, type, used_time，一条具体的记录为 2012-01-01 23:45:45，10001(10001代表师门任务），2(type=2代表完成），120。显然易见，不同格式的数据记录，需要写不同的脚本提取相应字段，才能完成基本的数据抽取工作。例如文本日志log就经常利用正则表达式匹配，抽取相应字段。
就算是采取相同技术的游戏数据，格式也会有很大有差异。归根到底，是由程序员实现相关数据存储功能的。一些童鞋喜欢把所有文本log存储在一个日志文件；一些童鞋则把不同的数据存储在不同的日志文件，例如针对主线任务和每日循环任务的微小差异，程序员童鞋可能会存放在不同的日志文件或者数据表。因此对于做底层数据处理的同学，很多时间和精力得花在处理这些差异上。
真实情况中更特别的是，一些游戏记录了任务的接受和完成记录，因此可以方便计算任务的完成率；但一些游戏却只记录了任务的完成记录，就无法计算任务的完成率了。面对不同的游戏，由于底层数据所限，能够计算的数据指标是不同的。不同游戏间一些指标的横向对比，有时候做不了，换句话说根本没有可比性。
对于已经成熟运营的游戏，这个问题不算太严重。但是对于开发期或者测试期的游戏，数据log变化是家常便饭。或者为了性能考虑，对大的的数据日志或者数据表进行拆分；或者开发到了一段时间，有几个数据log是非常相似的，程序员为了接口考虑，把这几个游戏数据log合并成一个数据日志。对于数据处理人员，也要相应不断调整这些数据抽取脚本。站在数据处理的角度看，我们是希望数据格式不要变化那么频繁的，因为消耗时间在数据抽取脚本的抽取上，就没有富于的人力时间做分析等工作。但程序员童鞋也是从保证游戏服务器稳定运行为看待问题，所以大家要相互了解。
对于例行的数据log，有的程序员为了性能考虑，不希望每天导数据，而是希望在每周停机维护的时间才将相应的数据log同步给我们，这样例行的数据分析，有时候需要等上一周的时间。例如每周三停机维护，但到了周五，策划想看下周四的数据，我们只能在下个周三停机维护时，才能拿到相应数据，然后做处理分析。很多时候，大家看数据的热情或者时间已经没有了，因此还有其它事情要做。当然，现在部分游戏是可以做到每天导一次数据的，这样保证了数据的及时性。
游戏就是一个小世界，跟真实世界一样，世界变化总是太快。因此总会存在一些临时性的数据需求。例如对于春节、中秋等节日，策划会设定一些特定的玩法活动，会有相应的数据分析需求。但这些玩法仅会在节假日出现，只能存储几天的数据。如果没有在节日活动前实现对应的数据存储，就没有数据供给分析了。一般情况，MMORPG每周都会有停机维护时间，进行相会的服务端和客户端更新。因此需要在这个维护时间前，需要程序能把打数据log的功能实现并且外放（一般做数据的都希望程序这段时间开发任务不要繁忙，否则根据优先级，打数据log可能要延后了），这个时间点需要密切关注策划和程序员童鞋。此外收集这些数据log也要一段时间周期，才能获取足够的数据量做分析。从提出定量数据分析需求，到实现数据存储功能，到获取游戏数据做完分析，很多时候都要经历至少半个月的时间。