好了，不耽误大家的宝贵时间，切入正题：

　　大家一定还记得在上个月的时候的这个趣味题目。

　　题目如下： 

　　你的公司的网站有5000多页，很庞杂，有很多内容是重复的，所以管理起来非常麻烦，结构也很不优化。有一天，你的老板彻底发怒了，他非常不喜欢网站目前的状态。
　　你是这个公司的网站总监，你被请去了老板的办公室，他开始对你抱怨网站页面太多，太乱，而且内容重复，你也深感赞同。于是，他命令你，在一个周之内把网站的页面数减至现在数量的10%，即精简到500页。
　　你觉得能实现这个目标吗？为了这个目标，你会怎么做？

　　对于这个题目，有很多精彩的回复，几乎把这个题目能想到的地方都想到了，所以我再说说我的看法其实也了无新意。不过，再谈谈这个题目背后的意思其实还是有趣的。

　　我强调过，这个题目其实没有标准的答案，但有明确的目的。这个题目来自于Omniture SiteCatalyst招聘咨询顾问的一个面试题目。这个题目的目的是构建一个开放的环境，以测验应聘者对目标的准确认识、对网站状态的把握以及对策略的敏感性和独到性。

　　首先，题目有几个值得注意的地方：

1. 页面多达5000页以上；

2. 网站很庞杂，且内容重复，结构不优化；

3. 时间限制是一周之内。

　　这些地方告诉了我们一些重要的信息。首先，最主要的题点是“页面有5000多页”，我们要做的是减法，让网站瘦身。而瘦身，不能随意瘦，人说“前凸后翘”是最好的（对不起，有点粗鲁:），但腰最好细点才性感，网站瘦身同样如此。因此，这个案例要考察的“瘦身方法”体现了你对网站页面的价值定位策略以及在页面结构策略方面的敏感性和独到性。

　　最常见的策略是：

　　利用网站分析报告的Top content（pages）报告，把访问最少的页面找出来，然后把它们搞定完事。这个方法，不错，不过总让人觉得有些隐隐的不对头。你怎么能肯定这些页面的访问者不是你的优质客户呢？比如说，你的VIP客户才能访问的页面，往往只有极少的访问量，可是这些客户却给你带来很多的收入，你不可以随意删除这些页面。

　　如果你这样多想了一步，你就可以想到一个更加先进一点的策略——先细分访问者，再来查看页面的访问量，然后再删除页面。如果你想到这里，面试官可能会相当impressed。:)

　　你也可以告诉面试官，你会在一开始就设定一些Red Zone，这里面的页面内容是你无论如何不会删去的（但可以优化）。这些页面包括：转化的末端页面（转化漏斗，越到末端越小，访问量小，但是你不能删除）；VIP或者高级客户的特殊服务页面；为普通用户设置的特殊服务页面（比如航空公司的退票refund页面，用的人少，但仍然是关键页面）等等。

　　你也同样可以告诉面试官，你会在一开始就设定一些Green Zone，这里面的页面无论访问量，我一上来就会删除，最典型如过期页面，例如限时促销页面，旧闻（并不是旧的新闻，而是过期的通知启事等），下架商品或者退市产品的页面等等。

　　如果你说出上面的这些策略之后，会让面试官刮目相看，也能说明你对网站的情况有相当不俗的了解。紧接着，在答出上面这些之后，你将面对另外一个诱惑——“0”访问页面。

　　越大的网站，越可能有一些页面是长时间无人问津的，这些页面也是最有可能被删除的，但，不要过于轻率。由于页面无人问津有几种可能，搞清楚什么原因造成的无人问津再依情况处理非常重要。一种情况是，0访问页面的入口链接有问题，访问者很难从其他页面（或者站内搜索）进入这个页面，但这个页面本身是很重要的；另一种情况是，不仅内部链接不佳，而且这个页面的SEO做的也非常糟糕，造成从外部进入这个页面也很困难。这种情况下，草率删除这个页面可能会产生问题。

　　总体而言，对待0访问页面要小心，并不是直接全部删除，而是考察异常，留下小部分，删除大部分。

　　如果你这么回答，你开始超出面试官的期望了。

　　除了用流量来判断页面的价值，还可以用停留时间，或者exit rate等，这些方法是用来衡量engagement的常用方法，但time on page小，并不一定意味着页面不好。exit rate高的页面，也不见得是有毛病的页面——比如Call center电话显示页面的exit rate如果高于70%，我认为很正常，不能因此就删除这个页面。另外，这些细致的分析可能需要花更多的时间，一个星期的时间是否足够，需要掂量。

　　删除页面还有一个快速方法，就是如Dick所说的，直接去掉无用的网友部分（如，某个频道）。当然这个方法不一定总是用得上，因为网站砍掉某个部分绝对是大举动，除非这个部分已经完全失去作用。Dick的原话是：

Q2：太乱
A2:确定网站主体同容，重理框架，或把不要的栏目直接砍掉

　　现在，开始处理重复页面的问题。网站的内容庞杂，内容重复，结构不优化，这是网站需要解决的问题，是网站优化的目标，这里请大家注意“内容重复”这个问题。网站出现内容重复不奇怪，而且越是历史悠久的网站，越可能内容重复。处理重复绝对是这个题目的精华所在。

　　这个问题，Vocano同学回答的太好了（比我想到的方法更好），不敢据为己有，他的答案如下：

    1.从网站中挑出Top20-Top30 PV的页面列表A；
    2.通过A列表，用Google的相似度参数related+site本站定位找出一个列表B；
    3.结合GA的同出口路径分析，从B列表中找出导出路径基本一致的页面；
—–经过上面3步，基本可以找出80%的重复页面，如果5000个页面大部分都是重复的，起码可以找出3000多个页面—–
    4.从找到的每个系列的相似页面中，每个系列取前5，然后人工审核保留的必要性（甚至可以把若干比较有争议的交给Boss做决定，增加互动），其他删除之；

　　Vocano用了一个很棒的工具“related+site”，这样让找重成为可能，而且能够提高效率。

　　我没有想到这么高级的答案，我自己的办法如下：

• 首先，研究什么原因造成的页面重复？大部分页面重复都是由于很多历史原因造成的，挖掘一下这些历史原因，能够顺藤摸瓜揪出很多重复的页面；
• 其次，这些重复的页面是否可以删除？或者可以最大限度不“伤筋动骨”的删除？因为，链接问题，删除页面之后，会造成大量的死链。
• 最后，网站应该考虑内容复用，即模块化网站的页面，以及对页面的动态调用。

　　另外，在这个题目中，谈到了要一个星期完成这个任务，时间非常紧迫。要做的事情，是摘下那些不用梯子就能够得着的果子（英语谚语：low hang fruites，即容易快速完成且快速见效的事情）。例如：快速删去过期页面和失效页面——这个不需要用网站分析就可以做到；快速分析0访问或者近0访问页面，然后删去大部分；快速分析重复的页面，删去大部分，然后快速搜寻替换链接；最后，如果老板愿意给更多的时间，那么做页面模板，并且实现种子页面（例如产品介绍页面）的动态复用。

　　现在，面试官会觉得你太牛了，是不二之选。

　　但还没有结束，如果我们还能继续考虑一下删除页面可能造成的其他问题。典型的问题，如SEO。Tenly以及其他朋友也提到了使用SEO的质量情况来分辨页面的重要性，这绝对是一个重要的方法。例如，Tenly的意见是：

简而言之：
1、查看SEO的结果，保留搜索引擎收录排名最好的头1000个页面。
2、查看WA的结果，挑选1000个访问者最关注的页面。
3、求个交集，然后合并内容、简化内容、逻辑化与结构化内容，精减到500页面左右。

　　我认为，删去页面，如果会严重影响到SEO，实际上可能得不偿失，所以，要做好将SEO performance损失降低到最小的准备工作。网站结构不佳，本身实际上会影响到SEO，如果在删除页面的同时，保留SEO价值最高的页面，并且重新理清网站的内部链接情况，不失为一次SEO提升的机会，完全可以坏事变好事。

　　你答到这里，面试官会觉得你有资格跟他一起做面试官了。

