作者归档：joegh

怎样合理地定义用户流失

　　很久没有更新博客了，这篇再写一些关于“用户流失”的内容。之前发布的网站的活跃用户与流失用户这篇文章对网站的活跃用户、流失用户及新用户流失做了定义，这里修正下对流失用户的英文叫法，一般对流失用户常用的英文为“churn user”，之前用的wastage、away、lost等都不是太规范。后来陆续有做相关分析的朋友问到流失用户的流失时间长度到底选择多长是合理的，尤其是《网站分析实战》这本书出版之后，我在里面有提到如何更准确地定义流失的时间长度，可能解释的比较简单，还是有朋友留言反馈这方面的问题，所以这里再用一篇文章解释一下。

流失用户与回访用户

　　流失用户的定义请参考“网站的活跃用户与流失用户”这篇文章，要解释怎么样合理地去定义用户流失时间段长度的问题，需要先介绍一个新的指标概念：回访用户。这里的回访用户不是指Google Analytics上面的Returning Visitor（与新用户相对，指之前访问过网站的用户再次访问网站），这里的回访用户指流失之后再次访问网站的用户，即用户曾经流失过，满足流失时间期限内完全没有访问/登录网站的条件，但之后重新访问/登录网站。然后，根据回访用户数可以计算得到用户回访率，即：

　　用户回访率 = 回访用户数 ÷ 流失用户数 × 100%

　　回访用户率的数值大小间接地可以验证对用户流失定义的合理性。正常情况下，用户的回访率应该是比较低的，从业务的角度考虑，如果对流失的定义是合理的，那么很难让那些对你的网站已经失去兴趣的用户重新来访问你的网站。一般情况下，网站的用户回访率应该在10%以下，在5%左右的数值是比较合理的，对于成熟的网站而言用户回访率会稍高，而新兴的网站的用户回访率通常更低，尤其像手机APP这类用户易流失的产品。

流失期限与用户回访率

　　用户流失的流失期限的长度与用户的回访率成反比，我们在定义用户流失时使用的连续不访问/登录网站的期限越长，这批流失用户之后回访网站的概率就会越低，并且随着定义的流失期限的增大，用户回访率一定是递减的，并逐渐趋近于0。那么如果选择合适的流失期间长度？我们可以设定不同的流失期限长度，进一步统计每个流失期限的用户回访率，并观察用户回访率随定义的流失期限增大时的收敛速度。如果以“周”为单位设定流失期限：

　　根据设定的不同流失周期的用户回访率的变化曲线，我们可以使用拐点理论（Elbow Method）选择最合适的流失周期。

　　拐点理论：X轴上数值的增加会带来Y轴数值大幅增益（减益），直到超过某个点之后，当X增加时Y的数据增益（减益）大幅下降，即经济学里面的边际收益的大幅减少，那个点就是图表中的“拐点”。比如上图中流失周期增加到5周的时候，用户回访率的缩减速度明显下降，所以这里的5周就是拐点，我们可以用5周作为定义用户流失的期限，即一个之前访问/登录过的用户，如果之后连续5周都没有访问/登录，则定义该用户流失。

　　所以，有个这个办法之后，就能更加合理地定义流失用户的统计逻辑，而之前要做的就是选择不同的流失期限分别计算用户的回访率，然后用统计的到的数值生成如上的一张带平滑线的散点图，问题就迎刃而解。

网站数据分析的一些问题3

7 条回复

　　之前的文章——网站数据分析的一些问题2中主要整理了BI相关的问题，这篇文章主要想整理一些数据仓库相关的问题。因为最近重新在看一些数据仓库的资料和书籍，想把之前以及当前遇到的主要问题提出来（博客中有关数据仓库的相关内容请参阅网站数据仓库这个目录），同时自己也对数据仓库方面的知识进行下重新的整理和认识，而且很久没有在博客发新的文章了，不能让自己过于懒散了。

　　之前看过Inmon的《构建数据仓库》和《DW 2.0》，而另外一位数据仓库大师Kimball的《数据仓库生命周期工具箱》一直没有时间阅读，最近才有时间看完了大部分，就迫不及待想写点东西了。其实数据仓库领域普遍认为Inmon和Kimball的理论是对立的，两者在构建数据仓库上方向性的差异一直争论不休，谁也无法说服谁到底哪种方法更好。我的Evernote的笔记里面不知什么时候从哪里摘录过来了对两者观点的概括性描述，非常简洁明了而一针见血：

　　Inmon vs Kimball
　　Kimball – Let everybody build what they want when they want it, we’ll integrate it all when and if we need to. (BOTTOM-UP APPROACH)

　　Pros: fast to build, quick ROI, nimble

　　Cons: harder to maintain as an enterprise resource, often redundant, often difficult to integrate data marts

　　Inmon – Don’t do anything until you’ve designed everything. (TOP-DOWN APPROACH)

　　Pros: easy to maitain, tightly integrated

　　Cons: takes way too long to deliver first projects, rigid

　　其实看了《数据仓库生命周期工具箱》之后，发现两者的观点没有那么大的本质性差异，可能随着数据仓库的不断发展，两者在整体的架构上慢慢趋同。基本上，构建统一的企业级数据仓库的方向是一致的，而Inmon偏向于从底层的数据集成出发，而Kimball则趋向于从上层的需求角度出发，这可能跟两者从事的项目和所处的位置有关。

　　有了上面这段高质量的概括，第一个问题——你更偏向于以何种方式搭建数据仓库（BOTTOM-UP or TOP-DOWN），分别有什么优劣势？——其实就不用问了，所以下面主要提几个在实际中可能经常遇到或者需要想清楚的问题：

Q1、数据仓库的技术解决方案有哪些，这些解决方案的优势在哪，瓶颈在哪？

　　随着数据仓库的不断发展和成熟，“大数据”概念的风靡，有越来越多的相关产品出来，最常见的技术解决方案包括hadoop和hive，oracle，mysql的infobright，greenplum及nosql，或者多个结合使用。

　　其实归纳起来就两类：一是用传统RDBMS为主导的数据库管理数据，oracle、mysql等都是基于传统的关系型数据库，优势就是有更严谨的数据结构，关系型数据库对数据的管理更加规范，数据处理过程中可能出现的非人为误差极小，而且标准的SQL接口使数据获取的成本较低，数据的查询和获取更加灵活和高效；但劣势也很明显，对海量数据的处理和存储的能力不足，当数据量达到一定程度的时候就会出现明显的瓶颈。而是基于文本的分布式处理引擎，hadoop、greenplum和nosql都是基于文本数据的处理和存储，优势是强大的数据处理能力，分布式的架构支持并行计算，并且具备超强的扩展延伸能力；劣势就是上层接口不方便，因此Hadoop上层的hive和greenplum上层的postgreSQL都是为了解决数据接口的问题，并且数据的查询和获取很难做到实时响应，灵活性不足。

Q2、数据仓库是否就应该保存聚合数据，细节数据不应该放入数据仓库？

　　其实这个问题基本已经达成共识，如果是构建企业级的数据仓库，那么对细节数据的集成和存储是必不可少的，但现实中还是存在很多直接从外部数据源计算聚合之后导入数据仓库的实例。如果对数据仓库只是轻量级的应用，仅存放聚合数据也无可厚非，毕竟没人规定数据仓库一定要是怎么样的，最终的目的无非就是满足对数据的支持和需求。

