网站数据分析

数据立方体与OLAP

joegh — Sun, 29 Aug 2010 21:57:19 +0800

　　前面的一篇文章——数据仓库的多维数据模型中已经简单介绍过多维模型的定义和结构，以及事实表（Fact Table）和维表（Dimension Table）的概念。多维数据模型作为一种新的逻辑模型赋予了数据新的组织和存储形式，而真正体现其在分析上的优势还需要基于模型的有效的操作和处理，也就是OLAP（On-line Analytical Processing，联机分析处理）。

数据立方体

　　关于数据立方体（Data Cube），这里必须注意的是数据立方体只是多维模型的一个形象的说法。立方体其本身只有三维，但多维模型不仅限于三维模型，可以组合更多的维度，但一方面是出于更方便地解释和描述，同时也是给思维成像和想象的空间；另一方面是为了与传统关系型数据库的二维表区别开来，于是就有了数据立方体的叫法。所以本文中也是引用立方体，也就是把多维模型以三维的方式为代表进行展现和描述，其实上Google图片搜索“OLAP”会有一大堆的数据立方体图片，这里我自己画了一个：

OLAP

　　OLAP（On-line Analytical Processing，联机分析处理）是在基于数据仓库多维模型的基础上实现的面向分析的各类操作的集合。可以比较下其与传统的OLTP（On-line Transaction Processing，联机事务处理）的区别来看一下它的特点：

OLAP与OLTP

数据处理类型	OLTP	OLAP
面向对象	业务开发人员	分析决策人员
功能实现	日常事务处理	面向分析决策
数据模型	关系模型	多维模型
数据量	几条或几十条记录	百万千万条记录
操作类型	查询、插入、更新、删除	查询为主

OLAP的类型

　　首先要声明的是这里介绍的有关多维数据模型和OLAP的内容基本都是基于ROLAP，因为其他几种类型极少接触，而且相关的资料也不多。

MOLAP(Multidimensional)

　　即基于多维数组的存储模型，也是最原始的OLAP，但需要对数据进行预处理才能形成多维结构。

ROLAP(Relational)

　　比较常见的OLAP类型，这里介绍和讨论的也基本都是ROLAP类型，可以从多维数据模型的那篇文章的图中看到，其实ROLAP是完全基于关系模型进行存放的，只是它根据分析的需要对模型的结构和组织形式进行的优化，更利于OLAP。

HOLAP(Hybrid)

　　介于MOLAP和ROLAP的类型，我的理解是细节的数据以ROLAP的形式存放，更加方便灵活，而高度聚合的数据以MOLAP的形式展现，更适合于高效的分析处理。

　　另外还有WOLAP(Web-based OLAP)、DOLAP(Desktop OLAP)、RTOLAP(Real-Time OLAP)，具体可以参开维基百科上的解释——OLAP。

OLAP的基本操作

　　我们已经知道OLAP的操作是以查询——也就是数据库的SELECT操作为主，但是查询可以很复杂，比如基于关系数据库的查询可以多表关联，可以使用COUNT、SUM、AVG等聚合函数。OLAP正是基于多维模型定义了一些常见的面向分析的操作类型是这些操作显得更加直观。

　　OLAP的多维分析操作包括：钻取（Drill-down）、上卷（Roll-up）、切片（Slice）、切块（Dice）以及旋转（Pivot），下面还是以上面的数据立方体为例来逐一解释下：

　　钻取（Drill-down）：在维的不同层次间的变化，从上层降到下一层，或者说是将汇总数据拆分到更细节的数据，比如通过对2010年第二季度的总销售数据进行钻取来查看2010年第二季度4、5、6每个月的消费数据，如上图；当然也可以钻取浙江省来查看杭州市、宁波市、温州市……这些城市的销售数据。

　　上卷（Roll-up）：钻取的逆操作，即从细粒度数据向高层的聚合，如将江苏省、上海市和浙江省的销售数据进行汇总来查看江浙沪地区的销售数据，如上图。

　　切片（Slice）：选择维中特定的值进行分析，比如只选择电子产品的销售数据，或者2010年第二季度的数据。

　　切块（Dice）：选择维中特定区间的数据或者某批特定值进行分析，比如选择2010年第一季度到2010年第二季度的销售数据，或者是电子产品和日用品的销售数据。

　　旋转（Pivot）：即维的位置的互换，就像是二维表的行列转换，如图中通过旋转实现产品维和地域维的互换。

OLAP的优势

　　首先必须说的是，OLAP的优势是基于数据仓库面向主题、集成的、保留历史及不可变更的数据存储，以及多维模型多视角多层次的数据组织形式，如果脱离的这两点，OLAP将不复存在，也就没有优势可言。

数据展现方式

　　基于多维模型的数据组织让数据的展示更加直观，它就像是我们平常看待各种事物的方式，可以从多个角度多个层面去发现事物的不同特性，而OLAP正是将这种寻常的思维模型应用到了数据分析上。

查询效率

　　多维模型的建立是基于对OLAP操作的优化基础上的，比如基于各个维的索引、对于一些常用查询所建的视图等，这些优化使得对百万千万甚至上亿数量级的运算变得得心应手。

分析的灵活性

　　我们知道多维数据模型可以从不同的角度和层面来观察数据，同时可以用上面介绍的各类OLAP操作对数据进行聚合、细分和选取，这样提高了分析的灵活性，可以从不同角度不同层面对数据进行细分和汇总，满足不同分析的需求。

　　是不是觉得其实OLAP并没有想象中的那么复杂，一旦多维数据模型建成后，在上面做OLAP其实是一件很cool的事情。

　» 本文采用 BY-NC-SA 协议，转载请注明来源：网站数据分析 » 《数据立方体与OLAP》

Share and Enjoy:

关于实时数据统计

joegh — Mon, 23 Aug 2010 20:32:31 +0800

　　随着互联网的不断发展，信息更注重实时性，微博的风靡，搜索引擎相继推出实时搜索的功能，但是对于网站分析而言实时的数据是否更有意义呢？

　　其实看数据看报表的人往往希望数据越实时越好，他们希望掌握网站每个小时甚至每十分钟的变化情况，能够对网站的当前状况了如指掌，能够发现问题并快速响应。但其实如果你问下他们在知道了网站数据的实时变化情况后，或者在某个时间段网站访问量突然剧增或者剧增，我们又能做些什么？我估计大多数人答不上来。刚好前段时间在做网站的实时数据统计相关的工作，所以有些想法在这里分享一下。

实时统计的优缺点

　　先不说实时统计到底有用还是没用，先看看如果需要获得实时的统计数据需要做些什么，以及实时的数据能够给我们带来什么，也就是实时统计的Pros and Cons。

　　首先从技术的角度来看一下，很明显实时的数据统计需要更多的资源占用，因为网站分析的数据大部分是需要从点击流数据中计算得到的，并没有现成的结果数据可以直线获取显示。从点击流中获得的数据需要进行计算和汇总，无疑这些操作需要更多的成本，特别对于大型网站的大数据量处理而言，同时实时数据增加了实现的复杂度，并可能会在某种程度上增加数据的不准确性。