　　不过，还没有结束。:)

　　还有一个最有趣的问题，也是有一些朋友提出来的问题，那就是，我完全可以质疑删除90%页面这个要求本身的合理性！或者，我至少要探讨如何可以优化结构，精简网页，去除重复，而不是简单的删除90%！

　　例如dodoro同学直言：

先要质疑一下老板的10%的想法何来?为何不是11%,不是9%。

　　你完全可以质疑面试官关于这个问题的合理性，然后阐述你觉得合理的解决办法。这样的回答也绝对会让人刮目相看。

　　总之，这个题目非常有意思，大家的意见也非常棒！因为是开放题目，没有标准答案，所以，我也不过是一家之言，若有见笑，多包涵。另外，朋友们的回答不能一一列举，请见谅。请没有参与这个题目的朋友看看其他朋友的回答，他们也给出了很多富有创意，卓有见地的思路。

　　最后，衷心地感谢大家的参与！如果有新的想法，欢迎继续留言讨论！

什么是企业在线营销优化的关键?

What is the Key to Online Marketing Optimizaiton?

——2010 （上海）在线营销研讨会

您的网站在外部营销渠道做了很多推广，网站改版多次，网站访问量很大，但是业务提升却并不明显，那么您需要对您的在线营销活动和网站进行优化。

本次会议的主要议题是：

· 在线营销优化的意义

· 如何提升您的在线业务

· 先进的分析优化工具

会议时间：2010年09月16日下午13：30

会议地点：上海徐汇区建国宾馆（漕溪北路439号四楼，地铁1，9号线徐家汇站2号出口）

演讲嘉宾

Sidney Song 宋星

Business Consultant

Greater China, Omniture Technology , Adobe Systems

TBD 演讲人员待定

艾瑞咨询集团

Darryl Su 苏士杰

Senior Enterprise Account Manager

Greater China, Omniture Business Unit, Adobe Systems

Oliver Lu 卢子为

Implementation Consultant

Shanghai Virtual Communications Co.,Ltd.

如果您本次由于某些原因不能参加，请将您的信息发送到seminar@virtualcom.com.cn，下次举办研讨会，Virtualcom会再次通知您参加。

很多朋友问，线下活动为什么没有上海的。现在有咯！不过，因为这个活动，这个周末又会是一个忙碌的周末，我自己小声告诉自己一声：挺住。期待和大家的见面，不会辜负大家的期待！BTW：在美国的时候剃光了头发，所以我会带帽子，大家不要嘲笑我哦。

　　细分是网站分析的灵魂所在，细分是发现真相的必由路径，对我而言，无细分，毋宁死。在所有网站分析的思维方式之中，细分是最为重要的一课，没有之一。这将不是一个独立的文章，而是一个可能长达6、7篇文章的系列。每一篇文章，都将分析一两个小案例，以跟朋友们一块初窥细分的秘密。这是第一章。

【正文】

　　提前预告各位朋友，一直在跟轻度抑郁症斗争的我，十月份将休几个周的假，可能没有时间再写文章。毕竟我担心，不调整，我会陷入整天沉默中 。所以朋友们如果想让我讨论哪个方面的问题，不妨给我留言，我会尽量赶在10月份前完成。:)

　　最近正在做一个不小的项目，挺有感悟，网站分析是一个非常实践的科学，实践里面出真知，也出经验，即使是一个很不顺手的分析，去慢慢啃，恐怕也比只是坐着光看理论学起来更有效。目前我最大的感悟，还是在那让我又爱又恨的细分上。

　　细分是网站分析的灵魂，几乎所有insight的得来都跟细分有关。细分帮助我们抽丝剥茧，让我们知道成败在哪儿，让我们有一把手术刀，把网站解剖，痛快淋漓。

　　但细分其实也是最难的，经常让我花大量时间却又只能得到一小块木炭，有时候甚至什么也得不到。而且，细分，其实是无止尽的，你陷入了，可能意味着你把全部精力（甚至青春）挥霍其中，你敢下这么大的赌注吗？:)

　　不管怎么样，细分具有魔力，你不亲自体悟，不知其中滋味。我要写出的，是尽量带大家去感受，但真正的感受，得靠您自己，我亲爱的朋友。

第一章：分析流量的增长/降低

【案例1】前天，南奇问我，我的网站（一个知名的B2C网站）在舟曲哀悼日那天，流量不降反增，比平日大大提升，我要怎样才能知道什么原因？

　　我一听乐了，这就是我最喜欢的问题之一啊！亲爱的朋友，我想我不需要多讲，您已经知道这个问题的答案了，其实大家心里都是一样的答案，只是我们需要找到证据。

　　我告诉他，我想你的直接（Type/Booked）流量和搜索引擎流量一定发生了很大的增加，而其他流量也有增加，但增幅不明显，远不如这二者的流量。南奇果然不辜负我，告诉我我猜测的不错。不需要太多深挖，这事儿靠谱。

　　不过，下面这个案例，相对而言就没那么简单了。

[版权归Sidney Song（宋星）所有，欢 迎转载，但请事先告知作者并注明出处]

【案例2】我曾经研究过的一个网站，是一个活动网站。这个网站的目的是为了让网友提交自己设计的数码图像作品，然后由专家评出优胜者，获得举办者的奖励。这是一个典型的UGC（User Generate Content）的活动站，活动只依靠媒体的广告进行推广，没有关键词推广等其他推广方式。整个活动期间的流量增减趋势其实都还比较正常，如下图所示：

图中流量每周呈现比较正常的增减趋势（确实一般到了周末流量会降得比较低，也属正常）。一切似乎都正常，你还会去研究它吗？你会从什么角度研究它呢？

　　思考两分钟？

　　现在，说说我是怎样行动的。我的思路可能只是无数解决问题的思路之一，所以同样欢迎朋友们留言提出自己的观点和看法。

　　我做的第一件事情，当然，毫无疑问，细分——流量细分。从最粗的角度开始细分，选取时间区间为整个活动区间，得到了下面的这个图：

　　各位朋友，看出来点儿问题了吗？

　　Traffic Sources Overview中，流量只有Direct Traffic和Other，没有referring sites。不过，之后我们认为这个很正常，这是一个非常新的而且生命周期很短的网站，没有交换链接，而且也没做任何social networking之类的推广，所有流量都来自于媒体的硬广推广。

　　如果这个问题排除了，还有什么值得关注的吗？

　　我的感觉是，Direct Traffic高达28%的比例让我很震撼，同时，也让我很疑惑。

　　原因在于，它违背了我的常识。请大家记住我下面所说的一些常识：

　　常识一：Direct Traffic流量和SEO流量一定是共生的。只有SEO流量的几率或者只有Direct Traffic的几率和看到外星人的几率差不多。道理我不多解释了。

　　常识二：完全依靠互联网广告推广的事件营销类网站的Direct Traffic的比例难以超过10%。这个数据也许会受到您的挑战，但我几乎没有见过例外。

　　现在，这个28%的Direct Traffic，突兀的让我心惊胆战。

　　发现问题了，你会怎么办？

　　再思考两分钟？:)

　　我立即，而且自然而然地着手做了下面的事情。

[版权归Sidney Song（宋星）所有，欢 迎转载，但请事先告知作者并注明出处]

　　1. 把其他流量去掉，在高级细分（Advanced Segments）中仅保留Direct Traffic。是的，我们要看看这家伙到底发生了什么，我们必须排除干扰。

　　2. 把Direct Traffic细分出来之后，看趋势。得到下面的图：

　　问题更明显了，Direct Traffic的趋势很诡异。这违背我们的第三个常识：

　　常识三：除非你的网站出现凤姐、马诺、苍井空之类的狂暴事件或者外部发生地震海啸之类的大型突发事件，你网站的Direct Traffic难以出现短时间的大起大落。对于案例网站而言，没有这样的事情发生，凤姐也没有报名参赛。

　　这使Direct Traffic显得更加诡异。——请原谅我不自觉地用起了“走进科学”体行文。咱们得找到原因。

　　3. 分析Direct Traffic从哪个页面（landing page）进入网站。