　　但对于企业的长期发展来看，数据仓库中存放细节数据有两方面的好处：一方面从技术层面，数据仓库存储细节数据可以释放前台数据库的查询压力，同时对于文本类数据和外部文档类数据入库之后管理更加规范，数据仓库保留历史和不可变更的特性可以让信息不被丢失；另一方面就是从数据的使用上，数据仓库让数据的获取和使用更加简便，集成细节数据让大量的文本型数据可查询，可关联，而面向主题的设计让数据的展现和分析更有方向性和目的性，而且细节数据是支持数据分析和数据挖掘应用所必不可少的。所以，如果数据仓库要不断地催生出更大的价值，细节数据的存储是必不可少的。

Q3、你会把数据仓库分为几层，每层的数据作用是什么？

　　没有标准答案，根据数据仓库中数据的复杂性和对数据使用的需求程度，数据仓库可以有不用的层级划分。

　　我一般会把数据仓库划成三层：最底层的细节数据，管理策略是优化存储，一般存储导入的原始数据，便于进行向上的统计汇总，因为数据量较大所以需要优化存储；中间层是多维模型，管理策略是优化结构和查询，面向主题的多维模型的设计，需要满足OLAP和数据查询的多样需求，同时保证查询的便捷性，关键在与维表的设计和维度的选择及组合，事实表需要关注存储和索引的优化；最上层是展现数据，管理策略是优化效率，一般会存放每天需要展现的汇总报表，或者根据多维模型拼装的视图，展现层的数据需要以最快的速度展现出来，一般用于BI平台的Dashboard和报表。

Q4、数据仓库搭建中最繁杂的事情是什么，最容易缺失的是哪一块？

　　一直觉得数据仓库的核心不在于数据集成，当然数据集成是数据仓库实现价值的前提，数据仓库真正的价值体现在数据的有效应用，数据源于业务反作用于业务。而搭建数据仓库的核心在于数据仓库的架构和数据模型的设计，怎么权衡数据的存储和数据获取效率之间的矛盾是数据仓库管理上的难点，这个难点任何数据仓库都会存在，而大数据增大了这种权衡中的难度。而数据的集成和数据质量控制是数据仓库搭建中最繁杂的事情，尤其是数据清洗的过程，我之前也写过几篇数据质量控制的文章，但现实中这个过程还要复杂得多，而且为了上层数据产出的准确性和有效性，这项工作又不得不做，而且要做得尽量细致。

　　搭建数据仓库中最容易缺失的就是对元数据的管理，很少有数据仓库团队具备完整的元数据，当然搭建数据仓库的工程师本身就是活的元数据，但无论是为了用数据的人还是数据仓库自身的团队着想，元数据都不可或缺。一方面元数据为数据需求方提供了完整的数据仓库使用文档，帮助他们能自主地快速获取数据，另一方面数据仓库团队成员可以从日常的数据解释中解脱出来，无论是对后期的不断迭代更新和维护还是培训新的员工，都非常有好处，元数据可以让数据仓库的应用和维护更加高效。

　　写在最后：以上仅代表个人观点，欢迎大家踊跃拍砖，更加希望高手们能在评论中给出宝贵的答案，任何角度的观点和讨论都可以，集思广益。

大数定律与抽样陷阱

6 条回复

　　前面一篇文章——难以解释的数据异常——发出来之后，朋友推荐我去读《黑天鹅》，刚刚翻完这本书，发现书中的很多观点和细节的表述都能给人启发，尤其是“叙述谬论”和“过度解释”这个两点能对难以解释的数据异常这篇文章中描述的内容给出另一个侧面的解释。从作者塔勒布的后记和书中表述的观点来看，读过这本书的人可能很容易走入两种认识的极端：

　　1、既然一些未知的黑天鹅事件可能对我们造成极大的影响，那我们就应该去努力预测这些未知事件，以便做好充分的准备来应对这些事件。但作者在书中明确说了黑天鹅事件的不可预测性；
　　2、既然我们无法预测未知，并且未知事件可能对我们的生活造成翻天覆地的影响，我们只能不去做任何的预测和准备，等待命运的审判。但书的副标题是“如何应对不可预知的未来”，所以作者塔勒布并不认为我们什么都做不了，至少能够认识到黑天鹅的存在，打破传统思维的局限性，谨慎地预防，黑天鹅是未知的未知，我们需要为已知的世界和已知的未知做好准备。

　　《黑天鹅》中多次提到大数定律可能会愚弄我们，作为数理统计和概率论中两个经典的理论（中心极限定理和大数定律）之一，为什么遇到黑天鹅事件时就会失效？或者说大数定律在遇到任何的小概率事件时都有可能“失效”，需要谨慎地认识，以防掉入应用中的陷阱。

大数定律

　　大数定律（Law of Large Numbers），指在随机试验中，每次出现的结果不同，但是大量重复试验出现的结果的平均值却几乎总是接近于某个确定的值。典型的例子就是抛硬币的伯努利试验，当抛硬币的次数足够多的时候，正反面出现的概率都接近于1/2。

　　常用的大数定律有伯努利大数定律和辛钦大数定律。其中伯努利大数定律指在n次独立试验中，事件A发生的频率为p，当n足够大时，p无限接近事件A真实的发生概率，即频率的稳定性；辛钦大数定律指若n个独立同分布的随机变量存在数学期望，则当n越大时，其算法平均数越接近于这些随机变量的真实数学期望值，即均值的稳定性。

　　大数定律为统计推断提供了充分的理论依据，我们可以通过抽样的方法用样本统计量的特征去估计总体的特征，而不需要去研究整个总体。当样本的数量越大时，其对总体的估计就越接近总体的真实特征。但在面对小概率事件时，大数定律对总体的估计会显得无能为力，很多时候结论是失效的。

小概率事件

　　假设我们进行重复10000次的伯努利试验，事件A、B、C发生的次数均满足二项分布X~B(n, p)，n代表试验次数，p代表事件发生的概率。其中事件A发生的概率为10%、事件B发生的概率为1%、事件C发生的概率为0.1%。我们知道，满足二项分布的随机变量的均值是np，方差为np(1-p)，于是就可以用变异系数CV（具体内容参见衡量数据的离散程度这篇文章）来衡量这3个事件发生次数的变异性或者波动情况，可以得到如下的结果：

事件	试验次数	发生概率	均值	方差	变异系数
A	10000	10%	1000	900	3.00%
B	10000	1%	100	99	9.95%
C	10000	0.1%	10	9.99	31.60%

　　从上表中可以看出，当试验的次数保持恒定时，事件发生的概率越低，则事件发生的次数会存在越大的波动性或者波动幅度，如果我们继续降低事件发生概率，比如事件D发生概率为0.01%，也就是10000次试验中发生的期望次数是1次，那么事件D的CV就高达99.99%，完全无法预判其是否发生。所以在相同的条件下，小概率事件一定比普遍发生的事件存在更大的变数，概率越小波动的幅度就越大。

抽样误差

　　随着网站数据量的不断增大，数据的处理和统计需要更高的成本，于是有些分析就会借助抽样的方法来处理数据，Google Analytics的免费版当数据量达到上限时就会采用抽样的方式显示结果报表。其实很多时候我们都在使用抽样的方法分析数据，我们可能会用最近7天的数据来评估近段时间的流量变化、转化情况等，但7天并不能完全代表近段时间，其实做的也是一种抽样。下面来看看现实的网站数据分析的例子：

