他是爱德蒙·唐泰斯，是我的父亲，我母亲，我哥哥，是我的朋友，是我，也是你。——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优化路径中，你还需要做其他一些重要的事情以保证你所采取的行动是卓有成效的。这些，我将在这个系列的最后一篇文章中阐述，包括如何通过测试寻找真正的优化方法，以及如何更高级的满足用户的转化预期。

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

【前言】

　　上一回讲到如何更好使用网站分析工具的五个原则，本期接着讲后五个原则。在上一回中，有一个朋友Liang同学在留言中提出了非常有高度的意见，绝对是高手。但我还是想说，我仍然保留我的意见。:)

　　为什么呢？如下原因：

基础和能力不是问题，但如何能够帮助夯实基础，培养能力，却是问题。

　　也许不远的未来我们网站分析的环境变了，专门做分析的网站分析师在中国普及，大家的基础和能力都很扎实，情况会不一样。

　　就我所见，我以前的一些澳洲客户，他们也用不好付费系统的许多功能，除非如我在前文所说，有很好的培训和咨询帮助。在中国，后二者难寻觅，而自己摸索——太难太难，要资料没资料，要经验没经验，要指导没指导。

　　所以，目力所及，拿在手里有牛X工具的，不少；用好的，稀少。

　　关于帮助形成思维体系的问题，Omniture的思维体系的第一步其实不在于前期完善的tag制作方案，这已经是懂了很多很多才能做好的事情了。Omniture的思维体系的第一步在于真正理解和辨清流量流（点击流）和业务流，以及在工具中对它们二者的原理和定义。这是Omniture和免费工具最大的不同。辨清这二者，才可能真正理解在实施中围绕它们所编织的如你所说的page name、hierachy（层级）、SAINT Classification、转化和其他自定义的event、prop和evar。而Page Name、Hierachy和SAINT Classification其实是Google Analytics也有的，没有付费工具那么灵活，但思维方式和工作的严谨细致程度其实相差不远。

　　正是因为Omniture或其他付费工具在这两个流上有不同的逻辑，所以在国内没有课本、没有培训、没有咨询的情况下，理解起来的难度就太大了。而且，仅仅是一个SAINT Classification工具，国内能理解能用好的太少，我当时给Intel、HP做，用这个，但Intel、HP自己是不懂的，那个时候我其实也没有真正理解。

　　是的，付费工具的公司有培训、有咨询、有方法论指导，但国内真正愿意付费购买的又很少。国内乐意花钱买实施，这个看得见摸得着，但不乐意花钱买培训和指导——他们问，这不是本来就包含在一起的吗？！而且买多少才能真正培训到位呢？就算花钱，培训是用汉语为母语的老师进行的吗？——不是人人都有这样的机会接受200个小时专门的汉语母语Omniture培训，这样的培训根本就不存在。英语？你可以，我可以，但对大多数朋友来说，还是有难度。如果连能够理解的途径和机会都没有，那就很难谈到培养思维体系了。这些是中国WA市场的真实情况，很多东西，就是花钱都做不到，做不好，跟国外其实完全不同。

　　Liang同学也谈到：“免费付费还是依据应用场景和预算投资回报来定为好。读者如果对于付费运行原理多些了解应该去除一些不应有的误会。”问题就在这儿，读者朋友如何去了解付费运行原理呢？如果他们没有机会去了解，或者只能被灌输个“一知半解”，那么这个工具还是不是“简单便捷的效率之选呢”？这也是我为什么不建议选择超出你能力范围的工具——除非你能确保这个工具的提供商或你的公司能够帮助你形成这个能力。

　　回到这个SAINT工具上。与SAINT相对应的工具，GA也有，叫UTM link tag，功能和使用都简单得多，能上手的朋友和公司就多了不少了，因为它不用上传，不用考虑为什么流量（PV，Visit）就是出不来，而是出来个instance（国内理解prop和evar不能correlation的可能除了少数几个高人，恐怕没了，能知道如何解决这个问题的，那就更寥寥无几）。免费工具只是流量流工具，严谨上肯定是输了付费的，却胜在这点脉络清晰、简单易用，而且有社群能够互相帮助，快速使用上手，对于大家快速切入网站分析是有很多益处的。至于这个方案是不是矮矮的天花板，根据不同的业务需求，情况真是不同。功能和能力有关，功能超级强大，使用者不懂用，没用啊。

基础工作不到位，思维体系是pillar of sand（用沙建起来的柱子）。

