userfly—网站可用性测试工具

  博客之前介绍过网站点击热图的测试工具,同样是用于分析和优化网站的用户体验,而这篇文章中介绍的这个工具更加全面和可视化,叫做userfly

  userfly几乎可以监控用户在网站上的所有操作,通过视频的方式录制并提供回放和下载,可以记录的用户行为包括:

  • 监控鼠标的移动、点击和选取;
  • 监控文本框的输入、选择框的选取;
  • 记录页面的缩放、上下滚动和页面浏览的跳转;
  • 监控对链接、按钮的有效点击;
  • 排除对用户输入密码的记录,保护隐私。

  我看到的就是这些,也许还有更多,这里将试用该工具录制下来的网页录制成了Flash视频:

[swfobject]833[/swfobject]

  看到Demo的效果时,我有被这个工具吓到,上面是我在自己博客中的试用,可以看到几乎一切的操作都被录制了下来,包括所有的移动、点击和输入,也包括在浏览文章时可能出现的走神或者离开去做了其他事情,这些都一览无余。我怀疑这是否在一定程度上侵犯了用户的隐私,当然现在我的博客上的监控代码已经撤下来了,大家不用担心自己的操作会被“偷窥”,这里也建议如果你的网站准备使用这类工具最好事先提醒下用户:他们的操作可能会被记录监控,这是对用户的一种尊重。

  当然这种功能强大的工具不可能让你完全享受免费的午餐,你可以有一个月10次的免费捕捉用户行为的机会,如果需要更多,那么就要支付相应的费用了。建议研究网站用户体验的同学可以去试用下这个工具。

维(Dimension)和立方(Cube)

    博客之前的两篇文章:数据仓库的多维模型数据立方体与OLAP中分别对多维模型和OLAP的一些基本概念进行了介绍,这篇文章是基于那两篇文章的深入扩展,主要介绍的是多维OLAP中两个重要构成元素——维和立方的结构和组成。可能内容会偏向于模型构建方面,对那方面不太感兴趣的同学可以直接跳过。 ;-)

维(Dimension)

  维是用于从不同角度描述事物特征的,一般维都会有多层(Level),每个Level都会包含一些共有的或特有的属性(Attribute),可以用下图来展示下维的结构和组成:

Dimension

  以时间维为例,时间维一般会包含年、季、月、日这几个Level,每个Level一般都会有ID、NAME、DESCRIPTION这几个公共属性,这几个公共属性不仅适用于时间维,也同样表现在其它各种不同类型的维。其中ID一般被视为代理主键(Agent),它只被用于作为唯一性标志,并且是多维模型中关联关系的代理者,在业务层面并不具有任何意义;NAME一般是业务主键(Business),在业务层面限制唯一性,一般作为数据装载(Load)时的关联键;而DESCRIPTION则记录了详细描述信息,在多维展示和分析时我们都会选择使用DESCRIPTION来表述具体含义。这3个属性一般是所有Level都会共用的,而比如用于描述星期几的属性weekid可能只会用于“日期”这层,因为年月都不具备这一信息。所以图中我将Attributes放到了一个层面上,就如同是不同的Level从底层的多个Attributes中选取自身所需的属性,Attributes层是包含着各个Level的共有和特有属性的集合。

Hierarchy

  因为不知道怎么翻译好,所以还是用英文吧。Hierarchy(等级、层级的意思),中文的OLAP相关文档中普遍翻译为“层次”,而上面的Level被普遍翻译为“级别”,我经常会被这样的翻译搞混淆,所以我上面也一直用Level,至少对我来说这样看起来反而清晰点 :)

  因为上面这个结构的维是无法直接应用于OLAP的,我前面的文章有介绍,其实OLAP需要基于有层级的自上而下的钻取,或者自下而上地聚合。所以每一个维必须有Hierarchy,至少有一个默认的,当然可以有多个,见下图:

Hierarchy

  有了Hierarchy,维里面的Level就有了自上而下的树形结构关系,也就是上层的每一个成员(Member)都会包含下层的0个或多个成员,也就是树的分支节点。这里需要注意的是每个Hierarchy树的根节点一般都设置成所有成员的汇总(Total),当该维未被OLAP中使用时,默认显示的就是该维上的汇总节点,也就是该维所有数据的聚合(或者说该维未被用于细分)。Hierarchy中的每一层都会包含若干个成员(Member),还是以时间维,假设我们建的是2006-2015这样一个时间跨度的时间维,那么最高层节点仅有一个Total的成员,包含了所有这10年的时间,而年的那层Level中包含2006、2007…2015这10个成员,每一年又包含了4个季度成员,每个季度包含3个月份成员……这样似乎顺理成章多了,我们就可以基于Hierarchy做一些OLAP操作了。

  每个Hierarchy都包含了一个树形结构,但维中也可以包含多个Hierarchy,正如上图所示,维中的Hierarchy相互独立地构建了自己的树形结构。还是以时间维为例,时间维可以根据日历(Calendar)时间组建日历的Hierarchy,也可以根据财务(Fiscal)时间组建财务的Hierarchy,而其中财务季度的划分可能并不与日历一致,基于这种多样的Hierarchy,我们在组建多维模型时可以按需选择合适的,比如给财务部的数据分析模型选用财务Hierarchy,而其他部门的分析人员显然希望看到日历样式的Hierarchy,这样就完美地满足了不同的需求。多种的Hierarchy划分同样适用于产品维,根据产品类型、产品规格等划分 Hierarchy,对于按多种条件的产品筛选和检索是十分有效的,实例可以参见淘宝搜索商品界面和太平洋电脑中产品报价界面分类筛选模块,这里不再截图了。