　　转化率（Conversion Rate）是网站分析中非常重要的一个指标，很多公司会把转化率当做运营产品部门的KPI，但对于很多网站而言，转化率并不大，一般不会超过10%（根据网站业务特征的差异和对目标转化的定义不同，转化率在不同网站间没有一个恒定的标准，也不具备可比性），如果网站的内容质量不高或者用户体验不好，转化率也很可能低于1%。这个时候如果用抽样的方法来预估网站整体的转化情况，就很容易掉入抽样误差的陷阱。

　　网站的转化情况其实是一个二项分布，即转化或未转化，满足X~(n, p)。根据中心极限定理，二项分布的极限是正态分布，一般认为当np和n(1-p)同时大于10时，二项分布近似地满足X~N(np, np(1-p))的正态分布，即均值为np，方差为np(1-p)。将二项分布除以n之后可以得到均值，即概率p的分布，当n大于30时，近似服从N(p, p(1-p)/n)的正态分布，即均值为p，方差为p(1-p)/n，当n无限大时，样本概率p与总体概率就不存在误差，也就是满足大数定律。假如我们从网站每天几百万次的访问中抽样1万次访问来预估整体的转化率，当样本的转化率（即概率p）分别为10%、1%、0.1%时，预估的总体转化率的变异系数同上表，分别为3.00%、9.95%、31.60%（可以用均值为p，标准差为sqrt(p(1-p)/n)进行验证），所以样本转化率越低，使用样本转化率去预估总体转化率就会越不准确。

　　既然过小的转化率在抽样中可能导致预估的结果存在巨大的误差，那么如何合理地选择样本数量来控制这个误差？上面已经提到，当二项分布的np和n(1-p)同时大于10时，可以认为近似满足正态分布，在正态分布下面，就可以计算在一定置信水平下的置信区间（详细计算方法见参数估计与置信区间中的区间估计），而要让抽样的误差控制在可接受的范围内，可以增加抽样的样本数来提升样本对总体估计的可信度。

　　假设我们将置信水平设定在90%（一般认为95%的置信水平是满足统计学意义的，但互联网的数据影响因素较多，普遍波动较大，不需要科研实验那么高的精确度，所以90%的置信水平足够了），即Z_α/2取到1.65，我们对转化率的控制一般要求较高，假设在90%的置信水平下，样本的置信区间必须控制在样本转化率的±10%，可以看下在这种条件下各种转化率水平所需的抽样样本数必须满足怎么样的条件：

转化率	10%的转化率	σ需要满足	n需要满足
10%	0.01	<0.00606	>2451
5%	0.005	<0.00303	>5174
1%	0.001	<0.000606	>26958
0.1%	0.0001	<0.0000606	>272032

　　上表的样本数条件可以作为我们抽样时的参考，具体的应用可以根据概率的大小和对置信水平、置信区间的需要进行计算得到。

　　最后再回到黑天鹅，通过上面对小概率事件和抽样误差的解释，其实已经很明显了。黑天鹅是极小概率事件，可能几十年几百年才遇到一次，而大数定律是一个理想化的状态，也就是n值趋近于无穷，我们很难在人生短短数十年经历很多小概率事件，或者我们的知识阅历的储备无法包含这么多的异常，很多事情在几十年的“抽样样本”中是不存在的；同时因为时代在快速地变化，当前可能发生的事件可能仅限于当前这个环境，我们无法通过历史去预见未来。于是我们完全没法知道黑天鹅事件发生的可能性，甚至不知道它的存在，即黑天鹅事件是未知的，也是无法预测的。

　　春节前的最后一篇文章了，提前祝大家春节快乐，一起期待下一年的精彩！

关于《网站分析实战》

16 条回复

　　我和蓝鲸的新书——《网站分析实战——如何以数据驱动决策，提升网站价值》终于在春节前正式出版发售了，中间经历了差不多一年的时间，非常感谢各方的努力和协同合作，也希望书的内容真正能给大家带来一些有价值的东西。

　　其实一开始并没有写书的意向，一方面因为书的内容需要比较严谨，而博客上面发布的文章在组织和叙述上都是比较随意的，而且基于目前积累的知识不足以写成一本完整的书；另一方面由于工作的原因，不太可能保证有足够的时间和精力去完成撰写。但机缘巧合，刚好蓝鲸有意向写些东西出来，然后去年春节恰好换工作的间隙有一段空闲时间，所以刚好利用这段时间完成了新书绝大部分的内容。

　　我在书中提到的内容会基于博客内容做些扩展，有些内容是博客中完全没有提到过的，并且书中的内容组织会更加地系统和完整，包括一些应用案例也是反复思考后，在能够有效地解释和反映主题前提下才放上去的。而博客中提到的一些不太成熟的思考没有放进书里面。同时配上一些重新制作或加工的图表和图片，保证内容的质量能够满足出版的要求，而且全书采用了彩印，所以阅读的体验应该还是不错的。

关于书的内容

　　《网站分析实战》主要介绍的是网站分析和数据分析相关的内容。蓝鲸对Google Analytics十分精通，所以他的内容主要是结合GA展开的，GA有一套完整的网站分析体系，所以蓝鲸的内容基本上涵盖了网站分析的整个知识面；而我的内容相对分散，主要是网站的数据分析方面的一些思路和个人在工作实践中总结的一些想法，也有一些网站数据分析的基础方法，穿插在整本书的内容中。全书的目录如下：

第1章.         解析神奇的网站分析——网站分析的目的、流程及价值

第2章.         从这里开始学习网站分析——网站分析中的基础指标解释

第3章.         网站分析师的三板斧——网站分析常用方法

第4章.         网站流量那些事儿——网站流量分析

第5章.         你的网站在偷懒吗——网站内容效率分析

第6章.         谁在使用我的网站——网站用户分析

第7章.         我们的目标是什么——网站目标与KPI

第8章.         深入追踪网站的访问者——路径与转化分析

第9章.         从新手到专家——网站分析高级应用

　　其中我涉及的内容主要包括：第1章网站分析的基础流程，第2章的数据获取，第3章的分析前准备、趋势分析和对比分析，第5章的最终产品页分析，第6章用户分析的所有内容，第7章的目标KPI监控与分析，第8章的关键路径转化分析和多路径选择分析，第9章的数据分析高级应用，关于数据仓库和内容推荐的部分。

　　因为书的内容是把我和蓝鲸的内容组合在一起，我们两人在表述方式上难免会存在一些差异，有些地方可能会存在一些细微的不一致，我们已经试图做一些串联和组合使内容更加连贯，但难免还是会存在一些细节上的小问题，还望大家见谅。

谁适合读这本书

　　其实所有对网站分析、数据分析感兴趣，或者工作在互联网领域，每天多多少少需要涉及一些看数据的工作的所有朋友都适合读这本书，我想书的某些方面的内容应该会对你有所帮助。主要适合的读者群体如下：

网站分析师、数据分析师：这个不用说原因了；
SEOer、SEMer：其实所有做互联网市场推广的朋友都可以读，因为至少流量分析跟你们的工作是相关的；
网站运营和产品经理：其实数据分析是运营和产品经理的日常工作，书中的内容分析和用户分析可以为你们提供一些思路；
个人站长：Google Analytics本身就是个人站长进行网站数据统计的普遍选择，所以蓝鲸的一些独门小技巧绝对对你们有帮助；
中高层管理人员：数据对企业越来越重要，公司的中高层管理者需要对一些核心指标了然于心，而书中目标和KPI相关的内容也可以为管理者提供一些参考建议。
网站分析和数据分析爱好者、初学者、或者准备往这个领域发展的朋友：这本书足够让你们了解和学习到网站数据分析到底是怎么样一个有趣的东西。

致谢

