关键转化路径优化

16 条回复

　　其实网站分析中很重要的一块就是网站的关键转化路径分析，可能很多的网站分析师在这一方面都倾注了大量的时间和精力，尽最大的努力寻找最优的转化路径，因为优化关键转化路径相当于提高转化率，进而提高网站收益。所以，尤其对于电子商务网站或者付费服务网站而言，关键转化路径分析尤为重要。之前的文章——网站转化率与漏斗模型对关键路径的定义和分析做过简单介绍，同时推荐了一个非常形象的数据展现方式——漏斗模型，能够让每一步的转化看起来一目了然。

　　既然对关键路径和转化率的定义和计算已经做过介绍，这篇文章不再累赘，这里只是想分享一下近段时间在统计关键路径的数据时对数据表现出的特征的一些感受，不知道跟大家日常看到的想到的是否一样。

　　其实对网站转化路径的优化无非就是一句话：简化、多样化关键转化路径。

简化转化路径

　　简化转化路径是近些年在关键转化路径分析优化方面讨论的较多的，同时大部分网站也都是朝这个方向在做，也带来了不错的效果。简单看一下电子商务网站转化路径的简化流程：

　　首先是把放入购物车作为了可选步骤，而不是必需步骤，购物车可以为购买多种商品的顾客带来方便，因为可以统一下单，也就是只需要完成一次订单填写和确认的工作；而对于只购买了一样商品的用户而言，显然放入购物车步骤是一个累赘，直接拿着商品结账就完了。

　　再者就是前段时间网上讨论很多的对注册和登录步骤的简化，用户选择购物和选择成为网站的会员完全是两码事，为什么买东西就一定要先注册成为网站用户？就像你去超市买东西为什么一定要办一张会员卡。当然注册成为网站会员可以为你下次的购买带来不少的方便，对于网站而言，只有用户注册才能构建器网站完整的CRM系统，实现用户的跟踪分析和用户的保留，所以一度注册登录是网上购物的必需步骤。但随着去年团购网站的纷纷涌现，用户对去每个网站消费都要注册一遍感到了厌烦，于是就有了简化注册的讨论，毕竟给网站带来直接利益的还是用户的购买行为，没有必要因为注册步骤的存在而引起潜在消费用户的流失。

多样化转化路径

　　其实上面说的“放入购物车”从必需的步骤到可选的步骤就是一个转化路径多样化的实现，这种灵活的选择同时满足了购买单独商品和购买多种商品的用户需求；但这里要说的是另一种多样化的形式。

　　先简单再看下上面的转化步骤，有哪几个是必需的步骤？商品、订单和支付，这3个分别代表了信息流、物流和资金流，是必需的（对于某些不需要物流的虚拟商品而言，订单步骤也是可以省略的，这里不考虑这类商品）。所以最简单的转化路径应该是：

　　跟上面简化后的步骤比较下：

　　少了一个浏览商品详情页面的步骤，我们先不去讨论这个步骤到底是否是必需的，先看下数据能告诉我们什么？

　　刚好公司的产品同时提供了以上的两种转化路径，可以通过数据来分析一下这两种路径哪个更加有效。不妨将上面那条最简化路径叫做路径1，下面的叫路径2，先看下用户的选择，有多少用户选择路径1完成购买，数据的结果大概是50%，也就是选择路径1和路径2的用户几乎相等；再看看下从“确认订单”到“完成支付”的转化情况，这是两条路径都有的转化，数据显示路径1的转化率要比路径2高了30%，可以看到选择路径1的用户具有更加明确的目的性，就是为了完成购买；那是不是如果只提供路径2一种选择，那些有明确购买目的的用户即使走路径2也会产生跟路径1一样的转化质量呢？这个显然是不可能的，一旦转化步骤多了一步，肯定会多多少少伴随着部分用户的流失，数据显示如果只提供路径2，整体转化率要比提供两条路径低了20%左右，所以对于这个案例，提供两条转化路径对于整体转化率的提升上显然是有效的。

　　当然每个数据分析的结果都是以运营环境及产品业务的特征为基础的，在不同的商业模式下完全相同的分析指标可能得到的是完全不同的结果。所以需要对以上数据的环境做个说明：移动互联网的网络环境使用户多请求一个页面的成本相对较高；产品的规格比较统一，差异性小，质量比较稳定；运营的商品价格较低，对于用户而言购买的风险相对较低。

　　现在再来回答上面的问题——商品详情页面是不是必需的？用户总是在寻求最简单有效的实现途径来降低成本，但同时也会担心风险的存在，而不同的用户对待风险的态度又会有所不同，诸如上述的运营环境，当风险相对较小时，会有相当一部分用户选择最简化的转化途径来满足自身的需求，同时那些较为严谨的用户也有更多的选择来屏蔽风险。所以转化路径的多样化指的是根据自身产品和业务的特征，定制多种的转化路径来满足不同用户的需求。假设卓越首页也上加上这样的“立即购买”按钮，不知道会有多少用户会选择去点击这些按钮：

　　最后总结起来无非就是一句话：给用户更多的选择。还是以用户中心的理论，不要因为网站自身的需要而给用户造成额外的麻烦和负担，给用户更多的选择和自由，只要用户参与进来了，就是在为网站创造价值，而网站存在的本质无非就是体现其应有的价值。

数据的报表和报告

11 条回复

　　最近一直很忙，所以博客的更新频率会相对慢一点。今天想聊聊关于数据展现方面的几个看法，数据在后台经过各种的计算和处理最终得到了一些合理和直观的指标，我们需要将这些指标展现给数据的需求方，其中就会涉及数据的展示方式和数据的可视化的问题。可能这些问题日常并不被数据处理人员所重视，数据处理人员更关心数据的完整性、一致性、准确性和及时性，而对于数据的展现，更多的是只要数据能够到达需求方的手里即可，很少会有人花心思去关注数据的展现是否合理，需求方是否能够理解数据的含义，理解是否一致，数据是否通俗易懂这些问题。但这里需要说的是，其实数据的展示非常重要，它直接影响看数据的人能否用最短的时间去读懂数据、理解数据，去合理地应用数据，让数据产生价值，最终会影响到用户对数据的兴趣，而一旦用户对每天繁琐累赘的数据失去耐心的时候，数据的价值也会随之泯灭。

　　这里主要介绍日常最常提到的两类数据展现方式——报表和报告，从字面上看好像大同小异，但其实两者发挥着截然不同的功效。

报表

　　说起报表大家都不会陌生，数据分析师每天都需要看各类形形色色的报表。报表主要展现的是数据的值、趋势、比例等，所以报表只能体现数据上的表现，数据的异常和变化情况。

　　报表的展现方式主要包括两类，一类是目前最常见的WEB报表，基于B/S架构的报表系统可以提供支持多人同时登陆和查看相关的数据；另一类就是基于客户端的数据展现，最常见的就是我们会用Excel来制作报表。

　　WEB端的报表可以直接通过浏览器登录进行查看，最常见的就是Google Analytics、百度统计等第三方网站分析工具的数据展现，将数据托管到了它们的服务器上提供SaaS的服务；

　　WEB报表另一类就是BI报表工具，与第三方工具的不同之处在于系统搭建在自己的服务器上，数据自然也保存在本方，能够保证数据的隐私和安全。定制性也会比第三方工具高一些，除了提供自定义Dashboard、简单的数据筛选等功能外，还可以自己制作报表、定制图表，提供各类Query和Hint组件，而且随着BI功能的不断发展，大部分的BI报表都提供了多维模型的制作和OLAP的展现。国外知名的BI工具包括IBM的Cognos，Oracle的BIEE及SAP的BO(Business Object)，国内比较熟悉的水晶报表是BO面向中心企业的一套解决方案；开源的BI工具在国内用的最普遍，文档资源最丰富的要数Pentaho；国内的BI工具目前不多，前段时间发现用友有个BQ的商务智能平台，但没有细致了解，所以不好评述。