　　谈到思维体系的培养，就不能不再罗嗦下。我喜欢先易后难，因为我也是这么学过来的。我最早接触到的工具就是Omniture SiteCatalyst，之后才是GA。但坦率说，我学习入门，慢慢加深对网站分析的理解还是靠GA，SiteCatalyst则是在理解了GA的基础之上才慢慢理解了部分，而真正深入了解脉络则是在进入Adobe之后。原因很简单，Omniture的东西是要配置的，不同的客户配置不同，我那是用Omniture的客户少，因此看不到折工具的全景，没有那么大的视野，而且——没有培训，我的外国老板（他其实当时也是一知半解）教我，学起来那叫一个费劲。

　　而这位朋友谈到的“（对于GA等免费工具，）使用者基本上不需要前期的构思和铺陈，快速的进入导致的是之后的技巧难度加大，对于技术上要求不比付费工具低，与其让使用者和技术人员合作去在有限空间进行极限探索，不如给他们一个大的局去做更有效率的实施和应用。”这里可能有误解。国内的免费工具我不了解，但GA的实施一定要前期的构思和铺陈，肯定也是要和业务需求相结合的。在部署GA之前，页面前端的URL的抓取方法和变量的设置与配合就要开始规范了。如果没有前期的完整巧妙的布局，之后就不是技巧难度变大的问题，而是功能受限、分析受损的问题了。

　　同样，在部署的时候，GA也要考虑全局和局部，全局如profile的定义，过滤器的定义，Goal的设计等等；局部则是event的tracking，交易的tracking或是搜索的tracking，还要考虑全局和局部的关系，二者紧密联系。所以全局思维的锻炼是少不了的。只是我也承认，由于付费工具更强大灵活，所以要考虑的“全局”更大，难度更高。但付费工具也好，免费工具也好，在“全局”没有质的区别，区别是付费工具更强调对于业务有更深入细致的了解，从而能够把业务定义到工具的业务流监测中。我相信这正是这位朋友所强调的，这的确也是免费工具不能及的。

　　呵呵，这个讨论我额外添加了前提，所以有偷换概念之嫌。我想，Liang同学所说和我所说的可能并无对错。只不过条件不同，情况不同，就造成了方法和选择的差异。钱够，资源够，咱们甭谈什么免费了，那么多好的付费工具，来一个，把人顺便给我培养好。钱不够，资源少，问题就大了。

　　最后，把这位朋友的意见贴在这里，欢迎多多讨论。Liang同学的商榷，一下子激发了我很多思考，非常感谢。大家的视角不同，观点不同，你让我看到了另外的角度。

Liang said:

原则一二提及免费工具和收费工具的先后顺序，和博主有商榷。。。免费收费工具真有难易之分，对于能力有要求高下之分？从文中和实践都无法印证这一观点。
我们看看收费软件，以博主常说到的omniture对照GA而言:
1. 收费的功能强大并不表明就复杂，而是博主文中说到的空间增大应用天花板高了。举例来说，omniture的跟踪代码classification是商用的便利之选，工具提供商要在服务器运算能力方面支撑这一解决方案，商用是你花钱换来一个简单便捷的效率之选。。到底是一个如何花钱的问题。。是花钱让技术人员在矮矮的天花板下折腾找个解决方案，(通常结果依然犹豫免费本身的方案也不完善实用)，还是让技术人员的才智和解决问题能力发挥到更广阔的天地去。虽然，文中的没预算的情况下适的做法不错，却不能佐证应该先用免费，免费先行。这是一个花钱方法选择的问题。
2. 以omniture为代表的付费的方案更能够培养一个良好的思维体系，尤其对于初学者。tag类型分析工具如omniture确实不是一段代码立即上手，需要完善的前期tag制作方案，如page name的定义，层级的划分，都需要去铺垫，这需要的是对于全局的思维方式和细致的工作方法，但，这是基本的思维方式和能力要求，对于使用者来说一个基本的学习过程，技术难度而言也谈不上，实施上都需要技术人员参与。。尽管GA、百度统计易于上手，基本上他们采取的方法是把常用场景功能推送到主界面的设计逻辑，延展性限制在使用中逐渐显现。使用者基本上不需要前期的构思和铺陈，快速的进入导致的是之后的技巧难度加大，对于技术上要求不比付费工具低，与其让使用者和技术人员合作去在有限空间进行极限探索，不如给他们一个大的局去做更有效率的实施和应用。
免费付费还是依据应用场景和预算投资回报来定为好。读者如果对于付费运行原理多些了解应该去除一些不应有的误会。

　　这是我“博客史”上最长的前言了，再次感谢Liang同学的留言，你吹醒了这个博客被我弄得沉闷的氛围。

【正文】

原则六：选用一个工具之前，首先必须了解它的原理