　　这本书完全是多方协同合作的产物。首先感谢我的合作者 @蓝鲸碎碎念，没有你的高质量内容的支持我压根就不会考虑写些东西出来，而且整个过程的合作都非常的顺畅愉快。

　　再要感谢的就是图书策划姚新军先生 @长颈鹿27 ，给了我们很多的建议，并且协调完成了整个图书出版流程，当然也要感谢所有参与后期排版、制作、美工等各方面的优化工作的朋友们，你们的辛苦工作才使整本书的面貌焕然一新。

　　感谢所有撰写图书推荐的朋友们，能在百忙之中抽空阅读书稿并提出宝贵的意见，在收到写推荐的邀请邮件后都非常积极地给出了反馈。

　　最后，这次写书对我来说也是一次特殊的经历和体验，希望书的内容能最终为大家带来一些有趣和有用的东西，希望你们能够喜欢，新书的推荐已经挂在博客的右侧边栏 ==> ，新书的网购地址如下：

　　亚马逊　　　当当　　　京东　　　豆瓣

衡量数据的离散程度

8 条回复

　　我们通常使用均值、中位数、众数等统计量来反映数据的集中趋势，但这些统计量无法完全反应数据的特征，即使均值相等的数据集也存在无限种分布的可能，所以需要结合数据的离散程度。常用的可以反映数据离散程度的统计量如下：

极差（Range）

　　极差也叫全距，指数据集中的最大值与最小值之差：

　　极差计算比较简单，能从一定程度上反映数据集的离散情况，但因为最大值和最小值都取的是极端，而没有考虑中间其他数据项，因此往往会受异常点的影响不能真实反映数据的离散情况。

四分位距（interquartile range，IQR）

　　我们通常使用箱形图来表现一个数据集的分布特征：

　　一般中间矩形箱的上下两边分别为数据集的上四分位数（75%，Q3）和下四分位数（25%，Q1），中间的横线代表数据集的中位数（50%，Media，Q2），四分位距是使用Q3减去Q1计算得到：

　　如果将数据集升序排列，即处于数据集3/4位置的数值减去1/4位置的数值。四分位距规避了数据集中存在异常大或者异常小的数值影响极差对离散程度的判断，但四分位距还是单纯的两个数值相减，并没有考虑其他数值的情况，所以也无法比较完整地表现数据集的整体离散情况。

方差（Variance）

　　方差使用均值作为参照系，考虑了数据集中所有数值相对均值的偏离情况，并使用平方的方式进行求和取平均，避免正负数的相互抵消：

　　方差是最常用的衡量数据离散情况的统计量。

标准差（Standard Deviation）

　　方差得到的数值偏差均值取平方后的算术平均数，为了能够得到一个跟数据集中的数值同样数量级的统计量，于是就有了标准差，标准差就是对方差取开方后得到的：

Standard-Deviation

　　基于均值和标准差就可以大致明确数据集的中心及数值在中心周围的波动情况，也可以计算正态总体的置信区间等统计量。

平均差（Mean Deviation）

　　方差用取平方的方式消除数值偏差的正负，平均差用绝对值的方式消除偏差的正负性。平均差可以用均值作为参考系，也可以用中位数，这里使用均值：

　　平均差相对标准差而言，更不易受极端值的影响，因为标准差是通过方差的平方计算而来的，但是平均差用的是绝对值，其实是一个逻辑判断的过程而并非直接计算的过程，所以标准差的计算过程更加简单直接。

变异系数（Coefficient of Variation，CV）

　　上面介绍的方差、标准差和平均差等都是数值的绝对量，无法规避数值度量单位的影响，所以这些统计量往往需要结合均值、中位数才能有效评定数据集的离散情况。比如同样是标准差是10的数据集，对于一个数值量级较大的数据集来说可能反映的波动是较小的，但是对于数值量级较小的数据集来说波动也可能是巨大的。

　　变异系数就是为了修正这个弊端，使用标准差除以均值得到的一个相对量来反映数据集的变异情况或者离散程度：

　　变异系数的优势就在于作为一个无量纲量，可以比较度量单位不同的数据集之间的离散程度的差异；缺陷也是明显的，就是无法反应真实的绝对数值水平，同时对于均值是0的数据集无能为力。

　　其实这篇文章只是对基础的统计知识的整理，可以从很多资料里面找到，很多统计学的书里面都是在“统计描述”章节中介绍这些基础的统计量，跟均值、中位数、众数等一起罗列，很少通过统计量的具体应用进行分类，而国外的一些书对知识点的介绍更多的是从实际应用的角度出发的，这里推荐《深入浅出统计学》这本书，虽然介绍的都是基础的统计知识，但可读性比较强，通俗易通，相比国内的一些统计学教程，更容易在大脑中建立起有效的知识索引，在具体应用中能够更加得心应手。

难以解释的数据异常

11 条回复

　　在分析数据的时候，总有那些一些数据异常无法找到适当的理由进行合理解释，也许可以换个角度来看待这些异常。为什么明明数据发生较大的起伏波动，我们绞尽脑汁还是无法找到合理的原因，这些到底是怎么样的异常，是不是存在一些共性，或者这些异常是不是我们平常所说的异常，抑或是应该归到其他类别，不妨先叫它们“难以解释的异常”。

　　近段时间在读《思考，快与慢》这本书，作者卡尼曼的观点似乎可以给我们一些答案。卡尼曼是心理学和决策学方面的大师，他告诉我们如何避开大脑思考的误区，从而更加理性地进行认知和决策。这里引述书中提及的与上面“难以解释的异常”这个问题相关的两个观点：

回归均值效应：事物会经历好坏的随机波动，但最终会回归到平均水平。

用因果关系解释随机事件：人们总是试图为一些变化寻找可以解释的原因。

迪马特奥和贝尼特斯

　　对于回归均值效应（Mean reversion），卡尼曼举了一些与体育相关的例子，确实这个现象在体育竞技中较为常见：高尔夫球手为什么第二天无法打出前一天的好成绩，球员为什么第二个赛季无法复制前一个赛季的辉煌……这让我联想到了近期切尔西的换帅事件。

　　其实迪马特奥和贝尼特斯之间存在一些有趣的共同点：1) 都是欧冠的冠军教头，2) 能力都没有被完全认可。如果说迪马特奥是没有足够的时间来证明自己的执教能力情有可原的话，那么贝尼特斯显然是自己的选择造成了外界对其能力的质疑。

　　迪马特奥在上赛季中后段从助理教练接手切尔西，并以看守主教练的身份一路过关斩将，最终夺取欧冠冠军，成功带回球队历史上第一座大耳朵杯足够让其能在赛季末被扶正，但因为缺乏执教经验始终无法让挑剔的老板对其有足够的信任，于是当球迷和俱乐部还沉浸在上赛季欧冠的荣耀光环下，而球队的表现却无法延续“应有”的辉煌时，迪马特奥下课的命运是注定的。在竞争如此激烈的英超联赛，切尔西无法摆脱回归效应，如果说上个赛季切尔西在诸多有利因素的共同作用，再加上一些运气成分的基础上成功加冕欧冠的话，那么这个赛季这些有利因素不再集中地作用于他们，而他们的运气也似乎“用完了”，成绩回归之前的平均水平实属正常现象，而在昔日光环下的球迷和俱乐部显然认为这是“异常事件”，于是迪马特奥成为了回归效应的受害者。