　　客户端的报表将数据读取到本地进行查看，所以优势在于数据的响应速度很快，可以随意的更改和处理数据，不用顾忌对原数据的损坏，所以最大的好处就在于对数据操作的灵活性；而相应的不足就在于数据并不是最新的，每次需要去刷新数据，当遇到数据量比较大时，刷新的效率就会很低，并且对于能够承受的加载数据量也没有WEB端多。所以这也是目前WEB报表比较流行的原因。

报告

　　报告所体现的作用其实与报表截然不同，报表所能解释的问题仅限于数据层面，而报告则丰富得多，报告应该能够从各方面，包括产品状况、运营状况、市场推广状况、销售状况甚至总体的战略经营状况，对数据的表现提供业务和决策层面解释，从而分析和总结业务和决策上的问题，为有效的优化提供支持。

　　所以报告是对报表的一种提炼，不再局限于数据本身，而是要通过数据去寻找业务层面的原因，所以往往报告上的解释和总结对于公司的整体运营更有价值，报告是数据分析提炼的一个必要环节。

Excel报表实例

　　相信正在看这篇文章的人有99.9%用过Excel来查看、处理和分析数据，所以对于Excel里面一般的表格和图表都在熟悉不过了，我不是使用Excel的佼佼者，所以这里不去班门弄斧了。但从数据分析的角度，其实Excel里面的一类功能非常实用，而且能够非常方便地实现数据的汇总和细分，就是数据透视表。

　　数据透视表是作为报表来展现数据的一种很好的方式，有以下几个优势：

可以连接外部数据源将数据导入Excel，Excel几乎支持所有数据库作为外部数据源，通过数据—获取外部数据来进行数据源的连接数据，并导入数据。
可以实现数据刷新，Excel支持后台、定时和打开刷新这几种数据的更新方式，所以解除了需要手工输入维护数据的烦恼；
支持多种数据聚合方式，求和、计数、平均值、最大最小值等；
支持基本的OLAP操作，包括下钻（展开）、上卷（汇总）、切片（单项筛选）、切块（多项筛选）和旋转（行列交换）。

　　下面是我从Oracle导入制作的一个数据透视表示例，下面提供了Excel文件的下载，大家有兴趣的可以下载过去自己玩玩：

点击下载：Excel透视表示例

　　好了，趁着春节前一小段闲暇跟大家分享了我对报表和报告的理解，以及用Excel制作的一个最简单的交叉透视表，这也是近段时间我所进行的工作的其中一块，希望大家能够受用。无论你现在是不是足够重视数据的可视化，无论你现在有没有精心地去制作各类报表和报告，我想说的是请尊重数据的用户，我们要让用户更愉悦地去看数据，这样才能让用户更好地理解数据和应用数据，而这个正是数据的用户体验所在。

　　最后，提前祝大家春节愉快，跟家人好好聚聚，过一个温暖惬意的春节。

网站KPI的质量控制

30 条回复

——数据的上下文2

KPI-Quality-Control 　　前面的一篇文章——时间序列的趋势分析主要介绍的是通过同比和环比的方法为指标设置数据上下文（Context），从而观察和分析各指标在时间序列上的变化趋势，我的建议是在网站的目标指标（Goal）中使用这类方法。所以这篇文章就紧接着上一篇的专题，还是针对内部基准线（Internal Benchmark）的设定，主要解决的是网站关键绩效指标（KPI）的数据上下文的设置，推荐使用的分析工具是——质量控制图。

为什么将质量控制图用于KPI

　　需要明确一个工具可以用于何处，首先必须了解这个工具，所以概念和用处必不可少，这个可以直接参考质量控制图文章中的介绍，这里简单整理出几条适合于使用质量控制图的指标的前提条件：

指标能够体现产品或功能的质量情况；
指标能够持续地被观察测量，并且可以被量化，即从统计角度有足够的样本容量；
在正常情况下，指标的变化趋势保持恒定，不是持续上涨或下降，也不会经常出现大幅波动，即符合正态分布。

　　根据上述的适用条件，应该能够大概明白为什么要用控制图来作为网站KPI的参照设置标准，KPI是衡量网站的质量和表现的指标，在正常情况下，KPI可以保持稳定的趋势，不会出现大幅的波动。这跟网站的目标指标存在差异，一个运营良好的网站，它的目标（如收益）应该是保持稳定增长状态，而不是保持恒定，而它的KPI（如转化率）则应该保持恒定的趋势，除非受到了特定因素的影响或者网站做出了更改和变动。所以KPI指标的特点都符合使用质量控制图的条件。

KPI质量控制图的应用

　　这里选择最常见的两个网站的KPI指标举例下应用的过程，一个是基于网站转化率（Conversion Rate）的P控制图，另一个是基于平均订单价值（Average Order Value, AOV）的X-MR控制图，这里的数据都以天为单位，选择15天的数据进行举例，数据也都是虚拟的。

转化率的P控制图

　　这里以电子商务的交易转化率为例，我们需要获取每天的总访问数和完成交易的访问数，进而相除得到转化率，再根据P控制图的公式计算得到CL、UCL和LCL，为了图表的美观，我选择使用了样本容量取均值，也就是保证UCL和LCL的一致，而不是每天取各自的值，具体的数据见图表，包括15天的数据：

日期	总访问数	成功交易访问数	转化率	CL	UCL	LCL
2010-12-01	10231	201	1.96%	1.81%	2.16%	1.45%
2010-12-02	12874	229	1.78%	1.81%	2.16%	1.45%
2010-12-03	11229	231	2.06%	1.81%	2.16%	1.45%
2010-12-04	9870	201	2.04%	1.81%	2.16%	1.45%
2010-12-05	11804	237	2.01%	1.81%	2.16%	1.45%
2010-12-06	11652	224	1.92%	1.81%	2.16%	1.45%
2010-12-07	13259	236	1.78%	1.81%	2.16%	1.45%
2010-12-08	11891	167	1.40%	1.81%	2.16%	1.45%
2010-12-09	12876	213	1.65%	1.81%	2.16%	1.45%
2010-12-10	14562	240	1.65%	1.81%	2.16%	1.45%
2010-12-11	12933	259	2.00%	1.81%	2.16%	1.45%
2010-12-12	13548	241	1.78%	1.81%	2.16%	1.45%
2010-12-13	15230	256	1.68%	1.81%	2.16%	1.45%
2010-12-14	13815	276	2.00%	1.81%	2.16%	1.45%
2010-12-15	15766	248	1.57%	1.81%	2.16%	1.45%

　　根据表中的数据很容易就可以画出相应的P控制图，见下图（添加了μ±2σ的线）：

　　最后就是根据控制图寻找数据可能存在的异常并找到发生异常的原因，根据上图比对控制图的控制规则，可以发现这15天的数据存在2个地方的异常：

12月8日的数据低于LCL，表现异常；
12月3日到12月8日的数据连续6天呈下降趋势，存在异常。

　　到这里，数据层面的工作已经结束了，但接下去这一步却至关重要，就是分析发生异常的原因，这里抓住两个点：从12月3日开始数据呈下降趋势，12月8日到达低谷，之后开始反弹。那么我们可以知道很可能在12月3号的时候网站内部的调整或外部事件导致了数据异常的发生，并且持续到了12月8日，同时通过分析12月8日低谷的细分数据进一步明确到底是哪一块出现了问题，并做出及时的响应和调整，避免类似事件的再次发生。

