Engagement Index-4：数据准备和参数创建

作者： 晋秋 | 归档：网站分析（web analytics）

题记：

• A-你为什么想做这个手机应用呢？
• B-因为我觉得这个手机应用是个很好的，很创新的主意
• A-那它和你的业务有什么关系呢？是你的业务需要它呢，还是你在想用它往你的业务上靠？
• B-。。。。这确实是个很好的主意

快捷方式：1-2-3

直奔主题，

这个图概括了这篇博客要讲的主要的内容，数据清理，数据有效性的验证和各种视图的创建。（我知道如果没有相关的数据分析经验，并且对网站分析没有较好的认识的话，这些东西都是非常晦涩难懂，不知所云的；我想深入浅出的介绍，可惜我能力有限；所以如果真是这样的话，硬着头皮读下去也没有任何益处，反而不如把时间有效的利用在其他方面，比如读一些介绍网站分析的基础文章。）

1. 数据清理

在现实世界中，原始数据一般都因为种种原因充满了各种各样的噪音和污染，所以数据清理是做数据分析的一个必须的步骤。

技术意义上的数据清理，比如所谓的分析数据长度和类型，大家肯定不感兴趣，这里主要举例介绍在网站分析的需求上所做的数据清理工作：

1. 清除重要数据缺失/不符合规范的记录，比如，如果Visitor ID或者Session ID缺失/不符合规范的话，需要清除所有相关记录。在这一点上，我们一共清除了大约3万条记录。
2. 清除一些纯粹的没有实际意义的tracker element。这个是和特定的工具相连的，比如在Insight中，一些专门用来记录重要事件的image tracker(1×1px 的gif文件)在数据提取的时候被放到了原数据中，这个没有实际意义的记录对我们的分析机会没有帮助，所以我们也是要清除的。在这一点上，我们一共清除了3千条左右的记录。
3. 清除technical elements。这是一个Insight特有的概念（我个人的理解）。在使用Insight进行数据收集的时候，因为Insight是分析所有的URL中的“query”的，有些时候我们需要人为的加入一个“实体”来收集必要的信息。比如说，在一个flash网站中，在html部分刚刚开始load的时候，我们要从服务器上请求一个.jsp的空文件，然后把所有的诸如OS，browser，Datatime，Javascript version, Campaign Code等信息附加到这个文件上发送给服务器。这不是一个真正的页面，但是在我们提取的数据中含有这样的数据记录，所以也需要清除。在这一点上，我们清除了500万条记录。
4. 清除type=container的记录。这是我们所分析的网站所特有的。在网站收集数据的时候，每一条数据都给出了一个type的变量，来表示这条记录的类型。其中最常见的就是type=page或者type=click，这是有实在意义的记录，是我们分析所需要的；其他的还有type=line-item，这样的记录代表购买的产品，当然也非常重要；还有一种type=container的记录，它代表的含义是包含flash网站的flash框架被成功下载。这一条在我们本次的分析中也没有意义，所以我们为此清除了49万条记录。
5. 清除异常数据：这些往往在第一次数据清理中无法看出来，而是在后期做第一次数据检验的时候才能发现的。比如说在我们的数据中，发现了一些同样的记录重复200-500遍甚至更多的情况，并且两条记录之间相差时间为零。我们无法知道其中的原因，但是如果把每条记录都算作一个PV或者Click的话，那无疑会影响结果的准确性，所以这些数据我们最终的做法是只保留第一条记录，清除后面所有的大约总共近百万条记录（具体数字我记不清楚了）另外还有一些异常数据需要排除的，比如同一个session中时间间隔超过2小时的，PV/Session超过300页的等等。
6. 整理乱码：在原始数据中，在搜索关键字栏中，所有的中文/日文/韩文都无法正常显示，这一点我们做过各种尝试，但是无法解决问题；如果要求对方重新提供数据的话，在时间上来不及，所以我们只能忍受这方面数据的丢失，然后通过一定的手段把其中的和品牌相关的英文字符提取出来。
7. 整理异常数据：并不是所有出现异常的数据都要删除的，我们通常首先会整理异常数据，尝试解决相关问题。比如在同一个Visitor ID下面，在截然不同的访问日期下面竟然出现了相同的session number。最终经过各种比较和分析，我们确认这是不同的session，所以最终我们把date+session number组合作为新的session number。

最后，经过数据处理，这时候我们便有了一份干净的数据源，下一步，我们要确定这些数据和网站整体数据是否一致。这主要是从网站分析的角度考虑，检验在数据提取的过程中，是否遵循了“随机提取”的原则。

2. 数据的有效性验证

在这个项目中，我们采取相对简单的方法粗略的做了数据的有效性的检验，而没有做严格的统计学检验。具体做法是从Insight中调出Visits/month，Visitors/month, visits/visitor, pv/month, number of sales/month, visits/country等报告，然后从数据样本中也作出相同的报告，最后比较网站整体和数据样本的趋势图，得出样本数据可以代表总体的结论。这是我们在数据采集足够多的情况下所使用的方法，如果数据量小的话，做严格的统计检验还是有必要的。

3. 创建数据栈

原始数据的每条记录代表一个Page View，这里包含最全面的信息，但是不够概括；所以我们要把数据向上卷起(roll up)。这里我们主要创建三个视图：

1. 页面视图：也就是最原始的数据，每一条记录代表一个Page View，作为主要维度，其他的信息都是作为这个维度的属性值出现；在页面视图中包含内容组(Content Group)的信息，每一页分属5个不同层次的CG（从CG1-CG5）。
2. 访问视图： 在页面视图的基础上进行第一次向上卷起；之后每一条记录代表一次访问。数据向上卷起的过程是一个综合的过程，在这个过程中伴随着数据的丢失。在这里我们可以通过数据的转置，创建新的参数等方法来尽量减少数据的损失。在访问视图中要注意保留电子商务和营销活动信息。
3. 访问者视图：在访问视图的基础上进行第二次向上卷起；之后每一条记录代表一个访问者。

综合信息而又要尽量减少数据的损失是roll up过程中的一个挑战。哪些信息可以综合，哪些信息在以后会用到，哪些信息可以放心的删除等等，这些都是需要回答的问题。比如我们在把页面视图向上卷起到访问视图的时候，average time spent in page这个参数是不可能保留的，因为如果保留它的话，就意味着要保留每个页面；而如果要保留每一个页面，也就意味着要在一个visit上面平均多加入大约40个参数（PV/Visit~=40），这还仅仅是保留前40个访问的页面；所以，最终，对于一个visit来说，我们可以保留landing page，exiting page，time spent on landing page，time spent on exiting page, pv/visit, time spent/visit, visit product sheet(oui or no), visit product sheet in N-th page view等等诸如此类的重要信息。而具体的页面，页面访问的顺序，路径等信息都在向上卷起的过程中被精简掉了。

下篇预告：Engagement Index-5：副产品：高级参数列表

后记：一晃又是一个月了，这才更新一篇，实在是抱歉。

Engagement Index-4：数据准备和参数创建5.5102

收藏、分享这篇文章!

--