立方(Cube)

  这里所说的立方其实就是多维模型中间的事实表(Fact Table),它会引用所有相关维的维主键作为自身的联合主键,加上度量(Measure)计算度量(Calculated Measure)就组成了立方的结构:

Cube

  度量是用于描述事件的数字尺度,比如网站的浏览量(Pageviews)、访问量(Visits),再如电子商务的订单量、销售额等。度量是实际储存于物理表中的,而计算度量则没有,计算度量是通过度量计算得到的,比如同比(如去年同期的月利润)、环比(如上个月的利润)、利率(如环比利润增长率)、份额(如该月中某类产品利润所占比例)、累计(如从年初到当前的累加利润)、移动平均(如最近7天的平均利润额)等,这些计算度量在Oracle中都可以借助分析函数直接计算得到,相信大部分的OLAP组件都会提供类似在时间序列上的分析功能。而这些计算度量往往对于分析而言更具意义,立方中借助与各个维的关联关系从不同的角度和层面来展现这些度量。

  The end,因为最近在看相关方面的资料,这篇文章就作为读书笔记,如果有哪里表述不准确的,还望指正。

为网站选择合适的KPIs

KPI-Selection    KPI(Key Performance Indicators,关键绩效指标),似乎是一个很熟悉的名词了,很多企业都设置了各种各样的KPI来作为日常绩效考核的指标。公司会用KPI来评估员工的表现,同样网站也需要用KPI来衡量网站的表现,选择好合适的KPI有利于正确地把握网站的运营状况,迅速地做出调整和改进。

网站KPI的定义

  KPI的设定本来就是基于目标管理的基础上的,用定量的方式来评估目标的实现情况。对于网站而言,KPI是直接与网站目标(Goal)挂钩的,下面是我对网站KPI的一些理解:

  1. KPI并不等于网站目标,而是反映目标实现过程中网站在各方面的表现情况的指标;
  2. 每个网站对KPI的选择都会存在差异;
  3. KPI往往能够直接反映网站的目标实现情况,并且可以被量化;
  4. 分析KPI可以发现运营中的问题,并直接指导决策和行为的执行。

  同时,网站可以设定多个KPI,从多个层面来评估网站的表现,这也是我在标题中用KPIs的原因。

选择KPI的原则

  基于上面对网站KPI的定义,我们在选择KPI的时候需要注意以下几个原则:

  首先根据KPI的定义,知道KPI由网站目标决定,所以在选择KPI之前先要明确网站的战略和目标。什么,你不知道你的网站目标是什么?那就问下自己网站存在的意义是什么,或者你建立这个网站是为了实现什么目的。

  既然网站目标决定了KPI,而对于每个网站而言战略目标都会存在差异,即使网站的类型再相似,其在市场、运营和发展战略上面必然不尽相同,所以就导致了上面KPI定义第二项的差异性;而网站战略会不断变化,所以KPI应该根据网站目标的变化做出调整

KPI-Rule  网站分析的指标何其之多,我们应该选择哪些指标作为KPI?所以必须把握这个原则:KPI能够直接反映网站目标的实现程度。其实很多网站分析的指标都能反映网站的基本状况,比如访问数(Visits),但它只能反映网站的受欢迎程度,而并非目标,比如Visits的数量无法直接决定电子商务网站的利润,也没法确定那些访问用户是否能够成为博客的忠实读者。所以我们需要寻找更接近目标的指标,Avinash Kaushik先生在他的博客中也一再强调在做分析的时候需要不断探索更加深入和有效的指标。

  KPI是一个定量指标,可以被衡量,所以在选择KPI的时候,我们必须明确KPI的指标定义,计算逻辑和公式,以及其具体衡量的问题

  KPI最终目的是指导我们Make Decisions或者Take Actions,所以在选择的时候必须确定其在这方面能够做出有效的判断,于是就有了Avinash Kaushik的So What Test(有时候自问自答的模式也是挺有效的),假如能够在回答完3个So What前提出有效的解决方案,那么这个指标就过关了。

  大部分的KPI指标都是可以基于细分的。因为聚合的指标对于决策和行为是无效的,看着网站的总体转化率(Conversion Rate),也许你无法采取任何行动,但通过来源细分organic搜索、PPC和各来源网站的转化率变化趋势,也许你就十分清楚是应该加强SEO还是SEM、或者着重于链接建设了。