　　Direct Traffic从哪里来，我们不知道，但是我们能知道它们从我们网站的哪个门进去。现在，很轻易地打开Landing Page报告，我们得到下面的图：

[版权归Sidney Song（宋星）所有，欢 迎转载，但请事先告知作者并注明出处]

　　大家可能看不清楚具体的landing page的名字，没关系，我来解释。我们可以看到排名第一的拥有了绝大多数的Entrances。但是，我们却发现，这个页面不是网站广告推广的landing page（即网站的首页）。事情，开始朝着水落石出的方向前进了。

　　4. 我按捺住搞清楚这个上面那个Entrances最多的page具体是什么页面的欲望（实际上我们点击这个报告左边的那个图标就能知道这个页面是什么），我再做了下面这个事情，查看除了Direct之外流量的landing page是什么。

　　没有让我失望，绝大多数流量都按照预定的线路进入了属于它们该进入的网站首页。现在，我们可以怀疑Direct Traffic是可疑流量了。

　　5. 最后，不用说，大家都会做，那就是查看Direct Traffic的那个奇怪landing page究竟是什么page。点开之后，页面是这样的：

　　这是一个网友提交的作品页！现在，您一定明白怎么回事了。

　　之后，我们通知客户，然后客户通知这个作品的作者，再之后，神秘的Direct Traffic消失了。真正的Direct Traffic之后则显示为占到不到1%的比例。一切正常了。

　　一个小小细分，一个有趣的发现，一次成功的反“fraud”。:)

　　或许这两个都不是典型的案例，但确实体现了我们惯常的思维方法。现在，你能明白我为什么这么钟爱“细分”了。

[版权归Sidney Song（宋星）所有，欢 迎转载，但请事先告知作者并注明出处]

　　现在，轮到您了！说说您的体会吧！

　　续上回，继续讨论在网站分析监测的实施中所需要注意的一些地方。上回文请见：警惕网站分析监测实施的陷阱（上）。

【正文】

　　在上篇中，我们探讨了跨域监测、报告结构、页面动态事件监测这三个容易出现监测实施问题的地方，这一篇我们接着讨论外链监测、页面重定向、监测框架页面、代码冲突、以及自定义基本监测设置。

陷阱四：外链监测（Outbound Link Tracking）

　　标记法（页面加tag法）的网站分析有一个非常重要的原理，那就是对于某一个链接点击数量的监测，实际上是点击这个链接之后打开新的页面的PV数。如下图所示：

　　在这个案例中，所使用的监测系统是Google Analytics，GA的代码是添加在页面中，而不是加在每个链接之上，因此，图中我们对“全新招聘频道开播启事！”这个链接的点击数量的获取，取决于点击它打开的新的页面中是否加有监测代码。如果新页面中没有加上代码，或是新的页面没有正常被打开，那么这个点击行为本身不会驱动任何GA的监测代码，这个点击行为本身也就无法被监测到。

　　因此，在GA默认的情况下，某个链接的点击数=由它打开的页面的PV数。

　　由于网站是您自己的，因此您可以把您网站上的每一个页面都加上代码，这样就能确保大多数链接的点击数都能被记录下来，也就能够为您做页面点击热图提供数据。如果您亲手做过一个页面的点击热图，您就能知道，页面点击热图的数据来源是该页面的Next Page报告（GA中是Entrance Paths报告没有这个报告，遗憾），就是利用的这个原理。

　　不过，由于我们网站上总会有些特殊的链接，它们链接到的目标地址并非自己站内的其他页面，而是其他的网站，我们的麻烦就来了。

　　例如，我的博客有友情链接的栏目，这些链接都是链出到其他网站的，这些网站都没有加上跟我这个博客一样的GA代码——我想加，人家也不干啊！

　　所以，我们常常陷入的陷阱是，当需要获得外链点击数量的时候才发现原来外链监测不是Google Analytics标准解决方案的一部分，结果造成数据损失。有一些网站由于利用了第三方的客户服务系统，用户所点击的这个客户服务系统链接实际上就是外链。这些点击数据对于这些网站有重要意义。

　　为了解决这个问题，用Google Analytics的标准代码肯定是不够的，我们需要对代码进行一些定制。现在，我会再讲出一个“原理”（其实哪儿是什么原理啊，但是您能假装这样认为）：由于点击链接本身就是一个鼠标事件，因此，我们可以把点击链接的行为，同样当做一个“页面动态事件”——还记得我上一节所讲的吗。

　　因此，我们完全可以把外链作为“页面动态事件”来进行监测，记住加一个“onclick”/“onRelease”事件就行了（参看上一篇的陷阱三）。例如（基于最新的异步代码）：

• 虚拟页面方法：<a href="http://www.example.com" onClick="javascript:_gaq.push(['_trackPageview','/G1/example.com']);">

• Event Tracking方法：onRelease (button){getURL("javascript:_gaq.push(['_trackEvent','OutboundLinks','Click','Avinash Blog']);")}

　　在每一个外链链接上加上这些语句，就能够实现监测外链的目的，但是，如果一个页面上有很多个外链，而你又必须都要监测到这些外链的点击，怎么办呢？你可以一个一个的加外链监测，不过这绝对是一个体力活儿。你还可以采用我下面的方法，直接在页面中编写一段代码，让程序自动判断这个链接是不是外链，如果是外链，则自动加上外链监测的代码。这绝对是一个好工具，是压箱底多年的宝贝。

　　唯一可惜的是——这个代码是基于上一版GA代码的，而不是基于异步代码的。想用这个代码，必须切换回旧的代码。

　　这段代码不是我编写的，是我的好朋友乐做出来的，非常感谢！

　　有没有哪位精通JavaScript的朋友，能够编写一个新的，针对目前GA异步代码的新版本？不胜感激！

　　现在，外链监测对您应该不是问题了。

　　最后说一句题外话。Google Analytics帮助中关于外链监测的两个说明文档：http://www.google.com/support/googleanalytics/bin/answer.py?hl=en&answer=55527，http://www.google.com/support/analytics/bin/answer.py?hl=en&answer=72712都是基于旧版本的。我没有发现有异步代码外链监测的官方文档。请大家注意不要直接套用旧代码的语法到新代码上，肯定会出错。

　　还罗嗦一句：Omniture SiteCatalyst不需要额外编写程序，系统默认实现对外链的监测，这个功能确实比较窝心。

陷阱五：页面重定向

　　网站页面由于种种原因，需要一些跳转，跳转有多种，比如URL的直接跳转（服务器端的重定向），或是浏览器端的重定向。

　　重定向不影响对于页面PV数的监测，因为不论如何跳转，最终一定会跳到某一个具体的实体页面上，在这个实体页面上加上代码，页面的监测不成问题。

　　成问题的地方在于重定向会造成Referrer（流量来源）的混乱。由于重定向，真正页面的流量来源会被计为它之前的跳转页面。

　　在中国国际航空公司的美国站点中，由于跳转的存在，首页流量来源会混入很多来自于"air-china.us"和airchina.us"的流量，而实际上air-china.us和airchina.us就是实际首页http://www.airchina.us/en/index.html的服务器端跳转而已。

　　这种情况下，必须要在服务器端做一个设置，能够让跳转前的Referrer自动传到跳转之后的实际页面上，否则就会丢失真正的Referrer信息。我目前只知道这一个方法，不知道是否还有其他方法，似乎没有。所以这种情况是比较麻烦的。

　　客户端浏览器上发生的跳转相对而言要容易一些，由于浏览器端的跳转存在一个额外的空白页面，因此你可以把监测代码加在这个空白页面上，这样，Referrer的信息是可以被正常记录下来的。不过这个方法存在的问题在于，由于跳转前后两个页面都有代码，而且跳转是自动发生的，因此GA代码会在短时间内执行两次，造成bounce rate非人为原因的急剧偏低，即bounce rate无法正常监测。关于这一点，请见我之前的文章。

　　因此，对于浏览器端跳转监测的最好方法也是通过程序，把跳转前页面的Referrer信息传入到跳转后的页面上去，而监测代码则只是加在跳转后的页面。具体如何操作，就不罗嗦了，对前端工程师而言，这不是一个大问题。