　　但是实时的数据统计可以展现在技术层面上处理数据的能力，同时可以提供更丰富的报表展示，甚至在报表上使用动态的趋势图表进行实时刷新，在显示效果上自然不用说，所以有时候很多技术人员也很乐意做这些工作。

　　再从数据应用和分析的角度来看一下，目前很多实时数据统计的结果用于展示网站实时流量的变化情况，哪个时间段的访问量最高，或者网站的整体活跃度最高，同时可以分析每天各小时的流量或用户数分布，但这些分析的对于网站到底有多大的意义？即使知道网站在晚上8、9点的时候有最多的在线用户，我们又能做些什么？网站的压力测试显然不需要通过这种方式来完成。

　　所以个人认为实时统计更多的是对网站实时状态的监控，对于分析而言，没有多大的实际意义，至于能对网站的优化和决策支持起到多少作用，至少我还没有想到。

　　记到Avinash Kaushik在书中提到过一句话：“Real-Time Data: It’s Not Really Relevant, and It’s Expensive to Boot.” 其实我对这句话非常赞同。很多人都会觉得获取实时数据将更有利于做出实时的响应，细粒度的数据也为数据的分析提供了更加细节的基础数据，我们可以基于此做更多的分析工作，但我们需要认清实时数据给我们带来的成本及其真正的价值到底能够体现多少。Avinash Kaushik同时还列举了5中典型的获取实时数据所造成的消极影响，大致可以概括为以下几点：

不要一味追求数据的量，更应该注重数据的质，并通过有效的分析来体现数据的价值；
不符合10/90的原则，实时数据在获取上的成本显然无法和分析价值达成1:9的比例；
过多地关注实时数据会在分析工具的选择上造成拘束，无法使用真正优秀的网站分析工具；
技术上的系统资源占用、任务调度以及复杂的流程；
在某种程度上可能增加数据的不准确性。

　　当然实时数据也不是一点价值都没有，只是出于其成本的考虑，没有必要对每个分析指标进行实时统计，或者花费大量的精力去关注实时数据。

实时数据的价值

　　其实无论是Google Analytics还是百度统计，都提供了部分指标的每小时的统计数据。百度统计将实时数据统计放在网站概况里面显示，也就是用户只要一登录就能看到当天的PV、UV等整点数据的变化趋势：

　　而在Google Analytics中，可能我们会发现GA一般都是以天为单位显示各度量，但其实GA也有以整点统计的数据，只是潜藏的比较“深”，在Visitors—Visitor Trending里面，在Visits、Pageviews、Bounce Rate等报表中会发现右上方时间区间选择下面的时间汇总粒度多了一个选项——Hour，选择后就会看到每天个小时的数据变化趋势：

　　实时数据也并非一无是处，Avinash Kaushik认为当一个公司具有快速的分析能力、快速的决策能力和快速的执行能力时，那么实时的数据就能创造其价值。我这里举几个我想到的应用，如果我们能够获取到每小时的统计数据，那么我们就能知道网站在哪个时间段具有最高的用户访问数，可以在这个时间段做些推广活动，并通过实时的数据统计分析活动的效果，做出快速合理的反应。比如“秒杀”活动就需要在极短的时间内完成统计并展示结果，当然前提是需要在后台的统计系统可以承受的条件下。

　　最后还是借用Avinash Kaushik的一句话作为总结：如果只是为了看实时数据而进行实时统计，而不是根据实时数据做出相应的action，那么实时数据就是相当昂贵的。

　　轮到你了，大家有什么在实时数据分析上的想法吗？也许可以让我之前实现的实时数据产生除了实时监控外更有价值的结果，欢迎留言评论。

　» 本文采用 BY-NC-SA 协议，转载请注明来源：网站数据分析 » 《关于实时数据统计》

Share and Enjoy:

数据仓库的多维数据模型

joegh — Tue, 17 Aug 2010 20:09:07 +0800

　　可能很多人理解的数据仓库就是基于多维数据模型构建，用于OLAP的数据平台，通过上一篇文章——数据仓库的基本架构，我们已经看到数据仓库的应用可能远不止这些。但不得不承认多维数据模型是数据仓库的一大特点，也是数据仓库应用和实现的一个重要的方面，通过在数据的组织和存储上的优化，使其更适用于分析型的数据查询和获取。

多维数据模型的定义和作用

　　多维数据模型是为了满足用户从多角度多层次进行数据查询和分析的需要而建立起来的基于事实和维的数据库模型，其基本的应用是为了实现OLAP（Online Analytical Processing）。

　　当然，通过多维数据模型的数据展示、查询和获取就是其作用的展现，但其真的作用的实现在于，通过数据仓库可以根据不同的数据需求建立起各类多维模型，并组成数据集市开放给不同的用户群体使用，也就是根据需求定制的各类数据商品摆放在数据集市中供不同的数据消费者进行采购。

多维数据模型实例

　　在看实例前，这里需要先了解两个概念：事实表和维表。事实表是用来记录具体事件的，包含了每个事件的具体要素，以及具体发生的事情；维表则是对事实表中事件的要素的描述信息。比如一个事件会包含时间、地点、人物、事件，事实表记录了整个事件的信息，但对时间、地点和人物等要素只记录了一些关键标记，比如事件的主角叫“Michael”，那么Michael到底“长什么样”，就需要到相应的维表里面去查询“Michael”的具体描述信息了。基于事实表和维表就可以构建出多种多维模型，包括星形模型、雪花模型和星座模型。这里不再展开了，解释概念真的很麻烦，而且基于我的理解的描述不一定所有人都能明白，还是直接上实例吧：

　　这是一个最简单的星形模型的实例。事实表里面主要包含两方面的信息：维和度量，维的具体描述信息记录在维表，事实表中的维属性只是一个关联到维表的键，并不记录具体信息；度量一般都会记录事件的相应数值，比如这里的产品的销售数量、销售额等。维表中的信息一般是可以分层的，比如时间维的年月日、地域维的省市县等，这类分层的信息就是为了满足事实表中的度量可以在不同的粒度上完成聚合，比如2010年商品的销售额，来自上海市的销售额等。

　　还有一点需要注意的是，维表的信息更新频率不高或者保持相对的稳定，例如一个已经建立的十年的时间维在短期是不需要更新的，地域维也是；但是事实表中的数据会不断地更新或增加，因为事件一直在不断地发生，用户在不断地购买商品、接受服务。

多维数据模型的优缺点

　　这里所说的多维模型是指基于关系数据库的多维数据模型，其与传统的关系模型相比有着自身的优缺点。

优点：