订单均价的X-MR控制图

　　还是电子商务的KPI——平均订单价值，即所有成交订单的总价值除以订单数，当网站运营的产品没有做出大幅调整时，一般这个指标是保持恒定的，并且因为是均值所以每天之差的波动幅度不会很大，所以可以使用均值-移动极差X-MR控制图。

　　首先要先计算得到每天的平均订单价值，再通过当天与前一天的值相减计算得到移动极差MR，再根据X-MR控制图的公式计算得到CL、UCL、LCL，见下表（也是15天的数据）：

日期	订单均价	MR	X_CL	X_UCL	X_LCL	MR_CL	MR_UCL	MR_LCL
2010-12-01	103.76	12.65	103.48	133.84	73.12	11.41	37.29	0
2010-12-02	129.12	25.36	103.48	133.84	73.12	11.41	37.29	0
2010-12-03	107.30	21.82	103.48	133.84	73.12	11.41	37.29	0
2010-12-04	97.45	9.85	103.48	133.84	73.12	11.41	37.29	0
2010-12-05	105.10	7.65	103.48	133.84	73.12	11.41	37.29	0
2010-12-06	115.78	10.68	103.48	133.84	73.12	11.41	37.29	0
2010-12-07	105.21	10.57	103.48	133.84	73.12	11.41	37.29	0
2010-12-08	98.78	6.43	103.48	133.84	73.12	11.41	37.29	0
2010-12-09	101.74	2.96	103.48	133.84	73.12	11.41	37.29	0
2010-12-10	96.53	5.21	103.48	133.84	73.12	11.41	37.29	0
2010-12-11	97.99	1.46	103.48	133.84	73.12	11.41	37.29	0
2010-12-12	114.20	16.21	103.48	133.84	73.12	11.41	37.29	0
2010-12-13	116.18	1.98	103.48	133.84	73.12	11.41	37.29	0
2010-12-14	80.29	35.89	103.48	133.84	73.12	11.41	37.29	0
2010-12-15	82.76	2.47	103.48	133.84	73.12	11.41	37.29	0

　　X-MR控制图产生两张图，一张是均值X的控制图，另一张是移动极差MR的控制图，先是均值的（也包含了μ±2σ的线）：

　　再来一张移动极差的控制图：

　　同样，还有最重要的一步，就是发现数据的异常和寻找异常发生的原因。首先来看均值控制图，比对控制规则可以发现最近3天中两天的数据都在μ-2σ线以下，这给了我们一个很好的预警信号——数据有变坏的趋势，我们需要去寻找原因并做出快速的响应和调整了；再看移动极差控制图，也有一个异常的规律——连续8个点在中心线以下，为什么？这段时间数据的波动极其平滑，或者相对的说明时间段的两端波动较大，是什么导致了这种异常的波动趋势？这些都需要从业务角度或者外部因素中去寻找原因。所以数据分析师不仅仅是计算和展现数据，更重要的是基于数据的分析，寻找数据背后的影响因素和数据变化的原因。

　　上面就是我的两个应用，对于质量控制图，你是不是还能想到更加有创意的应用方案，欢迎跟我交流评论。这篇文章就作为2010年的收尾，祝大家新年快乐，希望2011能给大家带来更多的新意和惊喜，我的博客也会在新的一年里不断地向大家奉上更加精彩的内容，希望能跟大家一起不断地学习进步。

质量控制图

13 条回复

　　其实之前的一篇文章——网站数据分析的基本流程介绍过质量管理（Quality Management, QM）相关的内容，只是介绍的是概念和流程这类比较定性的东西，这篇文章也是跟质量管理相关的内容，但介绍的主要是定量分析相关的工具——质量控制图。

质量控制图的概念与用处

　　如果要系统地介绍，可能要从质量管理(Quality Management,QM)开始，从传统的质量管理七工具，到全面质量管理阶段的6σ管理，这里不去展开，只介绍质量控制图。

　　质量控制图，简称控制图（Control Chart），是质量管理七工具之一，由美国的贝尔电话实验所的休哈特(W.A.Shewhart)博士在1924年首先提出，因此也称为“休哈特控制图”。最初的应用当然是在生产领域，使用抽样的方式检验产品的质量是否处于控制状态。一般而言，指标的波动受随机因素和系统因素的影响，如果指标只受到随机因素的影响，那么在正常情况下指标的变化状态是稳定的、可控的，但如果发生某种系统性的变化就会使指标超出原先可控的波动范围，处于失控状态，所以控制图就是帮助我们及时发现这种失控状态，从而进行及时的调整。

　　质量控制图通过统计上均值μ和标准差σ的状况来衡量指标是否在稳定状态，同时选择3σ来确定一个正常波动的上下限范围（根据正态分布的结论，指标的特征值落在μ±3σ之间的概率是99.73%），使用均值μ作为控制图的中心线（Center Line, CL），用μ+3σ作为控制上限（Upper Control Limit, UCL），用μ-3σ作为控制下限（Lower Control Limit, LCL），如图。

　　根据衡量的指标数值类型的差异，质量控制图主要分为两类：计数型控制图和计量型控制图，下面分别介绍其中的一种：

质量控制图具体用法

　　因为生产制造业和互联网行业存在着较大差异，所以这里只介绍适合用于网站分析的2个控制图。其中计数型控制图中主要介绍P控制图，主要用于定类型变量，即符合二项分布检验“是否”的变量，如用户是否完成交易、用户是否为新用户……这类指标一般会以比率的形式出现，如转化率、新用户比例等，而P控制图正是衡量这些比率是否出现异常（在生产行业通常用于不合格率等）；另外的计量型控制图主要用于一些关键的数值度量，如每个订单的消费额、每个用户的下载次数等，这类指标在网站分析中通常计算全部数据的均值来观察波动情况，其实计量型控制图最常用的是均值-极差（X-R）和均值-标准差（X-S）控制图，但两者都是通过取样的方式实现的，并且每次取样的样本数最好能保持相等，所以这类抽样统计不太适合于上述网站分析中的指标，这里介绍个相对能够普遍适用并且计算也没有那么复杂的图——单值-移动极差（X-MR）控制图。下面一个个来，先是P控制图：

P控制图

　　根据中心极限定理规律，当二项分布的样本容量足够大时，分布趋向正态N(ρ, ρ(1-ρ)/n)（这里用ρ先暂代下p均值，上横线很难打出来，具体见下面图中公式），所以总体均值μ就是ρ，方差σ²就是ρ(1-ρ)/n，进而就可以计算得到中心线CL、控制上限UCL、控制下限LCL：

p-chart-expression

–p_k：每组样本的比例值，n_k：每组样本容量

　　我在这里使用了UCL_k和LCL_k，也就是每组样本都有各自的控制上限和控制下面，当然我们也可以跟CL一样使用统一的UCL和LCL，这时n不再使用每组的样本容量，而是使用每组样本容量取均值的结果，只是简单的变换，公式就不贴出来了。

X-MR控制图

　　第二类计量型控制图中的单值-移动极差（X-MR）控制图，需要先计算指标的移动极差：MR=|X_i-X_i-1|，即每个数值减去前一个相邻的数据的绝对值，进而计算指标均值和移动极差均值，通过公式转换算出均值X控制图和移动极差MR控制图的CL、UCL、LCL：

x-MR-Chart-expression

–x_i、MR_i：每个个体的数值和计算得到的极差，k：样本个体数，d₂、D₃、D₄：极差到标准差的转化系数，相当于n=2的极差转化系数，所以在这里可以看作是固定值。