几类网站的KPI选择

  很明显,电子商务网站的目标就是创造更多的利润(当然某些特定的时期也有可能专注于提高订单数或者创造更多购买顾客);而WEB2.0网站在不断地制造内容、聚合内容、传播内容,他们的目标在于信息的快速通常的流转;而搜索引擎一定希望更多的用户来使用他们的搜索服务,于是他们关注的是用户是否能够通过搜索引擎迅速地找到想要的信息。下面就看下这三类网站各自可以选择哪些KPI:

  对于电子商务网站,我可能会选择平均订单价值(Average Order Value, AOV)或者平均每次访问销售额(Sales Per Visit, SPV)来作为网站的KPIs,因为这些指标直指网站目标——利润。同时这两个指标都可以基于来源途径、用户类型、产品类型进行细分,可以更清晰地看到哪些渠道带来了最有价值的流量;网站吸引的是哪类用户,应该注重哪块市场的开发;或者网站的哪类商品是核心产品,网站应该坚持20/80法则还是走长尾路线。这些都是战略决策中应该考虑的问题,KPI可能已经给出了直观的参考答案。

web2_0  再来看一下博客类网站,作者都希望自己的文章被更多的读者阅读,所以他们对于博客的目标是更多的忠实读者、更多的评论和订阅,于是他们把忠诚用户访问比率每次访问的订阅几率每篇文章的评论数作为KPIs;而对于Blogger.com这类博客平台而言,吸引更多访问量的基础是用户能够不断创造出更高质量的内容,于是他们会把平均每位用户发表文章数或者产生的热门文章数作为自己的KPI,看上去两者存在很大区别,这完全取决于两者目标定位上的差异。

  同样对于Facebook、Twitter这些Social Media网站而言,他们都是以UGC(User Generated Content)为基础,用户生产的内容或者制造的热门正是他们的价值所在,也就是用户的活跃度的体现,只有足够活跃的网站才能吸引更多的眼球,制造更多的曝光和焦点。所以他们更加会关注每位用户的平均关注人数、发布信息数量、评论和转发信息数等。

  再看一下搜索引擎,Google另类地提出要让用户更快地离开网站的口号,这正是其自身目标的体现——让用户更方便快捷地找到自己想要的信息,所以是不是Google会把平均每次访问的搜索时间作为它的KPI呢?

  当然,上面都是作者的一家之言,大家可以各抒己见,基于KPI的定义的基础上,有原则地选择合适的KPI。我想网站的决策层一定会喜欢你为网站量身选择的KPIs的,因为没有比直接衡量网站战略目标更有意思的事了。

用户点击与网站目标

——基于Google Analytics的应用

click-and-goal    用户在网站的行为其实无非就是输入和点击,而点击又是最常见的行为,其实用户行为分析一大部分就是在分析用户各种各样的点击行为。我们可以通过各种途径来监控用户点击行为,同时各类网站分析工具都相继提供了丰富的事件监控功能,来满足不断发展变化的网站交互。刚好我的博客需要监控某些用户点击行为,并且要将这些点击行为设置成网站目标,所以这里跟大家分享一下我的实现步骤。

用户点击对你的网站重要吗?

  首先需要明确的是我们是否有必要去监控用户的点击行为,或者说用户点击对网站分析是否有价值?网站中有些按钮完全是交互或者浏览的需要,对于分析并不是那么重要,但显然有些按钮对于网站分析有着至关重要的作用,比如电子商务网站的“放入购物车”、“购买”、“支付”等按钮的点击;微博网站的“关注”、“发布微博”等按钮;视频网站的“播放”、“暂停”等按钮。通过统计和分析这些按钮的点击数据,我们可以对用户的这些对网站产生关键影响的行为了如指掌。

  我们需要去统计这些重要的用户点击,但也不是所有的这些点击都需要进行额外的设置,当点击跳转到一个新的页面时就会有新的Pageview产生,这类点击我们就不需要另外进行监控。但某些点击,比如Ajax架构的点击交互,或者是Flash中的点击按钮,抑或是出站的按钮或链接点击,这类行为不会产生新的页面浏览行为,也就不会有Pageview的记录,那么如果刚好这些点击像上面说的对网站来说是重要的,我们就必须对其进行监控和统计。

  以我的博客为例,对于我的博客而言,通过右方侧边栏最上方的5个按钮可以对博客进行订阅或关注,用户的这些行为对于我而言是十分有价值的,因为至少用户开始对我的博客内容感兴趣了,我需要知道每天有多少用户会尝试去点击这些按钮(无论点击的结果如何,因为最终的结果超出了监控的范围,无法追踪 =_=” ),其实通过Google Analytics就能简单地统计到这些点击数据。

Google Analytics的点击监控统计

  Google Analytics中监控点击一般通过事件追踪(Event Track)虚拟页面(Virtual Page)两种方式。我原先使用的是事件追踪的方法,因为事件追踪是GA专门为这类用户行为量身定制的,可以设置类别(Category)、行为(Action)、标签(Label),甚至可以为每个事件定义它的价值(Value),所以对于各类时间的分类汇总非常方便,比如我在RSS订阅中加入onClick=”_gaq.push(['_trackEvent', 'Feed&Follow', 'Feed', 'RSS']);”类别为Feed&Follow,行为为Feed,标签是RSS,另外设置邮件订阅的标签为为Email,关注的3个按钮的动作为Follow,再根据标签区分类别,这样就可以非常方便的看到汇总和细分的数据了(注意我这里使用的是异步代码,使用前请先看一下自己网站的GA代码类型,具体设置可以参考蓝鲸的文章——Google Analytics功能篇—事件追踪):