　　其实这类事件在足球界屡见不鲜，世界杯的98法国，02五星巴西，06意大利都难逃回归效应，夺冠之后成绩下滑，而很多教练也在夺冠之后纷纷辞职，因为他们也明白再续辉煌（摆脱回归效应）是如此之难，斯科拉里、里皮等都做出了明智的选择，而这些冠军球队的替任教练又往往是命运最为坎坷的，毕竟能像博斯克这样让西班牙不断延续辉煌的教练真的不多，而贝尼特斯恰恰当了回悲催的替任者。

　　2010年贝尼特斯接替穆里尼奥成为三冠王国际米兰的主教练，三冠王的光环太过耀眼，而阵容老化加引援不利，注定让国米走上回归效应的道路，于是赛季不到半程，贝帅即被解雇。其实贝尼特斯之前执教生涯的战绩并不是太差，成名于疯狂的“伊斯坦布尔之夜”，但也正是因为这传奇一战成了一座无法逾越的丰碑，即使之后帮助利物浦夺得诸多赛事的冠亚军，也无法让俱乐部和球迷真正的满意，而贝帅的决策失误在于其没有在任何一个辉煌或几近辉煌（07年虽然被米兰复仇雅典，但至少也是个欧冠亚军）的时刻选择退出，直到最后利物浦战绩实在看不下去了才以失败者的身份离开。贝帅真的应该向老辣的银狐里皮或者狡猾的穆里尼奥学习下什么叫做功成身退。

　　而这次，贝帅又一次选择了欧冠冠军光环下的切尔西，尽管这个光环已渐渐褪去，我们也只能祝他好运了。

倒塌的桥梁与突然安静的教室

　　共振（Resonance）催生了宇宙大爆炸，形成了星辰日月和世间万物，共振现象是自然界最普遍的现象之一。一群士兵骑马通过法国昂热市的某座桥时，共振现象导致了桥梁的倒塌，这个例子被引入初中物理教科书，从而成为了我们认识共振原理的启蒙记忆。但是什么原因引发了共振，进而发生桥梁倒塌这类异常事件，正常情况下同样一群士兵同样行军通过同样的桥，可能几万次中才会出现一次桥梁倒塌，士兵是普通的士兵，桥是正常的桥，产生共振完全是一个随机事件，但正是因为这类事件概率太小，所以人们总是试图从士兵或者桥的身上找原因（但是有时候确实是因为桥存在问题 ;- ) ）。

　　然后是一个在知乎上看到的问题：为什么原来大家都在讨论，声音嘈杂的教室会突然安静下来？这个也许大家都遇到过，也是一个类似的小概率事件，教室里每个人都在断断续续地说话，正常情况下声音的大小总是保持在一个水平波动，但可能突然有一个时刻同时说话的人数减少了，声音也随机地波动到了一个最低点，这个时候大家就会认为是不是发生了什么事情，老师来了？于是纷纷不说话，教室突然鸦雀无声，一片寂静。大家都感觉到了教室声音的“异常”，而试图为这个异常寻找可能的原因。

什么造成了这些“异常”

　　首先来看回归均值效应，一般表现为事物在某段时间表现得非常好，之后回归到正常水平的一个过程。这个按理来说是一个正常的过程，因为事物在诸多因素的共同影响下总有一些随机的波动，关键在于人们总是希望好的状态能够延续，而当事物从一个极好的状态出现下滑时，因为落差较大，所以很容易把回归均值之后的状态当做一种“异常”。如下图：

　　A段的曲线即使有上下波动，但一般不会被认为有异常，但C段曲线很容易被误认为是异常，因为我们很容易将C段与B段进行比较，而不是A段的均值水平（绿线所示，C段与A段均值差异并不大）。因为这里给出了完整的曲线变化趋势，所以犯这种错误的可能性会降低，但当我们比较短时间内的数据变化，或者简单看数据同环比的时候，就很容易误把回归均值当做一种异常。所以分析数据要结合长期趋势，当事物状态未发生质变而数据明显上升一个台阶的情况下，不要认为好的数据表现总能够持续，因为好的数据表现也只是一个正常的随机波动引起的。

　　解释了回归均值效应，还需要搞清楚的是虽然事物大部分时间都有小幅的随机波动，但偶然也会出现较大的波动，即极好或者极差的状态，正如上图的B段状态，我们如何认定这个状态也是随机的，而不是异常呢，不能因为难以解释而不把过大的数据波动当做一种异常来看？

　　这个问题还是可以从物理学的角度开始解释，先看下波的叠加原理（Superposition Principle）：

　　左图的下面2个波在叠加之后合成了更大的振幅，而右图的下面2个波相互干涉，合成后振幅消减为零。引申到数据变化的情境下，一般一个指标会受到多个因素的影响，比如网站的访问量会受多个渠道数据波动的影响，搜索引擎、外部链接、社交媒介、付费广告等这些外部渠道带来的流量总是在变化的，如下图：

　　当某个渠道的流量异常的时候，如A线所示，或者由于外界因素的影响，如春节或节假日所有渠道的流量都可能普遍下降，如B线所示，这些都可能导致总体访问量的异常，这些异常是可以解释的。C线中每个渠道的数据都未出现明显异常，但由于多个渠道的流量因为随机波动碰巧同时都到了一个较低的点，这个时候总体访问量也会出现明显低于正常水平的情况，于是就出现了“难以解释的异常”。

　　所以，这些“难以解释的异常”之谜可以揭晓了，当很多因素同时作用于某个指标的时候，即使所有的影响因素都没有出现显著的异常，指标数据仍然可能表现异常，虽然这个概率非常低，但确实会发生，这是因为多个因素共同作用下的叠加效应导致的，如果通过细分指标的影响因素没有发现明显的异常，那么不要试图为这个“难以解释的异常”寻找看上去可以解释的原因。

分析的前提—数据质量3

2 条回复

　　前面的两篇文章——分析的前提—数据质量1和分析的前提—数据质量2分别介绍了通过Data Profiling的方法获取数据的统计信息，并使用Data Auditing来评估数据是否存在质量问题，数据的质量问题可以通过完整性、准确性和一致性三个方面进行审核。这篇文章介绍最后一块内容——数据修正（Data Correcting）。

　　数据审核帮助我们发现数据中存在的问题，而这些问题有时候可以利用一些方法就行修正，从而提升数据的整体质量，数据修正就是为了完成这个任务，可以从以下几个方面进行修正：

填补缺失值

　　对于记录缺失的问题，最简单的办法就是数据回补。一般而言统计指标数据缺失可以从原始数据中重新统计获取，而原始数据缺失可以从抽取的数据源或者备份数据中回补。如果原始数据完全丢失，基本就回天无力了。

　　对于字段值的缺失，很多资料都会介绍使用一些统计学的方法进行修补，其实就是对缺失值的预测或者估计，一般会使用平均数、众数、前后值取平均等方法，或者使用回归分析的方法拟合指标的变化趋势后进行预测。这些方法在缺失值无法使用其他途径找回或者重新统计计算，并且在缺失值有变化规律可循的前提下都是可取的，当某天的指标值丢失时可以通过这类方法根据前几天的数据来预估该天的数值。但很多时候网站分析中如果底层的日志存在缺失值，我们很难预测具体的缺失值，因为访问的细节几乎是无迹可寻的，所以对于访问记录存在缺失值并且这些字段的缺失会明显影响一些统计指标的计算时，最简单的方法就是舍弃该记录，但这种直接过滤掉缺失记录的方法一些只会用于访问日志等不需要非常精确的数据上，如果是网站的运营、交易等这些需要保证完全计算准确的数据绝对是不能直接舍弃的，而且对于访问日志中缺失或者异常记录的过滤也需要基于对这类数据的统计基础上，一般的原则是不太重要的字段如果缺失或者异常的记录占比小于1%或者5‰的情况下可以选择过滤这些记录，如果占比比较高，需要进一步排查日志记录是否存在问题。