　　通过套用上面的公式，可以计算得到相应的CL、UCL、LCL，结合每个特征值就可以画出控制图。因为这篇文章主要基于方法，同时也主要是为下一篇文章作为技术铺垫，所以不具体举例了，具体实例见之后的——网站KPI的质量控制，这里先附上一张维基百科上的质量控制图：

质量控制图的控制规则

　　既然质量控制图是为了帮助我们及时发现指标的不正常状态，那么当我们看到上面的图以后，需要观察和分析是不是存在异常的点或异常的变化趋势，如何定义这些异常，需要有一套控制规则：即样本点出界或者样本点排列异常：

点超出或落在ULC或LCL的界限；（异常）
近期的3个点中的2个点都高于+2σ或都低于-2σ，近期5个点中的4个点都高于+σ或都低于-σ；（有出现异常的趋势）
连续的8个点高于中心线或低于中心线；（有偏向性）
连续的6个点呈上升或者下降趋势；（有明显的偏向趋势）
连续的14个点在中心线上下呈交替状态。（周期性，不稳定）

　　查资料时发现不同的地方对控制规则有不同的定义，我这里参照的是SPSS里面的规则，具体应该可以根据实际的应用环境进行调整。

　　看到这里，你是不是会发现质量控制图其实很有用，结合图比对这些规则后能够很快地发现指标的异常和可能产生的异常，一目了然。具体应用会在近几天内一并奉上，请继续关注。

时间序列的趋势分析

17 条回复

——数据的上下文1

　　无论是网站分析工具、BI报表或者数据的报告，我们很难看到数据以孤立的点单独地出现，通常数据是以序列、分组等形式存在，理由其实很简单，我们没法从单一的数据中发现什么，用于分析的数据必须包含上下文（Context）。数据的上下文就像为每个指标设定了一个或者一些参考系，通过这些参照和比较的过程来分析数据的优劣，就像中学物理上的例子，如果我们不以地面作为参照物，我们无法区分火车是静止的还是行进的，朝北开还是朝南开。

　　在实际看数据中，我们可能已经在不经意间使用数据的上下文了，趋势分析、比较分析、细分与分布等都是我们在为数据设置合适的参照环境。所以这边通过一个专题——数据的上下文，来总结和整理我们在日常的数据分析中可以使用的数据参考系，前面几篇主要是基于内部基准线（Internal Benchmark）的制定的，后面会涉及外部基准线（External Benchmark）的制定。今天这篇是第一篇，主要介绍基于时间序列的趋势分析，重提下同比和环比，之前在网站新老用户分析这篇文章，已经使用同比和环比举过简单应用的例子。

同比和环比的定义

　　定义这个东西在这里还是再唠叨几句，因为不了解定义就无法应用，熟悉的朋友可以跳过。

　　同比：为了消除数据周期性波动的影响，将本周期内的数据与之前周期中相同时间点的数据进行比较。早期的应用是销售业等受季节等影响较严重，为了消除趋势分析中季节性的影响，引入了同比的概念，所以较多地就是当年的季度数据或者月数据与上一年度同期的比较，计算同比增长率。

　　环比：反应的是数据连续变化的趋势，将本期的数据与上一周期的数据进行对比。最常见的是这个月的数据与上个月数据的比较，计算环比增长率，因为数据都是与之前最近一个周期的数据比较，所以是用于观察数据持续变化的情况。

　　买二送一，再赠送一个概念——定基比（其实是百度百科里附带的）：将所有的数据都与某个基准线的数据进行对比。通常这个基准线是公司或者产品发展的一个里程碑或者重要数据点，将之后的数据与这个基准线进行比较，从而反映公司在跨越这个重要的是基点后的发展状况。

同比和环比的应用环境

　　其实同比、环比没有严格的适用范围或者针对性的应用，一切需要分析在时间序列上的变化情况的数据或者指标都可以使用同比和环比。

　　但是我的建议是为网站的目标指标建立同比和环比的数据上下文，如网站的收益、网站的活跃用户数、网站的关键动作数等，这类指标需要明确长期的增长趋势，同比和环比能够为网站整体运营的发展状况提供有力的参考。

　　还有个建议就是不要被同比和环比最原始或者最普遍的应用所束缚住：同比就是今年每个月或每季度的数据与去年同期比，环比就是这个月的数据与上个月比。对于方法的应用需要根据实际的应用的环境，进行合理的变通，选择最合适的途径。所以同比和环比不一定以年为周期，也不一定是每月、季度为时间粒度的统计数据，我们可以根据需要选择任意合适的周期，比如你们公司的产品运营是以周、半月、甚至每年的特定几个月为周期循环变动，那完全可以将这些作为同比的周期。

　　特别对于互联网这个瞬息万变的环境，常用的年与年之间的同比，以季度或月为粒度的统计可能不再合适，为了适应快速的变化，以月为周期、周为周期的同比，以天为粒度、小时为粒度的统计数据进行环比将变成常见的方式，因为要适应这种快速的变化，我们需要做出更迅速的决策和调整，当然数据要适应这种快速决策的需要。

应用实例

　　同比和环比被广泛地应用于各个领域，在Google的图片中搜索同比和环比会有丰富的包含了同比环比的图表显示在你的眼前，所以这里只举个简单的例子：因为很多的互联网产品的数据变化情况会以“周”为周期进行波动（周末会出现明显的上升或者下降趋势），所以这里以一周的数据为例来看下同比和环比的展现效果。还是虚拟数据，为了展示上的需要而临时设定的：

	周一	周二	周三	周四	周五	周六	周日
上周收益	113	134	123	145	137	196	187
本周收益	129	122	134	149	146	215	208
同比增长	14.16%	-8.96%	8.94%	2.76%	6.57%	9.69%	11.23%
环比增长	-27.88%	-5.43%	9.84%	11.19%	-2.01%	47.26%	-3.26%

　　从图中可以看出数据在一周中的变化趋势，周中和周末之间存在明显的差异，周末的收益会有明显的上涨，在使用同比的时候需要抓到这类数据的周期性的变化规律，让数据的对比能够更加有效地反映数据的变化。同时在Excel里面可以直接为一组基于时间序列的数据绘制趋势线，正如图中的虚线所示，本周收益在一周中的变化趋势就显得非常明显，这里用的是指数的拟合，Excel的趋势线提供了线性、指数、对数、幂等回归分析的方式，同时也包含多项式和移动平均等趋势分析的方法。

　　最后看看我们经常在使用的网站分析工具里面有没有同比和环比的功能呢？这里以Google Analytics和百度统计为例截了两张图，首先看下百度统计登录进去后的网站概况：

　　百度统计默认就为我们提供了一个比较环境，上方表格中是今天与昨天的数据对比及变化情况，还提供了预测的功能；下方的折线图显示的是每小时数据的变化，提供前一天或者上周的同一天（百度可能已经意识到网站大部分会存在以周为变化周期的趋势，所以很多地方都提供了以周为单位的参考数据）的每个整点的数据对照，同时可以选择不同的时间区间和各类指标。再看看Google Analytics的Dashboard：

　　Google不像百度那样一进去就能看到对照数据，需要我们手工去选择，在时间区间的选择界面提供了“Compare to Past”的勾选按钮，如果默认是近一个月的数据，那么参照数据就是再往前推一个月的每日变化数据，Timeline的选择面板做得非常炫，可以自定义地选择任何有效的时间区间，当然也同样提供不同的参考指标，鼠标移到图中相应日期的点后会显示具体的数据及差异的大小。

　　同比和环比是最简单直观的基于时间序列的趋势分析方法，通过观察关键指标的变化情况来洞察网站的发展和运营情况，同时衡量目标的实现程度。所以这篇文章的主题是使用趋势分析的方法来为网站的目标设定数据的上下文，下一篇将主要针对KPI指标进行数据上下文的选择和设定。