　　有一些实际上是老生常谈了，但仍然有初入门径的朋友会问起，为什么我GA的数据跟日志的不一样。

　　讲一个真实的故事，我们的网站有一天感到服务器的压力很大，公司想知道是不是因为用户突然暴涨所致，或是有其他恶意的原因。

　　这是一个极为容易解决的问题。从GA上，我们能够轻易的看到“真实的人”，而不是机器访问的流量；而日志文件（log file），则能够捕获大部分机器人（蜘蛛爬虫）遍历网站的流量。因此，如果GA的数据暴涨，那么这是好事，服务器压力大，应该添加服务器了。可是，如果GA没有暴涨，而log file的数据暴涨，那么可能是某些恶意的网站数据采集软件在作恶，公司该要注意的是网络安全领域的问题。

　　所以，日志文件的分析工具（例如逆火软件，老版本的WebTrends，或是Piwik），跟页面标记监测分析工具（例如Google Analytics和Omniture SiteCatalyst）在监测原理上有根本性的差异。你可以读这两篇文章了解它们之间的差异：服务器日志法网站分析的原理及优缺点，页面标记法网站分析及数据捕获原理。

　　所以，不同原理的工具，收集数据的范围是不同的。

　　即使同为页面标记监测分析工具，它们的原理也是不同的，这同样造成数据差异。例如，GA的监测数据利用的是cookie，典型的GA的cookie是utma，utmb，utmc，utmz什么的（它们是什么意思，请看网站分析度量、意义以及不为人所知的（2））。而Omniture SiteCatalyst则是使用cookie和虚拟cookie的共同作用监测数据。SiteCatalyst的cookie比GA的cookie简单，只用来记录访问者的唯一识别编号，而这个编号对应的数据，则全部存放在数据库的虚拟cookie中。虚拟cookie实际上是数据库中的一张大表，记录了这个cookie编号用户访问网站的全部行为。

　　由于利用了虚拟cookie，因此，在用户的客户端不支持cookie的情况下，SiteCatalyst还是可以利用IP地址或client agent记录一个visitor，但GA在没有cookie支持时，就什么也不能做了。

　　因此，我们可以按照监测原理为常见网站分析工具分类，如下图所示：

　　由于监测原理的不同，工具的作用也就有很大不同。

　　想要做SEO，了解机器人扒取数据的原理，用日志工具；想要看鼠标轨迹和停留，用鼠标捕捉工具，例如ClickTale；要看人的行为，还是用页面标记工具。

引申阅读：不同工具，对于网站分析基础度量的定义也是不同的

　　监测原理的不同会影响不同工具收集数据的范围，同样，不同工具在定义基础度量的时候，也有差异。典型的差异是我在介绍bounce rate时候所提到的Google Analytics和Omniture SiteCatalyst（SC）之间的差异。对于GA，bounce rate是预置的基础度量，定义是single page view的访问；而在SC中，bounce rate则不是预置度量，你可以自定义它，一般用single page visit/visit定义。single page view和single page可有天壤之别，前者定义的bounce rate不把reload页面的情况计为bounce，因为页面reload，1个page view就变成2个，所以不再是bounce。而single page的定义则包含了reload的情况，因为无论你在一个页面上reload多少次，这个页面还是这个页面，仍然你只访问了一个页面，所以仍然是single page。所以SC的bounce rate一般比GA要略小大。

　　同样，对于visit的定义有各种不同；对于时间（time）的定义则更多不同了，这里不一一列举。虽然不同的定义得出的结果并不一定有很大差异，但了解一下无害处。

　　当然，我也认为，如果你不了解这些，也并不妨碍你做分析。但监测原理的不同，则是必须要了解的。

原则七：不要利用不同工具做一件事

　　我总觉得，用Google Analytics和Omniture SiteCatalyst监测网站每天visit的多少有些无聊。并不是说这两个工具更准确的问题，而是你永远说不清楚到底谁的数据更准确。

　　理论上，如果两个工具监测的大小不一致，那么它们至少在趋势上是一致的。也就是说，如果GA记录的昨天的visit比前天的大，那么SC的visit也应该是昨天大于前天。可是，天杀的，鬼知道为什么有时候它们连趋势都是不一样的。

　　你可以对GA多一分信任，但我说不好，毕竟有时候Google的服务被鬼使神差的阻断，让它看上去好像是自身营养不良不能提供靠谱的服务。你也可以多信任一点Omniture SiteCatalyst，但我也说不好，毕竟服务器也远在重洋之外（但听说年内香港就会有服务器，到时也许会有不同）。

