分类目录归档:个人观点分享

一些个人的观点和想法

时间序列的趋势分析

——数据的上下文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指标进行数据上下文的选择和设定。

用户需要什么数据?

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)的企业文化,让数据不单只是单纯的展现这么简单,能够满足各类人员的不同需要,并最终依靠数据提高企业在各个领域执行的效率和效果。

BI应用中的三大矛盾

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

一个有效的内容推荐方法

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

为什么要推荐

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

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

选择简单有效的推荐方法

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

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

google-webmaster-linkrank

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

GA-landing-pages

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

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

GA-weighted-sort

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

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

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

为网站选择合适的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的,因为没有比直接衡量网站战略目标更有意思的事了。

让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%的工作就已经足够了。

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

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

关于实时数据统计

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,那么实时数据就是相当昂贵的。

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

优化相关内容推荐

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

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

更好地衡量导航实现度

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

featured-topics-navigation-summary

  从上图可以看到页面被浏览的次数(图中标注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个。

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

网站的相关内容推荐

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

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

rfm-related-posts

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

相关内容推荐效果分析

  网站中的相关内容推荐功能很多都是借助机器算法来自动生成的,所以从某种层度上来说,算法一定会存在优劣,我们需要通过分析来评估功能的实现效果,从而不断地对算法进行优化。而基于用户浏览行为的分析是评估功能实现效果的最有效的方法,所以网站分析又有了用武之地了,上面介绍的Google Analytics上的Navigation Summary就是非常适合用来分析相关内容推荐效果的工具。这里还是以电子商务网站RFM分析这篇文章的上下游页面分析为例看看我使用的这个插件的效果到底怎样:

rfm-navigation-summary

  从上下游页面的列表中查看那些来源于内容页面和去往其他内容页的比例,其中哪些页面的流入和流出的比例最高,然后再与网站相关内容推荐列表中的排名进行比较,这样就能反应网站功能的相关性与用户眼中的相关性是否一致,从而检验功能的实现效果。

  如果进行算法调整,那么同样可以用该方法检验算法调整前后的上下游页面转化比例,从而衡量在算法调整后相关内容推荐功能是否真正得到了优化。而我们要做的就是通过不断优化相关内容推荐的算法使网站内容的相关度排名与用户对内容的预期相关性尽量达成一致,这样才会使页面上显示的相关内容就是用户想要寻找的内容,从而满足用户的需求。

  这里需要注意几个问题:

  1. 也许一个内容页面里面会有不止一处的相关推荐模块,或者会有多处出现其他内容页的链接,在GA的报表上提供的是所有流入流出的总和,所以如果只是评测某一推荐模块的效果,需要区分该模块中的链接,也许加URL参数会是一个解决方案。
  2. 注意数据的时间区间与网站内容的变化带来的相关内容推荐的变化。Google Analytics上默认的时间区间是前一个月,你可以选择合适的区间来进行分析和比较,注意网站内容的更新对相关内容推荐带来的影响。
  3. 有些相关内容间的推荐并不是双向的,比如在购买MP3的页面推荐耳塞,而在购买耳塞的页面可能并不会去推荐MP3,所以有时有必要对上游页面和下游页面分开分析,注意转化的方向性。

  上面就是我想到的Google Analytics的Navigation Summary功能的两个应用实例,你是不是还想到了更多的应用,欢迎分享你的观点。