数据仓库元数据管理

5 条回复

　　元数据管理是整个数据仓库架构中很重要的一块（关于数据仓库的架构，请参考这篇文章——数据仓库的基本架构），但发其实现很多书里面都没有对元数据下一个详细的定义，或者没有系统地介绍到底数据仓库的元数据应该包括哪些。下面是我个人整理的一些对元数据管理的看法，主要来自Inmon的《数据仓库》的两本书、Oracle的文档及个人在数据仓库的应用中认为应该记录的一些元数据。

元数据的定义

　　元数据（Meta Data），从字面来看好像无法看出所以然，我当初看到的时候也是，但其实看看对应的英文，含义还是挺明确的，Meta一般是指“对……的解释或描述”，类似的还有Meta Tag。所以元数据其实就是对数据的解释和描述，这种解释可以以多种形式存在，数据库的数据字典、外部文档，工具的资料档案库（Repository）等。

元数据包括哪些

　　这里主要将数据仓库的元数据分为3类：数据库管理系统的数据字典、ETL处理流程产生的日志、BI建模和分析中工具或文档中记录的信息。

DBMS数据字典

　　数据库管理系统（DBMS）中的元数据一般在所有的数据仓库都会包含，因为数据仓库一般都是基于数据库搭建的，而数据库本身的管理系统就会自动维护一套数据字典供用户查询。这些信息一般包括：

数据库的关系模型，包含的对象及对象的描述；
数据库的表结构、字段信息及描述；
表和字段中的主外键、索引、约束等信息；
各对象的存储位置和操作权限等。

ETL处理日志

　　ETL是数据仓库管理和维护的基础，就像是数据仓库的血液维系着整个数据的新陈代谢。我们需要时刻关注血液的循环是否正常，它是保证数据完整性、一致性、准确性和及时性的重要参考依据，所以我们需要记录ETL任务的处理日志，我一般会记录以下几类信息：

任务信息、调用的程序或脚本、前置任务；
数据来源、加载目标、转化规则或计算公式；
数据的刷新类型、刷新频率，任务调度信息；
每次运行的起始时间、结束时间、操作记录数、任务状态及出错信息。

　　记录ETL信息的方式有很多，一般我会将上面罗列的信息分两类进行记录，一类是ETL基本信息与调度信息，另一类是ETL的每次运行日志。其实ETL的任务信息和任务调度一般比较简单且更新频率不高，可以以文档或建数据库表的形式记录，当有新的ETL任务配置进去时进行手动更新；而ETL的运行日志一般是当任务运行一次就会记录一条，反映该次运行的状态，所以一般每个程序或脚本每天甚至每小时就会产生一条，建议如果ETL环境在数据库里面的话，建立ETL日志表记录相对会比较方便，当每次ETL运行时自动地去维护这张表，INSERT一条任务运行的记录。

BI分析模型

　　这里的BI分析模型主要有两类，一类是数据仓库常见的多维模型，另一类是根据具体业务构建的商业分析模型。无论是哪类模型，其实都已经在分析的层面上，所以都有必要记录以下几类信息：

分析模型的设计和结构；
模型的分析应用和商业价值；
模型中指标的定义、计算方法；
模型的展现和效果。

　　模型一般由分析师设计和构建，所以这类信息一般会以文档的形式记录下面，或者制作成相应的PPT进行展示。这里必须注意的是分析模型在构建之初就必须明确应用的环境、体现的价值或可能实现的预期，明确这些是为了更好地应用到实践中，如果只是单纯为了实现这样的模型或者基于相应算法的实现，那么很有可能最终模型会变成一种摆设；再有一点就是模型的展现，模型需要优化其在可视化层面的效果，也就是要让其他人能够更好地理解模型的使用和价值，一切底层的算法和数据的处理只是为了让模型在最终的展现上更加有效。

　　上面只是对于所有的分析模型而言，对于多维模型，其在数据仓库的应用已经形成了一定的规范，所以我们可以获取到更多的信息：

多维模型的结构（星形、雪花等）；
多维模型的维（层次、级别、属性）和立方（度量、计算度量）；
多维模型的数据组织和加载；
可以实现的OLAP应用与展现。

　　其实如果你用工具来构建多维模型，那么这些多维模型的元数据信息可能很多直接就会保存在工具相应的资料档案库（Repository）里面，当然你也可以自己整理出相应的文档，供不时的查询和分享的需要。

　　好了，数据仓库的元数据管理方面的总结就是这些。非常感谢近几天一些网友在博客中的评论和留言，让我学到了很多，也让我可以去改善一些东西，希望大家能够继续在博客中提出宝贵的建议。近段时间可能会比较忙，留言的回复和文章的更新可能会相对慢一些，希望大家谅解。

用户需要什么数据？

21 条回复

　　这里首先需要说明的是标题中的“用户”指的是数据的用户，或者数据的需求方，这些用户往往不是网站或企业面向的外部用户，数据的消费者通常是公司内部各个部门和领域的人员。

　　为什么会提出这个问题，其实我们经常会遇到这样的情况：公司的高层抱怨从报表里面看不到有用的东西，是不是可以对报表做下整理（于是下面就忙开了），但是该怎么整理或者他们到底需要的是什么数据（好吧，高层的需求一般是不会明说的，我们要试着自己去揣摩）；同时各个部门也在不断地提各类数据需求，往往他们的需求就比较明确，有时可能会细得吓人，需要每个用户的每次关键操作（考验服务器的时间到了）。数据部门就是处在这样一个对数据的需求存在着如何多样化的环境里面，所以考验数据人员的时间到了，我们能满足所有的需求吗？

目标和KPI

　　好了，首先来解答一下我们揣摩“圣意”后的结果，老板或者高层需要什么数据？其实很简单，他们只想知道公司的总体状况如何，所以我们只需要提供汇总的目标和KPI数据，不需要太多，2-3张报表，10个左右的指标足够展现出公司的全局了，但其实首先要做的是对公司的目标和KPI有一个明确的认识和定义。

　　主要关注人员：决策层

　　虽然目标和KPI的主要关注人群锁定在公司的决策层，但其实公司的每位员工都应该关心公司的目标实现情况及KPI指标的表现，因为目标和KPI是客观评价公司状况和效益的最有效途径。但往往各个部门关心目标的KPI的方式会有差异，于是数据需要去满足各个部门不同的关注目标的KPI的方式，就有了下面的细分。

细分与功能点

　　公司的决策层可能会希望看到上面这些目标和KPIs的汇总数据，但如果我们给所有用户都提供这类汇总数据，那么可能其他用户就只能远远地望着这些数据，什么都做不了。所以我们需要给不同的用户不同类别不同层面的数据，因为我们要做的就是让每个数据消费者都能根据数据Take Actions，而其中很重要的一块就是数据的细分。

　　我们可以从多个角度对网站分析的报表和指标进行细分，每个公司根据自己运营类型的差异选择适合自己的细分模块，当然这里说的最常见的几个细分模块：内容、用户和来源，也就是Google Analytics的分块方式。

内容细分

　　主要关注人员：产品运营

　　尽管互联网的形式在不断地多样化，但无论如何互联网还是主要以信息服务提供商的角色存在，归根到底还是内容，所以对于网站而言内容是它的核心竞争力所在，对于网站分析同样如此，所以首当其冲的就是内容的细分。之前有篇文章——网站页面度量与细分，对网站的内容的一些度量指标和几个细分方式作了介绍，无论以哪些指标或者以何种细分方式来评价内容，最终我们的目的都是区分优质和劣质的内容，掌控产品的运营状况，从而保持或者改进网站内容。