　　所以，遗憾的讲，这里存在一个谁也说不清楚的盲区，当你的老板询问你为什么GA的数据和SC的数据不一样的时候，你永远也不能找到一个圆满的解释，除了骗他说你花钱买的SC更加可靠之外。

　　所以，为了监测某个相同的度量，如果你认准了一个，那么就一直认准它，如果你结识了新欢，就不要再想旧爱，也别玩儿藕断丝连脚踩两只船。并且，我的忠告是，不要再浪费时间想象为什么它们之间究竟发生了什么而造成了差异。

　　是的，重在分析，而不是数据本身。

　　这也是为什么Avinash总说，同时使用两种或以上的工具是不理想的。

原则八：利用多个工具的长处

　　但你是不是应该永远不同时用多种工具呢？

　　我不知道大师们怎么说，但是我当然不是。我不仅用多种工具，而且乐在其中。

　　我不会去用Google Analytics和Omniture SiteCatalyst比较visit，但我的确会用SC弥补GA没有路径监测的缺憾。（关于这一点，请看我之前的文章：Google Analytics的能与不能）

　　而且，当你花了钱用了ClickTale之后，你也会知道，GA的In-Page Analysis不是不好，但功能确实还不够强大。

　　百度统计？恩，这是颗国产的新星，不管怎样，百度、腾讯和阿里都是极为重视产品的，所以这个产品也不会太差，尤其是在你想要统计和分析凤巢投放的效果的时候。

　　你应该用多种工具，因为没有任何工具能八面玲珑，面面俱到。

引申阅读：在一个网站上使用多个工具时的注意事项

　　在一个网站上使用多个工具并不会带来什么麻烦，大多数情况下我们的网站访问者不会察觉出任何异样。

　　但在一个网站上使用多个工具时可能会对网站性能带来负面的影响，尤其是当某个工具的JavaScript运行发生问题响应缓慢时。所以，加入的代码一定要放到页面的最底端。

　　选择你认为真正有意义的工具，当你需要进行的分析结束后，你完全应该删除这些工具的监测代码。并不是所有的网站分析工具都如同基础分析工具GA或SiteCatalyst一样是从头到尾都需要的，事情总是有始有终。在这一点上，始乱就应该终弃。

原则九：善用复制和过滤——给你更多尝试和细分的机会

　　如果你用过GA，你不会对它的account和profile陌生。account由不同的GA记录号区分，例如UA-123456和UA-123457就会被放入不同account中。而一个account下可以容下很多个profile，每个profile对应一个报告。

　　例如，我想在我的这个网站www.chinawebanalytics.cn上做一些实验，但我又不想影响正常的数据监测。我可以用两个方法。

　　第一个方法是一个笨办法，即在页面上再新建一个GATC（Google Analytics Tracking Code），也就是我们在GA上生成的监测代码。这个代码一定跟最初的代码有不同的记录号，即UA-XXXXXXX不同。我不是很喜欢这个方法，因为GA本身提供了更好的方法。

　　第二个方法是在你原来的account中再复制一个profile，即把你已有的报告再复制一个一模一样的。这个新的报告，可以供你肆意玩乐啦。

　　如果你不了解如何进行这种操作，请看谷歌官方的帮助讲解：http://services.google.com/analytics/breeze/en/accounts_profiles/index.html

　　其实，很多工具存在类似Google的这种报告复制的机制。例如Omniture SiteCatalyst拥有report suite的定义，你可以定义多个report suite为你的一个网站服务，当然，收费也就会更贵一些。

　　一旦复制了一个一模一样的报告，你就可以对这个报告进行过滤操作。过滤实际上是一个不恰当的说法，应该说，是对这个报告的监测方式进行新的配置。

　　例如，我可以利用这个新的profile（report），加上一个地域的过滤，用于只监测从北京访问网站的客户。也可以加上一个过滤，只监测从搜索引擎导入的，且只以某一个页面为landing page的流量。

　　复制和过滤给你更多的尝试机会，和更灵活的细分功能，使用任何一个工具，你都需要了解这个工具的复制和过滤功能，它能让你的工作事半功倍。

　　详细了解GA的过滤，请看这篇文章：五个实用的Google Analytics过滤设置。

原则十：让需求指引你，而不是让工具指引你

　　最后一个原则，是我内心的呼声。

　　我不是一个Geek，所以，坦率讲，当新的网站分析工具出现的时候，我并不是焦急地盼望着更早一日试用。所以，在朋友问到GA V5的时候，我的感觉是：“哦，还不错，用户体验上有改进。”事实上，我认为除了multi-channel funnel和自定义高级群组也可以使用报告过滤功能外，V5的版本改进并不能称得上是革命性的。