陷阱六：框架页面

　　frame或者iframe也叫页面的嵌套是网站分析的大敌，为什么如此，我就不再重复了，请大家看我之前的文章。

　　对于框架页面，我认为本身就是网站分析监测的一个大坑，我自己觉得克服这个问题最好的方法就是告诉网站设计师或者前端工程师尽量不要采取这种设计页面的方法（个人觉得这个方法也属于过时的网站设计方法）。

　　不过，随着页面前端技术的提高，现在很难看到一个页面由几个大的框架拼合而成的情况，而只是在某些局部开一些“小窗户”，例如我博客上的Google AdSense广告系统：

　　“小窗户”对我们监测的影响不大。我常用的方法是不理会这些小窗户，当它们不存在，即不要再额外给这些“小窗户”页面加上额外的代码，除非它们非常重要。

　　总体而言，在处理嵌套页面上，秉承“抓大放小”的原则，把主要的框架页面上加上代码，而对次要的框架页面放任自流。

陷阱七：代码冲突

　　由于页面标记法的网站分析都依靠JavaScript的代码实现，因此，监测用的JavaScript代码和网站上原有的其他JavaScript代码存在冲突的可能性。

　　这种可能性很小，但并非从不发生。

　　对于GA，用新的异步代码后跟其他JavaScript发生冲突的可能性不大，但最好在类、变量以及函数的命名上保持各自的唯一性。如果用旧的代码，那么发生冲突的可能性更大一些，而GA代码本身的类以及相关的函数是不能够被修改名称的，因此务必保证其他的JavaScript与GA代码的绝缘。

　　Omniture SiteCatalyst的代码的类名称可以在后台进行修改，例如把类“s”修改为“s2”，以避免跟其他程序冲突。

　　代码冲突会造成监测无法实现，因此，在实施完监测代码之后，必须要检查监测代码是否正常工作。常用的监测监测代码的方法是利用Sniffer软件，我最喜欢的是HttpWatch，但更强大的工具是Charles，也有些朋友用WASP。以HttpWatch为例（点击小图看大图）：

　　利用HttpWatch，我们能看到GA代码在运行时请求1×1像素的那个小图像的request，并且在这个request后附加的Query String的值是包括了GA搜集到的很多的相关信息的，这表明监测代码在正常的工作。

　　用这些工具检查代码的执行情况，是每一个网站分析实施都会进行的必需工作。

陷阱八：自定义基本监测设置

　　这个，基本上不能称为陷阱，但是初学的朋友还是有必要了解一下。

　　在Google Analytics中，很多基础的设置其实是可以修改的。例如，有朋友问我，他的网站里面有些合同性文本需要较长时间的阅读，很可能超过30分钟访问者一直在阅读而不会点击到其他的页面，有什么样的方法能够延长visit（session）过期的时间。其实GA是能够做到的。

　　例如，对于visit的过期时间长度，如果想要调整为1个小时才过期，那么你可以用如下方法：

　　如果你想修改UTM代码的有效时间长度（一旦访问者点击了一次加有UTM参数的链接进入到网站，那么此后这个访问者即使是收藏了你的网站，在未来的6个月中他都会被认为是从这个UTM定义的campaign而访问的你的网站，直到过期或者点击了其他的UTM或者从其他的Referrer再次访问你的网站为止），可以用如下方法：

　　由于Google Analytics只认为Google，Baidu等少部分国际知名的搜索引擎，因此要加入搜搜，搜狗之类的搜索引擎，需要你手动设置，方法如下：

　　以及其他的一些默认设置的修改，Google Analytics都有专门的介绍，请见：http://services.google.com/analytics/breeze/en/additional_customizations/index.html。

　　最后，一个小彩蛋，介绍给大家一个也许会用得着的网站：http://www.clker.com/，这个网站中有很多制作PPT实用的剪贴画。:)

　　轮到大家了，有什么问题和建议吗？请给我留言！谢谢！

　　这个平台其实已经建成了，网址是：http://www.chinawa.org。

图：这是首页的样子，还是个简单的博客，但慢慢功能会越来越强大

　　如果您正在找人才，可以从这里提交需要发布的职位；如果您是求职者，也同样可以提交您个人的情况，让招聘者直接找到您。提交之后，会给我和Tenly自动发出Email，我们审核无误后，就会贴出新的博文。

　　抱歉现在还不是那么智能化，还不能直接提交就显示在前台，但我和Tenly会很勤勉工作的！:)

　　目前有几个非常好的职位，还没有找到人才。

　　一个是上面首页图中的思科Digital Marketing Manager的这个职位，年薪是40万~70万人民币；这个薪水在美国都还说得过去，在中国就相当可观了。

　　另一个是联想招聘网站分析人才，负责联想的新兴海外市场的网站（AP, East Europe, Middle east, Afica, Russia）的优化，年薪是10万到25万人民币。

　　如果你想要招聘，或者想要求职，别等待，在这里试试运气吧！我们会帮助您！

　　网站分析仍然是新鲜事，因此，我们对她的认识可能存在种种偏差。这篇文章总结了在我的工作中发现的种种容易出现的对网站分析认识上的误区。这是第三部分，也是最后一部分。第一部分请见：网站分析的十大误区及候补（一），第二部分请见：网站分析的十大误区及候补（二）。

【正文】

　　写这个系列的上一篇文章时还是在5月1日，现在已经是8月1日了，时间过得真快，令人感慨。

　　其实在前两集中，十大误区已经谈完了，今天要讲的只能是候补。之所以叫做候补，原因是它们都是很有争议的领域，我是一家之言，仍只敢博君一笑。不过知识没有候补之说，我希望引发讨论，甚至争论，以获得真正的见识和真理。

候补误区一：网站分析有标准的benchmark

　　这是一个存在普遍误解的地方。我们经常讨论bounce rate，讨论time on site，所以有很多朋友会问：

　　我的网站bounce rate是60%，好不好？或者，平均time on site是5分钟，好吗？

　　这些其实都是我无法回答的问题，因为网站分析对于这些关键度量并没有一个所谓标准的benchmark可以参照。我只能说，bounce rate是60%不是我见过的最糟糕的或是最好的，5分钟的time on site也是如此，不过至于到底好不好，仅凭这几个孤立数据本身是无法解答的。

　　为什么网站分析没有标准的benchmark的原因，在于网站和网站之间的区别太大了。首先，网站的受众/流量来源不同；其次，网站的功用不同；再次，网站设计的内容也不一样；最后，网站新旧程度也不一样……

　　所以，网站分析没有标准的benchmark！例如，不能说bounce rate低于60%就是好，高于60%就是不好。

　　现在，你会问一个更好的问题：

　　如果是同一个细分行业的，或是受众很重合的网站，是不是可以相互比较这些诸如bounce rate、time on site、PV/V、访问者忠诚度等基础指标？比如，新浪和搜狐、土豆和酷6、京东商城和新蛋网，他们可以两两相互比较这些指标吗？

　　我认为完全可以相互比较，不过，千万不要觉得自己网站的指标数值比别人差，就是自己的网站不好。假如新浪的bounce rate是10%，而搜狐的是15%，阳哥就要发飙了吗？大可不必，这未必说明搜狐就比新浪要差。还是那个原因，新浪和搜狐的页面其实很不一样，虽然他们都是门户，而且他们牟足了劲在竞争，但他们仍然有很大很大的差异。

　　同样，Nike和Adidas的网站，Intel和AMD的网站，他们都是同一个tier（类别）的，但他们其实也很不一样。这些指标的大小不能简单说明一个网站就好于或者差于另外一个网站。

　　所以，我一直坚持：即使是相同类别的网站，指标简单的数值好坏也不能说明网站的好坏。

　　那么，你又会问了：

　　既然比较不能说明好坏，那比较还有什么意义？！

　　有，当然有！如果你知道了竞争对手的数值情况，你就可以分析它咯；你知道了你的数值不如它而了解自己。所谓以人为鉴可以知得失，网站之间也是如此。

　　最好，请大家不要产生另一个误解，那就是既然没有标准的benchmark，那么无论我的数值无论多少，都不说明我的网站好坏，我大可以高枕无忧。