　　内容细分的分析结果无疑可以给产品运营或者网站运营提供有价值的参考依据，明确了哪些是需要把握的核心内容，哪些内容需要改进。同时借助一些特殊的指标还可以指引细节上的改进，比如一个Pageviews很高但Avg. Time on Page较短、Exit Rate很高的页面显然在内容上没有足够的吸引力，但标题或简介信息足够吸引眼球，那么改进的方向就可以确定为提高内容的描述方式；如果你的网站提供电子商务服务，那么每个或每类产品细分的销售额（目标）及转化率（KPI）将让你能够更好地有针对性地进行产品和运营方式的选择。

用户细分

　　主要关注人员：用户体验、销售

　　我们一般通过用户的使用环境（网络、设备、系统和客户端等）、人口统计学信息（性别、年龄、地域等）、用户行为类型（使用的趋势、忠诚度、创造的价值等）这几类数据和指标对用户进行细分。在现在“用户中心论”盛行的潮流下，是不是把用户放在内容后面有点不妥？网站的一切就是为了满足用户的需求，包括所有的内容的提供，但其实在数据分析上用户分析并没有内容分析来得普遍，特别是还要对用户进行细分，道理很简单，内容或者产品是可以自己把握的，而用户不行，所以尤其是基于用户行为分析的数据，说得很多但真正做好的或者应用于实践的其实并不多。

　　但有一块必须要有用户分析数据的支持，那就是用户体验的设计和优化。对于用户体验设计而言，其目标是能够满足所有用户的使用习惯，所以比较和优化各类用户在不同的使用环境和使用习惯中的数据能够对用户体验的改善起到很大的作用；而如果你的网站产品需要进行销售，那么用户行为分析对于个性化的产品销售和推荐能够起到很好的效果，它刚好与用户体验的目标相反，这类细分分析主要是为了满足每类甚至每个用户需求上的偏好。

来源细分

　　主要关注人员：市场推广

　　其实对于网站分析人员而言，渠道来源的数据分析肯定不会陌生，许多网站都会重点分析这块的效果，包括SEO和SEM等都已经发展成为了非常专业的领域。网站分析工具里面一般都会区分直接进入、搜索引擎、外部网站及促销途径这几项来源，其实我们可以使用一些有效的途径将这些渠道分得更细，包括社会化媒介、合作网站、广告直邮等，通过这些来源细分去观察各渠道带来的流量的质量（在目标和KPI指标上的表现），我们就可以看清楚各推广渠道的优劣，从而为有效的推广行动提供参考。

　　其实还有一块——线下渠道，我们往往会认为线下的电视、报纸等上面的促销或广告的效果很难用数据进行监控，但其实只要我们去寻求一些办法，这些也是可以实现的，比如离线通是监控线下电话营销渠道的很好的工具。通过对线下渠道的监控分析，是我们更了解线下推广的效果以及其对线上推广所带来的关联和影响，最终指导推广人员更有效地布置和实施整套完整的推广计划。

功能点分析

　　主要关注人员：技术、用户体验

　　如果你的网站不单是简单的几个页面，而是一个庞大复杂的系统，其中提供了丰富的功能和应用，那么我们还需要做一类分析，就是各功能点的分析。之前在“让用户更容易地找到需要的信息”专题中分析过几类网站中常见的功能：站内搜索、导航设计和内容推荐，这些功能点我们都可以使用特殊的方法获取数据、设置特殊的指标去分析他们的实现效果。

　　技术和用户体验团队都需要关注这些功能的实现效果和优化空间，数据是评价这些功能最有效的途径，因为这些功能都影响着用户的体验和满意度，一个真正优秀的网站需要把握好每个功能的每个细节的实现。

分析模型

　　上面提到的相关人员几乎涵盖了每个公司的各个领域，但其实还缺少一块重要的组成部分，就是我们自己——数据分析人员。其实对于数据分析人员来说，他们需要把握所有的数据，从全局的目标和KPI到各类细分指标，以及各类功能点的数据。但这些还远远不够，数据分析师必须发挥他们的所长，设计并构建起各类分析模型，这些模型不仅可以对公司的关键业务和运营状态做出客观的评价，起到总结的效果外，更可以发现一些潜在的商业需求点，为公司的发展提供可能的方向和决策依据，起到预测的作用。

　　分析模型主要分为两类，一类是定量分析模型，这个在我的博客中已经介绍过一些，包括关键路径分析的漏斗模型、基于用户行为分析的用户评价模型，当然也包括数据挖掘领域的用户兴趣发现、内容模式匹配，以及基于其上的个性化推荐模型，这些都在一定程度上实现了预测的效果。

　　另一类是定性分析模型，包括目标市场的调研、以用户为中心的研究以及竞争优势的分析。当然现在可能在用户调研和用户体验方面做得相对多些，通过网上问卷、可用性实验、实景访问调研，结合一些可视化的点击热图、鼠标移动监控等工具来评估用户在使用网站是的整体感受和满意度，这种更加接近用户的分析方法将逐步为网站和产品的优化带来许多新的思考。

自定义Dashboard

　　其实大部分的网站分析工具和BI报表工具中都会提供自定义Dashboard的功能，以便用户可以将自己关注的指标、报表和图表集成地显示在同一个Dashboard上面，方便日常的观察和分析。本来这是一个很Cool的功能，因为只要稍微用点心，可以把自己的“仪表盘”做得很漂亮，但现实中这个功能没有想象中实现得那么好，或者用户没有去自定义Dashboard的习惯（当然存在数据的组织和关联上的限制以及报表工具易用性方面的问题），但作为数据的提供方，我们在定制好公用的Dashboard的同时，有必要时还要帮助某些特定需求群体定制自定义的Dashboard。

　　优秀的自定义Dashboard不仅能够合理地组织数据，同时更加可视化地展现数据，让数据的观察的分析不需要这么累，是的，也许用户会爱上这些数据。同时自定义的Dashboard其实还可以有效的控制数据权限，在Dashboard里面将合适的指标和报表开放给用户，从而屏蔽掉一些敏感的数据，数据的保密性对数据部门而言也是一块重要的工作。

　　不知道读完整篇文章会不会觉得有点空，没有实质的内容或实践性的分析方法，但其实这篇文章花了我很长的时间进行总结和思考，梳理整个数据提供方案的可行的思路，希望能给出一个系统全面的数据组织和提供方案，用数据为线索贯穿企业的各个角落，真正能够建立起数据驱动（Data Driven）的企业文化，让数据不单只是单纯的展现这么简单，能够满足各类人员的不同需要，并最终依靠数据提高企业在各个领域执行的效率和效果。

BI应用中的三大矛盾

17 条回复

　　因为近期工作的变更，一直在忙一些杂七杂八的东西，工作交接、离职手续及对新工作的思路整理，目前还处在这个阶段，所以可能近期没有比较新的内容跟大家分享，最近的几篇文章会以一些总结的内容为主，主要是对之前的工作中的一些感想。但相信之后会有更加丰富的数据分析相关的内容向大家呈上，因为我相信我要去的新公司是一个朝气蓬勃、充满创意和挑战的地方，而最重要的是他们对数据的重视和理解。

　　看到文章标题，相信大家已经知道这篇文章还是关于BI方面的，其实这是我刚进现在所在公司的时候所写的一篇文章，现在回头看来即使一直努力地在协调好这些矛盾，但说实话最终没有一个是真正完完全全的解决了的。我相信如果其他公司也是自己搭建BI系统的话，多多少少也会遇到这些问题，可能其中的一两个矛盾现在也正困扰着大家，我这里提供了我的解决方案，至于可行性和效果，有待大家去验证。