　　我是一个懒人，所以总是信奉“enough is enough”。我是有了需求之后，再去选择工具，但我不是有了工具之后，才去理解它能够满足哪些需求。所以我很少在第一时间认真研究工具本身，除了在百度统计刚刚出来的时候，好奇研究了它。

　　不要为工具所累，是我认为使用工具的最重要原则。

　　如果你认为网站分析工具很复杂，那就大错特错了。网站分析工具，咳，说实话，都大同小异，那些模样越是fancy，功能越是让你眼花缭乱的报表，实际上使用的机会越少。我认为工具复杂性的提升并不在于本身学习成本的提升，学习不过是麻烦的最开始。真正的麻烦在于，工具复杂性提升意味着工具背后实施难度的增加，而我亲身的体验告诉我，在中国的电商环境中，想要找到一个特别可靠的团队去实施复杂的WA工具是非常困难的——除非你的团队既有好的前端IT，又有懂前端IT且了解网站分析工具的达人，还有对网站分析需求掌握到位的人。这不是那么容易的事情。

　　当然，我们不需要被吓唬住。我还是觉得（与Liang同学的观点有差异）一步步来是可能的，使用GA是一次免费的实习，你不仅仅是了解了网站分析工具和概念，更关键的，你通过运用这个工具了解了你的分析需求是什么，这才是非常关键的。当你知道这一点之后，你能够提出有价值的切合现实的商业问题，并且以这些问题为基础，选择真正能够解答这些问题的工具，这个时候你就不是盲目的。否则，工具的逻辑是工具的，让它牵着你的鼻子走，你很难找到北。

　　我的实践告诉我，这是相对小风险的一条路，或许对你也适用。

【题后】

　　好了，这个话题就聊到这里，欢迎大家继续拍砖，有问题也欢迎提出。最后，要向朋友们致意诚挚的歉意。我之前说的两个事情都没有兑现，一个是7月份的活动，一个是每周一篇博客。原因在于这个月又离开亲爱的祖国刚刚回来。

　　好消息是，8月6日和8月7日，各有一次活动，但都在北京，都是小规模的CWA聚会活动。8月6日的已经敲定了。具体报名规则和细节我稍后会在博客中通知，8月7日的活动我与组织者确定安排后也会通知大家。

　　新的一周开始了，也希望连续7天工作的我，今天能睡个早觉！晚安！

　　通知一：请大家在加入CWA的QQ群（CWA三个新的QQ群：87963666, 82922176, 47686693）的时候，注意一定要填写加入理由为CWA爱好者。因为有很多垃圾号码加入，所以没有填入理由的都被拒绝了。我估计会误伤一些朋友，所以特此通知。

　　通知二：一个重要的招聘启示在CWA的招聘博客上，请点击这里。一个相当不错的机会，要独当一面，有挑战，但绝对有收获。请想致力于在真是商业环境中进行网站分析实战的朋友猛击。

　　通知三：我现在在深圳，可能会待一段时间，我想在深圳或者广州组织一次CWA的活动，请大家响应。晚一些我会通知大家具体我的计划，目前看，广州活动的可能性很大。

【前言】

　　接着上回书，我们接着说这个模型的第二部分，ISPT中的S。S不是大S也不是小S，也不是刚结婚的我的偶像Stephanie，而是我时时提到的Segmentation（细分）。偏激点儿讲，分析的本质就是Segmentation。我在很多博文和场合都提到了细分的重要性，这篇文章则对细分做一个“细分”。

【正文】

　　ISPT模型本质上是互联网营销分析的必使的几种武器。我觉得S是这些武器中最牛逼的。这种牛逼不是说它是原子弹，丢下来搞定一片，而是如同AK47一样，无论是kongbu份子还是CS玩家直到2011年的今天都还极为钟爱，并且其改装改制的型号至今还在我们这个世界人口最多的国家服役。这就叫牛逼，叫范儿！

　　Segmentation就有这种范儿。如果你做好了细分分析，网站分析你至少成功了一半。我特别钟爱细分，这也是我为什么觉得Google Analytics虽然有诸多不好但仍然是最棒的免费网站分析软件的原因——它对于细分有着近乎于偏执的重视。

　　上一回我们提到了ISPT中的“I”——整合，即Integration。介绍I的目的，是因为在I的前提下，我们可以实现“S”。如果你自信自己的“I”做的足够好，而且数据的粒度足够低（即细节度足够高），那么你可以着手进行细分。但在你动手前，你应该看看下面的内容。

细分不是目的！

　　细分虽然重要，但细分不是目的。所以，不要为做细分而做细分！很多朋友问我，“Sidney，请告诉我应该怎么做细分？”，或者“我这么细分你觉得可以吗？”之类的问题，我肯定会一时语塞，因为在我了解到你要做细分的目的之前，我也不知道你应该如何做细分，我真的不知道。