　　相信没有朋友会这么想。:)

　　如果您的数值太过离谱，超出了普通的范围，那么还是很能说明问题的。例如，如果您的网站整体bounce rate高于80%甚至90%，那还是要注意下了。:) 网站分析喜欢这些异常现象，还记得这篇文章吗？

　　下面列举一些我经验中的一些极值（请注意，这些值只对用Google Analytics分析有效，其他WA工具因为定义和监测方式的不同，数值可能有明显区别），如果超过这些值，可能说明网站出现了较为严重的问题（但不绝对！）

　　最后再次提醒大家，由于每个网站都是独一无二的；而且指标本身也不能孤立的解读，所以，网站分析的标准benchmark不存在。

候补误区二：利用自动BI系统进行网站分析

　　是否能够利用自动BI系统进行网站分析？这是一个很聪明的问题，提出这个问题的朋友，都是很动脑筋，而且很愿意去解决问题的。但是，就我愚见，这个想法很好，但是很难实现。

　　网站分析有一些固定的模型。根本上，遵循“输入->分析->输出”模型，我们希望的，是在分析这个环节利用计算机的智能运算能力帮我们进行分析，然后直接输出结果。这就好比IBM的深蓝和人下国际象棋，输入是当前的棋局，分析是它自己肚子里面的程序，输出是棋的下一步。网站分析也希望能够类似，例如，输入网站的bounce rate=65%，网站的PV/V=2.54，网站的time on site=187秒，网站产生的revenue=$332,343，conversion rate=1.34%以及其他各种指标和metrics（包括各个页面的指标）等等，然后智能程序开始运算分析，最后输出结果——网站是否健康，网站有哪些优点和弱点，以及网站在什么地方需要改进，以及建议。

　　很美好，但是比较难实现（除了某些特殊情况，后面提）。

　　问题出在什么地方呢？输入、分析、输出都有问题，都无法实现——原来现实总是这么残酷；而且，我认为，输入的问题最难解决。

　　为什么输入的问题最难呢？举一个不恰当的例子，例如战争（请原谅我是和平主义者，所以这个例子并不好），假如俄罗斯和美国要打一仗，我们可以通过计算机模拟出胜率，但真正开仗了，你会相信战争的过程一定会和计算机模拟的一样吗？不可能一样，因为左右战争进程的除了武器装备等内部因素外，外部因素往往更加重要，而外部因素难以界定边界，而且有很多时候完全是混沌的。

　　网站分析如此。网站的种种可以被监测的指标，是内部因素，有明确的定义和边界，但是遗憾的是，仅仅只有这些内部因素，不足以帮助我们完成分析。网站分析师分析的核心价值在于，把这些用网站分析工具监测到的内部因素，与网站所拥有的外部因素进行关联，并进一步分析挖掘，从而寻找到真正有价值的洞见（insight）。

　　你会问我，网站的外部因素是指什么？——好问题！网站的外部因素是那些瞬息万变，不可能墨守成规却又无时不刻不再影响网站变现的事物，我能想到的包括如下内容：

• 网站的设计——不仅仅是流程上的，更是视觉上的，usability上的，这些怎么输入给BI系统呢？
• 网站受众的情况
• 网站所处的行业和经营环境
• 网站的竞争对手
• 中国互联网的一些独特“怪癖”
• 网站经历的其他外部事件等等

　　这些外部事物哪怕对你的网站产生一点点影响，都会改变最终的分析结果，而它们既不格式化，也不结构化，都无法输入到BI中，所以输入上就有问题。

　　由于输入上无法解决的问题，分析也就很困难了，在真正的类人神经网络计算机出现前，我们现在的计算机的分析只能按照结构化和程序化的方式来，如果输入是模拟的，甚至是模糊的，那它就无可奈何了。

　　谈点儿题外话。一定有不少朋友喜欢炒股，我读过一本书，讲华尔街的金融分析师，书名叫《华尔街的肉》。其中作者提到了那些天天玩儿数学模型按照“输入·分析·输出”进行预测的分析师，往往预测的结论跟实际结果都不同，所以他对这个方法十分质疑。我现在明白其中部分原因所在，就是许多外部因素是无法准确输入到模型中的。

　　输出也存在问题，即使分析有了结果，如何进行建议仍然是非常困难的。计算机只能给出一些大概的指导性意见，它不可能告诉你应该如何调整你的call to action元素，或者应该如何修改流程，又或者如何重新构造首页，它做不到。

　　所以，我斗胆预测，10年内用BI做深入的网站分析是不可能的，还得靠伟大的人脑。

　　当然，万事无绝对，BI系统在一些方面很有价值，如下：

• 当网站的外部环境比较恒定，可以作为常量时；
• 自动优化流量来源，如SEM的自动投放系统；
• 做A/B测试或者多变量测试时；
• 自动根据测试结果进行内容投放时，如Omniture的Test&Target系统；
• 自动根据访问者行为profile的分析结果进行定制化内容feed的时候。

　　就不再具体展开了。

候补误区三：分析个体行为具有重大意义

　　我见到一些工具，记录每一个访问者在页面上的鼠标轨迹。这些工具各有千秋，不过都很强大。通常，这些工具是为UED（UCD）设计师准备的，但是它们对网站分析有重大意义吗？

　　网站分析是一般是通过全体（即完全不抽样）或者是大样本量数据来分析网站访问者所趋同的一些行为模式，并据此优化最主要访问群体的访问体验。网站分析极少通过研究个体访问行为来进行分析。在这一点上，网站分析和网站可用性（usability）分析是大相径庭的。

　　如果您读过《Don't Make Me Think》，您就知道，网站做好后，请一些从未使用过您的网站的普通人，在您的面前完成一些您规定的网络访问事情，并且记录下他们的访问行为，是一种非常重要的网站usability测试和改进的方法，但是网站分析则极少采取这种方法，即通过某一个访问者在网站上访问留下的数据情况来分析和优化网站。

　　原因很简单，因为大量访问者的访问情况是符合正态分布的。有可能某些访问者的访问数据分布在极值地区，如果用这些数据进行分析，偏差很大。例如，A访问者在网站上停留的时间长达1个小时，访问的页面多达100页，这不代表着所有的访问者都是如此，分析单个访问者容易陷入危险。也许你会说，我可以多分析几个访问者的行为，这样会更可靠。但是，问题是，与千百万的访问者数量比起来，你能够分析的个体总是有限的，而且越多的个体分析，你就会越辛苦。

　　所以，在我的实际工作中，我几乎不会用到一些非常具体的鼠标轨迹监测工具，但我希望能够有一个鼠标轨迹记录工具，记录所有的鼠标行为，并用不同的色彩表示鼠标行为的密度，这对我们会非常有用，而且会比我们目前所做的热区图（heat map）更有价值。但似乎目前没有这样的工具出现。

候补误区四：优化方案是进行分析后的必然结果

　　网站分析重在分析，不错，但分析并不是网站分析的全部，分析的最主要目的是发现问题，但分析本身不足以帮助解决问题，或只能解决部分问题。

　　例如，在研究转化时，我常常发现很明显的某个页面丢失了大量的访问者，但是为什么这个页面的表现会如此糟糕？有时候，根据经验，我们立即就能想到原因，并且据此提出改进意见；但有时候，我们其实并不知道为什么这个页面如此糟糕。即使根据经验我们能够想到原因，这也并非一定就是真实的（或根本的）原因所在。

　　所以，有些时候（其实更准确的是大多数时候），真正可靠的优化方案，并不能从分析中直接得来，而是来自于你通过分析提出建议之后的测试。建议本身是主观的，但测试之后的结果则是客观的（只要你采用了科学的方法和流程）。网站分析的一个轮回并不结束于分析，而是结束于测试，测试才是王道。

　　所以，下面的这个图虽然是老生常谈，但却是真正重要的方法论。

　　好了，这篇文章终于结束了，这个系列也终于结束了（之后可能会有修订和增补）。感谢所有朋友们一直以来的鼓励！希望大家提出不同意见，欢迎探讨，欢迎争吵！