Event-Track-Drilldown

  但事件追踪有一个局限性就是无法设置为网站目标,熟悉Google Analytics的朋友都知道GA的目标只能是三种类型:页面浏览(URL Destination)、停留时间(Time on Site)、每次访问页面数(Pages/Visit)。所以如果我要将我的博客的订阅和关注的点击作为网站的目标,在GA中通过事件追踪的方式就没法实现了,就需要通过设置虚拟页面的方式,详细操作也可以参考蓝鲸的Google Analytics功能篇—虚拟页面,这里来说一下我的设置:

点击类型 追踪代码
RSS订阅 onClick=”javascript: _gaq.push(['_trackPageview', '/virtual/feed/rss']);”
Email订阅 onClick=”javascript: _gaq.push(['_trackPageview', '/virtual/feed/email']);”
关注Twitter onClick=”javascript: _gaq.push(['_trackPageview', '/virtual/follow/twitter']);”
关注Buzz onClick=”javascript: _gaq.push(['_trackPageview', '/virtual/follow/buzz']);”
关注新浪微博 onclick=”javascript: _gaq.push(['_trackPageview', '/virtual/follow/sina']);”

  但是设置虚拟页面后会出现另外一个问题,就是导致Pageviews的增加,因为虚拟页面也会被算到页面浏览量中去,所以还需要进行另外一步操作——添加过滤器,下面来看一下过滤器(Filter)的添加,及如何将点击行为设置为网站目标。

将点击设置为网站目标

  首先来看一下通过上面的设置后在Google Analytics的报表上显示的结果:

虚拟页面统计

  虚拟页面在数据展现其实与普通的页面浏览并没有区别,也是在Content模块中,可以在Top Content报表中查看,根据我上面的设置可以直接filter出包含“virtual”的页面统计:

content-virtual

  同时,根据上面虚拟页面的URL结构,也可以使用Content Drilldown中按层次一次向下展开,可以同时查看各类汇总数据和细分数据,详细介绍参考前一篇文章——让URL更适合分析。这样依次展开的顺序为:virtual=>feed=>feed的各子项,virtual=>follow=>follow的各子项,十分清晰。

设置网站目标

  因为虚拟页面已经将点击转变成了页面浏览,因此可以将这些行为设置成网站目标了:

Feed&Follow-Goal

  这里的目标类型(Goal Type)选择URL目标(URL Destination),我在这里使用了正则表达式进行匹配,将所有/virtual/feed或follow/开头的URL设置成目标,同时设置该目标的价值(Value)为10(对于博客而言,这类点击价值较高,同时博客还设置了其他的目标,价值相对低一些),这样按确定就设置完成了,可以在报表上查看每天的目标转化率(Conversion Rate)和价值了。

添加过滤器

  因为使用虚拟页面监控点击行为将点击当做了页面浏览统计,因此会导致网站的Pageviews虚高,我们需要将这些虚拟页面的浏览量从网站的Pageviews统计中过滤掉,所以需要用到Google Analytics的过滤器功能。首先要新建一个配置文件(Profile),这一步是必需的,因为一旦在配置文件中加入过滤器后不符合条件的数据就会直接被剔除,无法找回,所以我们必须保留一个最原始的配置文件以查看未过滤的虚拟页面的统计情况。我这里只要用到预定义过滤器(Predefined filter)中的排除子目录即可,详细的设置参见下图:

virtaul-filter

  只要把所有以/virtual/开头的子目录的流量过滤,然后把新建的配置文件放到下方右侧“已选择的配置文件”的区域即可,非常简单方便,之后你就可以从你新建的配置文件中看到“干净”的网站Pageviews的统计了。不过需要注意的是,因为在这个配置文件中虚拟页面被过滤,所以上面设置的目标只能通过查看原配置文件的报表中才能看到。

  最后总结一下,网站的点击行为统计对于某些网站的分析而言是十分重要的,基于Google Analytics的点击事件追踪可以通过事件追踪和虚拟页面两种方式,如果你单纯为了统计点击事件发生的情况(当然不一定是点击,同样适用于其它事件),那么时间追踪是非常不错的选择,如果你要将点击最为网站目标,那么就需要通过虚拟页面的方式了。我的博客也是刚换过来,大家也可以自己动手试试。

让URL更适合分析

url-optimization   网站的存在离不开URL,URL与网站内容形影不离。URL用于唯一地标识网站的页面、内容或资源的“位置”,所以很多时候它只是被看做一种识别码,就像是商品上的条形码,对于用户来说,这些识别码是没有任何意义的,用户不需要关心它们到底代表着什么。但对于网站分析而言,URL并不只是网站内容的识别码这么简单,其实它可以在分析过程中发挥更大价值。