　　多维数据模型最大的优点就是其基于分析优化的数据组织和存储模式。举个简单的例子，电子商务网站的操作数据库中记录的可能是某个时间点，某个用户购买了某个商品，并寄送到某个具体的地址的这种记录的集合，于是我们无法马上获取2010年的7月份到底有多少用户购买了商品，或者2010年的7月份有多少的浙江省用户购买了商品？但是在基于多维模型的基础上，此类查询就变得简单了，只要在时间维上将数据聚合到2010年的7月份，同时在地域维上将数据聚合到浙江省的粒度就可以实现，这个就是OLAP的概念，之后会有相关的文章进行介绍。

缺点：

　　多维模型的缺点就是与关系模型相比其灵活性不够，一旦模型构建就很难进行更改。比如一个订单的事实，其中用户可能购买了多种商品，包括了时间、用户维和商品数量、总价等度量，对于关系模型而言如果我们进而需要区分订单中包含了哪些商品，我们只需要另外再建一张表记录订单号和商品的对应关系即可，但在多维模型里面一旦事实表构建起来后，我们无法将事实表中的一条订单记录再进行拆分，于是无法建立以一个新的维度——产品维，只能另外再建个以产品为主题的事实表。

　　所以，在建立多维模型之前，我们一般会根据需求首先详细的设计模型，应该包含哪些维和度量，应该让数据保持在哪个粒度上才能满足用户的分析需求。

　　这里对数据仓库的多维模型进行了简单的介绍，你是不是想到了其实你在分析数据的时候很多的数据就是复合多维模型的结构的，或者你已经用自己的方法构建出了多维模型或者实现的数据的多维化展示，欢迎与我分享。

　　文章当时发的时候好像有点问题，后面有段没更新进去，评论也被关了，居然发布了近两周才发现，现在补上了，对所有看过这篇文章的朋友说声抱歉！

　» 本文采用 BY-NC-SA 协议，转载请注明来源：网站数据分析 » 《数据仓库的多维数据模型》

Share and Enjoy:

网站的活跃用户与流失用户

joegh — Sun, 08 Aug 2010 23:44:04 +0800

　　网站用户管理的目标是发掘新用户，保留老用户。但仅仅吸引新用户还不错，还需要保持新用户的活跃度，使其能持久地为网站创造价值；而一旦用户的活跃度下降，很可能用户就会渐渐地远离网站，进而流失。所以基于此，我们可以对用户进行又一个细分——活跃用户和流失用户。

活跃用户与流失用户

　　活跃用户，这里是相对于“流失用户”的一个概念，是指那些“存活”着的用户，用户会时不时地光顾下网站，同时为网站带来一些价值。同时，我们还需要知道到底有多少用户可能已经抛弃了我们的网站，不可能再为网站创造任何的价值，也就是所谓的流失用户。

　　流失用户，是指那些曾经访问过网站或注册过的用户，但由于对网站渐渐失去兴趣后逐渐远离网站，进而彻底脱离网站的那批用户。当然，一个网站一定会存在流失用户，这是网站用户新老交替中不可避免的，但流失用户的比例和变化趋势能够说明网站保留用户的能力及发展趋势。

　　举个简单的例子，我们经常可以看到某些数据分析报告中说：某某网站的注册用户数已经超过几百万，但其实这些数据并没有太大的意义，因为可能这几百万里面很多用户都已经不再登录该网站（流失用户），真正最近登录过或有过操作行为的用户（活跃用户）其实不到一万。所以对于一个网站而言，真正有意义的是活跃用户数而非总用户数，因为只有这些用户在为网站创造着价值。

　　活跃用户用于衡量网站的运营现状，而流失用户则用于分析网站是否存在被淘汰的风险，以及网站是否有能力留住新用户。

活跃用户分析

　　我的博客中之前的文章——用Engagement衡量用户活跃度中已经介绍了用户活跃度的衡量方法，并基于Engagement的定义计算网站的活跃访问量（Visits），同样可以用这类方法计算网站的活跃用户数（Unique Visitors）。同时可以计算不同时间区间的活跃用户数，比如每天、每周、每月……这里就不再详细介绍了，需要注意以下几个问题：

用户Engagement的定义，并以唯一用户为单位进行统计；
只要用户有任一一个Engagement的行为，就可以定义为活跃用户；
不要仅关注活跃用户数，试着分析活跃用户的变化趋势和所占比例。

流失用户分析

　　流失用户的定义比较简单，就是一段时间内未访问或登录过网站的用户，一般流失用户都是对于那些需要注册、提供应用服务的网站而言的，比如微博、邮箱、电子商务类网站等。不同网站对于流失的定义可能各不相同，对于微博和邮箱这类用户几乎每天登录查看的网站而言，可能用户未登录超过1个月，我们就可以认为用户可能已经流失了；而对于电子商务而言，可能3个月未登录或者半年内没有任何购买行为的用户可以被认定是流失用户。下面的分析主要是基于网站的注册用户的，因为这类用户更容易识别，而且分析这类用户的流失情况对网站而言更有意义。

数据的获取

　　流失用户是通过用户的最近一次登录距离当前的时间来鉴定的，所以要分析流失用户，需要知道每个用户的最后一次登录时间，而对于不同网站而言，这个时间间隔会各不相同，最长可能会有1年或者更久，所以在数据获取方面会有一定的难度。如果分析的是注册用户，那么一般网站都会在数据库中建相应的表来存放用户信息，所以建议在储存用户基础信息的同时记录用户的最近一次登录时间，这样就能够准确地计算用户最近一次登录距离当前的间隔时间，进而区分该用户是否流失。

流失用户变化趋势

　　首先需要明确的是用户的流失可能并不是永久的，也许用户在一段时间内对网站确实没有任何需求，那么他会远离网站一段比较长的时间；或者流失用户也会因为网站的某次营销或者网站质量的改善而重新回来。网站总的流失用户数的计算比较简单，以超过1个月内登录即为流失为例，那么总流失用户数就是所有“当前时间点-用户最近一次时间点>1个月”的用户数量。但是单纯的总流失用户数量对于分析是没有意义的，因为大部分情况下这个数值是一直递增的，我们需要计算总流失用户数占总用户数的比例及新增流失用户数，观察它们的变化趋势，如下表：

日期	总用户数	流失用户数	新增流失用户数	用户流失率
2010年8月1日	325694	228451		70.14%
2010年8月2日	326127	228925	474	70.20%
2010年8月3日	326789	229507	582	70.23%
2010年8月4日	326297	230023	516	70.49%
2010年8月5日	326913	230618	595	70.54%
2010年8月6日	327514	231209	591	70.60%
2010年8月7日	328163	231672	463	70.60%
2010年8月8日	328517	232216	544	70.69%
……	……	……	……	……

新用户流失率

　　也许你的网站已经吸引了一批新的访客，并且他们成功注册成为了网站的用户，你有了一个好的开始，已经成功了一半，那么另一半呢？就是如何保留住这些新的用户，让他们持续地为网站带来价值，这就是分析新用户流失率的意义。

