他是爱德蒙·唐泰斯，是我的父亲，我母亲，我哥哥，是我的朋友，是我，也是你。——Evey

【前言】

　　先要答谢各位读者，现在一个月一篇文章已经远不如当初承诺的一星期一篇文章，但仍然有朋友苦苦等待，我很辜负你们的期待，真的很抱歉。过去，有些文章，是献给某些朋友的。今天，这篇文章也想献给一位素不相识的朋友，包括今天的每期一句，我不知道是不是这世界还会有light，还会有honesty，但因为他，我信一切会有，因为如果你真的不恐惧来这个世界这个国度，并且为这个浑浊黑暗带来一点点光亮，那么，你踏步前行的身后，便终可能全是光明。我们与你同在。

　　这篇文章接上回：电子商务关键数字优化（线上部分，上）（http://www.chinawebanalytics.cn/kpi_optimization_part1/）

【正文】

着手提升基础驱动因素

　　我们在前文中，把影响电子商务关键数字（KBR数字）的驱动因素区分为两类：基础驱动因素和非基础驱动因素。我们也强调了基础驱动因素的重要意义，在大干快上的时候，千万不要忽视了打牢基础。

　　提升基础驱动因素，看似抽象，例如我们上回中的例子——“转化率的基础驱动”——多少听起来有些拗口，但操作却是实在的，具体的。在上回中，我们把影响转化率的基础驱动归结为如下项目，这些项目（item）即是我们需要动手逐个优化的。而这些项目优化的结果好坏，当然对转化率的好坏起到至关重要的作用。

　　影响转化率的基础驱动因素如：

• 关键转化过程
• 导航（分类）
• 搜索
• 信任
• ……

　　非基础驱动因素如：

• 产品页面
• 登陆页面
• 活动和流量匹配程度
• 外部流量本身质量
• ……

案例：如何优化KBR之转化率（3）——关键转化过程优化

　　现在我们开始着手一项一项提升作为KBR的转化率的基础驱动因素。这没有什么神秘的，这些都是网站分析从业者的基本功，也是网站分析这门学科必学必用的内容。如果要编一本网站分析的教材，这些必然是占有这本教材的主体部分。

　　例如，对于关键转化过程，这是我们大家都很熟悉的，我们找出转化过程中不佳的环节，然后检视这个环节中哪里出现了问题，然后加以改进。

　　左图中是这样的一个转化过程，电子商务网站上一个产品的销售过程大致是这样的过程。产品页可能本身就是登陆页，但是更多的时候，访问者看到产品页之前会先浏览其他的页面，比如活动页面、首页或是商品的列表页等等，然后，某个页面上的某个陈列着的商品引发了购买者的兴趣，于是他们才会进入这个产品的具体说明页（产品页）。

　　我们都知道，在进入产品页直到最后完成支付的一系列环节中，任何一个环节出现问题，就会影响最终的转化。例如下图中所展示的某种问题：

　　这虽然不是典型的电子商务网站，但“毛病”是一致的，在两个虚线的方框内的转化是存在明显问题的。我们通过Google Analytics的预定义转化（Goal和Step）功能，或者Omniture SiteCatalyst的转化丢失报告（Fallout），这些问题能够很容易地被发现。知道问题在哪里，事情就多少好办一点，我们可以用数据做进一步的证明问题出现的原因，或者有时候只是猜测，然后再改进现有的毛病，并进行测试真正解决这些毛病（具体的这些步骤我们后面会详谈，这里不引申了）。

　　总之，这是一个很稀疏平常的方法论，我想如果有一本网站分析的教材，这应该是基本的方法论了。

　　不过，有时候，事情不是这么“完美”的。并不是所有的转化都有明显的毛病，如果每个环节的丢失率都比较均匀，没有明显的短板，你会怎么办？或者，换另外一种极端的情况——每个环节都存在明显的转化丢失，你应该怎么着手处理？

　　显然，优化是永无止境的，没有明显短板并不意味着不值得优化，而如果每个环节都存在明显的转化丢失，你肯定更会手忙脚乱。这时候，上面的方法论可能不适用了。事情总都是一步步解决的，你不可能同时对所有的环节都进行优化，因此现在有三种可供选择的方案，你会选择那种？

　　A. 你会先从转化的前端开始解决问题，然后逐步深入到转化的后端环节；

　　B. 你会先从转化的后端开始解决问题，然后往前推，解决转化前端出现的问题；

　　C. 你会决定——这玩意儿好不了了，破罐子破摔吧。

　　选项C当然是开玩笑，如果你真的在乎这个网站的话，你不会这么听之任之的。但有时候，我们确实存在恨铁不成钢的沮丧，而且确实有些网站只能回炉重造。

　　A和B，我们往往是按照A实践，但我会选择B。

　　这或许没有对错，但我更倾向于B。

　　原因在于，越深入到转化的后端，就越可能是“基础驱动因素”，而转化的前端，则更多时候，是“非基础驱动因素”。我同样认为，有时候，把前端解决好了，会有很直接快速的效益显现，但我还是固执地认为，后端就是更重要些。没有对错，只是我的感觉。

　　这个感觉来源于对问题定位和解决的难度会因为这个问题是出现在前端还是后端而不同。看看下面这个例子——我们对转化的前端和后端分别进行优化，前端我们优化登陆页二跳率，从40%升高到50%，后端我们优化支付转化率，从40%提升到50%。其他条件不变的情况下，这二者优化对整体转化提升的贡献是一样的。可是，往往我们的分析和技术团队资源是有限的，我们如何选择？

　　我倾向于选择优化支付转化率。有两个原因。第一个原因，很明确，支付转化率是基础驱动因素，它的好坏影响全局。而登陆页数量众多，而且登陆页是会不断发生变化的，并非是基础驱动因素。

　　第二个原因，是因为对前端的优化相对而言更困难。转化越靠前端，影响其转化的因素越多，越分散，解决起来越是费劲。比如，影响二跳率的因素涉及到页面的设计、call to action、用户导引、流量质量、商品吸引力等等，这些都不是很快很轻易能够解决的。当然，明显无知小白错误（例如不匹配之类）的除外。

　　影响整体转化率的另一个基础因素是转化结构。这一点我在几次演讲中都有提到，但没有听过我演讲的朋友可能并不熟悉。

　　如下面三个转化的结果图所示：

　　正常转化是左边的图，有泄漏点（如同我们上面讲的那个航口售票网站）是中间这个，而不正常结构的转化（最右边这个），则是在转化过程中，很奇怪的没有按照预订的转化路径，而是发生循环，或是“四处乱窜”。通过“全路径报告”（这个报告在Google Analytics中没有，但是Omniture SiteCatalytics提供），我们可以发现这类奇怪的转化结构。这种结构对转化效率有重大影响。下图中，第八条主要路径（Top 8路径）发生了循环，而且循环发生在购物转化过程中。

兴趣阅读：转化结构失误的真实案例

　　转化结构失误是否真的存在？答案是肯定的。一个真实的案例是某一家航空公司的电子客票销售过程中，发生了显著的流程循环。

　　我们看到，在用户选择好航班，点击下一步之后，超过40%的访问者又会回到上一步，即回到选择航班的页面。

　　这种状况的发生极为严重的影响了整体转化率，订票转化率低至不足3%，但这个网站的同行们却平均有接近10%的整体转化率。

　　发生这种现象的原因很快被找到，当用户在航班选择页面挑选好某个航班后，相应的价格并不会显示在这个页面中，而是需要你点击“check price”按钮，进入到下一个页面中，才能看到你刚才选择的航班的票价。这是一个显然不会让人愉快的设计，而这个设计，也显然造成了转化过程中的循环——当人们看到机票价格并不是自己期望价格的时候，不得不回到上一页去选择新的航班，然后再点击“check price”查看新的价格。总之，这样的设计真的是糟透了。