矛盾一：业务部门对数据的理解与数据部门对需求的理解

　　把它放在第一位是因为这个直接影响着数据所能发挥的效用，或者说这个矛盾没协调好的话，数据所能创造的价值将大打折扣。造成这个矛盾的原因就是业务部门无法了解数据的获取、处理、计算整个流程，从而对数据的含义和用处产生了自己的理解；同时数据部门无法真正了解业务需求，不清楚数据到底用于何处，为了监控或评估产品的哪个方面，于是无法提供最优或最有效的数据。

　　解决方案：建立业务部门与数据部门间的接口。这个接口包括规范的流程、详细的文档、合理的数据展现，而最重要的还是能够衔接起业务和数据之间的人。

　　首先是数据需求流程的规范化，也就是需求一般由业务部门提起，通过数据部门对数据的获取和计算将结果返回给业务部门，这个流程中业务部门不仅要提供数据的规则，同时应该对获取数据的目的、指标的定义、用处和价值做出详细的描述；而数据部门不仅要给出最终数据，同时需要对指标的获取途径、计算方法作出解释，最终的目的都是为了使双方在理解上能够达成一致。

　　其次是详细的文档。这个其实就是上面所说的流程中必然会产生的两类文档：数据需求文档和数据解释文档（在数据仓库里面是元数据的重要组成部分，关于数据仓库的元数据一直想整理一篇文章出来，希望在之后尽快贴上来），文档的内容基本就是包含上面流程中提到的那些内容。

　　再者就是合理的数据展现。其实就是一个原则：让每个人看到自己想看的数据，并能直观地理解这些数据。无论是报表、Excel还是其他展现方式，每个指标都应该能够有途径去直接查看相应的数据解释文档，而数据应该以最直观的方式展现出来以方便理解，借助各类图表结合的方式。

　　最后也是最重要的一点就是业务与数据的衔接者。这类人员应该对产品的战略目标、业务流程十分熟悉，同时对数据的获取途径、计算方法也了如指掌，或许不需要涉及高技术难度的数据ETL处理、组织和优化，但必须具备自己去计算和获取各类数据的能力。

矛盾二：业务需求的不断变化与生成数据的复杂流程

　　业务需求是不断变化的，尤其是身在互联网这个发展迅速的环境中。所以我们往往会遇到每天业务部门都会有新的需求过来，或者几天前某个指标的计算逻辑在几天之后就发生了变化。而数据部门面对这些情况，往往会陷入困境，一方面由于数据获取上的问题导致某些指标没法计算得到，另一方面指标计算逻辑的改变可能需要改动到整个复杂的数据处理流程，令人头疼。

　　解决方案：集成化的完整的底层数据与快速灵活的数据获取途径。

　　其实在关于数据仓库架构的文章中就提到过数据仓库尽量保存所有的底层细节数据，包括原始的日志点击流数据和前台数据库的ODS数据以及其他来源的数据，其实我不太建议数据仓库是单纯根据需求建立起来的多维模型，因为需求始终会变，但多维模型在应对变化时有缺失灵活性。而如果保存的底层数据，其实在大部分时间内就能做到以不变应万变，因为几乎所有的指标都是从这些底层数据中计算得到的，拥有了底层数据相当于满足了大部分数据的需求。

　　还有一个问题就是对需求改变时的及时应变，一种方法是建立面向不同主题的多维模型（当然是在底层数据的上层建的），因为多维模型能够满足从多个角度多个层面对数据的观察分析，能够从一定程度上解决数据的多样需求；同时基于底层数据集成化的组织管理环境，使用标准化的统计语言，如SQL语句，借助其强大的对数据的聚合、排序、分组等能力，加速数据的获取和计算。

矛盾三：数据即时查询的效率与海量数据的处理和建模

　　其实这里又是一个权衡的问题，即如何在提供足够丰富的指标的前提下保证数据的展现、获取和查询的效率能够满足数据需求方的要求。如果提供的指标不够，或者数据的粒度不够细，就无法满足日常数据监控和分析需要；相反，如果每天计算和统计的指标过多或者数据分得太细，那么显然会增加服务器运算的负荷，同时在数据查询上的响应能力也会相应的下降。

　　解决方案：把握核心数据，建立合理的多维模型。

　　其实数据仓库中海量数据的处理和查询效率的问题本身就是一门很深的学问，涉及数据仓库结构和ETL的优化、OLAP的优化（上一篇文章——OLAP的基本特征有提到Oracle在这方面所做的优化），这里不谈论这些技术上的实现途径，还是说应用上的。

　　核心数据，简单说就是网站的目标、KPIs等，这些数据是从高层到基层人员都在时刻关注的数据，所以最优先的原则就是保证这些数据的查询效率和及时响应。最简单的做法就是这些指标独立统计，不放入多维模型，只做每天的简单聚合存入Summary表中直接供报表展现。

　　另一个就是建立合理的多维模型，说到合理这里又要抱怨下，数据的需求方起初会漫无边际地提各种需求，可能会有上百个指标，但一旦统计出来之后很少会有人真正去使用和分析这些指标（估计是因为看了会眼花），这个我在关于实时数据统计中提到过类似问题。因为在多维模型中增加一个维或维的层次加深一层，对于立方的数据是以乘积方式递增的，比如增加一个100条记录的维相当于立方的数据乘以100，或者时间维的粒度从天到小时，相当于数据量是原先的24倍，这个对于那些本身数据量就非常庞大的多维模型而言本身就是一场灾难。所以建立多维模型时的原则是提供实际应用中需要的维和指标，同时把握好各个维的层次粒度。

　　上面就是我遇到的三大难题了，一下子又写了这么多，希望大家有耐心看完。其实之前的工作也较多地涉及了一些技术上面的东西，主要是Oracle和PL/SQL，由于对于那方面不是很擅长，另外博客主要面向网站数据分析方面的主题，所以很多总结的东西也不敢拿出来献丑，如果大家希望也有这个方面的讨论的，我可以分享几篇上来，大家可以留言给我点建议。

OLAP的基本特征

7 条回复

　　又是一篇关于商务智能（BI）方面的文章，前面有几篇文章介绍了数据仓库、多维模型和OLAP方面的知识。这篇文章主要总结了OLAP具备的一些基本特征，以及其在数据的处理、展示和分析中体现的优势。

　　其实我们大部分时间是在模仿，参考书本或者他人的范例，而当我们去实现这些东西的时候，我们又会有自己的体验，我们需要将这些体验记录下来，当我们能够自己去总结整个实现过程的时候，其实可以认为我们已经掌握了这个知识或技能。而正是在总结的过程中，我们也许会发现原先的范例可能并不是最优的，我们会产生自己的思考和优化方案，其实到这一步的时候你已经实现了一个超越，而当你自己的方案被实践所验证时，那么可能你已经站在了一些人的前面了。而我今天要做的就是——“总结”。

OLAP的类型和基本操作

　　先来回顾下一些基础知识，之前的文章——数据立方体与OLAP中介绍过OLAP的一些基本知识，包括OLAP的类型：ROLAP、MOLAP、HOLAP。

　　以及OLAP的基本操作：钻取（Drill-down）、上卷（Roll-up）、切片（Slice）、切块（Dice）以及旋转（Pivot）。

　　因为这些在之前的文章中都有介绍，这里不再重复了，有兴趣了解的同学直接去看我之前的那篇文章即可。

OLAP的优势