　　最近忙着东游西逛，所以忙中偷闲写东西有些不易，就暂时不准备长文了，大家看着也轻松点。在美国有段时间了，不是不爱国，但挺喜欢这个国家，特别是素不相识的人见面都对你微笑say hello how are you的时候，感觉在异国他乡有温暖。咳，我是有些乐不思蜀了。

　　今天暂时不接着上次关于报告的话题继续谈，而是开始一个新的话题，谈一谈网站分析的监测实施，因为最近也在学习这个领域，勾起了一些回忆，想起自己刚刚入手网站分析时所犯的那些实施小错误，正好是梳理一下的时候。本来准备一个文章就搞定，结果一写，发现没那么简单，所以又只好开上下篇了。

【正文】

　　网站分析之所以能够实现分析，在于获得了网站访问者的行为数据。但是，我从来没有遇见过一种情况，那就是做到了100%地获得了分析所需要的全部数据。相信我，没有，从来没有，无论谁都无法做到，因为有些东西是后知后觉的，你不能在事前百分之百预料到你所需要的数据。

　　不过，这并不意味着你可以放弃对更全面更准确数据的追求，拿破仑也无法每次都预料到他将面对的全部战斗细节，但没有哪次他不是事前做到最好准备的。你也是网站分析的常胜将军，所以你需要在事前做到最好，不然很有可能在网站分析的站以上一败涂地。

　　所以，无法否认，网站分析的监测实施异常重要，甚至比如何进行分析本身还要重要。

　　下面，我要谈一些我常常遇见的网站分析实施中的陷阱，有些可能老生常谈，但对于初学者却很有价值。请注意，下面所写的每个都可以作为监测实施前对网站进行检查的扫描列表，在这个系列的末尾我也会做一个网站实施准备工作列表。另外，我总结的肯定不全面，希望大家能够在评论框中继续补充，谢谢！

• 陷阱一：跨域监测

　　这是网站分析实施时候最容易忘记的问题，我第一次做，完全不知道有这么一回事，现在想起来当时非常傻。

　　跨域监测是对Google Analytics而言的一个问题，Omniture并无此忧虑（当然，它有别的跟域类似的地方要注意）。对于Google Analytics而言，如果你要把不同的域（domain）或者子域（sub-domain）的所有监测结果放在一个 报告集合（profile）中，那么你就不能只是直接把不经处理的标准代码放到每个页面上。

　　例如，如果chinawebanalytics.cn、chinawebanalytics.com和chinawa.org这三个主域逻辑上其实是一个网站，你想让他们在一个报告集合中呈现，就需要在监测实施时做跨域处理。

　　方法很简单，选择正确的代码加到页面中就行了。如下图所示（点击看大图）：

　　相信您一定知道这个截图来自哪里。

　　不过，由于跨主域监测情况不多见，所以很多时候我们落不到这个陷阱里面去。我们常常出问题的是在跨子域监测上，因为我们误以为这种情况不是特殊情况。

　　子域形如：blog.chinawebanalytics.cn和www.chinawebanalytics.cn，都属于chinawebanalytics.cn这个主域，但是我们也要给他们特殊的代码，否则部分数据就会混乱。例如，traffic source中会出现blog.chinawebanalytics.cn和www.chinawebanalytics.cn这样的referrer，bounce rate之类的数据也会出现不正常。你的相当部分的数据都毁掉了，基本上就无法进行关键的分析了。

　　方法跟上面一样，如下图所示（点击看大图）：

• 陷阱二：报告结构

　　既然涉及到跨域和跨子域的问题，那么，如果再多想一下，就会涉及到报告结构的问题了。什么是报告结构？先举个例子，您就明白了。

　　假设有一个很大的网站，例如sony.com，它有各个地区的网站，比如china.sony.com、japan.sony.com、gemany.sony.com……；它也有各个产品细分的网站，比如psp.sony.com、notebook.sony.com、movie.sony.com……。

　　再假设，您是这个公司的网站优化部门总监（一个不错的职位，不是吗？），你的内部客户包括CEO、各个区域的总经理、各个产品部门的总经理，他们都想知道网站给他们带来了些什么价值。为了圆满解答他们的问题，你需要怎么监测这个网站呢？

　　这就涉及到不同范围的报告了。对于CEO，我们肯定至少要给他全局报告，因为只有他和为数不多的人（包括你自己）需要看到全面的情况；对于各个区域的老大们，他们只要了解自己地区的网站就好了；对于各个产品部门的头儿，他们看自己的产品网站也就足够。

　　现在假设我们所使用的网站分析工具是Google Analytics，这样可以得到至少如下四种解决方法：

• 解决方法一（这个方法是我们容易落入的陷阱）

　　给每个子站建一个独立的Profile。这种方法的弊端是没有一个全站的profile，所以为了得到全站的情况，只能自己手动加总求和计算。你千万不能这么做。

• 解决方法二（这个方法同样是大陷阱）

　　为全站建一个profile，当然已经注意了跨子域的问题。这种方法的弊端是没有一个个子站独立的情况，比如psp.sony.com的bounce rate是多少？不知道。解决问题的方法还是自己剥离数据慢慢计算。这方法可相当让人难过的。

• 解决方法三

　　是把每个网站都加至少两套代码：一套是全站的统一代码，建立一个总的profile，跟解决方法三一样；第二套代码则是每个子站自己的代码，这样就能有子站各自独立的报告。这个方法比起前面的来，考虑的周全了很多，能够解决不同用户的需要了。但不完美的地方在于代码实施复杂且存在冗余，所以还不算最优化的方法。

• 解决方法四

　　这是我认为最好的方法。原因在于我么能够通过一套代码实现既有总体，又有细分的报告（profile），大家各不干扰，而且数据精确。怎么做到呢？其实不难。

　　我们首先从GA上建立好一个profile，并且获取一套跨子域监测的代码。然后，把这段代码实施到网站所有的页面上。这之后，真正的tricks开始了。我们在GA报告的settings后台中复制刚刚建立的profile，有多少个子站就复制多少个，然后，做过滤，只留下各个子站自己的流量，过滤的方法请见这里。

　　其实，这个解决方法是Google Analytics实施的入门功课之一，请点击这里学习官方的资料，我推崇哦！

　　上面的这个解决方法是Google Analytics的，对于Omniture，思想完全一致，而且方法也类似，为不同的网站范围建立不同的report suite，实现不同网站范围的报告分割 。

　　在这个陷阱的最后，我要说，网站监测结构其实挺重要，因为它能让各个部门都满意，而且，还能让你获得一种生杀予夺的快乐——因为只有你一个掌握了全部的秘密。

• 陷阱三：页面动态事件监测

　　所谓页面动态事件，即我们常说的页面上的非HTML链接的交互式元素，包括flash/flex中的按钮或链接、JavaScript、AJAX、SilverLight、HTML5中的动态事件等，例如下图中hulu的滚动图中的“watch now>”就是一个flash按钮。用户访问这些动态事件的行为，不能够直接通过标准代码获得监测数据，因此需要对监测代码做一定的定制。

　　这个地方的陷阱在于，一来我们不知道要做额外的定制化监测，二来我们容易出现监测实施失误。

　　在Google Analytics中，监测页面动态事件的方法可以用两种方法，一种被称为virtual page，即虚拟页面；另一种被称为event tracking，即事件追踪。前一种方法，把这些动态事件的点击都等同于打开了一个新的页面；后一种方法，则把这些事件单列出来，作为特殊的情况在专门的Content的event tracking报告中体现。

　　Virtual page方法需要用_trackPageview()函数来解决问题，语法是：“_gaq.push(['_trackPageview','/events/playvideo']);”，之后，这个事件会在content中的top content报告中以/events/playvideo为页面名出现。

　　在实施时，把_trackPageview()函数放到这些动态事件的onclick（或者onrelease）事件中即可，如果您不了解如何添加，您的网站前端IT同事一定懂得，请教一下他们，这不是大问题。

　　Virtual page方法很简单，但是最大的麻烦在于会inflate（虚增） “top content”报告的数据，而且能够监测到的行为属性也就只是点击一种，做更细的分析时不够用。