　　在做细分之前，你不应该把问题聚焦在我该如何做细分上，而应该放在我为什么应该做细分上。也就是说，你得要首先厘清细分背后的分析需求（或者说细分要解决的问题）是什么。

　　没有比这个更重要的了（当然，数据挖掘又是另外一个故事，暂时不在这个逻辑考虑之列）。

　　现在有一个问题：

我想知道为什么我的网站总是留不住用户？

　　我们可以做细分，把用户细分分为新访问者和老访问者。留不住用户，可能是新访问者这里出了问题，所以值得重点查看新访问者的行为和兴趣。也可以把用户按照来源进行细分，来观察是不是某些比较大的流量源不够踏实。当然，你还可以按照注册用户和非注册用户的方法来进行细分。解决这个开放问题，细分的方法有很多，但目的很明确。

　　但反过来，如果没有上面的问题，你只是漫无目的地直接进行新老访问者的细分，也许的确能发现点儿什么，也许不能，总体看这种方式并不一定完全没有收获，但的确是一种效率低下的方法。当你有很多时间，那么就碰碰运气吧，如果你没有那么多时间（毕竟时间是现代人真正的奢侈品），你应该做更有针对性的细分分析，即按照解决问题导向的细分分析。

　　细分不是目的，只是手段。无论做何种细分，都不要忘记了自己是为了什么商业分析需求而做。

细分要解决的常见商业问题

　　既然细分不是目的，商业问题才是目的，那通过细分要解决的常见商业问题有哪些呢？

　　这是一个开放式的问题，回答的难度不低，商业需求是千变万化的，因此商业问题毫无疑问也无穷无尽。但总体而言，我们想要把握规律，想要知道细分适合于解决哪些常见的商业需求的类别。以B2C电子商务网站为例，这些问题例如如下类型。

类型一：与网站用户体验相关的问题

1. 网站哪些页面受欢迎，哪些不受欢迎？

2. 页面上哪些内容受欢迎，哪些不受欢迎？

3. 哪些流程受欢迎，哪些不受？

4. 哪些表单填写用户更乐意填写，哪些不愿意？

5. 导航——什么样的导航靠谱？

6. ……

类型二：与流量数量和质量相关的问题

1. 哪里来的流量数量大，质量高？

2. 哪里来的流量性价比（ROI）高？

3. 哪里来的流量能够满足网站的一些特殊需求？

4. PPC流量应该如何优化？

5. 什么流量让人又爱又恨（食之无味、弃之可惜）？

6. ……

类型三：商品品类相关的问题

1. 哪些商品用户更关注；

2. 哪些商品用户更乐于购买；

3. 哪些商品更……还记得我的商品品类分析的四象限模型吗？

4. ……

类型四：用户行为相关的问题

1. 购买商品的用户体现出什么样的趋同行为？

2. 哪些用户用户将商品放入购物车却没有购买？

3. 注册用户展现出什么样的特征？

4. 在网站上停留了15分钟却没有将商品添加到购物车的访问者都干了些什么？

5. 从我的博客（www.chinawebanalytics.cn）到www.xiu.com的访问者，对这个网站感兴趣吗？

6. 哪些访问者更有忠诚度，哪些则更似冲动型购物者？

7. ……

类型五：跟客户端相关的问题

1. 网站应该支持什么浏览器，应该放弃什么浏览器？

2. 网站的页面应该多长为好？

3. 用JavaScript会不会造成一部分用户体验不佳？

4. ……

类型六：上面五种类型的再综合

1. 什么用户偏爱什么样的商品？

2. 什么来源的用户喜欢看哪一类型的页面？

3. 什么流量渠道带来了喜欢注册为用户的人群？

4. ……

　　这些问题，不做细分是无法解决的。而这些问题，似乎已经是网站分析需要解决的问题的全部。对于我自己而言，几乎所有的商业问题都需要用细分来解决。即使是为什么今天流量突然增高了这样常常都要面对的问题，也自然而然通过细分来解决。网站分析的艺术似乎就是细分的艺术。

细分的艺术在于制定规则

　　如果说网站分析的艺术是细分的艺术，那么细分的艺术在于建立规则。事实上，规则的建立体现了对于商业问题的快捷解答。因此，规则的定义必须针对网站本身的特点。

　　例如，在细分访问者参与程度的时候，对于你的网站而言，什么样的访问者才算是深度访问者呢？