URL与网站内容

  URL由协议、域名、请求地址三部分组成,完整地URL唯一确定了一个请求的资源,可以是页面、内容模块、文件或多媒体资源等。对于网站而言,URL的用处是对资源的唯一定位,所以方式可以有很多,用资源的唯一描述(资源名称或简称等),资源的唯一识别码(ID、数字标记等),也可以是动态参数,这样就导致了各网站的URL会存在很大的差异。

  比如浏览网易首页=>体育频道=>意甲=>米兰新闻,它们的URL依次为 http://www.163.com/=> http://sports.163.com/=> http://sports.163.com/yj/=> http://sports.163.com/special/00051NSK/moremilan.html,其实对于用户而言对于前三个页面的URL还可以读懂,而最后一个可能就难以理解了;而在去看一下淘宝的URL,在进入首页后点击任一一个商品分类,可能展现出来的URL就已经很难读懂了。

  无论怎么样,这些URL对于网站而言都是有效的,因为它们都能做到唯一地识别网站的内容,既然如此,那么是不是URL就不再需要进行另外的整理设计了呢?还是先看看URL在网站分析中扮演着怎样的角色。

URL在网站分析中的用处

  我们知道,在网站分析中一般都是用页面的URL地址来唯一地标识一个页面(当然现在GA上也有根据页面标题显示的报表,但是网站的页面标题是可以重复的,所以无法“唯一标识”),我们根据URL地址来查看该页面的Pageviews、Unique Pageviews、Exit Rate等。但不知道大家有没有发现Google Analytics的Content模块下还有一张有趣的报表——Content Drilldown(内容下钻,关于下钻的概念可以参考文章——数据立方体与OLAP),这张报表中的Page列就像是一个树形结构可以不断地向下展开直到底层节点,其实在GA的其他报表上也有类似的下钻功能,比如Visitors—Browser Capabilities—Browsers这张报表也支持从浏览器类型到浏览器版本的下钻操作。

  也许你看了页面下钻的报表后,已经有点理解为什么URL的设计会对网站分析产生影响,下面就来看一下我的博客的实例:

  顶部导航中的“文章专题推荐”中分类罗列的一些相应的文章,并且在该页面下还根据文章分类设置了4个子页面:“电子商务分析”、“网站用户分析”、“用户体验分析”、“其他文章推荐”,URL也是按照页面的层次结构进行设计的,如下图:

GA-content-drilldown

  所以Google Analytics页面下钻的实现方式是将页面的URL根据”/”进行切分,从左向右分级存放,同时将下一层的数据向上汇总到上一层,这样报表上既可以查看每个页面的数据,也可以查看根据URL的结构向上逐层汇总的聚合数据。这对网站分析是十分有用的,因为我们同时获得了细分数据和汇总数据,从而可以从不同的数据粒度上进行分析。也许你会说不就是将同一类型的页面的数据加起来吗,在分析的时候自己加一下就行,也许上面例子中的2层并且只有4个子页面是很好处理,但如果网站页面超过3层,每层可能会有上百个子页面,那么如果没有这类下钻功能就会变得难以应付了。

  可能有的朋友会问,那有没有不通过URL来区分个页面类型和层级的?如果你是用第三方工具,就需要进行额外的设置来让网站分析工具可以识别和区分你的网站页面,比如在页面上加入Google Analytics的自定义参数(Custom Variables)区分页面类型,但是如果无法自动添加这类JS代码的话,那么对于一个页面繁多的网站这个工作量就会相当庞大。如果你用自己的分析工具或者基于网站数据仓库,也许你需要维护一张页面的维表,可以包括[页面ID,页面URL,页面描述,上级页面,页面层级]这些属性,从而建立起具有层级关系的页面结构树,当然如果你的网站时常变动,那么要维护这张维表也是一件十分头疼的事情。

  下面就以我的博客作为实例来说明下URL结构设计对于网站分析的影响是如何体现的。

我的博客的URL设计

  得益于Wordpress这个强大的开放内容管理系统,让博客的URL定制变得不再复杂。Wordpress的后台控制界面中提供了“固定链接设置”的功能,用户可以根据自己的需要设计适合自己网站的URL结构,比如我的博客的固定链接是/%category%/%postname%/,也就是/文章分类/文章名/,可以再来看一下我之前一篇文章——优化网站信息架构中的我画的Wordpress的简要信息架构图:

Wordpress-IA

  通过上图结合我的URL结构设置,可以理解为我将信息架构中的一个分支——分类目录——作为URL结构设计的主依据,这样做有什么好处?在GA的页面钻取的分析报告中我既可以查看每篇文章的数据,同时可以查看每个文章分类的汇总数据:

GA-category-drilldown

  图中左侧的数据对应我的博客侧边栏分类目录中每个分类的汇总数据,右侧的数据对应“网站定量分析(web-quantitative-analysis)”分类下面各文章的细分数据。同时,当用户使用博客侧边栏的各索引(根据分类目录、文章标签、日期归档)时,Wordpress也提供了非常友好的URL结构,比如分类目录用了/category/分类名、文章标签用了/tag/标签名、日期归档用了如/2010/09/这类年月的结构来罗列相应的文章列表,这样就可以在GA中同样可以使用跟上面一样的下钻来分析有多少用户试图使用这些功能来索引博客文章,并且查看了哪些分类、标签或者日期归档,有兴趣的朋友可以到自己的Google Analytics上面试试。

  这是我的博客的URL设计,每个网站可以根据自身的特点和需要设计适合自己的URL结构,从而有效地简化和提升网站分析中页面数据的细分和汇总。

总结

  层次清晰、结构规范的URL不但可以为网站分析节省更多的工作量,同时可以提高URL的可读性,有效地提升对搜索引擎的友好度,增加网站SEO的效果。而清晰的URL结构需要基于对网站信息架构的系统有效的梳理,一旦做好了这些,一定会让网站建设的各个方面都受益匪浅。

  需要注意的是,URL的设计和规则需要在网站开发阶段就进行明确定义,写入相关的设计规范和文档中,因为一旦网站上线后要想再对URL的结构进行调整将会是一件极度麻烦并且得不偿失的事情。

  中秋节在江南阴雨绵绵的天气中度过,接下来马上又是7天的长假,提前祝大家度过一个Happy的国庆假期!

直邮营销分析(下)

  上一篇文章——直邮营销分析(上)中已经介绍的直邮营销(EDM)的特点及基本的实现流程。这篇文章重点介绍一下与直邮相关的分析指标,这些指标的数据获取方式,及基于直邮实现流程的漏斗模型的构建。

直邮的分析指标

  因为直邮的分析始终是基于其实现流程的,所以在列举直邮相关的分析指标前,还是再引用下上一篇文章中的实现流程图,这样对照着看会更加清晰:

direnct-mail-process

  发送邮件数:这个一般是已知的,从可以获取到的邮箱中抽取一定数量的用户作为直邮的对象用户;

  发送失败邮件数:这里的发送失败是指邮箱服务器有失败响应的邮件,如无效地址、网络错误等,这个也是在发送后可以直接统计得到的(需要注意的是我们无法获取诸如邮件被防火墙屏蔽或者被识别为垃圾邮件等这些意外事件,因为无法知道也就不会被算入发送失败);

  打开邮件数:即被用户打开查看阅读的邮件数;

  点击数:如果邮件中有引导用户进入网站的链接或者call to action的按钮,那么当用户点击这类链接进入网站时就被计入点击数的统计中;

  上面四种数据是直邮的基础统计数据,基于这些数据我们可以计算得出一些有价值的指标:

  发送成功邮件数 = 发送邮件数 – 发送失败邮件数

  邮件发送成功率 = 发送成功邮件数 / 发送邮件数

  邮件打开率 = 打开邮件数 / 发送成功邮件数

  邮件点击率(Click-to-Open Rate, CTOR) = 点击邮件数 / 打开邮件数

  邮件的目的是实现预期的营销目的,所以自然还要统计目标实现的指标,举个例子,比如电子商务的网站用直邮吸引用户购买新出来的产品,那么目标指标就是直邮带来的网站收益,所以直邮的KPI可以是平均每封直邮收益 = 直邮带来的总收益 / 发送成功邮件数;如果目标是吸引用户注册,那么目标指标就是直邮带来的注册用户数,目标转化率 = 直邮带来的注册用户数 / 发送成功邮件数。

  最后不要忘记还有退订邮件数,以及邮件退订率 = 退订邮件数 / 发送邮件数。

直邮的追踪与数据获取

directmail-analysis  从上面列举的指标中,我们已经知道发送邮件数、发送失败邮件数可以直接获得,而当用户进入网站后的数据也可以从网站分析工具中获取;所以只有邮件的打开和点击情况是由用户操作,并且处于网站之外,是比较难以追踪和获取的一部分数据。

  关于邮件的打开统计,一般的实现方式是通过Beacon log的形式获取数据,即在邮件中加入1×1px的透明图片,通过统计该图片被加载情况来获取邮件被打开的次数,如果你用的是Google Analytics,当然也有一些解决方案,具体的介绍可以参考之前的文章——NoJS的网站数据统计。但是我在实践的时候发现这种方式只能统计到网页邮箱的邮件打开情况,如果用户使用邮箱客户端(如Outlook等),那么图片请求不会显示在GA的报表上,我猜想是当使用邮箱客户端时,没有相应的URL链接,于是GA无法获取utmp参数也就无法识别和统计,不知道有没有GA的大牛可以提供其它完整的解决方案。

  关于邮件的点击统计,也许很多同行已经想到了办法,那就是为邮件上每个可点击链接加上URL参数,根据参数进行追踪。如果要用GA,那也相当方便,因为GA提供了广告流量追踪,我们可以使用同样的方法来统计,详细的设置方法可以参考蓝鲸的文章——Google Analytics追踪不同渠道的广告流量。比如我要为我的博客的推广邮件中的“欢迎访问网站数据分析”这个按钮添加追踪链接参数,点击后进入我的博客首页,使用Google的URL构建器(因为Link Tag加的参数都严格区分大小写,所以在这里我全部统一使用小写):