　　现在，这个网站已经改掉了这个设计。但最初的毛病，在今天却成为一个很好的反面案例。

案例：如何优化KBR之转化率（4）——导航优化

　　我们解决了关键转化过程的问题，现在我们开始关注第二个基础驱动因素：导航。

　　导航优化也是网站分析学科中必学的课程，而且这一块也相对有成熟的方法论。

　　对于导航，我们关注几件事情：

　　首先，导航被过多的使用并不意味着是一件好事。可能你的商品并不容易被人轻易地找到，或者，人们总是容易找不到自己想要的商品，而不断尝试通过导航解决问题。

　　其次，导航被很少使用也是不合理的，这意味着你的用户没有访问深度。

　　然后，导航区域本身的设置是否合理？是否有一些导航的入口根本不值得放在导航区域，而另外一些则应该添补进来？

　　对于第一、二个问题，我们如下解决：

• 导航利用率的评价

　　导航利用率用来衡量网站导航被整体使用的情况，并进而推算用户是否过度或者过少使用了导航。当然，我们看到的一般现象是过度使用导航。

　　导航利用率通过网站中导航的总点击密度来表现，公式为：，分母为什么要减去bounce掉的PV，原因在于我们衡量这个值只有对非bounce的visitor才是有意义的。有时为了简单起见，有时候我也用公式：，但这个公式的意义显然不是很精确，减去首页PV意味着摒弃了首页的影响，这在首页最为最主要的landing page的时候说得过去，但并不科学。

　　上面两个公式计算的结果，如果数字越大，表明导航区域被使用的概率就越高。一般而言，对于第一个公式，我认为这个比例不超过40%是合理的，如果超过这个数字，说明用户在导航中转来转去，并没有实现你希望他们去做的事情——找到他们喜欢的商品并购买它。

　　现在，你一定会提出一个问题——总PV和Bounce掉的PV是容易拿到的，但导航区域的点击数如何获得？我的方法很简单，对所有的导航位置的链接URL，均会加上一个参数后缀，以区别它是用作导航的链接。例如，某一个入口处于首页的导航区域，链接到销售Prada的专题页面上，这个入口链接本来是http://www.chinawebanalytics.cn/prada.html，但是，因为它处于导航位置，因此我为它增加一个专门的参数“?from=nav”，这个链接也因此变为http://www.chinawebanalytics.cn/prada.html?from=nav。在GA中，这个URL会被记为一个不同的页面，但并不影响用户使用网页。这样，导航区域的点击数量就被转化为导航入口被点击之后所打开的相应页面的PV数，这样这个值就能够比较准确的获得了。