　　为了弥补这个缺陷，Google Analytics开发了另一种更先进的功能，就是已经不再神秘的event tracking功能，语法是： “_gaq.push(['_trackEvent','category','action','lable',value]);”，同样是添加到onclick（或是onrelease）事件中，跟virtual page的添加方法非常类似。

　　关于这两个功能，GA官方也有说明，请点击这里。

　　我们推荐这个功能的原因在于：

　　1. event tracking不会把数据放在top content报告中，从而不会混乱这个报告。它有自己独立的报告，如下：

　　2. Event tracking的诸多属性很好用，尤其是增加了“value”这个属性，通过它我们可以为不同的动态事件赋予不同的权值（weight），从而能够很自动的计算engagement index。

　　3. 属性的增加也带来了更多的细分分析的可能。我们能够据此加强对页面（或整站）动态事件的分析。

　　但是，凡是有利有弊，由于多了几种属性，所以朋友们有时候容易出点儿小差错，这些差错已经在Tenly的文章中提及（请注意这个文章是根据GA旧的代码写的，新的代码已经更新了pagetracker对象为：_gaq.push，但是其他没有变）。如果没有尝试过event tracking的童鞋值得看看这篇文章。

　　另一个弊端在于，event tracking是没有pathing的，也就是说，不能了解到它们和页面间的路径关系，而只是单纯的计数。用virtual pageview的功能则可以获得pathing功能，尽管不能说非常准确，但聊胜于无。如何取舍，完全取决于您事先的监测需求。

　　另外，还需要注意的是，有时候我们会把这个function加到flash的第一帧，结果造成页面（上flash）载入的同时，会自动运行这个function，而不是在访问者点击了某个动态事件才运行，这实际上是监测实施事故。

　　最后，event tracking因为包含多个属性，所以你需要注意命名规则的一致性，如果events都是注册，那么就把他们都丢到registration的category去，而不要既有registration的命名，又有register的命名。否则报告就不那么好读了。

　　好了，上节书完，虽然都是很基础的内容，但可能大家还是会有不少问题，现在时间留给您，请在留言框给我回复吧！

　　下节我们将会涉及的陷阱包括：外链监测、代码冲突、跳转、框架页面、自定义修正等。Stay tuned！

　　题目如下：

　　假设有一个很大的网站，例如sony.com，它有各个地区的网站，比如china.sony.com、japan.sony.com、gemany.sony.com……；它也有各个产品细分的网站，比如psp.sony.com、notebook.sony.com、movie.sony.com……。

　　现在您是这个公司的网站优化部门总监（一个不错的职位，不是吗？），你的内部客户包括CEO、各个区域的总经理、各个产品部门的总经理，他们都想知道网站给他们带来了些什么价值。为了圆满解答他们的问题，你准备怎么监测这个网站呢？

　　小提示：

　　这个题目相对不那么开放了。由于需求不同，所以大家关注点也不同，我想，关键在于，怎么样高效而且省力的为不同的需求准备网站分析和优化。:) 

　　再试试看？谢谢！

　　BTW：这个题目将在我正在写的一个帖子中出现，最近会奉上，其中会以我的观点解答其中的一部分。敬请期待。

　　题目如下：

　　你的公司的网站有5000多页，很庞杂，有很多内容是重复的，所以管理起来非常麻烦，结构也很不优化。有一天，你的老板彻底发怒了，他非常不喜欢网站目前的状态。

　　你是这个公司的网站总监，你被请去了老板的办公室，他开始对你抱怨网站页面太多，太乱，而且内容重复，你也深感赞同。于是，他命令你，在一个周之内把网站的页面数减至现在数量的10%，即精简到500页。

　　你觉得能实现这个目标吗？为了这个目标，你会怎么做？

　　小提示：

　　这是一个完全开放的问题。你当然需要运用网站分析的方法来解答，但是这里没有正确答案，只有更有道理的答案。另外，别忘了，网站分析最终的目的是什么。:)

　　试试看？

【正文】

　　在美国网站分析人才最集中的地方呆了近一个星期，曾经耳闻现在目睹了他们的工作，必须感叹他们在这个领域的领先。一方面，是技术水平的确强大；另一方面则是专业性无可挑剔。凭着一腔热爱做事情、相当不错的收入，以及业界的认可和需求地不断壮大，让这个产业在美国越来越欣欣向荣。等结束了这次美国之旅，我将撰文谈谈澳洲和美国网站分析的见闻。

　　不过，这个话题不是国外，而是解决我自己同样长期萦怀的一个问题——如何做出漂亮的网站分析报告？这个话题是一个不小的挑战，光我一个人不够，需要在这个文章之后，得到大家的提问、反馈、建议和经验。我不准备，也不可能在一个文章中把网站分析报告的所有问题都说清楚，还是开一个系列吧！

　　首先，我要说，如何制作网站分析报告不是一个问题，而是多个问题的集合，为什么这么说呢？因为网站分析报告是一系列不同报告的总称。我们先从这个话题入手。

　　由于侧重点不同，阅读报告的用户也不同，因此网站分析报告绝对没有一个标准。虽然都叫报告，但是内容和格式可以大相径庭！我所知道的网站分析报告包括下面的一些类型：监测和分析计划报告、实施策略报告、Dashboard（精要报告）、Kick off（启动）报告、痛点辨识报告、分析和优化报告、优化实施报告、测试报告。限于篇幅，今天讲前三个。

[版权归Sidney Song（宋星）所有，欢迎转载，但请事先告知作者并注明出处]

• 监测和分析计划报告

　　监测和分析计划报告，即我在以前Agency的工作中常常要做的Measurement and analytics plan，或者简称M&A Plan，是关于一切监测和分析行动的指导。

　　各位网站分析爱好者朋友，大家可能毫无关于监测和分析计划报告的概念，也可能完全不认为它是重要的。恩，的确，某种程度上，即使我们没有它，老板布置下来的分析工作照样还是要做的，不过这个报告的意义实际上很重要，因为它不仅仅是一个行动纲领，同时也是一个契约。

　　下面我列出了这个报告的内容后，您就能明白我为什么这么说。

　　监测和分析计划报告的具体内容包括：

[版权归Sidney Song（宋星）所有，欢迎转载，但请事先告知作者并注明出处]

•  网站分析的对象、范围和时间

　　网站分析的对象当然是网站，但是，是网站的全部，还是局部（比如某个频道，或者网站的外部流量源等）？如果是局部，范围是多大？需要采集多长时间的数据？

• 网站的关键业务需求（KBR：Key Business Requirements）

　　KBR是Omniture方法论常常提及的一个词，它代表的是网站在商业上要达到的目标及关键环节，是网站分析需要最终实现优化的落脚点，或者换句话说，是网站分析的意义，如果没有KBR，也就不需要网站分析了。

　　还有什么比KBR更重要的？

• KBR目标设定

　　并不是每个网站分析都有设定KBR目标，因为KBR可能受很多因素的影响。不过KBR目标的设定，能够让网站分析有一个明确的努力方向。KBR目标设定并不复杂，因为业务目标往往都是清晰的。例如，网站渠道带来的Revenue在半年内增长30%；或者网站平均每个月用户提交review的数量增加5%等。这些都是一些纯业务领域的目标。

• 可能用到的分析方法或者模型（可选）

　　网站分析很多时候并不可能在事前预见到会用到何种分析方法或者模型来解决问题。这就如同我们去钓鱼之前去找虫子当诱饵，我们面前有很多石头，掀开一个个石头，有的下面有一个肥美的蚯蚓，有的下面有一群四散奔逃的蚂蚁，有的下面什么也没有——所以方法和模型很多时候是通过试错得到的，而不是你能预先就全盘计划的。不过我们还是可以从大处着手，考虑我们可能用到的分析方法或者模型，比如，我们要研究转化、我们要从流量变化中发现促进流量的因素等。这个部分，有时候只是作为参考项，可选。

图：一个方法和策略的例子。是由Florian Pihs先生创立的

• 人员和资源分配

　　让马儿跑不让马儿吃草可不行。人员和资源分配当然是很重要的。这是这个报告契约功能的另一个体现。不多说了。

• 进度计划