　　我喜欢把访问者定义为轻度、中度和深度访问者。对于不同的网站，这一定义肯定是不同的。通常而言，访问者在网站上停留的时间是一个好的标准，例如停留时间少于5分钟的，可以算作轻度访问者，5~10分钟的，中度；10分钟以上，深度。但是，这个标准往往过于一刀切，我们还可以增加一些额外的规定，例如访问十分钟以上并且访问页面数至少达到3个且访问了至少1个产品详情页面的访问者才算深度访问者，因此这个规则变为：

　　深度访问者=time on site > 600 & PV/V > 3 & 1个或以上产品详情页面PV。

　　如何选取定义的标准，完全依赖于你的网站的特性，没有统一的标准。但我有一个喜欢利用的方法，即倒推法。

　　比如，我想知道在网站上停留时间超过多久的人，更有可能购买我们的商品。我们可以做一个细分，计算所有发生商品购买visit的平均time on site。也许是11.5分钟。我们可以认为，超过11.5分钟（690秒）停留的visit，更有可能发生购买。

　　我们还可以做另外一种细分，即最短网站停留时间为多少时，visit带来的order数量等于10%的总order数量。例如，我们发现停留时间小于140秒的visit带来的order数量约为总order数量的10%。因此我们可以认为用户完成一次购买行为最起码需要140秒钟。

　　了解了这两个时间，对于你区隔用户，就有很大的帮助。而这两个时间，在不同的电子商务网站上是非常不同的。我对这两个时间的定义是：平均购物时间和最短购物时间。

　　然后，你再利用最短购物时间和平均购物时间反求一段时间内的visit的数量，你可以发现这个波动趋势。如果流量没有发生明显变化，而最短购物时间的visit在减少，那说明人们越来越不倾向于“冲动购物”；如果平均购物时间之上的visit在增加，则说明人们进行购买决策所需要的时间也在增加，你应该考虑进行更好的说服，或是更多的促销。另外，比较各个时间段的visit所占的比例变化，也能说明类似的问题。

　　规则没有必要非常复杂狭窄，选取合理的粒度是重要的。研究在网站上PV/V刚好为131的访问者其实没有太大的意义，你可以把细分人群定义为PV/V>10的部分。如果你在利用工具做细分的时候，发现某个规则下的visit或者visitor比你预期的小很多，那么这个细分规则的制定可能存在问题。这是判断细分是否合理的一个很重要的线索，也是Google Analytcis的“细分群体”中有一个“测试”按钮的重要原因。记住，确定你的细分是否有效只能通过测试！在Omniture SiteCatalyst中，我们也进行测试，但没有Google Analytics的测试那么简单。方法是建立1天的细分规则，拿到数据没有问题后，再延展这个细分到更长的时间，原因在于1天的数据在SiteCatalyst中反馈很快，1个月的数据就需要一些时间抽取了。这即是我们内部所称的对于某一种解决方案而言的best practices。

真正有效的细分，不仅仅只是维度细分

　　细分规则作为细分艺术体现的另外一个原因，在于细分不是任意制定的，逻辑上成立的细分，实际上未必能够在工具上实现。真正有效的细分，必须依赖于有效地系统间数据整合。

　　举一个例子，我们知道Google Analytics能够很方便地通过UTM标签标识网站的流量来源，因此我们可以快速且较准确地得到不同来源的流量数量，但是GA的电子商务统计功能却不能非常准确地统计到这些流量实际带来的订单（order）和收入（GMV），而必须依赖电子商务企业内部的销售统计系统或ERP系统。但后者又未必能够按照GA的流量标识方法来统计数据。如何解决这个问题？我会在之后的文章中详细解答。

　　因此，如同我们在这个系列中的第一篇所讲到的，我们需要整合，没有整合，真正有效的细分无法实现。

　　事实上，刚才讲的问题，涉及到了细分的另一个操作要点，即细分不仅仅只是对于维度的细分，而且也是对于度量（metrics）的细分。显然，由于分析的需要，不同的维度往往会对应不同的度量。我在工作中，最常见的问题是，那些不能直接带来ROI的流量，我们是应该购买，还是不应该购买？很显然，虽然都是流量，但作用不同。对于部分流量，利用ROI来相关度量来衡量是有意义的，而对另外一些，则要采用其他的度量来剖析它们的非ROI价值。但所谓非ROI价值，当然最终还是能够转化为ROI的，只是相对间接，所以我们需要有不同的metrics来衡量。

细分对于工具的依赖