删除重复记录

　　数据集里面某些字段的值必然是唯一的，比如按天统计的指标值中的日期字段，用户信息表的用户ID等，这些需要保证唯一的规则可以对数据库设置唯一约束，但我们在做ETL处理时，有时为了保证数据加载全过程可以不因为违反唯一约束而中断（有时Load的过程需要较长的时间或处理成本，ETL需要有容错能力以保证整个过程不被中断）会先忽略重复记录，待整个ETL过程结束后再对需要保证唯一的字段进行去重处理。

　　这些重复记录可以比对Data Profiling中数据统计信息的唯一值个数和记录总数是否一致进行审核，而进行修正的最简单办法就是重复记录仅保留一条，删除其他记录。这个需要根据现实情况，有时也可能使用把重复记录的统计量相加的方法进行去重。

转化不一致记录

　　数据的转化是数据仓库抽取数据过程中最常见的处理，因为数据仓库“集成性”的特征，需要把来自多个数据源的数据集中存入数据仓库，而不同数据源对某些含义相同的字段的编码规则会存在差异，比如用户ID，虽然是相同的用户，但可能A系统的ID是u1001，B系统是1001，C系统是100100，来源于这三套系统的用户ID就需要统一，比如我们将A数据源的u前缀去除，C系统ID除100后统一成B系统的编码方式一起导入数据库；即使是来源于同一套日志，也可能存在记录的不一致，比如之前遇到较早发布的产品版本记录的日志中移动操作系统是Android，而版本更新后记录改成了android，新老版本的日志打到了一起，于是也会涉及数据的转化，但这种记录的不一致性无疑会增加ETL的处理成本。

　　上面举例的转化规则是比较简单的，在数据仓库的ETL处理数据转化时可能会遇到一些很BT的规则，这个时候最关键的还是对数据源记录方式足够的熟悉，这样才能保证进入数据仓库的数据是一致的。最好的做法就是数据仓库的开发工程师与其他前台系统的开发人员能事先约定一套统一的数据记录和编码的方式，这样可以减少后期的协调沟通和转化处理成本。

处理异常数据

　　异常数据大部分情况是很难修正的，比如字符编码等问题引起的乱码，字符被截断，异常的数值等，这些异常数据如果没有规律可循几乎不可能被还原，只能将其直接过滤。

　　有些数据异常则可以被还原，比如原字符中参杂了一些其他的无用字符，可以使用取子串的方法，用trim函数可以去掉字符串前后的空格等；字符被截断的情况如果可以使用截断后字符推导出原完整字符串，那么也可以被还原，比如移动操作系统的记录一般包括Symbian、Android、iPhone、BlackBerry等，如果某些记录的是And，那么可以被还原成Android，因为其他的移动操作系统被截断不可能出现And这种记录。数值记录中存在异常大或者异常小的值是可以分析是否数值单位差异引起的，比如克和千克差了1000倍，美元和人民币存在汇率的差异，时间记录可能存在时区的差异，百分比用的是小于1的小数还是已经乘了100等等，这些数值的异常可以通过转化进行处理，数值单位的差异也可以认为是数据的不一致性，或者是某些数值被错误的放大或缩小，比如数值后面被多加了几个0导致了数据的异常。

　　最后，总结一下数据可修正的前提：1) 数据质量的问题可以通过Data Auditing的过程被审核出来；2) 数据的问题必须有迹可循，可以通过趋势进行预测或者可以通过一些规则进行转换还原。否者，对于异常数据只能直接进行删除丢弃，但进行数据过滤之前必须评估异常记录的比例，当占比过高时需要重新审核原始数据的记录方式是否存在问题。

分析的前提—数据质量2

2 条回复

　　前一篇文章介绍了数据质量的一些基本概念，数据质量控制作为数据仓库的基础环节，是保障上层数据应用的基础。数据质量保证主要包括数据概要分析（Data Profiling）、数据审核（Data Auditing）和数据修正（Data Correcting）三个部分，前一篇文章介绍了Data Profiling的相关内容，从Data Profiling的过程中获得了数据的概要统计信息，所以下面就要用这些数据统计信息来审核数据的质量，检查数据中是否存在脏数据，所以这一篇主要介绍数据审核（Data Auditing）的内容。

数据质量的基本要素

　　首先，如何评估数据的质量，或者说怎么样的数据才是符合要求的数据？可以从4个方面去考虑，这4个方面共同构成了数据质量的4个基本要素。

data-quality-elements

完整性

　　数据的记录和信息是否完整，是否存在缺失的情况。

　　数据的缺失主要有记录的缺失和记录中某个字段信息的缺失，两者都会造成统计结果的不准确，所以完整性是数据质量最基础的保障，而对完整性的评估相对比较容易。

一致性

　　数据的记录是否符合规范，是否与前后及其他数据集合保持统一。

　　数据的一致性主要包括数据记录的规范和数据逻辑的一致性。数据记录的规范主要是数据编码和格式的问题，比如网站的用户ID是15位的数字、商品ID是10位数字，商品包括20个类目、IP地址一定是用”.”分隔的4个0-255的数字组成，及一些定义的数据约束，比如完整性的非空约束、唯一值约束等；数据逻辑性主要是指标统计和计算的一致性，比如PV>=UV，新用户比例在0-1之间等。数据的一致性审核是数据质量审核中比较重要也是比较复杂的一块。

准确性

　　数据中记录的信息和数据是否准确，是否存在异常或者错误的信息。

　　导致一致性问题的原因可能是数据记录的规则不一，但不一定存在错误；而准确性关注的是数据记录中存在的错误，比如字符型数据的乱码现象也应该归到准确性的考核范畴，另外就是异常的数值，异常大或者异常小的数值，不符合有效性要求的数值，如访问量Visits一定是整数、年龄一般在1-100之间、转化率一定是介于0到1的值等。对数据准确性的审核有时会遇到困难，因为对于没有明显异常的错误值我们很难发现。

及时性

　　数据从产生到可以查看的时间间隔，也叫数据的延时时长。

　　虽然说分析型数据的实时性要求并不是太高，但并不意味了就没有要求，分析师可以接受当天的数据要第二天才能查看，但如果数据要延时两三天才能出来，或者每周的数据分析报告要两周后才能出来，那么分析的结论可能已经失去时效性，分析师的工作只是徒劳；同时，某些实时分析和决策需要用到小时或者分钟级的数据，这些需求对数据的时效性要求极高。所以及时性也是数据质量的组成要素之一。

Data Auditing

data-auditing 　　基于数据质量的4个要素，可以对数据进行审核，以评估数据是否满足完整性、一致性、准确性和及时性这4方面的要求，其中数据的及时性主要跟数据的同步和处理过程的效率相关，更多的是通过监控ETL任务的方式来保证数据的及时性，所以这里的数据审核主要指的是评估数据的完整性、一致性和准确性。

完整性

　　我们从Data Profiling得到的数据统计信息里面看看哪些可以用来审核数据的完整性。首先是记录的完整性，一般使用统计的记录数和唯一值个数。比如网站每天的日志记录数是相对恒定的，大概在1000万上下波动，如果某天的日志记录数下降到了只有100万，那很有可能记录缺失了；或者网站的访问记录应该在一天的24小时均有分布，如果某个整点完全没有用户访问记录，那么很有可能网站在当时出了问题或者那个时刻的日志记录传输出现了问题；再如统计访客的地域分布时，一般会包括全国的32个省份直辖市，如果统计的省份唯一值个数少于32，那么很有可能数据也存在缺失。