　　我们可认为新用户注册后就完成首次登陆，那么简单地定义新用户流失，就是用户在注册后一段时间内都没有登录过网站，即

当前时间点 – 用户注册时间点 > 流失临界时间间隔

　　比如我们定义用户的流失临界时间间隔为1个月，也就是在注册后的一个月内未登录的用户意味着已经流失，那么就可以计算每天的新用户流失数，即注册时间为1个月前的那一天，而从注册到当前没有登录过的用户数。这个用户数与1个月前的那一天的总注册用户数的比例就是新用户的流失率：

当天的新用户流失数 / 当天的总注册用户数 = 新用户流失率

　　计算出每天的新用户流失率，并观察它的变化趋势：

　　网站能否保留住新用户就在于是否能够不断地降低新用户的流失率。

　　总结，这里主要介绍的是如何分析网站真正拥有的有价值的活跃用户的数量以及网站保留这些用户的能力，可以用流失用户的变化趋势来衡量网站用户的总体流失情况，用新用户流失率衡量网站保留住新用户的能力，而分析活跃用户数的比例和变化趋势分析能够衡量网站现有用户的质量和价值。

　» 本文采用 BY-NC-SA 协议，转载请注明来源：网站数据分析 » 《网站的活跃用户与流失用户》

Share and Enjoy:

数据仓库的基本架构

joegh — Sun, 01 Aug 2010 21:50:35 +0800

　　数据仓库的目的是构建面向分析的集成化数据环境，为企业提供决策支持（Decision Support）。其实数据仓库本身并不“生产”任何数据，同时自身也不需要“消费”任何的数据，数据来源于外部，并且开放给外部应用，这也是为什么叫“仓库”，而不叫“工厂”的原因。因此数据仓库的基本架构主要包含的是数据流入流出的过程，可以分为三层——源数据、数据仓库、数据应用：

　　从图中可以看出数据仓库的数据来源于不同的源数据，并提供多样的数据应用，数据自上而下流入数据仓库后向上层开放应用，而数据仓库只是中间集成化数据管理的一个平台。

　　数据仓库从各数据源获取数据及在数据仓库内的数据转换和流动都可以认为是ETL（抽取Extra, 转化Transfer, 装载Load）的过程，ETL是数据仓库的流水线，也可以认为是数据仓库的血液，它维系着数据仓库中数据的新陈代谢，而数据仓库日常的管理和维护工作的大部分精力就是保持ETL的正常和稳定。

　　下面主要简单介绍下数据仓库架构中的各个模块，当然这里所介绍的数据仓库主要是指网站数据仓库。

数据仓库的数据来源

　　其实之前的一篇文章已经介绍过数据仓库各种源数据的类型——数据仓库的源数据类型，所以这里不再详细介绍。

　　对于网站数据仓库而言，点击流日志是一块主要的数据来源，它是网站分析的基础数据；当然网站的数据库数据也并不可少，其记录这网站运营的数据及各种用户操作的结果，对于分析网站Outcome这类数据更加精准；其他是网站内外部可能产生的文档及其它各类对于公司决策有用的数据。

数据仓库的数据存储

　　源数据通过ETL的日常任务调度导出，并经过转换后以特性的形式存入数据仓库。其实这个过程一直有很大的争议，就是到底数据仓库需不需要储存细节数据，一方的观点是数据仓库面向分析，所以只要存储特定需求的多维分析模型；另一方的观点是数据仓库先要建立和维护细节数据，再根据需求聚合和处理细节数据生成特定的分析模型。我比较偏向后面一个观点：数据仓库并不需要储存所有的原始数据，但数据仓库需要储存细节数据，并且导入的数据必须经过整理和转换使其面向主题。简单地解释下：

　　(1).为什么不需要所有原始数据？数据仓库面向分析处理，但是某些源数据对于分析而言没有价值或者其可能产生的价值远低于储存这些数据所需要的数据仓库的实现和性能上的成本。比如我们知道用户的省份、城市足够，至于用户究竟住哪里可能只是物流商关心的事，或者用户在博客的评论内容可能只是文本挖掘会有需要，但将这些冗长的评论文本存在数据仓库就得不偿失；

　　(2).为什么要存细节数据？细节数据是必需的，数据仓库的分析需求会时刻变化，而有了细节数据就可以做到以不变应万变，但如果我们只存储根据某些需求搭建起来的数据模型，那么显然对于频繁变动的需求会手足无措；

　　(3).为什么要面向主题？面向主题是数据仓库的第一特性，主要是指合理地组织数据以方面实现分析。对于源数据而言，其数据组织形式是多样的，像点击流的数据格式是未经优化的，前台数据库的数据是基于OLTP操作组织优化的，这些可能都不适合分析，而整理成面向主题的组织形式才是真正地利于分析的，比如将点击流日志整理成页面（Page）、访问（Visit或Session）、用户（Visitor）三个主题，这样可以明显提升分析的效率。

　　数据仓库基于维护细节数据的基础上在对数据进行处理，使其真正地能够应用于分析。主要包括三个方面：

数据的聚合

　　这里的聚合数据指的是基于特定需求的简单聚合（基于多维数据的聚合体现在多维数据模型中），简单聚合可以是网站的总Pageviews、Visits、Unique Visitors等汇总数据，也可以是Avg. time on page、Avg. time on site等平均数据，这些数据可以直接地展示于报表上。

多维数据模型

　　多维数据模型提供了多角度多层次的分析应用，比如基于时间维、地域维等构建的销售星形模型、雪花模型，可以实现在各时间维度和地域维度的交叉查询，以及基于时间维和地域维的细分。所以多维数据模型的应用一般都是基于联机分析处理（Online Analytical Process, OLAP）的，而面向特定需求群体的数据集市也会基于多维数据模型进行构建。

业务模型

　　这里的业务模型指的是基于某些数据分析和决策支持而建立起来的数据模型，比如我之前介绍过的用户评价模型、关联推荐模型、RFM分析模型等，或者是决策支持的线性规划模型、库存模型等；同时，数据挖掘中前期数据的处理也可以在这里完成。

数据仓库的数据应用

　　之前的一篇文章——数据仓库的价值中介绍过数据仓库的四大特性上的价值体现，但数据仓库的价值远不止这样，而且其价值真正的体现是在数据仓库的数据应用上。图中罗列的几种应用并未包含所有，其实一切基于数据相关的扩展性应用都可以基于数据仓库来实现。

报表展示

　　报表几乎是每个数据仓库的必不可少的一类数据应用，将聚合数据和多维分析数据展示到报表，提供了最为简单和直观的数据。

即席查询

　　理论上数据仓库的所有数据（包括细节数据、聚合数据、多维数据和分析数据）都应该开放即席查询，即席查询提供了足够灵活的数据获取方式，用户可以根据自己的需要查询获取数据，并提供导出到Excel等外部文件的功能。

数据分析

