月度归档:2010 年十二月

网站KPI的质量控制

——数据的上下文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σ的线):

p-chart-sample

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

  1. 12月8日的数据低于LCL,表现异常;
  2. 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σ的线):

X-MR-chart-sample1

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

X-MR-chart-sample2

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

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

质量控制图

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

质量控制图的概念与用处

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

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

Control-Chart   质量控制图通过统计上均值μ和标准差σ的状况来衡量指标是否在稳定状态,同时选择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均值,上横线很难打出来,具体见下面图中公式),所以总体均值μ就是ρ,方差σ2就是ρ(1-ρ)/n,进而就可以计算得到中心线CL、控制上限UCL、控制下限LCL:

p-chart-expression

–pk:每组样本的比例值,nk:每组样本容量

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

X-MR控制图

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

x-MR-Chart-expression

–xi、MRi:每个个体的数值和计算得到的极差,k:样本个体数,d2、D3、D4:极差到标准差的转化系数,相当于n=2的极差转化系数,所以在这里可以看作是固定值。

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

ControlChart-Sample

质量控制图的控制规则

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

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

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

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

时间序列的趋势分析

——数据的上下文1

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

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

同比和环比的定义

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

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

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

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

同比和环比的应用环境

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

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

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

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

应用实例

  同比和环比被广泛地应用于各个领域,在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%

time-series-trend-analysis

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

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

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

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

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

数据仓库元数据管理

Meta-Data  元数据管理是整个数据仓库架构中很重要的一块(关于数据仓库的架构,请参考这篇文章——数据仓库的基本架构),但发其实现很多书里面都没有对元数据下一个详细的定义,或者没有系统地介绍到底数据仓库的元数据应该包括哪些。下面是我个人整理的一些对元数据管理的看法,主要来自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)里面,当然你也可以自己整理出相应的文档,供不时的查询和分享的需要。

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

用户需要什么数据?

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

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

目标和KPI

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

  主要关注人员:决策层

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

细分与功能点

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

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

内容细分

  主要关注人员:产品运营

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

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

different-data-requirement用户细分

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

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

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

来源细分

  主要关注人员:市场推广

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

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

功能点分析

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

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

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

分析模型

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

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

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

自定义Dashboard

dashboard

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

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

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