　　OLAP的优势包括之前提到的丰富的数据展现方式、高效的数据查询以及多视角多层次的数据分析。这里再补充两点，是Oracle 11g的官方文档介绍OLAP时提到的在Oracle中使用Cube所具备的优势（当然Oracle里面的Cube指的是MOLAP类型的数据组织方式，有点偏技术了）：

　　从细粒度数据到汇总数据的预聚合（fine-grained approach to pre-aggregating summary data）：Oracle的Cube提供了基于成本的预聚合（Cost based pre-aggregation），也就是既不会完全不进行预先的聚合，也不会将每个维每个层次的数据都预先聚合起来；而是会去考虑对于每条记录聚合的成本，并将那些在动态聚合中相对高成本的记录预先聚合并储存起来，这样相当于权衡了立方数据加载时的压力和数据查询时的效率（过度的预聚合会使数据加载的时间和空间成本提高，而过少的预聚合则会让数据查询的效率降低）。而其最终实现的就是最具性价比的快速查询（fast query）。

　　维和立方之间的预关联（pre-joining of dimensions to cube）：当然这个也是基于MOLAP所具有的优势，MOLAP是基于数组来构建的，所以维和立方之间是预关联的，也就是相比ROLAP而言，其消除了构建索引以及建立表或物化视图时所需要的额外的时间开销，而在聚合数据的时候也避免了维和立方之间的多次关联。

OLAP的基本特征

　　进入主体内容，下面是我自己对OLAP所具备的基本特征的总结，当然包括一些国外的博客和相关网站的介绍（现在打开某些国外的网站还真累），Oracle的一些文档资料以及自己在实际使用时的体会。其实每个特征都从不同层面上体现着OLAP对数据的组织、处理和分析上的优势。

数据建模（Data Modeling）

　　我们知道数据仓库的特征之一是面向主题的，而数据模型的构建正是为了将原本基于业务关系的数据整理成更符合人们日常观察事物的一般方式，多维模型让人们对数据的观察更加得心应手，数据建模的优势就是体现在简化了复杂的数据组织逻辑和关系。

多维与可视化（Multidimensional and Visual）

　　多维和可视化体现在对数据多视角多层次的展现上。其实多维模型的OLAP在可视化层面上主要体现在报表上的钻取、上卷、切片等操作，如果用过Mondrian的开源OLAP引擎就能体验到其实就是一个类似树形结构的展开，就像Windows里面的资源管理器左侧列表，这个符合人们日常观察和使用的习惯。同时大部分的报表工具都支持此类的OLAP展示，MDX（Multi-Dimensional Expression，多维表达式）就是专门为多维OLAP打造的查询语法标准。

聚合（Aggregation）

　　聚合的优势体现在满足了从细节数据到高度汇总数据的不同需求。聚合的特征在多维模型中体现为预计算（pre-calculated）以及快速查询（fast query）上面，能够在不同的数据粒度上对数据进行聚合汇总，满足数据的多种需求。

计算度量（Calculated Measures）

　　计算度量更加丰富地表现了各类指标的延伸、比率及变化趋势等。最简单的计算度量就是指标间的加减乘除、排名及比例，常见的例子就是销售额减成本计算得到利润，进而根据利润对不同的产品进行排名，或者计算各类产品类型的利润所占的比例等；另外一种就是基于时间序列上计算得到的度量，比如同比增长、环比增长、期初累计、移动平均等。所以计算度量的存在让我们的分析指标有了更多的选择。

预测（Forecast）

　　其实熟悉OLAP，用过相关OLAP工具的朋友都知道，大部分的OLAP都会提供预测的功能，一般是基于时间序列的预测，工具直接提供相应的预测方法，比如加权移动平均法、指数平滑法（历史数据加权平均的不断迭代的过程）等。因为在实践中没有用到过，所以这里也不便讨论起具体的意义多大，但这种不需要自己去写算法，而直接使用工具根据相应的聚合数据预测未来的趋势，至少能为我们快捷地展现数据可能的走向，并做出可能调整。

　　好了，今天的总结就到这里，不知道对你来说是不是也有些许收获。

一个有效的内容推荐方法

17 条回复

　　内容推荐，似乎对于网站而言是个有点技术难度的功能实现，目前大部分网站可能都会提供热门内容排行的展示，这可以认为是最简单的推荐，因为只需要对内容的浏览量、下载量、评论量等进行排序即可，所以对于后台的计算不会造成太大的压力。但同样不需要高深的算法和复杂的数据处理流程，我们在内容推荐上可以做得更多，更有创意，当然也可能更具效益。

为什么要推荐

　　首先再来明确下为什么要进行内容推荐？我的理解是如果用户有特定需求，并且用户对自身的需求十分明确，那么用户会利用网站上可以使用的途径来寻找自己需要的信息，只要你的网站提供足够高效的渠道。而当用户对自身的需求并没有那么明确，或者用户从没发觉你的网站上存在一些会如此让他着迷的东西，那么显然用户很难发现这些内容，这个时候就需要一个有效的内容推荐途径来帮助用户了，给用户装上一个智能导航系统。

　　但往往我们很容易就陷入了这样一个思维怪圈：向用户推荐与用户的兴趣相关的内容，这确实是一个很棒的个性化服务的应用，我之前也写过此类的文章——向上营销、交叉营销与关联推荐；但这个毕竟实现起来需要一定的成本，而且如果把推荐限制在这个个性化的层面，容易让自己走入死胡同，或许不需要这么复杂，我们可以找到其他有效的推荐方法，而且可能对于中小网站其效果也不会比基于高级算法的个性化推荐功能会差。

选择简单有效的推荐方法

　　这里要介绍的推荐功能基于一个简单的实现方式，即在首页或者网站的侧边栏的某个模块中开辟一块小区域来放些你想要推荐的内容，正如我的博客首页导航栏正下方的滚动内容推荐。其实这个推荐的思维形式很简单，就是不要忽视用户的眼光和选择，把用户认为有趣的内容推荐给其他的用户。

　　首先要认识到的是那些网站曝光度很高的内容可能不需要你做另外的推荐，这也是这里要介绍的这个推荐方法与常见的热门推荐间的最大不同。因为用户能够找到途径去发现这些内容，可以看一下Google的网站管理员工具上对于“指向网站的链接”排名：

　　再看一下Google Analytics的Top Landing Pages的排名：

　　很显然用户可以找到一些渠道进入这些页面来查看内容，所以我们真的需要推荐的不是这些。那些转化率高（或者Avg. Time on Page）高的，但曝光度不够（用户找不到，或者没有意识到）的内容才是我们推荐的重点。因为它们拥有较高的转化率，能够直接帮你实现网站的目标，同时考虑较低的Bounce Rate或者较高的停留时间说明这些内容对用户具有一定的吸引力，这也是它们值得被推荐的理由，我们可以把它们展示到显眼的位置。

　　好的，既然我们已经有了思路，接下去就是寻找上面所说的值得推荐的内容了。这里不得不介绍下Google Analytics推出的新功能——Weighted Sort，进入Content模块的Top Content，先点击$ Index排序，就会出现一个Weighted Sort的勾选框，勾上它预期的效果就出来了：

　　接下去就是选择那些Unique Pageviews相对较低的内容放到推荐模块，这个工作就完成了，是不是很简单。

　　当然还有其它的方法，比如如果你已经将数据导出到Excel，那么在上面进行自定义排序会是个好方法：根据Conversion Rate、Avg. Time on Page降序，再按照Pageviews升序后，也就你就看到你该推荐的内容了。如果你的数据存在了数据仓库，那就更方便了，SQL强大的Order By功能就可以发挥作用了。

　　好了，我已经把自己的分析结果应用到我的博客首页面内容滚动展示模块的，你也可以尝试下这个推荐方法，也许会带来不错的效果。