URL_Builder

  生成的带参数的链接如下:

http://webdataanalysis.net/?utm_source=directmail0915&utm_medium=email&utm_term=%E6%AC%A2%E8%BF%8E%E8%AE%BF%E9%97%AE%E7%BD%91%E7%AB%99%E6%95%B0%E6%8D%AE%E5%88%86%E6%9E%90&utm_content=joeghwu%40gmail.com&utm_campaign=webdataanalysis_promotion

  细心的朋友可能注意到了,我在Campaign Content(utm_content参数)设置的是一个邮箱地址,是的,我放的是该直邮目标用户的邮箱地址,我们可以用它来追踪每个用户的点击情况(用户可能点击多次,跟踪每个用户的后续操作、目标实现等),当然这个需要根据每封直邮的对象用户进行动态生成,你可以请教下前台开发的同事,他们应该可以搞定。好了,参数加好后就可以将链接加到相应的邮件中去了,之后你只需要统计匹配相应参数的页面请求就行,如果你是用GA等第三方工具,那就只要坐等结果就行。

GA-directmail

  从上图GA的统计中可以看到Tom和Jerry都通过直邮渠道光顾了我的网站,如果你的网站设置了目标(Goal),那么就可以在Goal Set的标签下查看直邮来源的用户的目标实现情况和转化率了。

直邮分析的漏斗模型

  其实从看到上篇文章的那张直邮的实现流程图之后,可能很多朋友已经想到了,对直邮的统计同样可以使用漏斗模型,因为同样具有相对固定清晰的实现路径(Path)。关于关键路径分析和漏斗模型可以参考我之前的文章——网站转化率与漏斗模型。下面就基于直邮的实现流程来构建一下漏斗模型:

directmail-funnel

  具体的计算和分析这里就不展开了,详细可以参考我之前的那篇文章。其实只要成功获取上面提到的各类原始直邮追踪数据,然后通过这些数据计算得出上面直邮分析中相关的指标,那么上面的这个漏斗模型就自然成型了,让直邮整个实现流程的分析一目了然。

我们需要注意些什么

  直邮从发出到最终实现预期目标需要经历一个如此长的流程,自然流程中某些环节的不确定因素会对整个直邮的分析模型造成影响:

  1. 实际收到邮件的用户往往比预期的要少。受到邮件错发、屏蔽和邮箱反垃圾系统的影响,一般实际发送成功的邮件数(用户从收件箱中看到了该邮件)要比发送端显示的发送成功的数要少;
  2. 实际邮件的打开数可能比统计到的数字要多。上面已经介绍过了,邮件的打开数是通过Beacon log的方式统计的(图片请求),这种方式只有在支持HTML格式的条件下才能实现,也就是说当不支持HTML格式时,用户打开的是文字形式的邮件,图片无法被加载,那么打开数也就无法被统计到。
  3. 实际点击邮件数可能比统计到的数字要多。上面介绍的是通过统计加入相应参数的链接被请求的次数作为该链接被点击的次数,但实际是我们仅仅统计到了链接被点击并成功进入网站的用户,而那些点击了链接,但因为某些原因加载页面失败,或者那些在页面未加载完成之前就关闭了浏览器的用户都是未被统计到的,但这些因素一般可以被忽略。
  4. 提供邮件退订功能,分析邮件的退订率。提供退订是对用户的尊重,也是对自身形象的维护,如果用户对该类邮件不感兴趣甚至排斥,提供了退订的按钮可以避免用户直接把邮件归类为垃圾邮件,同时可以避免潜在用户直接流失这种更严重情况的出现;通过分析邮件的退订率我们可以分析直邮的内容对用户是否有足够的吸引力,如果某批直邮的退订率很高,那么显然那封邮件的内容出了问题。

  好了,我对直邮分析的总结和分享就是这些,你是不是还有更有价值的分析?欢迎评论分享。

  BTW. 上周末在英国留学的一个同学回国,几个同学一起来我这边聚了下,突然发现有朋友的感觉真好,似乎这个时候才真切地体会到了孔子的“有朋自远方来,不亦乐乎”的真谛。

直邮营销分析(上)

direct-mail  也许你平均每天都会收到一封各类的营销邮件,超市的广告、银行的记账单(里面一般都夹杂着广告)、各类电子商务网站的定期产品促销邮件、也许还有其他网站的产品或应用的更新通知,或者也不知道怎么会发到你的现实或电子邮箱的某些产品的推销广告。以此可以看到直邮营销正在被广泛的应用在各个领域,无论是传统的邮寄投递或者是通过网络的电子邮件,所以就出现了针对直邮的数据分析,这里主要介绍一下基于电子邮件形式的直邮分析。