　　数据分析大部分可以基于构建的业务模型展开，当然也可以使用聚合的数据进行趋势分析、比较分析、相关分析等，而多维数据模型提供了多维分析的数据基础；同时从细节数据中获取一些样本数据进行特定的分析也是较为常见的一种途径。

数据挖掘

　　数据挖掘用一些高级的算法可以让数据展现出各种令人惊讶的结果。数据挖掘可以基于数据仓库中已经构建起来的业务模型展开，但大多数时候数据挖掘会直接从细节数据上入手，而数据仓库为挖掘工具诸如SAS、SPSS等提供数据接口。

元数据管理

　　元数据（Meta Date），其实应该叫做解释性数据，即数据的数据。主要记录数据仓库中模型的定义、各层级间的映射关系、监控数据仓库的数据状态及ETL的任务运行状态。一般会通过元数据资料库（Metadata Repository）来统一地存储和管理元数据，其主要目的是使数据仓库的设计、部署、操作和管理能达成协同和一致。

　　最后做个Ending，数据仓库本身既不生产数据也不消费数据，只是作为一个中间平台集成化地存储数据；数据仓库实现的难度在于整体架构的构建及ETL的设计，这也是日常管理维护中的重头；而数据仓库的真正价值体现在于基于其的数据应用上，如果没有有效的数据应用也就失去了构建数据仓库的意义。

　» 本文采用 BY-NC-SA 协议，转载请注明来源：网站数据分析 » 《数据仓库的基本架构》

Share and Enjoy:

网站新老用户分析

joegh — Sun, 25 Jul 2010 22:32:24 +0800

　　网站中新老用户的分析已经成为了网站分析中常见的一类用户细分的方法，也是网站分析中用户分析的一个重要组成。Google Analytics中对新老用户的命名分别为New Visitors和Returning Visitors，同时也为许多的分析指标提供了基于新老用户的细分。

　　简单地说，新用户就是首次访问网站或者首次使用网站服务的用户；而老用户则是之前访问过网站或者使用过网站服务的用户。无论是新老用户都能为网站带来价值，这也是分析的意义所在。

分析新老用户的意义

　　网站的老用户一般都是网站的忠诚用户，有相对较高的粘度，也是为网站带来价值的主要用户群体；而新用户则意味着网站业务的发展，是网站价值不断提升的前提。可以说，老用户是网站生存的基础，新用户是网站发展的动力，所以网站的发展战略往往是在基于保留老用户的基础上不断地提升新用户数。

　　所以分析新老用户的意义就在于：通过分析老用户，来确定网站的基础是否稳固，是否存在被淘汰的危机；通过分析新用户，来衡量网站的发展是否顺利，是否有更大的扩展空间。一个着眼现在，一个放眼未来。

新老用户的辨别

　　对于网站用户的识别，之前写过一篇相关的文章——网站用户的识别，里面主要是在基于点击流日志的基础上提供的4类识别用户的方法，可以作为参考。但对于新老用户的辨别可能根据网站自身的特定而有不同的定义方法。

　　最常见的一种辨别新老用户的方式就是看该用户之前是否访问过网站，也就是以用户是否首次访问来区分，GA就是使用Cookie来定义新老用户的，即该Cookie之前出现过则该访客为老用户，否则为新用户。这个定义适用于所有网站，但有它不准确的地方，Cookie的删除、用户更换PC等都会造成数据上的偏差。

　　另一种辨别方式相对准确，但一般只适用于注册登录型网站，即定义首次注册登录的用户为新用户，再次登录的用户为老用户，而不是使用首次访问来辨别。这种区分方式一般以用户ID或用户名来辨别，相对准确，但应用的范围有限。

新老用户分析

　　网站的目标在于保持老用户，拓展新用户，那么对于网站数据分析上的表现，则是在保持老用户数量的稳定增长的前提下，提升新用户的所占比例。

　　对于大部分发展正常的网站而言，网站的老用户数应该是保持相对稳定的，并且会有持续的小幅上涨，可以看一下GA上我的博客每周老用户数的趋势变化：

　　可以通过GA的Dashboard上的Advanced Segments选择Returning Visitors，并选择合适的时间区间和汇总粒度（日、周、月）显示趋势变化曲线。这条平滑的上升曲线说明网站的发展是趋于正常的。

　　但并不是所有网站的老用户趋势都会如此的平滑，比如旅游网站，旅游业会明显地受到季节的影响呈现比较大的波动，所以这里要引入同比和环比的概念进行分析。

同比指的是为了消除季节变动的影响，将本期的数据与去年同期的数据进行比较，比如今年2月的数据与去年2月数据的比较；

环比指的是将本期的数据与前期的数据进行比较，可以是日环比、月环比、周环比等，例如今年2月与今年1月的数据比较。

　　同比和环比被大量地应用于基于时间序列的趋势分析中，对于网站而言，访问量、销售额、利润等网站关键指标同样可以引用同比和环比进行分析，对于分析这些指标的变化趋势，消除季节的影响等都是有积极的效果。下面是一张基于同比和环比的旅游类网站老用户数据模拟趋势分析图：

　　从图上可以看出由于季节的影响，老用户数的波动比较大，所以相应的环比增长的波动也很大，但同比增长的趋势却相对平滑，一直保持在10%左右的增长率上面，这就可以看出网站对保持老用户是有效的，网站的运营状况较为稳定。

　　可能有人会问，为什么要用绝对数量，而不是用相对数量，比如老用户占总访问用户的比例来进行趋势分析？这里主要考虑到网站会不定期的进行主动地推广营销，或者由于某些事件或媒体传播的影响而产生的被动推广的效果，这个时候可能会吸引大量的新用户进入网站而导致老用户比例的急剧下滑，而老用户的绝对数据对于网站而言相对稳定，更具参考价值。

　　新用户的绝对数量并没有老用户这么稳定，也不一定会保持增长的态势，而对于新用户的分析主要是为了衡量网站推广的效果，评估上述主动营销或被动事件带来的影响，所以不建议使用绝对数值，既然老用户相对稳定，那么就可以基于新用户比例的变化趋势来分析网站某段时间的推广效果。GA的Benchmarking中提供的也是New Visits所占比例与其他网站基准线的趋势比较：

　　往往曲线中某个时间点的大幅上升或下降都意味着某个营销事件的影响，而当曲线持续下降时就意味着网站推广效果的不利，需要增大推广的力度。

　　如果你有关于网站新老用户分析更好的见解，欢迎评论。

　» 本文采用 BY-NC-SA 协议，转载请注明来源：网站数据分析 » 《网站新老用户分析》

Share and Enjoy:

数据仓库的源数据类型

joegh — Tue, 20 Jul 2010 21:41:58 +0800