　　网站分析要按照大致什么样的计划进行？例如，什么时候完成监测实施，什么时候分析，什么时候提出建议，什么时候进行测试，最后又如何进行网站的优化等。之后，尽量按照这个计划进行。这样大家心里都有数，能够更好地步调一致的协同工作。 

图：进度计划的简单例子

• 实施策略报告

　　有了网站分析计划后，第一个重要的具体操作就是实施了。监测和分析计划报告和实施策略报告的区别是，前者强调监测和分析活动的项目计划，而后者则具体到实施的策略和方法。实施策略报告是在网站分析实施之前需要进行的。这个部分是网站分析最重要却最容易被忽视的领域。那些所谓添加代码的工作，如同盖房子的添砖加瓦。可是添砖加瓦要在一个蓝图的指导下进行，没见过盖房子不画图纸的，同样也没见过网站分析加代码不考虑监测策略的。

　　在我们最开始接触网站分析的时候，我们使用的是Google Analytics，我们的实施比较很简单粗暴，就是把GA的代码加到每个页面上就行了，但随着时日的增加，监测的需求开始变得细化，例如要监测一些页面上的event（flash或者javascript等），以及要监测业务上的一些指标，比如订单、购买、收入金额等，简单粗暴就力不从心了。监测策略是网站分析大厦的地基，没这个地基，上面的建筑物容易崩塌。

　　请记住，网站分析是商业分析，由于商业本身都是独一无二（unique）的，因此网站分析的监测策略和实施也肯定是独一无二的。

　　实施策略报告内容包括下面几个方面：

[版权归Sidney Song（宋星）所有，欢迎转载，但请事先告知作者并注明出处]

• KBR和网站KPI及监测对象的映射（KBR Mapping）

　　这个内容是我们俗话说的“翻译”，就是把KBR翻译成网站上的KPI指标，以及其他的监测对象。网站分析并不是监测的越多越好，也不是获得的数据越多越好，而在于得到我们满足KBR所需要的数据。

　　罗嗦一句解释一下我这个观点。理论上，网站分析当然是什么都监测到是最好，甚至把log file的数据都统统罗列下来，但是，实际上，我非常反对这么做，时间和精力是有限的，没有分析能做到100%全面覆盖。而且，网站分析的收获符合20-80法则，即80%的insight来自于20%的分析对象。

　　关于KBR的映射或翻译的具体内容，请看这个文章：Avinash：什么是目标、度量、KPI、维度和细分。

图：KPI列举。是由Florian Pihs先生创立的

• KPI及监测对象的实施策略映射（Implementation Strategy）

　　确定了KPI及监测对象后，就要考虑通过什么样的技术策略来监测它们了。我这几天正在学习这个领域，非常有意思，有不少收获。例如，我的老师常常问我们，如果要监测一个商品的SKU及对应的州、Zip号码、shipping花费，以及收入等等时，应该应用什么function、plugin、event和evar（见下），我们要能够对答如流。这些即KPI和监测对象在监测技术策略上的映射。

　　请注意，实施策略不是实际的coding，而是为最终的coding确定策略。

• 监测实施方法*

　　监测实施方法好比一个说明书，在Omniture被称为Playbook（注意不是playboy），详细说明了运用哪些function、plugin、s.prop、event、evar等。拿着这个说明书，IT工作人员（例如网站前端工程师）就能够按图索骥的添加代码了。

　　监测实施方法被加了星号的原因是，往往它会被单独拿出来作为一个独立的文档。

　　这个报告的内容说完了，是不是大家没想到，连监测策略都要有一个这么复杂的报告？不奇怪，科学需要严谨嘛。

图：实施策略报告的流程

[版权归Sidney Song（宋星）所有，欢迎转载，但请事先告知作者并注明出处]

• Dashboard（精要报告）

　　Dashboard这种报告绝对值得大书特书。这个报告体现了网站分析的艺术之美。不过，既然是艺术，就不要把它只当技术对待。

　　Dashboard不太好翻译，仪表盘？或者是总控台？总之，容易让你我迷糊。我还是觉得Dashboard被称为精要报告比较好，或者被称为KPI报告。当然，叫什么名字并没有关系，关键是对这种报告的理解。

　　在解释Dashboard之前，大家先设想自己在开汽车，汽车的仪表板表明了汽车行驶状态的最关键的一些特征——速度、行驶里程、油量。网站分析的Dashboard报告跟汽车的仪表板一样，表明了网站最关键的运行状态。

　　除了汽车和网站分析之外，其实只要是需要了解运行状态的行业都可以有dashboard，大到经济运行景气情况，小到您家的电表水表。如果您看看这个网站Dashboardspy，就知道我为什么说dashboard是一门艺术了。

图：这是一个博物馆的Dashboard，做的很棒！

　　没错，Dashboard是让你在最短的时间内了解网站最宏观最关键运行状态的报告。这个报告是给所有人看的，尤其是给你的老板看的，我认为它是被最多阅读也最常阅读的报告。从这个意义上讲，Dashboard是网站分析最重要的报告。

　　Dashboard报告具有如下几个特征：

• 精要

　　Dashboard一般只会把KPI和关键监测对象的运行数据放入报告中。无微不至、事无巨细不是Dashboard的特点。

　　除了在数据上体现在精要，Dashboard中其实也有精要的定性内容，这些内容即是简短有力的结论性文字和建议性文字，而绝对不会有分析性文字。Dashboard的文字只有一个要求——掷地有声！

　　精要的目的很明确，就是要让阅读者快速、清晰地了解网站状态，哪儿好，哪儿坏。

• 宏观

　　Dashboard一般只体现网站（或者网站Channel）的宏观数据，而不会涉及到某个具体页面的情况。

• 动态

　　Dashboard是动态的，随着时间变化能够随之更新。因为Dashboard要描述状态，如果不能更新，意义就失去了。很多网站分析工具提供自动化的Dashboard的功能，这些Dashboard可以实时描述网站状态。例如，Omniture SiteCatalyst的Dashboard能够自动按照访问报告的时间提供实时网站状态数据，也可以按照你自定义的时间区隔描述网站状态，很灵活。

图：Omniture SiteCatalyst的自定义动态Dashboard

[版权归Sidney Song（宋星）所有，欢迎转载，但请事先告知作者并注明出处]

　　其实，Dashboard还有另一个要求，那就是美观易用。如何让Dashboard变得更易于阅读（而不是让人看了想吐），以及更能让人快速从中间得到结论和见解，都和是否美观易用有很大关系。这体现了艺术。

　　如何做一个网站分析的Dashboard？敬请遵循下面的步骤：

1. 确定放入Dashboard中的KPI和其他关键监测对象；
2. 为这些KPI和指标确定合适的表达度量；
3. 为各个表达度量设计合适的时间范围和图表；
4. 制作图表，或通过自动化工具将图表和度量关联；
5. 填入定性文字。

　　我其实有一个非常高质量的文章关于如何制作Dashboard，是Avinash Kaushik先生写的。请大家点击这里：“可执行的网站分析报告精要”——跟糟糕的简要报告说再见吧！

　　最后，告诉大家一个词，reportlet，就是Dashboard中一个个的数据小区块。

　　好了，先介绍到这里。如果大家觉得有意义，我会继续写其他类型的报告。如果有任何问题和建议，也请告诉我。特别鸣谢Janny同学之前给我发信提出的一些问题，我之后也会写你所建议的相关文章。最后，老规矩，跟大家分享下我在美国的一些图片。

图：这就是Orem（以及挨在一起的Provo），Omniture总部所在的城市。在美国，这个超过10万人的（两个）城市已经是很大的了。这里地广人稀资源多，没有高楼，反而说明足够富裕。远处是淡水的犹他湖

图：Omniture的美国咨询顾问，能听说读写流利中文的Thayne Lewis先生，他竟然可以跟我讨论inception这个词翻译成“开始”好，还是翻译成“源头”好，太强了！背景是Bingham Canyon Mine矿车的轮胎

图：在世界最大的人造坑Bingham Canyon Mine

图：在摩尔门教总部Temple前，手里拿着摩尔门教的经书——摩尔门经

图：盐湖城的Apple店门口