直邮的特点和类型

  既然直邮被这么广泛的使用,一定有它的优势所在。直邮(Direct Mail,或者叫EDM,Email Direct Marketing),即直接通过邮件的方式发送的通知、广告等信息,它的特点简单地说就是:“定位准确、成本低、见效快”(都有点像医药的广告了-_-|||)。直邮的用户群体是既定的,也就是有选择性的,这让营销可以面向特定的市场和人群;直邮,尤其是电子邮件方式的直邮几乎没有显性的成本,这也让直邮成为很多促销和推广的首选;通过Email方式发送的直邮几乎可以认为是在发送后实时到达的,而大部分用户都有每天查看邮箱或者不定期地收取邮件的习惯,因此直邮的信息能够迅速地到达用户那边,以便快速地收到用户的反馈。

  直邮的类型比较多样,根据目的的不同可以分为:

  • 用于发展新用户的广告邮件,如邀请用户来使用或购买产品;
  • 用于推销产品的促销邮件,如产品的低价促销、活动奖励等;
  • 用于保留客户的提醒邮件,如购买商品的过期提醒,对很久未登录用户的召唤等;
  • 对用户操作的反馈,如订单状况、付款状况等;
  • 通过直邮方式发送的用户调查问卷。

直邮营销的准备

   发直邮前需要做哪些准备工作?也许营销部门的同事都已经驾轻就熟了,所以这里只是提一下当我们需要分析直邮数据时,在发直邮前需要做哪些准备:

  1. 明确直邮的目的,如吸引用户注册、购买等,这也是基于目标分析的前提;
  2. 选择合适的对象,也许可以通过分析用户的历史行为选择合适的用户群体进行精准地投放;
  3. 添加追踪的链接参数,主要包括统计直邮打开的带参数的小图片及需要追踪点击的各个链接及按钮的参数设置(这个会在下一篇具体分析的时候介绍);
  4. Call to action按钮及Landing page的设置,这些都将影响直邮营销的效果;
  5. 在直邮中添加退订按钮,这是对用户自主选择的尊重,也是直邮分析的需要。

直邮的实现流程

  好了,所有一切的准备工作都完成了,现在可以开始发送邮件了。那么我们来看一下这封小小的邮件会经历一个怎么样的冒险历程呢?

direnct-mail-process

——图中用黄色标识邮件服务器行为,蓝色标识用户行为

  其实一封邮件的路途看起来有点坎坷,它在任何时候都有可能经历被抛弃的危险。首先在发送时有可能因为地址无效或者网络问题导致发送失败;在到达用户的邮箱后,很有可能被邮箱服务提供商归为垃圾邮件而被放入垃圾箱;当然也可能招致用户的无视或厌恶,因而被用户直接删除或归为垃圾邮件;自然也会有些幸存者被用户打开了,但如果用户对内容不感兴趣也同样会遭受被抛弃的命运;而剩下的幸运儿们有幸得到了用户的赏识,用户准备点击链接进去看看,这时邮件的使命其实已经完成了,而很多时候大部分的分析工作也在这里“中止”了。

  根据上面的流程我们其实已经可以得到很多数据:发送邮件数、发送邮件成功数、用户打开邮件数、用户点击邮件数等的行为数据,基于此我们已经可以开展一些分析工作了,但这些数据和分析还远远不够,这也是为什么我上面用“中止”而不是“终止”的原因。其实从上面的流程图中可以看到还有最后一步——实现目标,这是基于目标的分析必须要做的事情,我们的目的并不只是让用户通过直邮进入我们的网站,我们的最终目的是为了让用户实现我们预期的目标(也就是直邮准备第一步中指定的目标),所以分析最终实现目标的用户数才是有意义的,也是对直邮效果的最客观的评价。这时我们可以说已经完成了80%的分析工作了,但我们还可以做得更多,我们可以考量下有没有实行剩下的20%的工作的需要——用户生命周期价值分析,也就是说我们不仅要关注直邮带来的用户的单次价值的实现,更应该关注这些用户是否能够为网站带来持续的价值,当然这类分析的成本也不低,对于某些类型的直邮而言,做好前面80%的工作就已经足够了。

  哦,对了,不要忘了,用户在打开邮件后,可能觉得这些信息他并不感兴趣,甚至已经有些厌恶了,他不再希望收到这类邮件,于是毫不犹豫地点击了退订按钮,所以我们也需要把用户的退订行为分析进来,这些对于我们也是有用的。

  这篇文章主要介绍的是直邮的一些特点和实现流程,以及我们可以对直邮做哪些分析。下篇会介绍针对直邮的具体的分析指标及分析方法,会在之后奉上。

数据立方体与OLAP

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

数据立方体

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

Data-Cube

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),下面还是以上面的数据立方体为例来逐一解释下:

OLAP 

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

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

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

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

  旋转(Pivot):即维的位置的互换,就像是二维表的行列转换,如图中通过旋转实现产品维和地域维的互换。

OLAP的优势

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

数据展现方式

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

查询效率

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

分析的灵活性

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

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

关于实时数据统计

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

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

实时统计的优缺点

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

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

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

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

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

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

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

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

实时数据的价值

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

baidu-data-by-hour

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

GA-data-by-hour

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

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

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

数据仓库的多维数据模型

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

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

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

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

多维数据模型实例

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

Star-Schemas

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

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

多维数据模型的优缺点

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

优点:

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

缺点:

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

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

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

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