　　数据仓库中集成了企业几乎所有的可以获取到的数据以用于数据分析和决策支持，当然也包括了我在网站分析的数据来源一文中所提到的所有数据。这些进入到数据仓库中的数据无外乎三种类型：结构化数据、半结构化数据和非结构化数据，它们经过转化后以某种形式统一地储存在数据仓库中，即通常说的ETL（Extract, Transform, Load，抽取、转换、装载）的过程。下面主要说一下这三种数据类型的区别，它们分别包括哪些源数据以及这些数据在网站数据分析中的作用。

结构化数据

　　这类数据的格式非常规范，典型的代表就是关系数据库中的数据，这些数据可以用二维表来存储，有固定的字段数，每个字段有固定的数据类型（数字、字符、日期等），并且每个字段的字节长度也相对固定。这类数据也是最易管理维护的，同时对于查询、展示和分析而言也是最为方便的一类数据格式。

　　结构化的数据在网站中一般指的是网站内部的数据库数据以及一些外部开放的数据库接口中获取的数据。这些数据可以直接通过ETL导入到数据仓库中进行集成化管理，而在网站分析和数据分析中直接可以根据需要通过SQL语句查询导出。

　　结构化的数据在网站数据分析中占据着举足轻重的地位，这些存储在数据库中的数据一般都是网站的运营数据及用户操作的结果数据（Outcome），比如网站的注册用户数、博客的文章数、评论数……而对于电子商务类网站而言，那些订单和销售数据也直接的存储与数据库中，而基于这些数据计算得到的总利润、每个订单平均利润、每个用户创造利润等KPI数据可以直接分析网站的目标是否实现。

半结构化数据

　　半结构化数据的格式较为规范，一般都是纯文本数据，可以通过某种方式解析得到每项的数据。最常见的就是日志数据、XML、JSON等格式的数据，它们每条记录可能会有预定义的规范，但是可能每条记录包含的信息不尽相同，也可能会有不同的字段数，包含不同的字段名或字段类型，或者包含着嵌套的格式。这类数据一般都是以纯文本的形式输出，管理维护也较为方便，但在需要使用这些数据时，如获取、查询或分析数据时，可能需要先对这些数据格式进行相应的解析。

　　半结构化的数据通常是指网站的日志数据，或者因为某些需求以XML或JSON格式输出的数据。最常见的就是网站的Apache日志，它根据预定义的字段顺序打出相应的值：

72.14.192.1 – - [09/May/2010:03:35:02 +0800] “GET / HTTP/1.1″ 200 13726 “-” “Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US),gzip(gfe) (via translate.google.com)”

而JSON格式则会以键值对（Key/Value）的形式输出数据：

{time: 1234567890, action: “comment”, respond: true, user: {userid: 1, username: “abc”}}

　　对于像Apache日志那样的数据，我们可以根据需要切分出那些有用的数据将它们导入到数据仓库，而xml和JSON格式的数据我们可以调用各类字符串解析的方法通过它们的标签或者名称来获取相应的值，对于嵌套结构可以使用逐层遍历的方法依次获取，同样选取那些对于分析有用的数据存在数据仓库。在这个过程中，ETL中的转换部分会显得较为复杂，因为这里需要进行格式解析，而这一步的优劣直接影响ETL的稳定性和健壮性。还有一个令人头疼的问题就是数据的格式和存放问题，也许有必要创建一些自定义字段类型；或者选择NOSQL数据库，关于NOSQL数据库的讨论一度热火朝天，从Google的Big table、Amazon的Dynamo到Facebook的Cassandra，NOSQL数据库提供了可扩展性的海量数据存储，对于WEB数据管理提供了新的解决方案。

　　半结构化数据对于网站数据分析同样非常重要，网站的点击流日志及一些用户行为数据一般都是以半结构化数据的形式输出的，当我们需要统计网站分析中的各类指标或者进行用户行为分析时，这类数据就必不可少。

非结构化数据

　　非结构化数据指的是那些非纯文本类数据，没有标准格式，无法直接地解析出相应的值。常见的非结构化数据有富文本文档、网页、多媒体（图像、声音、视频等）。这类数据不易收集管理，也无法直接查询和分析，所以对这类数据需要使用一些不同的处理方式。

　　富文本、图片、声音、视频等这些信息，除非需要进行高级的文本挖掘或者多媒体数据挖掘，否者对于一些日常涉及的数据统计和分析而言，非结构化数据本身是没有分析的价值的。所以一般不会将非结构化数据直接以二进制的形式存入数据仓库，数据仓库之父——Inmon的建议是在数据仓库中只需要储存非结构化数据的元数据（Meta Data），或者称为解释型数据。所以我们一般将非结构化的数据存放在文件系统（File System）中，而在数据仓库里面记录这些数据的信息，以便快速地索引和寻找需要的数据。如Word文档的标题、摘要、作者、创建时间、最近一次修改时间等，而图片则可能还包括像素、分辨率等。就像你右击文件属性的详细信息标签下看到的那些数据项，这些非结构化数据的元数据能够通过标准的形式记录，并且能帮助快速地搜索查询到对应的非结构化数据，同样可以被用于统计和分析，其实就是给每个非结构化数据贴上了标签，并将标签信息记录到了数据仓库中。

　　可能对于大多数网站而言，这类非结构化数据除非被用于高级的数据挖掘，在大部分时间中它们对数据的统计分析作用并不大，但对于某些网站，比如图片、视频类网站，这些数据就至关重要。对于图片、视频网站而言，每个图片和视频就是网站的产品，而记录图片视频的元数据就是这些产品的详细信息数据，产品分析、产品细分等都依赖于这些数据；同样，对于一些公司的内部归档的文档、资料而言，如果有数据仓库统一地记录这些文件的信息，就能够在必要时快速地搜索找到需要的文件，对于信息的统一集成化管理非常有效。

　　随着互联网的不断发展，各类信息不断膨胀，还有各式各样的数据类型会不断涌现，而数据仓库扮演着数据集成者的角色，对于各类数据的处理和管理也将不断地改进优化。

　» 本文采用 BY-NC-SA 协议，转载请注明来源：网站数据分析 » 《数据仓库的源数据类型》

Share and Enjoy:

提升用户满意度

joegh — Tue, 13 Jul 2010 21:30:56 +0800

——让用户更容易地找到需要的信息5

　　在前一篇文章——用户任务完成度分析中我似乎遗漏了一个重要的问题：为什么要分析用户的任务完成度？其实每个网站分析的方案和模型都应该具备它的目的和意义，否者就失去了分析的价值。所以这篇文章就是为了回答这个问题，同时也作为“让用户更容易地找到需要的信息”专题的完结篇。

　　所以这里先提出一个假设：让用户更容易地找到需要的信息进而帮助用户完成预期的任务，能够有效地提升用户满意度。

用户满意度的影响因素