　　前面已经讲了，逻辑上成立的，工具未必能实现。所以细分对于工具非常依赖。Google Analytics的新的版本，在细分上似乎又有加强（我需要使用一段时间感受下），而Omniture的SiteCatalyst本身的细分比较复杂，需要用它的一个专门的细分工具Discover来实现，这个工具的细分和数据交叉的能力非常强。Google Analytics的高级细分功能我极为喜爱，这个工具因为受到Avinash的影响，对于细分非常重视。

　　不过，受制于工具的算法和服务器响应能力，全数据的实时细分对任何工具都是极大的挑战。相对而言，如果能够实现全数据的细分，这个工具一般难以实时；而实时细分，又只能选取抽样数据。所以工具对于细分的能力并非十全十美。

　　Google Analytics的细分工具实际上包括“高级细分”和“自定义报告”，高级细分是亮点。

　　Omniture SiteCatalyst的细分工具包括ASI Slot，Data Warehouse和VISTA。这些工具属于全数据细分，但实时性相对较弱。

　　Omniture Discover本身是一个细分工具，数据来源于SiteCatalyst，能够抽取一定时间段的全数据实现实时细分，但不能实现全部历史数据的实时细分。不过足够用了。

图：Omniture Discover的界面

常用的细分规则

　　最后，大家需要常用的细分规则吗？给我留言吧！并且，请留下你常用的细分规则！很久没有发新的文章，现在发这篇文章，有点儿紧张。希望大家能喜欢！谢谢！

　　本文译自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）

　　合理吗？

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

未完，待续……

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.

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

　　未完，待续……

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）为辅的方式来标识访问者。

　　未完，待续……

1, 2, 3, 4, 5, 6

　　引言：

　　从今天开始，将分数次连载CNNIC在1999年12月发布的《网站访问统计术语和度量方法》。时间已经过去将近10年，但基本的概念却历久弥新。其中某些术语有些已经改变，编者将进行修订，以与当前情况相符。感谢CNNIC！

　　一、介绍

　　中国互联网络信息中心是成立于1997年6月3日的非盈利管理与服务机构，行使国家互联网络信息中心的职责。其宗旨是为我国互联网络用户服务，促进我国互联网络健康、有序地发展。随着互联网络在国内的飞速发展，广大互联网站迫切地需要了解他们的网站的访问量信息，于是他们采用了一些国内或国外的对于网站的访问量进行测算和度量的服务。然而，这些服务面临着一个重要的难题，即缺乏对访问统计指标的权威定义和度量标准，既缺乏官方的标准也缺乏事实上的标准。各个服务提供商提供了不同统计口径的统计指标，出于商业考虑，服务提供商往往也不公开他们的统计度量方法。对于网站来讲，由于使用了不同的网站访问统计服务，因而他们获得的报告无法和其它网站的访问统计报告进行比较。这种报告缺乏对广告客户的吸引力，一方面制约了网站的盈利空间，另一方面也制约了互联网络的发展。对于广告客户来讲，他们同样面临着困惑，因为他们判断不出选择哪一个网站播出他们的广告会收到更好的效果，他们的广告投资应该与网站访问量成正比，而可比较的网站访问统计报告是他们进行投资的依据。

　　中国互联网络信息中心（CNNIC）建议的网站访问统计术语和度量方法正是希望能够提出一种具有可比性的、可被广泛接受的网站访问统计的标准。我们的任务就是建立一套网站访问统计的术语，并对其度量方法提出建议。我们希望以此文档作为网站访问统计的指导方针，帮助网站的建设者、网站的访问者、网站的广告客户更全面更准确地获得他们想要了解的信息，为他们精确地计划、执行、实现他们的网上商业项目提供依据。

　　此文档提供了网站访问统计术语的解释和对度量方法的建议，这将有助于网站使用一种通用的语言向外界发布访问统计的信息。

　　我们起草这个建议是为了促进互联网络事业在国内的发展。我们也希望此文档能够引起互联网络界的注意，使大家关注网站访问信息的度量。因为我们真诚地希望互联网网站能成为广告客户更为友好的媒体平台，使互联网站能够走上持续发展的道路。

　　二、统计实现方式

　　对网站的访问信息的统计，我们建议采用如下的实现方式：

　　这种方式是对Web服务器生成的日志文件进行分析，这种日志文件有时是原始的文件，有时是由第三方统计机构在服务器端加入的模块生成的。这种方式的优点是可以定制自己格式的日志文件，采用加密算法和压缩日志文件的技术，以保证日志文件的真实性和可靠性，并且降低传递日志文件所产生的网络流量，适用于第三方机构进行网站访问量的认证度量工作。当然这种方式也有自己的不足之处，包括难以做到实时的统计分析，而且在服务器端的附加模块有可能降低服务器的性能。

　　在文档中，当提及此方式时，我们称为分析日志文件的方式。

　　待续……