　　当然，这个方法又引起了另一个问题，即同样页面因为增加了?from=这样的参数而造成了duplicate pages，从而影响SEO的权重。但这个问题实际上是很容易解决的。在robots.txt文档中添加Disallow: /*?*

　　可以屏蔽所有带动态参数的链接，如果只屏蔽带?from=的，Disallow: /*?from=*即可。感谢我的同事Jay Huang在这个领域的专业贡献。

　　对于第三个问题，我们常用的方法如下。

• 导航区域本身的合理性

　　导航区域的合理性指导航入口的设置是合理的。这些入口应该是用户常用，并且分类清晰，有逻辑性，更重要的，是用户能够轻易找到，且不会被随意忽视，起不到导航的作用。

　　下图显示了两个导航区域的用户点击情况。两个导航区域中，都有一些很少被点击的入口，尤其是上一个导航的help，contact us，agents等。而在下面的导航区域中，our trips，your booking又有太多的点击，甚至人们几乎就是冲着这两个入口来的。因此这些导航有优化的空间。

　　总体上，我们认为导航的点击不太可能平均分布，但是，如果有过于密集的点击入口，或者过少的点击入口，你应该考虑优化。过于密集，意味着这个页面上该路径或者该功能的进入方式太过单一，可以考虑增加一些辅助入口。过少的点击，意味着这个入口出现在导航区域中的价值值得重新掂量。

• 导航路径合理性

　　导航路径合理性也是对导航的重要的评价。方法直接，用网站分析工具的路径功能即可。好的导航功能有清晰的符合逻辑的路径，不好的导航则可能出现很多不符合预期的路径，以及出现更多的循环。不再赘述。

案例：如何优化KBR之转化率（5）——站内搜索

　　如果我们继续探寻优化转化率的足迹，我们在基础驱动因素的道路上将必然碰到站内搜索。站内搜索与导航对用户体验的影响本质上是相似的，对于部分电子商务网站，这种影响甚至是决定性的。

引申阅读：电子商务网站的用户体验不一致性

　　电子商务网站的类型不同，造成了电子商务必然对用户体验具有不同的作用。同样一个电子商务网站，对某一类用户有很好的用户体验，对另外一部分则不尽然。

　　进一步说，这是人类购物天性使然。

　　我们购物有两种情况，一种情况是带着某种明确的目的进行购买活动，另外一种则是随便逛逛之后的应激性购买。相对而言，男性更倾向于第一种情况，而女性则后者居多。

　　电子商务网站往往都是两者兼顾，但相对而言还是有所偏向。由于网站定位、品类和商品特点、面向的人群不同，电子商务网站仍可以区分为偏向于服务于明确目的的购买，和偏向于服务于兴趣激发的购买。

　　前者，例如改良前的京东商城，或者淘宝（你会发现在淘宝上随便逛逛真的很困难，你的购买欲不会提升）。后者例如走秀网。这两类电子商务网站，用户目的的不同，用户体验优化的要点也不一样。第一种情况，很显然搜索功能必须非常强大；第二种情况，导航和商品陈设则需要非常考究。当然，并不是说对第一种情况导航不重要或是第二种情况搜索不重要，但侧重确实是有不同的。

　　站内搜索的优化同样有固定的套路，在Avinash的第二本书《Web Analytics 2.0》中有详细阐述。我好像已经忘记了一些他的原文，所以我就讲我在实践中用到的。

　　我在很久之前那次拥挤的分享中专门做了如何通过站内搜索优化网站的内容，当时，我的观点很明确，没有任何用户行为比用户直接搜索关键词透露的信息更有价值。今天，这个观点仍然没有过时，尤其是在你资源有限无法跟用户直接对话的情况下。

　　对搜索的关注如我左图所示。

　　搜索利用率跟导航点击密度是相似的，公式也很简单：。搜索利用率高的网站，更偏向于目的购买型，搜索利用率低的网站，则可能属于兴趣应激购买型，或是——搜索实在做的太差了。

　　除了搜索利用率需要我们自己计算外，其他的几个关键点都可以通过网站分析工具直接获得。例如，对于高search bounce和refinement的搜索词，Google Analytics提供很不错的报告，如下所示：

　　而0搜索结果页面则更是非常重要的报告（这个报告Google Analytics似乎没有），在Omniture的SiteCatalyst工具中，有专门的报告提供：

　　在上面的报告中，搜索词“handicom”是返回0结果最多的，如果你是SONY，你一定会知道该怎么办了。如果我们挽救了这些搜索handicom的用户，而且满足了他们想要了解handycam的本意，那么我们的转化率一定会受益菲浅。

　　高搜索结果返回页面是那些承载着搜索结果期望的页面，这些页面是否能满足（或者至少是部分满足）搜索者的预期，也同样影响转化率。

　　例如，上面的报表中，对于handycam这个搜索词而言，用户更多会点击搜索结果中的首页。这意味着，首页最好要满足这些人的需求，否则他们可能认为，这个网站并不能让他们更多了解这个产品，更不用说让他们购买这个产品了。

　　上面的这些案例，只是想要说明如何在辨识出基础驱动因素之后，通过研究基础驱动因素的绩效来为改进和优化创造可能。我相信这些行动是意义的。不过，上面的这些案例都是分析，并不是优化建议本身，更不是带来的优化结果。在我们上面的KBR优化路径中，你还需要做其他一些重要的事情以保证你所采取的行动是卓有成效的。这些，我将在这个系列的最后一篇文章中阐述，包括如何通过测试寻找真正的优化方法，以及如何更高级的满足用户的转化预期。

　　好了，先写这么多，请大家提出建议和问题，期待大家的留言！

　　本文译自Avinash的博客文章：Standard Metrics Revisited: #4 : Time on Page & Time on Site，这是下部分。上部分请见《Avinash文章精选：Time on page和Time on site（1）》

[转载请事先声明并得到许可，版权归作者所有。]

续上回：

　　用多标签页面（Tab）的浏览器浏览网站时Time on Site和Time on Page如何被计算： 　　Firefox的多标签页面浏览方式为其赢得了声誉——我真的不知道，如果没有这个功能，我这几年的网站浏览体验会变的怎样糟糕！新近几个版本的IE也同样支持多标签页面浏览，因此大多数人现在都在使用这个令人愉快的功能。【点击标题阅读全文】

　　但是对计算Time on Page和Time on Site而言，这却带来了麻烦。当人们在另一个标签页中打开同一个网站的链接，也就是同时通过两个标签页面来浏览同一个网站的时候，Time on Page和Time on Site会被计算成什么样子？要知道，我现在每天都是这么浏览网站的！:) 

　　这种情况混乱了网站分析工具对时间的计算。

　　下面是一个普遍的场景，通过这个场景我们能够理解多标签页面浏览带来的影响……

　　一个访问者来到上面的“Home”页面，然后在新的标签页（图中的New Tab）中打开了这个页面上的一个链接，此时Home页面占用了一个Tab（标签页面），点击链接新打开的另一个页面Page4占用了另一个Tab。这个时候，虽然Page4在新Tab被打开了，但用户并没有浏览Page4，而是回到前一个Tab继续浏览Home页面。在浏览Home的过程中，他/她点击了Home页面上的一个链接，Home页转到了Page2，但Tab没有新开，还是先前那个。再接着，他/她又点击Page2上的链接到了Page3，当然，还是同样的Tab。最后，在Page3，他/她关闭了这个Tab（或是干别的去了，再也没有点击Page3——这跟关闭Page3的Tab是一样的）。

[转载请事先声明并得到许可，版权归作者所有。]

　　关闭了上面的Tab后，访问者转到另一个Tab，也就是之前载入了Page4的那个Tab上来。他花了一些时间浏览Page4，然后点击其上的一个链接转到了Page5，不过Tab也还是先前Page4那个Tab。最终，从Page5，他再也么有点击别的链接，而是离开了你的网站。因此，在图中蓝色表示原先Home页面的那个Tab，绿色表示新打开的那个Tab（即New Tab）。

　　Time on Site在这种情况下该如何计算呢？我的经验告诉我，不同的网站分析工具对这种“多Tab型”的浏览行为有两种计算方式。

　　方式一：

　　网站分析工具将上面的这种多Tab浏览的情况按Tab的不同，逐一进行记录，也就是发生下面的计算：

　　统计结果输出：2个访问过程（即2个Visit或2个Session，Visit和Session是一个意思），每个visit对应一个Tab。

　　Visit 1 （图中上面那个）：[访问的来源会被记为：来自于Google，即referrer -> Google]

• Tp (Home) = 2 分钟
• Tp (Page2) = 3 分钟
• Tp (Page3) = 0 分钟
• Ts (整个同一Tab的访问的时长） = 5 分钟

　　Visit 2 （图中下面New Tab那个）：[访问的来源会被记为：来自你的网站Home页面，即referrer -> your site/homepage]

• Tp (Page4) = 6 分钟
• Tp (Page5) = 0 分钟
• Ts（整个New Tab的访问时长） = 6 分钟

　　这种情况下：网站分析工具的报告中会记录2个Visit，1个UV（Unique Visitor）。另外，请注意这种情况对于访问来源统计的影响（New Tab的那个访问的来源是被访问的网站自身）。

　　软件工具给了一个非常有趣的输出结果！

[转载请事先声明并得到许可，版权归作者所有。]

　　方式二：

　　有一些网站分析工具会“纠正”所有的这种多Tab的“点击（hit）”（即log文件中的记录），他们会将这些hit进行线性化处理，把它们合并为同一个访问过程，以消除多个Tab（标签页面）造成的影响。

　　还是用上面那个例子，但是我们转化一下表现方式——下面的这个图表明了一个同样的过程，不同的颜色代表不同的Tab。

　　[此图更漂亮的高分辨率图请点击这里：多Tab浏览对Time on Site的影响——线性化]

　　统计结果输出：1个访问过程（即1个Visit或1个Session），在这个访问过程中包含了两个Tab。Visit的过程通过“时间戳”被重新组织为上图。

　　这个Visit：[访问的来源会被记为：来自于Google，即referrer -> Google]

• Tp (Home) = 1 分钟
• Tp (Page4) = 1 分钟
• Tp (Page2) = 4 分钟
• Tp (Page3) = 2 分钟
• Tp (Page5) = 0 分钟
• Ts (整个网站的访问过程) = 7 分钟

　　在这种情况下：1个Visit，1个UV（Unique Visior）。

　　这两种方式没有一个能够完美的再现这个访问者在网站上真正的访问过程和停留时间。

　　你喜欢哪一个统计方式呢？

　　请一定要问清楚你的网站分析服务提供商，他们采取了上两种方式中的哪一种来计算多Tab（标签页面）浏览时的时间和访问过程。

　　考虑到越来越多的人都在使用多Tab浏览，因此选用何种方式将会对你网站分析最后的数据输出有巨大影响——毫无疑问，两种方式统计的最终数据肯定会有很明显的差异。

　　Google Analytics使用第二种方法，即“线性化”访问过程的方法。

　　现在做个深呼吸吧！

 　　额外的监测手段：

　　总是有些类似于“黑客”的手段能够让你知道用户在最后一个访问页面上停留的时间（如果你使用事件logging (即event logging)的话，甚至能了解访问者最后一个行为是什么）。

　　最常用的手段之一（我指的最常用的手段的意思是大概有0.001%的人在使用）是在页面上增加额外的脚本（script）/代码（code），以帮助你抓取网站页面在浏览器中被关闭，或是链接到别的网站，或是长时间不再点击等情况发生时的真实过程。我们通称这些离开你的网站的种种情况为“页面在浏览器中的‘反载入（unloaded）’”，而在技术上，这种情况则被称为“反载入前进行的行为（onbeforeunload event）”。有点儿拗口，但相信你能理解。

　　在利用额外脚本或代码的情况下，你不仅能够像往常一样得到页面被请求时的“时间戳”，你还能得到页面反载入时的“时间戳”。这样，你就能够计算出最后一个页面的访问停留时间了。

　　你可以自己建立这种脚本，也可以让你的网站分析服务商帮你创建。接着你就能够让你的服务提供商帮你调整网站分析工具的Time on Site （以及Time on Page）的计算，以能够使这些工具利用额外的反载入的时间戳来进行更精确的时间计算。

　　如果你正在自己进行log文件的分析工作，你也可以通过额外脚本/代码的方式轻松的调整log文件的数据和分析，接着就能按照更准确的方式计算这两个度量（metrics）了。

　　下面还有一些其他的“黑客”工具。

　　总有一些人勇于冒险，他们在网站分析工具中添加了“链出链接追踪”（链出链接的英语是：outbound link，指网站上那些链接到其他网站而不是链接到网站自身页面的链接，译者注）链出链接追踪也被通常称为的退出追踪(exit tracking)。通过这个追踪方式，网站分析工具就能够利用访问者点击链出链接的“时间戳”来计算访问网站最后一个页面的时长。

　　我并不是这种就“链出链接”方法的“大粉丝”，因为大多数人离开你的网站可能并不是通过点击你网站上的“链出链接”——道理很简答，你网站上的绝大部分链接都肯定是连到自己网站内容的，而不是链接到别的网站。因此，假如你使用“链出链接”来计算的话，所有其他通过“直接关闭浏览器”或者“长时间不点击你网站链接”退出网站的访问，都将无法被计算出最后一页的访问时间。因此，对于一些访问者（指点击链出链接退出你的网站的访问者），你按照新的方式在统计，而对另外一些访问者（指关闭浏览器等方式退出的访问者），则还是沿用了最初的统计方式，这样就造成了统计方法的混淆。

[转载请事先声明并得到许可，版权归作者所有。]

　　这种方式把这摊浑水搅得更浑了。眉毛胡子一把抓不是好办法。

　　我希望这个帖子（实际上是连载的两个帖子）能够帮助你理解Time on Site和Time on Page是怎么计算的。当下次你再看到平均Time on Site和平均Time on Page的时候，你要知道这些数据中包含了什么，以及没有包含什么。

　　另外，下一次你在利用不同软件工具比较这两个度量的时候，在得出结论之前，你要知道那些必须先问问自己的问题。

　　最后的思考：这个帖子的目的不是有意无意的暗示Time on Site不是一个好度量。相反，对于各种类型的商业模式而言，它都是一个关键度量。我的希望是教会大家这个度量是如何计算的，以帮助大家在更多信息量的帮助下做出好决定。没有网站分析的度量是没有缺陷的（总不至于比UV即Unique Visitor的缺陷还大吧！），Time on Site或许是他们中间缺陷最小的一个了。:)

　　好了，现在轮到你说些什么了。请通过下面的评论栏分享你的看法，批评，给我鲜花或是向我拍砖。网站分析的天神在上，我说的都是对的吗？请留言吧！ 全文完。

[　　译者留言：如果你对自己的英语有自信，请看另外一个文章，这个文章对Time on Site和Time on Page有更精确的描述：http://www.roirevolution.com/blog/2008/05/time_on_page_and_time_on_site_how_confident_are_yo.html

　　谢谢大家撑着把这么长的文章看完！:) ]

　　本文译自Avinash的博客文章：Standard Metrics Revisited: #4 : Time on Page & Time on Site 　　翻译这个文章是很有意义的，因为Avinash的这篇文章精辟的讲解了二者的含义和区别。其中Time on page指访问在页面上的停留时间；Time on site则指访问在网站上的停留时间。下面是译文，因为原文较长，因此改为上下两期连载，下部分在：http://www.chinawebanalytics.cn/?p=159，请大家关注。最后感谢亲爱的Avinash！【点击标题阅读全文】

　　尽管我使用Time on page和Time on site作为网站分析的基本度量（metrics）已经有很长时间了，但直到此刻我才真正了解到它们到底是如何被测量出来的。

　　这真是个重要时刻！

　　当然，最有效最精确的了解每一个访问网站的visit的时间长度的方法是：给每一个visitor身上加装RFID标签（RFID标签是一种无线识别技术，我们最常见的应用是北京市政交通一卡通，译者注），而且要求每个visitor在浏览我们网页的开始和结束的时候都必须在识读设备上刷这个标签。这将能够让我们精确的知道访问时间的长度。

　　可是我们不可能做到！这——多么令人失望啊！！

　　哈哈，只是个玩笑罢了！

　　不过，说真的，我发现极少有人知道网站访问的平均时间（Average Time on Site）是怎么计算出来的。

　　而且不论数据源是什么，人们对Time on Site的计算都知之甚少——无论是使用竞争情报分析工具，还是某种网站分析解决方案（在网站分析解决方案中，也不论是那种数据的获取方式——不论是WebLog还是JavaScript的标签方式获得的数据，都没几个人知道网站访问平均时间是怎么算出来的）。

　　因此，这个帖子就是想要解释清楚，Time on Page（页面停留时间）和Time on Site（网站访问时间）是如何计算的。

　　为了简单点儿，我将假定下面的这个session（访问过程）发生在某一个网站上：

　　有人访问了你的主页（如图中Home），你的网站分析工具则开始为这个访问者计1个Visit。接着这个访问者又浏览了另外两个页面（如图中的Page2和Page3），然后他/她离开了你的网站（离开的你的网站可以是通过关闭浏览器，或在地址栏键入一个不同的网址，或是点击了你网站上链接到其他网站的链接……）。

　　我们想要知道的事情如下：

　　Tp = 花费在一个页面上的时间（Time spent on a page）；

　　Ts = 花费在这网站上的总时间（Time spent on the website）。

 　　假如这个从10:00开始访问你的网站……

　　你的log文件就会有一条记录（无论是weblog还是javascript标签都能得到这个记录）告诉你：“有人在10:00做出了访问网站首页的请求。”

[ 　　实际上看上去更应该是下面这样的……

111.111.111.111 - - [08/Oct/2007:11:17:55 -0400] “GET / index.html HTTP/1.1″ 20010801 “http://www.google.com/search?q=avinash+kaushik&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:en-US:official&client=firefox-a” “Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.8.1.7) Gecko/20070914 Firefox/2.0.0.7″

　　注意到粗体字的“时间戳（Time Stamp）”了吗？

　　为什么要插入如此技术性的东西破坏我们正常的讲解呢！这样吧，如果你想要更多的技术性的解释，请看这个帖子：通过样本解释Log文件（英文）。

]

　　目前，所有的网站分析程序都能精确的获知一个页面访问请求发生的时间，但是这还不足以解释Tp和Ts到底有多少，因为我们还需要更多的信息，因此：

　　Tp = N/A（N/A的意思是无法提供）

　　Ts = N/A

　　下面我们接着看，更多有趣的事情发生在你的网站上了：这个访问者点击了一个链接，然后从你的主页链到了Page2。万岁！没有Bounce！:)

　　现在，你的log文件上会出现一条新的记录：“同一访问者在10:01做出了Page2的访问请求。”

　　好了，你的网站分析程序能够计算出一些访问时间了！

　　我们能够知道这个访问者在主页上待了多久了。就是用10:01减去10:00即可，得到他/她访问主页的时间是1分钟，即：

　　Tp (Home Page) = 1 分钟。

　　请注意，下面这一点很重要：你的网站分析程序计算1个Visit花在某个页面上的时间（即Time on Page）有多长的唯一方式是比较两个“时间戳”。一个“时间戳”来自于第一个页面的访问请求，另一个“时间戳”则来自于第二个页面的访问请求。

　　现在回到我们的例子上，Page2上有一个“用200元买210元商品！”的链接吸引了这个访问者，于是他/她点击了这个链接到了Page3去买这个商品。真是甜蜜的成功啊！这时一个“Engagement！”

　　从上面的图中，我们可以知道，对于Page2而言，访问时间是10:05-10:01，即4分钟。

　　Tp (Page 2) = 4 minutes。

　　访问者来到第三页才发现这个“200元买210元商品”的折扣仅仅提供给生活在南极洲且能够证明已经拥有了自己的电冰箱的消费者！！这——真是“变态”的“折扣”，你能想象到这个访问者到了Page3看到这个信息后会做什么……

　　当然是离开这个网站！

　　那么，这个访问者到底在Page3停留了多长时间呢？

　　问题出现了，因为网站的log 文件上没有访问者离开Page3时的“时间戳”，这样我们就无法计算访问者到底在Page3上停留了多长时间！这样：

　　Tp (Page3) = 访问请求Page3的时间(10:05) 减去 下一个页面的请求时间（N/A即无法提供）。

　　因此，

　　Tp (Page3) = 0 分钟 （因为下一个页面的请求时间无法提供！）

　　因此，网站分析程序不知道访问者花在网站最后一个页面上的时间是多少。对于绝大多数网站分析工具而言，都是如此。

　　让我们用下图来表示各个页面网站分析工具统计的访问时间：

　　Tp (Home) = 1 分钟

　　Tp (Page2) = 4 分钟

　　Tp (Page3) = 0 分钟

　　那么，这个Visit在整个网站上的访问时间（即Visit Length，访问长度）是多少呢？

　　Ts = 5 分钟。（Ts即Time on Site）

　　合理吗？

　　我觉得可能不太合理，因为你不知道访问者花在最后一个页面上的时间是多少，因此网站分析工具给你的时间统计一般都会少于用户实际在网站上停留的时间。不过，对于这两个概念的计算方法的解释合理吗？给我留言吧！

未完，待续……

　　Bounce Rate既然引起了大家的兴趣，自然而然的，一个问题就会出现——Bounce Rate的数值介于什么样的区间算正常呢？

　　我们知道，某个页面的Bounce Rate = Single Page Visit / Total Visit，因此Bounce Rate的极限值是1，也就是100%。当Bounce Rate = 100%的时候，说明所有访问这一页的Visitor，都没有再点击这一页上的其他链接，以打开网站上其他新的页面。如果发生这样的情况，我们可以基本认定：【点击标题阅读全文】

• 要么是这个网页上根本就没有其他链接了（这实际上基本不可能）；
• 要么就是这个网页做的太没意思，没有激发起Visitor的任何意愿去该页面链接的其他内容了。

　　如果你的Bounce Rate是100%，除非你的页面上没有任何其他链接，那么，你应该相信，是你的页面内容质量相对于来你页面的访问者而言，出了相当严重的问题。

　　从这个角度看，Bounce Rate显然是越高越不好，反之，越低则表明你的页面更能吸引访问者。回到我们前面的问题，一般而言，多高的Bounce Rate算好呢？

　　Google Analytics提供了一个“Benchmark”的功能，即对比某个行业的网站统计数据均值，不过，遗憾的是，这个行业的均值并不能具体到我们国家，而是一个Global（全球）的行业均值。而我们国家的网络分析基准数据，又和美国或者欧洲有着巨大的差异。

　　其中，差异最大的当属Bounce Rate。差到什么地步呢？我只能凭借经验告诉你，因为，目前还没有找到一个方法或者一个提供商能够提供我们国家各细分行业网站的平均Bounce Rate。不过，没关系，已经能够说明问题了。在进行下面的比较之前，我要强调的是，由于不同的Traffic Source（流量来源）来的Visit，其Bounce Rate也是不同的，因此我们下面的比较基于从横幅广告，也就是点击Banner进入Landing Page的Bounce Rate，（我的朋友David Hao也谈到了这一点）。

→

图：从Banner到Landing Page的流量示例

　　从Avinash、Peterson的博客以及其他海外的网站分析（Web Analytics）资源中，我大致了解了美国和欧洲的从横幅广告链接到Landing Page的Bounce Rate，我听到他们更多谈论的是，“Bounce Rate超过了70%，这不是一个好信号！”而我在工作中，还很少发现有Banner过来的Visit，其Bounce Rate低于80%的，或者说，从来就没有看到过！我看到的更多的情况是，从Banner到Landing Page的Visit，其Bounce Rate介于90%到99%之间，能够接近90%，已经很不错了！

　　也就是说，Banner到Landing Page的Bounce Rate是：

• 美国以及欧洲：70%左右，或以内
• 我们国家：90%以上。

　　因此，如果你看到自己的网站有90%多的Bounce Rate，而且你的网站流量主要来源于广告Banner的话，那么你大可不必大惊小怪。如果高于95%，甚至达到99%，也未就是你一个网站如此，但肯定是不好的，这说明你在浪费广告预算，你该琢磨琢磨怎样降低这么高的Bounce Rate了。

　　最后要说明的一点是，这个数据不代表所有的情况，因为行业与行业之间是不同的，消费品行业和大型机械行业的Banner to Landing Page的Bounce Rate肯定有区别，而我并没有调查所有的行业。因此，这些数字仅是经验数字，供大家参考。

　　我非常想听到你们Bounce Rate的数据，以及你们关于Bounce Rate的任何看法，请给我留言吧！！

[转载请事先声明并得到许可，版权归作者所有。]

1, 2, 3, 4, 5, 6

　　七、其它可度量指标

　　带宽（Bandwidth）

　　定义：网站流量的度量标准（以数据传递的千字节为单位）。

　　度量方法：使用分析日志文件的方式进行统计可以根据日志文件中每条记录中返回文件的大小来统计网站的带宽。

　　重载（Reload）

　　定义：访问者点击浏览器中的重载（Reload）按钮或者是刷新（Refresh）按钮重新载入当前的页面的动作。

　　度量方法：用分析访问日志文件的方式进行统计，当访问者执行重载操作时都会重新发起对该页面的请求，可以将30秒内相同的请求判断为访问者执行了重载的操作，记录重载次数。

　　评论：重载操作的数目无法完全准确的被判断。我们建议并列页面阅览数和重载数，而不必从页面阅览数中减去重载数。迎程度和访问者对网站的忠诚度。

　　点击（Click）

　　定义：一次点击是指访问者的鼠标在一个超文本链接上的一次单击，目的是为了沿着它的链接获得更多访问者感兴趣的信息。

　　度量方法：只有使用分析日志文件的方式可以统计出对于某个超文本链接点击次数。

　　评论：点击数量（Click-Through、Clickthrough）和点击是同一术语。点击通常被用于网络广告的统计。

　　点击率（Click Rate）（事实上，目前的点击率所用的英文是Click Through Rate，简写为CTR，引用者注）

　　定义：点击链接的百分比。

　　度量方法：点击数除以链接所在页面的请求数。（更容易理解的方法是，点击率 = 链接被点击的次数/链接被曝光的次数。点击率一般用在横幅广告即Banner上，因此更简单的公式是，CTR = Click / Impression，引用者注）

　　评论：收益（Yield）和点击率是同一术语。点击率有多方面的价值，在网络广告中，它是广告有效性的表现，它表示访问者已到达广告客户的网站，而且这些网站还可以提供其它信息。

　　广告请求（Ad Request）

　　定义：指访问者对页面中广告元素的请求。

　　度量方法：广告请求的度量方法参考页面阅览的度量方法。

　　八、讨论（FAQ）

Q.

　　统计的实现有没有其它方式？

A.

　　另一种方式就是在希望进行统计的页面上嵌入一段统计的代码，这段代码引用了另一服务器上的资源，这个资源通常是由一个CGI程序（或其它类似的程序）动态生成的，当访问者访问该页面时，将向此CGI程序（或其它类似的程序）所在的那一台服务器发出请求，这样该页面被访问的信息及访问者的信息就会同时被那个CGI程序所记录。这种方式易于做到实时的统计分析，统计信息较为丰富，而且不会增加Web服务器端的负荷。但是这种方式容易被欺骗，也容易由于带宽等原因而造成统计信息收集的失败。这种方式由于易被欺骗而存在着不安全的因素，也许在安全问题得以解决之后，它将成为更好的统计实现方式。从易用性，内容丰富的程度来看，对这种统计方式的探索是有价值的。

　　（有意思的是，这种方式是目前我最常用的方式，也是操作最为简单的方式。我喜欢这种方式。引用者注）
Q.

　　为什么用户会话的时间期间定为20分钟？

A.

　　我们参考了国际互联网络界关于用户会话时间期间的使用，发现主要使用的时间期间为30分钟和20分钟。这个时间期间将影响到用户会话数的度量，如果该时间期间更加接近于用户在网站上的平均停留时间，则用户会话数将更加接近于网站的用户访问人次数。CNNIC对国内部分网站的统计表明，用户在信息量大的网站上停留的时间更长一些。我们认为目前用户会话时间期间定为20分钟是合适的。我们会调整这个时间期间以适应国内互联网络的发展。

Q.

　　广告客户想知道他们的广告确切地被访问者看到的数目，而不是仅仅知道访问者曾发出过请求。用什么指标可以回答广告客户的问题？

A.

　　我们非常理解广告客户想知道他们广告实际被看到的数目的要求，但实际上是无法完全准确地度量出这样的数据的。如其它媒体一样，广告客户为潜在的阅览数量付费（如按印刷的数量）。我们所能获得的准确的数据只有访问者发出的请求。在此文档中我们建议统计于”请求”的层次而不是”递送”的层次，因为网站是否成功地将内容递送给用户是由多方面因素决定的，其中包括网络的状况和用户的行为偏好等，所以难以被精确统计。可以用广告请求这一指标来近似表明访问者看到的广告的数目。

Q.

　　我们的网站想了解访问者是从哪一个省、市、自治区来访的，可是似乎没有这方面的统计指标？

A.

　　尽管访问者的地理位置是一个很有价值的信息，但列出访问者是由哪个地理区域来访的是很困难的，仅仅由IP地址来判断以地域划分的访问者来源是不可靠的，而且目前也没有近似的指标来表明访问者的地理位置。（这一点迄今为止似乎也没有精确的解决办法，从IP判断仍然是主要的方法，但这一方法的确不准确。Google Analytics目前似乎做的不错，但还没有证据表明，这个工具用了别的什么办法来精确化这一报告。引用者注）

Q.

　　页面阅览和页面请求似乎是不同术语，为什么这份文档认为它们是同一术语呢？

A.

　　页面阅览一词侧重于测量访问者真实看到的页面，页面请求则侧重于由访问者发起的请求数量，即使最后可能访问者并未真正阅览到页面。认为它们是同一术语有两个原因，其一是曾经提到的我们建议统计于”请求”的层次而不是”递送”的层次，因此这两个词的度量方法是一致的，其二是我们希望此文档能够简化过于繁杂的术语，将术语的数量精减，并有统一的解释。但当提到服务器接收到的对HTML文档的请求时，仍可以使用页面请求一词。

　　（我认为不应该混淆此二名词，二者并不等同。请参看我的相关帖子。引用者注）

Q.

　　我看到报纸上有报道说”某某网站首页访问量在两个月内达到70万人次”，这是什么意思？

A.

　　这是不准确的说法，因为精确的访问人次在目前的技术水平下是无法被测量到的，将用户会话数解释为访问人次是错误的。如果网站的用户会话数为70万，则报道就应该说”某某网站用户会话数在两个月内达到70万”而不是”某某网站首页访问量在两个月内达到70万人次”。

Q.

　　这些术语的定义和度量方法实现在我们现有的系统上是否很困难？

A.

　　对于大多数网站来讲，这并不会是一个大问题。因为在起草这份文档时，我们参考了一些国内外现有的统计和度量网站访问量的服务和软件工具，事实上它们基本已经在使用这些术语和度量方法。但是网站访问量的统计和度量还是一个缺乏标准的领域，我们起草这份文档的初衷之一正是希望此领域能够变得有章可循。

　　未完，待续……

　　不过，对于网站分析而言，Engagement就是一个让人捉摸不透的度量了。

　　首先，对它的翻译是很困难的，原因在于，在汉语中，找不到一个单纯的二字词能够代表它。不仅汉语没有，其他语言也很罕见。我在Avinash的博客中看到一个西班牙的网站分析师抱怨道，Engagement真不是一个好的度量，因为西班牙语中找不到能跟它对应的表达。由于这个原因（实际上是原因之一），不少网站分析师要求把Engagement从WA的度量中给去掉。【点击标题阅读全文】

[转载请事先声明并得到许可，版权归作者www.chinawebanalytics.cn所有]

　　其次，Engagement是WA度量中唯一一个存在不确定性的。为什么这么说呢？还是让我们首先了解什么是Engagement吧！

　　由于没有人给Engagement一个普遍认同的汉语名词（如同Bounce Rate一样），因此我斗胆给它取一个中国名字——“交互度”。（CNNIC曾经给Engage做出过一个解释，叫做“交互操作”，但没有给Engagement解释，我起的这个名字外延了这个解释。）

　　顾名思义，“交互度”衡量的是访问者和网站的交互程度。什么算是交互呢，没有一个精确的定义，但是一般认为，访问者参与到网站的服务中做出某些相应的行为，会被认定是交互。交互的类型包括但不限于：

• 点击链接，访问下一个页面
• 播放视频/音频/动画
• 下载文件
• 提交留言/参与调查
• 上传文件
• 进入互动游戏（如Flash形式的游戏）

　　你会看到，所有上面的这些交互行为都有一个共性，那就是用户必须做点儿事情，参与到网站中来。不过，你可以发现，在上面的列表并没有页面浏览，即PV（Page View）。的确，一般情况下，Engagement不会把页面浏览作为一种交互，而把Visit即访问作为一种交互行为。

　　当然，我相信，看到这里，你会很糊涂，你到底要讲什么？没错，这些都是网民的交互行为，但它们跟Engagement有什么关系啊！？

　　答案是，Engagement跟上面都有关系，它是上面这些行为的总称。而Engagement作为一个度量，就是用于衡量一个网站上所包括的所有交互类型中，从总体看（而不是分别衡量各个交互类型）用户到底参与了多少。

　　那么，怎样衡量Engagement呢？实际上，Engagement和Visit或者PV一样，都是用数量来衡量的。有一个名词专门代表Engagement的量——Engagement Index，即“交互度指数”。这一点与Visit和PV是不同的，你可以说Visit = 15，但是你不能说Engagement = 10，而必须说，Engagement Index =10，或简写为EI = 10。

　　既然Engagement可以用数量衡量，那么，应该怎样衡量呢？我举一个例子： 　　这是一个视频网站的截图。我们需要计算这个网站这个页面的用户Engagement Index，从而发现用户在这个页面上的参与度究竟如何。具体过程如下：

1. 考虑这个页面的不同交互，哪些是你认为重要的，哪些是次重要的，哪些是不重要的。在这个例子中，我们假设存在一个在线营销活动，我们最希望用户点击E区，访问“时尚迅驰”的活动页面；其次，我们希望用户尽量注册我们的网站，也就是C区，然后我们希望用户登陆，即B区；再次，我们希望用户至少能够访问页面中的视频，即A区。最后，最低限度，我们觉得用户点击访问“精彩频道”（D区）也有点儿价值，只不过价值没有前述行为那么大。这样，我们就有了一个图景：用户访问的价值从大到小依次是：E>C>B>A>D。
2. 为不同的价值互动区域赋以不同的权重（Weights）。既然，我们认为对E的访问是最有价值的，那么我们就为每个访问E区的Visit赋5分；其次C：3分，再次B：2分；A：1.5分，D：1分。除了ABCDE外，其他还有可以点击访问的链接，但是我们认为它们对这次营销没有意义，因此不赋分数。
3. 分别将ABCDE的Visit值与各自的权重相乘，然后再相加，得到总数即是Engagement Index。

　　如果Visit to A = 1,000，Visit to B = 2,500，Visit to C = 10,000，Visit to D = 200，Visit to E = 50。那么根据我们之前设定的权值，Engagement Index = 1000*1.5 + 2500*2 + 10000*3 + 200*1 + 50*5 = 36750。

　　这样，我们就知道，用户跟这个页面的交互度是36750，如果有其他的营销活动数据相比较，或者有历史数据，我们就能够知道这一次的网友参与情况究竟是好，还是不好了。

　　你可能会问，是不是赋权重值，完全是随意的？随意，并不是，因为要根据你认为的页面价值区域的不同，设定大小不同的权重。但的确，由于每一次网络营销或者网站本身的不同，权重是根据情况变化的，因此Engagement作为一个度量，它非常特殊，第一，它是一个复合度量，即权重和访问的乘积，然后求和；第二，它并不是放之四海而皆准的度量，根据不同的营销目的或网站，其内容一般都是不同的。

　　这样，就回到了我们前面所说的，Engagement是一个很难捉摸的度量。但是，这个度量却具有重要的意义，它能够告诉我们，网站的效果到底有没有真正达到目的，因为仅仅衡量Visit或者UV或者PV，而没有权重，很可能相应的数据非常好看，但实际上用户没有访问到我们希望他们的地方，正所谓收之桑榆，却失之东隅。

　　有没有什么我没有说清楚的？有什么建议吗？在实际使用Engagement的过程中，有没有碰到困难？请告诉我，给我留言吧！

[转载请事先声明并得到许可，版权归作者所有。]

　　事实上，Florian告诉我，我的这个观点是错误的，WA工具会自动屏蔽掉这部分流量，以免污染实际Visitor的访问，因此在GA上不会看到Robot的访问情况。

　　不过Tenly的期望是，能够从这些工具中看到对于Robot的访问，因为他对SEO非常关注，而Robot访问的情况，一定程度上能够帮助他了解SEO的效果如何。 　　有没有朋友了解这个问题？给我一些建议吧！

　　融海咨询的CTO程实给我们了一个非常准确的回答，非常棒！

　　“Hi, Sidney, WebTrends有专门针对Spider（或Robot）的报告，因为WebTrends可以将Web Server的原始日志作为数据源，对其进行分析获取相应的信息。

　　除此之外，WebTrends还可以提供服务器端错误（HTTP CODE 5xx系列错误），客户端错误（HTTP CODE 4xx系列错误），页面无法找到（404错误）等其他来源于Web Server原始日志的报告。 以上报告需要客户购买安装了WebTrends产品。

　　当采用在页面中嵌码收集日志时（例如On-Demand Service）是无法获取该类报告的，其他分析工具（如Google Analytics）因为只有页面中嵌码一种日志来源，因此均不能提供该类报告。

1, 2, 3, 4, 5, 6

　　五、访问者特征指标及度量

　　浏览器（Browser）

　　定义：一个用于定位和阅览HTML文档的程序（例如：Netscape Communicator、Mosaic、Microsoft Internet Explorer）。度量方法：

　　可以从日志文件中获得浏览器类型的信息，以此获得统计的数据。

　　评论：通常可以获得软件厂商的名字、浏览器的版本等信息。但是浏览器字符串（BrowserString）没有标准的格式，这是分析它的一个困难之处。

　　平台（Platform）

　　定义：访问网站的访问者使用的操作平台。

　　度量方法：同分析浏览器一样可以分析浏览器字符串（Browser String）来获得关于操作平台的信息。

　　评论：考虑到特殊的浏览器如WebTV和SEGA，称为操作平台比称为操作系统更恰当一些。它们可以通过伴随URL请求而来信息加以识别。

　　浏览器语言（Browser Language）

　　定义：浏览器所用的语言。

　　度量方法：可以通过浏览器字符串（Browser String）来得到浏览器的语言，HTTP_ACCEPT_LANGUAGE环境变量也可以反映浏览器所希望接收的HTML文档的语言。

　　评论：并不是所有浏览器都可以获得它所用的语言。使用分析日志文件的方式无法获得浏览器语言的数据。

　　域名（Domain Name）

　　定义：互联网络上对应于计算机的IP地址的文本地址，它是连接在互联网络上的计算机的正式的名字。

　　度量方法：度量域名实际上是考察远程计算机所在的一级或二级域（Domain），如：.com、.edu、.cn、.com.cn、.net.cn等等。REMOTE_HOST环境变量和日志文件都会记录远程计算机的主机名和域名，但并不是所有情况下都可以获得远程计算机的主机名和域名。

　　评论：并不是所有连入互联网络的计算机都可记录其主机名和域名，大部分计算机被记录的仍然是IP地址而不是它们的主机名和域名，对于没有主机名和域名的计算机，统计其所在域时应标明”未知”。不同的服务器及其配置，会影响到是否可以获得远程计算机的主机名和域名。可被反向解析IP地址的远程计算机往往会被记录下其主机名和域名，但是在记录日志文件时进行IP地址的反向解析将增大服务器的负荷，尤其对访问量很大的网站。可以在分析日志文件时再进行IP地址的反向解析，当然这也将减慢分析的速度。

　　指引链接（Referrer、Referral Link）

　　定义：访问者点击一个页面中的链接而被引导至当前HTML页面，则该链接是当前页面的指引链接。

　　度量方法：从HTTP_REFERER环境变量和对服务器日志文件的分析中可获得指引链接的信息。

　　评论：有时候也会遇到指引页面（Referring Page）一词，它们的意义相近，在浏览器中总是由指引的URL到达目标的URL。

　　六、访问者行为指标及度量

　　每页面请求的平均时间（Average Time Per Page Request）

　　定义：访问者每次多个页面请求的平均时间。

　　度量方法：用户会话的第一次请求至最后一次请求间的时间 ÷ （用户会话期间的页面请求数－1）。

　　评论：每页面请求的平均时间应该在一个比较大的范围内求得，计算用户会话时长之前应该已计算出这个值。

　　用户会话时长（User Session Length）

　　定义：一次用户会话的时间长度。

　　度量方法：用户会话的第一次请求至最后一次请求间的时间 ＋ 每页面请求的平均时间。

　　评论：用户访问时长和用户会话时长是同一术语。

　　平均用户会话时长（Average User Session Length）

　　定义：网站访问者用户会话的平均时间长度。

　　度量方法：总计的用户会话时长 ÷ 用户会话数。

　　评论：平均用户访问时长和平均用户会话时长是同一术语。

　　返回访问（Return Visits）

　　定义：在一特定时间内，访问者在不同用户会话中再次访问网站的次数。

　　度量方法：度量在一特定时间内，访问者在不同用户会话中再次访问网站的次数。

　　评论：这一特定时间可以由进行统计的机构决定。建议的时间可以是一天或者不设置这一特定时间，后者可以表明访问者总共访问该网站的次数。返回访问的次数表明了网站的受欢迎的程度。

　　未完，待续……

1, 2, 3, 4, 5, 6

　　四、网站访问量指标及度量

　　唯一访问者（Unique Visitor）

　　定义：

　　唯一访问者是指在一特定时间内第一次进入网站，具有唯一访问者标识（唯一地址）的访问者。这一特定时间建议为一整天。（Unique Visitor的缩写是UV，但是UV在目前的网站分析工具软件中，对UV的时间的定义是灵活的，一般，网站分析师可以根据需要，选择这一特定的时间，是一天，或是一个星期，或是一个月，甚至是一年。引用者注）

　　度量方法：

　　在同一天内，只记录第一次进入网站的具有唯一访问者标识的访问者，在同一天内再次访问该网站则不计数。

　　评论：

　　也称日唯一访问者（Daily Unique Visitor）。独立访问者、独立访客、独立用户、唯一用户和唯一访问者是同一术语。唯一访问者提供了一定时间内不同观众数量的统计指标，而没有反应出网站的全面活动。

　　月唯一访问者（Monthly Unique Visitor）

　　定义：

　　同上。特定时间建议为一整月。

　　度量方法：

　　在同一月内，只记录第一次进入网站的具有唯一访问者标识的访问者，在同一月内再次访问该网站则不计数。

　　用户会话（User Session）

　　定义：

　　用户会话是指具有唯一访问者标识（唯一地址）的访问者进入或再次进入网站的过程。（用户会话这个术语，目前用的更多的是，用户访问，即Visit，User Session虽然是同一个意思，但用的较少。从CNNIC对这个术语的定义看，没有详细定义什么算是Visit，什么算是Loss，目前，一个Visit必须至少完整下载一个页面到客户端，如果没有完全下载就被用户关闭窗口即结束请求，那么是一个Loss，而不是一个Visit或称Session，引文者注。）

　　度量方法：

　　访问者在20分钟内与网站有交互活动则被认为是同一次进入网站，不记录新的用户会话数；当访问者持续20分钟与网站没有交互活动，当他再次访问网站时访问者被认为再一次进入了网站，记录新的用户会话数。

　　评论：

　　用户进出数、访问数（Visit）和用户会话是同一术语。用户会话不应该被解释为网站的访问人次或访问人数，但是用户会话是相对接近网站访问人次或访问人数的指标。网站的精确的访问人次或访问人数难于被统计。用户会话比唯一访问者更能说明网站的全部活动，它表明了网站的使用频率。

　　页面阅览（Page View）

　　定义：

　　一次页面阅览就是一次页面的下载，访问者成功地阅览到页面应该在他的浏览器上完整地看到该页面。

　　度量方法：

　　一次浏览器请求即可算作一次页面阅览。

　　评论：

　　以一次浏览器的请求算作一次页面阅览并不是完全准确的。

1. 代理服务器（Proxy）缓存（Cache）和浏览器缓存（Cache）使服务器记录的请求数少于实际显示在访问者浏览器上的页面数。
2. 在带宽小、响应时间长的情况下，访问者可能在页面显示之前就跳转至其它页面浏览，因此即使服务器记录了访问者的请求，但实际上并没有被访问者阅览到。
3. 醒目页面（Splash Page）和空隙页面（Interstitial）不应该被记录入页面阅览次数之中。
4. 动态的由程序生成的页面应该记入页面阅览次数中。
5. 含有帧（Frame）的页面应该只被记录一次页面阅览，即使含有帧（Frame）的页面会产生对多个文档的请求。

　　使用分析日志文件的方式进行统计，醒目页面（Splash Page）和空隙页面（Interstitial）会被日志文件记录，在分析时应该忽略计算特定的醒目页面（SplashPage）和空隙页面（Interstitial）。在日志文件中会记录对特定的程序（如CGI程序）的请求，因而由这些程序动态生成的页面也可以被计算。日志文件识别不出含有帧的页面，使用分析日志文件的方式进行统计，这个误差可以被接受。

　　页读数、页面查看、阅览（View）、页面印象（Page Impression）、页面请求（PageRequest）和页面阅览是同一术语。

　　请求（Request）

　　定义：

　　为了获得服务器上的一个资源（可以是文本、图像或任何可以被包含在页面内的元素），浏览器和它连接的服务器之间进行的一次单一连接。

　　度量方法：

　　对于使用分析日志文件的方式进行的统计，日志文件中一条记录就是一个请求，通过对这些记录的统计来获得度量的数据。

　　评论：

　　命中（Hit）和请求是同一术语。当页面请求指对HTML文档的请求时，页面请求是请求的一个子集，当页面请求指访问者页面阅览数时，请求和页面请求的含义不同，在某些情况下，请求不被记录在页面阅览或页面请求内。

　　未完，待续……

1, 2, 3, 4, 5, 6

　　三、如何标识访问者

　　标识网站的访问者是网站访问统计的基础。不恰当的对访问者的标识是目前多种访问统计服务提供的报告难以比较的根本原因。目前还没有十全十美的标识访问者的方法，因此多种访问统计服务使用了不同的标识访问者的方法是可以理解的。我们希望能够提出一种具有可比性的、可被广泛接受的网站访问统计度量的标准。

　　访问者（Visitor）定义：一个与网站有交互操作(Engage)的个人。

　　度量方法：

　　我们建议采用以下方法作为度量、识别访问者的方法。先采用IP地址来标识访问者，不同的IP地址表明不同的访问者。当来访的IP地址相同的时候试图通过跟踪文件（Cookie）来标识访问者，不同的跟踪文件（Cookie）表明不同的访问者。在服务器端加入的模块生成的含有扩展内容的日志文件可识别出访问者的跟踪文件（Cookie），这将弥补原始日志文件未记录跟踪文件（Cookie）的不足。跟踪文件（Cookie）是指由服务器向浏览器发送带有Set-cookie头信息的HTTP响应，支持跟踪文件（Cookie）的浏览器将在本机硬盘上保留一小片用于标识自己身份的信息。不同的跟踪文件（Cookie）可以表明不同的访问者。

　　评论：标识网站的访问者是网站访问统计的基础。用户（User）和访问者是同一术语，它们的含义相同。

　　1，单纯使用跟踪文件（Cookie）的方法存的问题。（1）并不是所有浏览器都支持跟踪文件（Cookie）。（2）支持跟踪文件（Cookie）的浏览器中有些允许采用不接受任何跟踪文件（Cookie）的策略。（3）跟踪文件（Cookie）可以被某些程序或被手工删除掉。（4）如果用户同时使用多种浏览器，则每个浏览器会保存不同的跟踪文件（Cookie）。（5）当用户重新安装操作系统或重新安装浏览器时，跟踪文件（Cookie）都有可能丢失，除非用户手工保存它们。（6）浏览器只能保存总共300个跟踪文件（Cookie），每个跟踪文件（Cookie）有4K的容量限制，每个域或服务器只可以在客户端放置20个跟踪文件（Cookie）。（7）存在着关于跟踪文件（Cookie）侵犯访问者隐私权的争论。

　　跟踪文件（Cookie）存在着种种争议，但它仍然是值得推荐的方法之一，支持使用跟踪文件（Cookie）的意见包括：（1）由Web服务器响应的包含Set-cookie的头信息不会被代理服务器（Proxy）缓存（Cache），代理服务器（Proxy）将传送Set-cookie头信息给客户浏览器。同样地，包含Cookie的客户请求的头信息也将被代理服务器（Proxy）转发给Web服务器。因此，跟踪文件（Cookie）是目前简单而有效的识别使用代理服务器（Proxy）访问网络的用户的方法。（2）目前国内使用最广泛的浏览器Internet Explorer 3.x、4.x、5.x、Netscape 3.x、4.x及Opera 3.x均支持跟踪文件（Cookie），只有1％的访问者使用除此之外的其它浏览器。 （3）在默认状态下，上述浏览器都采用接受所有跟踪文件（Cookie）的策略。（4）对于大多数友善的网站，跟踪文件（Cookie）提供了一种方便访问者访问的机制，而不是一种偷窥用户访问路径的工具。

　　2，通过IP地址识别访问者是一种很常用而且值得推荐的方法之一，使用IP地址识别访问者的优点是：（1）对于直接连接在互联网络上具有唯一IP地址的计算机，IP地址可以准确地标识计算机及其来源。（2）相对跟踪文件（Cookie）来讲，IP地址跟踪到计算机，而跟踪文件（Cookie）跟踪到浏览器。同一IP地址的计算机有可能由于同时使用多种浏览器而保留有多个跟踪文件（Cookie），因此IP地址更好地标识了单独的计算机。

　　通过IP地址识别用户也存在一些问题。从Web服务器的访问日志中无法全部识别通过代理服务器（Proxy）访问网络的用户。尽管有时可以从HTTP_USER_AGENT环境变量看出访问者使用了某种代理服务器（Proxy），但仍然无法得知他到底是哪个访问者。因此我们选择采用IP地址为主，跟踪文件（Cookie）为辅的方式来标识访问者。

　　未完，待续……