　　完整性的另一方面，记录中某个字段的数据缺失，可以使用统计信息中的空值（NULL）的个数进行审核。如果某个字段的信息理论上必然存在，比如访问的页面地址、购买的商品ID等，那么这些字段的空值个数的统计就应该是0，这些字段我们可以使用非空（NOT NULL）约束来保证数据的完整性；对于某些允许空的字段，比如用户的cookie信息不一定存在（用户禁用cookie），但空值的占比基本恒定，比如cookie为空的用户比例通常在2%-3%，我们同样可以使用统计的空值个数来计算空值占比，如果空值的占比明显增大，很有可能这个字段的记录出现了问题，信息出现缺失。

一致性

　　如果数据记录格式有标准的编码规则，那么对数据记录的一致性检验比较简单，只要验证所有的记录是否满足这个编码规则就可以，最简单的就是使用字段的长度、唯一值个数这些统计量。比如对用户ID的编码是15位数字，那么字段的最长和最短字符数都应该是15；或者商品ID是P开始后面跟10位数字，可以用同样的方法检验；如果字段必须保证唯一，那么字段的唯一值个数跟记录数应该是一致的，比如用户的注册邮箱；再如地域的省份直辖市一定是统一编码的，记录的一定是“上海”而不是“上海市”、“浙江”而不是“浙江省”，可以把这些唯一值映射到有效的32个省市的列表，如果无法映射，那么字段通不过一致性检验。

　　一致性中逻辑规则的验证相对比较复杂，很多时候指标的统计逻辑的一致性需要底层数据质量的保证，同时也要有非常规范和标准的统计逻辑的定义，所有指标的计算规则必须保证一致。我们经常犯的错误就是汇总数据和细分数据加起来的结果对不上，导致这个问题很有可能的原因就是数据在细分的时候把那些无法明确归到某个细分项的数据给排除了，比如在细分访问来源的时候，如果我们无法将某些非直接进入的来源明确地归到外部链接、搜索引擎、广告等这些既定的来源分类，但也不应该直接过滤掉这些数据，而应该给一个“未知来源”的分类，以保证根据来源细分之后的数据加起来还是可以与总体的数据保持一致。如果需要审核这些数据逻辑的一致性，我们可以建立一些“有效性规则”，比如A>=B，如果C=B/A，那么C的值应该在[0,1]的范围内等，数据无法满足这些规则就无法通过一致性检验。

准确性

　　数据的准确性可能存在于个别记录，也可能存在于整个数据集。如果整个数据集的某个字段的数据存在错误，比如常见的数量级的记录错误，这种错误很容易发现，利用Data Profiling的平均数和中位数也可以发现这类问题。当数据集中存在个别的异常值时，可以使用最大值和最小值的统计量去审核，或者使用箱线图也可以让异常记录一目了然。

　　还有几个准确性的审核问题，字符乱码的问题或者字符被截断的问题，可以使用分布来发现这类问题，一般的数据记录基本符合正态分布或者类正态分布，那么那些占比异常小的数据项很可能存在问题，比如某个字符记录占总体的占比只有0.1%，而其他的占比都在3%以上，那么很有可能这个字符记录有异常，一些ETL工具的数据质量审核会标识出这类占比异常小的记录值。对于数值范围既定的数据，也可以有效性的限制，超过数据有效的值域定义数据记录就是错误的。

　　如果数据并没有显著异常，但仍然可能记录的值是错误的，只是这些值与正常的值比较接近而已，这类准确性检验最困难，一般只能与其他来源或者统计结果进行比对来发现问题，如果使用超过一套数据收集系统或者网站分析工具，那么通过不同数据来源的数据比对可以发现一些数据记录的准确性问题。

　　上面已经从Data Profiling的统计信息中，通过Data Auditing发现了数据质量上存在的一些问题，那么接下来就要针对这些问题对数据进行清洗和修正，也就是下一篇文章中要介绍的内容——Data Correcting，数据修正。

分析的前提—数据质量1

5 条回复

　　数据质量（Data Quality）是数据分析结论有效性和准确性的基础也是最重要的前提和保障。数据质量保证（Data Quality Assurance）是数据仓库架构中的重要环节，也是ETL的重要组成部分。

　　我们通常通过数据清洗（Data cleansing）来过滤脏数据，保证底层数据的有效性和准确性，数据清洗一般是数据进入数据仓库的前置环节，一般来说数据一旦进入数据仓库，那么必须保证这些数据都是有效的，上层的统计聚合都会以这批数据作为基础数据集，上层不会再去做任何的校验和过滤，同时使用稳定的底层基础数据集也是为了保证所有上层的汇总和多维聚合的结果是严格一致的。但当前我们在构建数据仓库的时候一般不会把所有的数据清洗步骤放在入库之前，一般会把部分数据清洗的工作放在入库以后来执行，主要由于数据仓库对数据处理方面有自身的优势，部分的清洗工作在仓库中进行会更加的简单高效，而且只要数据清洗发生在数据的统计和聚合之前，我们仍然可以保证使用的是清洗之后保留在数据仓库的最终“干净”的基础数据。

　　前段时间刚好跟同事讨论数据质量保证的问题，之前做数据仓库相关工作的时候也接触过相关的内容，所以这里准备系统地整理一下。之前构建数据仓库基于Oracle，所以选择的是Oracle提供的数据仓库构建工具——OWB（Oracle Warehouse Builder），里面提供了比较完整的保证数据质量的操作流程，主要包括三块：

Data Profiling
Data Auditing
Data Correcting

Data Profiling

　　Data Profiling，其实目前还没找到非常恰当的翻译，Oracle里面用的是“数据概要分析”，但其实“Profiling”这个词用概要分析无法体现它的意境，看过美剧Criminal Minds（犯罪心理）的同学应该都知道FBI的犯罪行为分析小组（BAU）每集都会对罪犯做一个Criminal Profiling，以分析罪犯的身份背景、行为模式、心理状态等，所以Profiling更多的是一个剖析的过程。维基百科对Data Profiling的解释如下：

Data profiling is the process of examining the data available in an existing data source and collecting statistics and information about that data.

　　这里我们看到Data Profiling需要一个收集统计信息的过程（这也是犯罪心理中Garcia干的活），那么如何让获取数据的统计信息呢？

　　熟悉数据库的同学应该知道数据库会对每张表做Analyze，一方面是为了让优化器可以选择合适的执行计划，另一方面对于一些查询可以直接使用分析得到的统计信息返回结果，比如COUNT(*)。这个其实就是简单的Data Profiling，Oracle数据仓库构建工具OWB中提供的Data Profiling的统计信息更加全面，针对建立Data Profile的表中的每个字段都有完整的统计信息，包括：

　　记录数、最大值、最小值、最大长度、最小长度、唯一值个数、NULL值个数、平均数和中位数，另外OWB还提供了six-sigma值，取值1-6，越高数据质量越好，当six-sigma的值为7的时候可以认为数据质量近乎是完美的。同时针对字段的唯一值，统计信息中给出了每个唯一值的分布频率，这个对发现一些异常数据是非常有用的，后面会详细介绍。