　　我们不妨先来看一下用户满意度是怎么定义的，根据美国顾客满意度指数模型（ACSI, American Customer Satisfaction Index）的描述，用户满意度是用户对产品或服务的预期与实际接受的产品或服务的感受间的差距，差距越小，满意度越高。对于以信息服务为主的网站而言，用户访问网站的预期就是找到自己需要的信息，完成既定的任务（寻找信息、购物、娱乐等），那么如何衡量用户实际接受到的网站服务的质量水平，进而推测它们之间存在的差距？对于用户对网站实际的感受，可以从以下3方面体现：

用户是否完成预期任务（网站是否及格）
完成任务过程中良好的体验（也许网站能打八九十分了）
感受创意或意外的收获（获得附加分的机会）

　　所以，保证用户完成预期的任务是网站质量的及格线，也可以看作是网站的生命线。那么任务完成度对于用户满意度是否有这么重要的影响呢？我们需要对以上的假设进行验证。

任务完成度与用户满意度

　　为了验证任务完成度是否对用户的满意度有显著的影响，我们在统计用户任务完成情况的同时，需要收集用户对网站的满意度，所以上篇文章问卷调查中对用户满意度的打分题中采集到的数据就有了用武之地。我们可以通过比较完成任务的用户与未完成任务的用户对满意度的打分是否存在显著性差异的方法来验证任务完成度对用户满意度的影响是否显著。

　　这里可以使用两组独立样本T检验的方法，把问卷调查中采集到的样本数据分为两组，一组是未完成任务的用户的满意度打分，另一组是完成任务用户的满意度打分，我们可以认为这两组数据都是近似的符合正态分布，进而比较这两组样本的总体均值是否存在显著差异。（或许你认为这个结果是显而易见的，这个验证完全是多此一举，那就当我是画蛇添足，无聊打发时间吧。）

　　首先提出零假设：

H₀： μ₁= μ₂

　　再将收集到的样本数据通过SPSS或Excel的数据分析功能进行双样本均值T检验，过程就不详细论述了，不然估计很多用户立马会离开网站甚至直接关闭浏览器了。

　　从SPSS的分析结果中可以看出，完成任务与未完成任务用户的满意度打分均值（上面一张表Mean值）可以看出，完成用户的满意度均值明显大于未完成用户。从下面那张表的95%置信区间的检验结果可以看到，F检验的显著性概率为0.847>0.05，所以我们可以认为完成任务用户与未完成任务用户的满意度打分的样本方差没有明显差异；而T检验的显著性（双尾）概率近似于0，小于0.05，因此拒绝零假设，即两个样本的总体均值存在显著差异，进而我们可以得出完成任务的用户满意度显著地高于未完成任务的用户满意度。

　　通过上面的分析，我们验证了文章一开始提出的假设，即用户的任务完成度对提升用户的整体满意度有显著的影响。那么如何通过提高用户的任务完成度来提升用户满意度呢？

如何提升用户满意度

　　提升用户满意度，我们可能需要做很多事情，从全局到细节，需要处处为用户的体验和感受着想。既然我们已经验证用户的任务完成度对用户满意度会产生显著影响，那么我们可以先从提升用户的任务完成度开始。这里可以参考我之前写的关于如何让用户更容易地找到需要的信息的4篇文章——优化网站信息架构，优化网站内部搜索，优化网站导航设计，优化相关内容推荐。

　　这些优化可以从普遍的层面上提高用户的任务完成度，但显然以上这些还是不够的，因为用户的知识构成存在着差异，用户遇到的问题也会各不相同，所以上篇文章的问卷中当用户未完成任务时填写的为什么没有完成任务的开放性问题就能发挥作用了，我们需要针对各类用户（甚至个别用户）遇到的不同问题分别提供有效的解决方案，这也是为什么很多网站都会设置FAQ甚至在线客服的原因。

　　所以我们首先要满足用户访问网站的最基本的期望——完成他们预期的任务，从该层面上提升用户满意度，下面是我画的一个简单的示意图，就作为文章的结尾吧：

　» 本文采用 BY-NC-SA 协议，转载请注明来源：网站数据分析 » 《提升用户满意度》

Share and Enjoy:

用户任务完成度分析

joegh — Sun, 04 Jul 2010 21:18:53 +0800

　　欢迎来到艾泽拉斯大陆……如果你玩过魔兽世界，也许你在里面完成过无数个任务；当用户在访问网站时，其实他们也在试图完成某些特定的任务。

　　也许大家都比较熟悉网站目标（Goal），因为很多网站分析工具都提供了基于目标的分析，网站目标更多地是从网站的角度去定义的，比如电子商务网站的目标就是促成有效的交易；而用户任务（Task）则是从用户的角度去定义的，用户会有自己的目标，比如用户上电子商务网站可能只是为了查询某些商品的信息，询价，或者只是单纯的逛逛。所以每个用户带着自己的任务访问网站，这些任务可能各不相同，这无疑给分析带来了一定的难度。

关于任务完成度的定义

　　其实跟前面一篇文章——用Engagement衡量用户活跃度中的Engagement度量类似，用户任务也是一个非标准度量，而且根据网站的不同和用户访问目的的不同而显得千差万别。但用户任务完成度（Task Completion）与Engagement也存在着差异，Engagement定义的是用户的行为或动作，只要发生我们就认为用户参与了；而任务完成度定义的是结果，只有当用户的某个需求被实现时（如购买成功、获取到了相关信息、通过网站解决了某个问题……）才能认为用户完成了任务。

　　用户的Engagement不会直接影响网站目标，那么用户的任务完成度是否会对网站目标有直接影响呢？如果说网站目标（Goals）是从网站的角度衡量网站的商业目的（Business Objectives）是否实现的话，那么任务完成度（Task Completion）则是从用户的角度衡量用户的期望（User Expectation）是否达到。所以只有当网站目标与用户的任务一致时，我们才能认为用户任务完成度会对网站目标产生直接影响，因为两者衡量的都是结果，所以这种直接的影响有些时候甚至是可以划等号的。

　　既然用户访问网站的目的各不相同，每个人都带着各自的任务，那么我们如何获悉用户访问网站到底是来做什么的呢？

如何获取用户的任务信息

　　用户任务是一个非标准度量，并且是由用户自己决定的，我们似乎无法从点击流日志的用户行为分析中辨认用户到底是以什么样目的访问网站，我们需要直接向用户寻求答案。

　　前几天在Justin Cutroni的博客Analytics Talk看到了一个有意思的在线问卷调查，其实就是简单的2-3个问题，关于你为何来到这个网站，你完成了预期的任务吗，以及你对这次网站浏览的满意度如何，最后再加上一个可以自由填写的反馈，Justin Cutroni使用的是http://www.4qsurvey.com/这个网站提供的在线问卷服务，好像蓝鲸的博客也提供了在线问卷，他使用的是http://polldaddy.com/，还有一个提供反馈的功能http://www.kampyle.com/。其实这些都是收集用户信息的好办法，通过调查问卷（Survey）的方式让用户来告诉你答案。

　　如果我们需要分析用户的任务完成度，可以设计一个简单的在线问卷，提供在线问卷调查的网站很多，国内的国外的、免费的收费的，其实操作都比较简单，但首先我们需要注意一下几个问题：