　　看到上面这些Data Profile的统计信息，我们可能会联想到统计学上面的统计描述，统计学上会使用一些统计量来描述一些数据集或者样本集的特征，如果我们没有类似OWB的这类ETL工具，我们同样可以借助统计学的这些知识来对数据进行简单的Profiling，这里不得不提一个非常实用的图表工具——箱形图（Box plot），也叫箱线图、盒状图。我们可以尝试用箱形图来表现数据的分布特征：

　　箱线图有很多种表现形式，上面图中的是比较常见的一种箱线图。一般中间矩形箱的上下两边分别为数据集的上四分位数（75%，Q3）和下四分位数（25%，Q1），中间的横线代表数据集的中位数（50%，Media，Q2），同时有些箱线图会用“+”来表示数据集的均值。箱形的上下分别延伸出两条线，这两条线的末端（也叫“触须”）一般是距离箱形1.5个IQR（Q3-Q1，即箱形的长度），所以上端的触须应该是Q3+1.5IQR，下端的触须是Q1-1.5IQR；如果数据集的最小值大于Q1-1.5IQR，我们就会使用最小值替换Q1-1.5IQR作为下方延伸线末端，同样如果最大值小于Q3+1.5IQR，用最大值作为上方延伸线的末端，如果最大或者最小值超出了Q1-1.5IQR到Q3+1.5IQR这个范围，我们将这些超出的数据称为离群点（Outlier），在图中打印出来，即图中在上方触须之外的点。另外，有时候我们也会使用基于数据集的标准差σ，选择上下3σ的范围，或者使用置信水平为95%的置信区间来确定上下边界的末端值。

　　其实箱线图没有展现数据集的全貌，但通过对数据集几个关键统计量的图形化表现，可以让我们看清数据的整体分布和离散情况。

　　既然我们通过Data profiling已经可以得到如上的数据统计信息，那么如何利用这些统计信息来审核数据的质量，发现数据可能存在的异常和问题，并对数据进行有效的修正，或者清洗，进而得到“干净”的数据，这些内容就放到下一篇文章吧。

SkyGlue—用GA标记用户生成点击流

13 条回复

　　最早看到SkyGlue这个工具是在Cloga博客的文章，后来经过jasseyyang的推荐，向SkyGlue的cindy申请开通了博客GA账号的试用。经过一段时间的使用，现在来简单介绍一下SkyGlue这个工具。

　　SkyGlue是Google Analytics的一个扩展工具，基于对网站中唯一访客的识别和标记，自动追踪网站的事件监控，记录用户操作的点击流数据。SkyGlue同样是通过JS页面标记进行安装部署，不过前提是你已经部署了GA的代码，因为SkyGlue其实是对GA标记的扩展。SkyGlue的JS会自动判断并监控页面的可交互按钮和链接，包括输入框、视频、图片等，监控用户的交互操作，并将结果通过事件追踪（Event Tracking）的函数提交给GA。

　　SkyGlue提供的功能，主要是为了弥补GA本身存在的一些缺陷：

1、 GA用cookie标识访客，但是无法查看每个访客的信息和访问行为；

2、 GA用cookie标识访客，无法真正识别到用户，如果使用用户注册ID会更加准确；

3、 GA用Event Tracking可以定制监控用户的交互事件，但如果需要定制大量的用户交互，设置过于繁琐；

4、无法追踪用户的生命周期，特别是对于跨Visit的分析和转化计算，比较无能为力；

5、无法区分用户个体行为，使针对用户行为的细分和分析变得困难；

6、 GA大部分数据基于前后的页面浏览串联，对于页面中相同链接的点击操作未做区分，对站外链接的点击未做监控。

　　来看一下SkyGlue的报表页面截图，用户的列表里面显示了自动生成的用户ID、来源、国家、城市及在所选时间段内的总访问数和页面浏览量：

　　点击每个Userid就可以进入该用户的点击流数据，按照操作的时间排序，如：

　　上图是在SkyGlue网站的User Report上查看数据，报表会对用户操作做下分类，包括Pageview和Click，Click显示了用户通过点击哪个链接或者图片进入了页面，Pageview则显示了进入的页面的URL。同样在Google Analytics里面也可以在Event的报表中查看这些细节数据，对于SkyGlue的具体功能和使用这里不详细介绍，有兴趣的朋友可以去他们的网站查看。（这篇文章主要是看到SkyGlue这个工具能够弥补GA的一些功能缺陷，而且完全基于GA本身进行扩展，无论是工具的实现和一些细节设置都有许多可取之处，当然也因为cindy的邀请，希望将他们的工具在国内做些介绍，所以只是想介绍一下这个工具的功能和对分析的帮助，没有任何广告的意思，如果不喜欢的可以忽略这篇文章。另外，SkyGlue是需要收费的）

　　SkyGlue提供的功能在分析上体现的价值主要两方面：一是使针对独立访客的分析成为可能；二是使针对客户操作细节的分析成为可能。

　　首先，GA是不提供用户的点击流数据的，也就是我们无法区分每个用户去观察用户的操作步骤，GA的数据都是经过一定维度聚合的，这样就丧失了对独立用户进行分析的可能性。通过SkyGlue的扩展，对访问网站的每个访客做了标记（类似GA的cookie，自动生成一个字符串来标识访客，同时可以标记注册用户的UserId，注册登录后可以在Track registered users里面设置网站的注册登录页面及相应的表单元素的名称），这样GA就具备了每位访客维度的数据，不仅可以观察每个访客在一个访次（Visit）内的浏览和操作情况，更重要的是可以跟踪访客的整个生命周期的行为，合并多个Visits分析每位用户行为，同时针对用户特定行为的过滤和细分也成为可能。最常见的就是我们要分析那些访问深度（Depth）很长的用户，他们到底是频繁穿梭于各类导航索引页面一直迷失，还是真正在浏览他们感兴趣的内容；或者用户如果未在一次访问中完成转化，那么有没有可能在之后继续访问并完成转化，他们在转化前做了什么？同时可以分析每位用户的忠诚度指标和生命周期价值的体现。

　　然后就是操作细节，从图中我们可以看到SkyGlue对用户操作的记录是非常完整的，不仅有Pageview，同时包含了用户点击链接（动作包含“A”关键字）的链接名或者点击图片（动作包含“img”关键字）的图片名，如果是站外链接会有“outbound”标记进行区分，还有输入标记“INPUT”等，这就一次性解决了GA中隐藏的一系列问题：无法区分指向相同链接的点击、无法监控站外链接的点击等。这些对网站用户体验的分析优化是非常有用的，具体可以参考博客中关于点击情况分析和用户体验分析的文章。另外，SkyGlue在自动识别监控可交互页面元素的基础上也支持自己定制需要监控的页面事件，可以在登录进去之后的Customize Event Tracking添加新事件的监控或者变更现有事件。

　　既然SkyGlue解决了一些GA的局限性，具备了使用的价值，同时也给使用带来了一些复杂性。SkyGlue基于标识用户之后使用GA的事件监控生成了用户的点击流数据，输出了大量的细节数据，这些数据细到用户的每一步点击和输入操作，对于观察分析而言就没有GA本身的聚合数据那么直观了，所以就需要更多地结合过滤和细分的方法去处理和定制数据，SkyGlue提供了一些定制的报表，结合Event Tracking对Category=>Action=>Label的钻取，让我们可以更加有效地去做些分析。但GA的优势就在于使用的灵活性和可定制性，对于那些DIY能力强的人来说，细节数据往往能够给他们带来更加丰富的分析视角，所以如果你喜欢自己捣腾下GA的话，也可以试试SkyGlue这个工具。