什么时候向用户提供调查问卷？如果是分析任务完成情况，那么很明显要在用户离开网站的时候；
以何种方式提供问卷？比较常见的是弹出窗口或跳转链接，但无论用什么方式建议都先礼貌地问下用户是否愿意填写问卷；
在用户完成问卷时不要忘记感谢用户的支持，或者让用户留下邮箱以告知他们调查分析的结果，这些都是他们应得的，当然也可以借机推广你的网站；
问卷的设计，这是个复杂的问题，完全可以写本书了，这里只是提供用户任务完成分析的问卷设计，我的建议是如果不是一次全面系统的网站分析问卷调查，那么尽量减少问卷中的问题数量，而且尽量要一开始就告诉用户问卷的长度及可能占用他们多少时间。其实如果只是分析用户任务完成度，3个问题就足够了：

分析用户的任务完成度

　　基于从问卷调查中获得的数据，我们可以借用一些图表来分析用户的任务完成情况。

　　首先，必须明确用户任务也是基于用户在网站上的一次访问（Visit）。一般用户一次访问只是为了完成一个任务，所以对于大部分网站而言，更偏向于衡量一次访问的任务是否完成而不是完成的百分比。所以这里的任务完成度（Task Completion）的定义并不是每次访问用户完成任务的程度，而是所有的用户访问中完成任务的访问占所有访问的比重，即

任务完成度 = 完成任务的访问数 / 总访问数

　　可以基于任务类型进行细分，以电子商务网站为例，假如问卷中的任务选项包括：

购买商品
查询商品信息
售前售后咨询
其它

　　根据问卷采集的数据可以得到下图：

　　基于任务类型的细分，可以分析每类任务的用户访问量所占比例（左侧饼图），以及每类任务的完成情况（右侧柱状图，总高度为每类任务的总访问量，，蓝色区块的高度为完成任务的访问数，可以看出每个任务类型中完成的访问数所占比重）。如果网站中进行的是长期的问卷调查，同样可以对每类任务的完成度进行趋势分析，如下图：

　　趋势分析可以有效地掌握用户在网站中完成任务的变化情况，进而衡量网站在运营优化上面取得的成果。

　　接下来该由你来做些什么了，你可以尝试用你的方法寻找更恰当的图表来展示和分析数据。

　» 本文采用 BY-NC-SA 协议，转载请注明来源：网站数据分析 » 《用户任务完成度分析》

Share and Enjoy:

优化相关内容推荐

joegh — Sun, 27 Jun 2010 20:46:05 +0800

——让用户更容易地找到需要的信息4

　　博客之前的一篇文章——优化网站导航设计，介绍了如何评价网站导航功能及基于分析的优化。但后来才发现其中遗漏了Google Analytics上一个很实用的功能——Navigation Summary，字面上翻译是“导航概要”，但似乎用“页面上下游”（百度统计上的称呼，拿过来先借用下）分析更加贴切。它能够很好地分析网站导航的实现度（说得直观点就是导航功能上的有效点击或操作），下面就来介绍下这个功能。

更好地衡量导航实现度

　　先看一下我的“文章专题推荐”这个导航索引页面的在GA的Navigation Summary报表（该功能在Content模块的Top Content标签下面）：

　　从上图可以看到页面被浏览的次数（图中标注1），有多少的比例的Visits是从站外进入这个页面开始访问网站的（图中标注2），有多少的比例的Visits是从网站内部的页面跳转到这个页面的（图中标注3），有多少的比例的Visits在浏览的该页面后离开了网站（图中标注4），有多少比例的Visits从该页面进入了网站的其他页面（图中标注5，4和5部分现在貌似数据有点问题）；同时列出了网站内部前10名的上游页面（浏览该页面之前用户所在的那个页面，图中标注6）和下游页面（浏览该页面后紧接着浏览的下一个页面，图中标注7），及它们各自所占的百分比。这里需要注意的是有时会在上游页面和下游页面出现与选择页面相同的URI地址，比如你选择首页（/）进行分析，上游页面和下游页面也出现了首页地址（/），这个主要是刷新操作引起的，GA会把页面刷新统计到Pageviews里面。

　　通过上面这个功能，我们就不再需要通过导航页面的离开率（Exit Rate）来粗略估计有多少的Visits留在了网站并可能点击了导航页面的链接。并且通过Navigation Summary我们不仅可以看到有多少Visits从导航页直接离开了，而且可以通过分析导航页的下游页面更加准确地衡量有效点击率，排除那些刷新、返回或者调到其他非导航列表页的操作，将那些导航页面中的链接的点击率（%Clicks）相加，就是该导航页面的有效点击转化（CTR），也就是该导航功能的实现度指标了。以上表为例，排除返回首页（/）、页面刷新（/featured-topics/）及跳转到非导航页面中的页面（/about/、/site-map/等）这些点击，将剩下的实现了导航功能的有效点击率相加就是该导航功能的实现度，可惜GA上的上下游页面都只能显示前10个。

　　上面是对前一篇关于优化导航设计的内容的补充，其实页面的上下游分析是一种很有效的网站分析方法，不仅可以用于分析导航实现度，下面介绍一下它的另外一种应用——相关内容推荐效果分析。

网站的相关内容推荐

　　博客之前的一篇文章——优化网站信息架构中介绍了大部分的网站可能都是基于树形结构来进行购建的，但是原始的树形结构本身存在一个问题就是叶子节点（或者说是网站的内容节点）之间没有直接的联系，也就是用户无法从一个底层的内容页直接跳转到另外一个底层内容页，需要返回首页或者中间导航索引页面才能进入其他的内容页面，从那篇文章的树形架构图中也有体现，底层页面之间没有直接相连的线条。所以很多网站都会在内容的结尾或侧边栏提供相关内容的推荐，比如亚马逊、淘宝等电子商务网站产品页面会有同类别、同价位的产品推荐，或者是用户在购买该产品的同时也购买了的产品推荐，豆瓣上的书籍、音乐、电影页面也提供了相关内容的推荐。

　　这些功能很多都是基于内容相关度的算法来实现的，之前的文章——向上营销、交叉营销与关联推荐介绍过基于用户行为的关联推荐方法。其实很多博客也有类似的功能，即每个文章结尾的相关文章，下图是我的博客的电子商务网站RFM分析这篇文章的相关文章列表：

　　我是用Wordpress的插件——Yet Another Related Posts Plugin来实现这个功能的，按照插件的介绍，它是通过计算文章的标题、正文、标签和分类的相关度选取排名前几的显示到页面上。这个功能很棒，它打通了文章页面之间的通道，也许用户在看完一篇文章之后还想浏览下相关的文章，那么相关内容推荐就提供了很好的途径，用户不需要再回退到内容的检索页面，直接点击就行，帮助用户更加方便、快速地定位到想要寻找的信息上。