理论：

对于一个需求不太专业的电子商务网站客户来说，他们关注的东西并不多，但是“转化”倒是一个重要内容。

面对这种转换分析，常用的方法是使用“目标”。以 Google Analytics 为例，即设置特定的页面为目标（Goals），从而知道转换的变化与好坏。对于封闭的，单一的转换，这种方法是完全没有问题的，但是对于非封闭的，而且是动态的页面，方法论就会有一些瑕疵。

网站主问我：“我的访问者，有多少人会去我的商品页？”；“我的访问者，有多少人会去下单？”

于是使用定义“目标”方法的话，需要定义所有的商品页为 Goal 1，购物车页为 Goal 2，……

Goals 的定义是以Page Views为单位的。也就是举例说：

• 2次 Visits，其中1次，从促销页去查看了3个产品页，另外一次从页面去看了2个产品页，共实现了5个 Goals，转化率为 5 / 2 = 2.5。
• 2次 Visits，其中1次，从促销页去查看了6个产品页，另外一次直接从首页跳出（Bounce）。这样共有6个 Goals，转化率为 6 / 2 = 3。
• 结论是后者的转换率高？可是前者2个访问者皆实现了到产品页的转化哦！如果数据放大，这种疑问就值得沉思了。

所以我就觉得有点奇怪，用 Page Views 作分子，Visits 作分母，它们的比值似乎不太对劲。因为个别狂热的的访问，会造成多次的目标实现，就会拉高整站的转换率。

于是我们调整算法，抛弃 Goals 的设定方法：

• 2次 Visits，其中1次，从促销页去查看了3个产品页，另外一次从页面去看了2个产品页。2次 Visits 都成功转化到了产品页，转化率为 2 / 2 = 100%。
• 2次 Visits，其中1次，从促销页去查看了6个产品页，另外一次直接从首页跳出（Bounce）。2次 Visits 只有1次转化到了产品页，转化率为 1 / 2 = 50%。
• 这样看起来是否更合乎逻辑了。因为是 Visits 与 Visits 之间的比，而且分子除以分母的比值永远小于100%。

实践：

基于前面的结论，我们需要知道数据：

1、有多少次访问来到了我们的网站
2、其中有多少的访问造成了转化去了我们的任意产品页
3、再其中有多少的访问会进去购物车
4、然后是下单 – 物流 – 支付……

这样才是一个完全的 Funnel 漏斗，而且这个 Funnel 的确是越来越小。

首先，查看我们网站的 Visits，这样可以知道有多少次访问来到了我们的网站。

然后，定义多个 Advanced Segements：

• Segement 1（去看过产品页的Visits） 的条件是：Page Contain “ProductID=”；
• Segement 2（去购物车的Visits）的条件是：Page Contain “Flow.php”；
• Segement 3 （去下单的Visits）的条件是：Page ……（忽略掉请自由发挥）。

不同的电子商务网站的产品页的共性不同，你只需要找出共性，找到他们即可。有的是“/goods.php?id=888”，有的是“/Product/3333.html”，有的是“/StyleDetail_9384/”……

最后，我们开始跑报告，把定义好的 Segements 都应用到报告中去：

结论：

于是得到按周来看，这三个 Segements 的数据（声明：演示数据，数字已人工调整）。

从下面的图表，我们就很容易回答刚才的问题：

1. 本电子商务网站会有 61% 的访问会转化到产品页，从上线第一周开始，随着网站的优化，以及各种促销活动的开展，这个转换率一直在提升。特别是在11周，由于季末大甩卖的促销的有力推动，转化率一度拔高到 67% 的历史最高水平。
2. 从产品到下单的的转化率平均为 3%，低于行业平均水平（行业平均水平为 XX%）。令人关注的是，最近的产品到下单的转化率一路下滑。
3. 尽管有较高比例的用户会访问产品页，但下单的用户转化率偏低，可能存在的问题有：
   • 价格优势不够明显。
   • 页面购买下单的按钮都不明显。
   • 页面设计不够合理。
   • ………………说一大堆。

　　市面上有很多流量购买源，可以导入降低 Bounce Rate 的流量。搜索“流量购买”即可查到。

　　如果你运营的网站是商业性质的，会购买广告媒介来进行市场和销售的推广与促进，那么你就不得不关注这些看似高质量的流量，并能进行有效的甄别。否则，营销效果是好是坏？如何评估？将无法解答。像句俗话：“被人骗了还帮别人数钱”。

　　如何甄别虚假互动呢？网站分析师或者网站管理人员，需要有效的方法论来指导工作。此文将详细讲述另一种流量质量评估的新度量——深度互动时间（Time Spend on Deep Content）。

下面将按照以下逻辑进行叙述：1.发现虚假互动。2.研究虚假互动的特性。3.分析建立模型来进行甄别。4.实证研究，看看模型的效果。

[ Tenly Wu 版权所有欢迎转载，但请事先在下方评论知会作者，并注明出处]  

1、发现问题：

　　在前面的文章提到：网站的Bounce Rate很正常，或者很好，可网站的互动行为却非常的不正常。

　　这样的后果是：如果使用不全面、不科学的的分析方法，分析研究结论会被误导为“获得良好的效果”。

2、研究问题：

　　研究发现，停留时间是甄别虚假互动的突破口。因为虚假互动可以伪造点击，但是深度的停留时间很难伪装，仔细研究现象就会露马脚。

　　以Google Analytics为例，在时间上有很多度量（之前有一篇文章《Google Analytics时间观》）。下面我们以一个图说明“时间上”的问题：

　　图中有四种情况，黄色的为Time on Page，蓝色的Time on Site。如果页面的访问深度是1，那么就会有Bounce。访问深度是大于等于2，就不会Bounce。如图中第二种情况，当深度 = 2 时，Landing Page Time on Page = Landing Page Time on Site。注意到第三和四种情况，深度大于 2 后，Landing Page 的 Time on Site 的时间比 Time on Page 更多。原因是访问者通过Landing Page到达后，会进行一系列的互动，在其它页面的互动时间会算在该页面的 Time on Site 这个度量上。

Landing Page Time on Site = 
Landing Page Time on Page + Deep Content A Time on Page + Deep Content B Time on Page + …

　　互动的更深（访问页面多）更久（各页面停留更久），反映了访问者对内容感兴趣，推广效果、网站运营效果良好。

　　现阶段虚假互动能够操作影响到的都是在第一个页面上， 即来到“Landing Page–>停留->点击链接”，我们只需要通过一个度量将这些元素所造成的影响剔除，才可以研究真正的互动程度。

[ Tenly Wu 版权所有欢迎转载，但请事先在下方评论知会作者，并注明出处]  

3、建立解决模型：

Average Time Spend on Deep Content =
( Landing Page Time on Site – Landing Page Time on Page ) / Landing Page Pageview

公式简单说明：登陆页的全站停留时间，除去登陆页的页面停留的时间。余下的时间就是访问者在页面其它深度页面的停留时间。然后除以这个登陆页的浏览量，则可以求得一个平均的深度互动时间。这个值反映了平均每个访问者，点击登陆页内容后，除掉在登陆页的时间外，在网站上其它页面花的时间长短。有效的剔除了容易被“虚假流量”影响的登陆页停留时间这个度量。

4、实证模型：

举例：建立自定义报告（可以自行定义，但保证Entrance是第一个度量，这样可以保证主要的 Landing Page 显示在前面，也要保证 Time on Page、Time on Site 和 Pageview 这三个度量选中，以便新度量的计算。

下面是我建立的自定义报告共享连接：

http://www.google.com/analytics/reporting/edit_custom_report?share=P01MqyUBAAA.5cmZVfTgv7FSDQaf3SApcOxsrvVFOMhXTyWae26xzB8D2OsZLRP6CRorB5cbkn53KnEyuJAzLj-2rfM18IeuWw.-djiSrTR40xr_JrPt1z4Ow

　　套用了新度量进行不同的媒体的评估就显得很清晰了。原来左边第一个 Bounce Rate 特别的好，可是在 Average Time Spend on Deep Content 这个度量上，显得特别的低，开始矛盾了。这说明，最左边的流量中含有大量的虚假互动。

　　那么这个度量值在多少属于差？多少属于好呢？

[ Tenly Wu 版权所有欢迎转载，但请事先在下方评论知会作者，并注明出处]  

　　下面是我们的经验值：对于一些有广告推广的网站而言，低于 1 秒就是很差了，说明推广的效果非常差。5 秒以上就是很不错了。

　　你知道宋星的这个博客：Chinawebanalytics.cn的深度互动时间么？123秒。也欢迎大家把你的博客的深度互动时间与大家分享。

　　没错，这个度量很好的扩大了真流量与虚假流量的差距，这种杠杆方法常用在统计学研究中当中。

　　俗话说：偏之毫厘，差之千里。那么一点点的具有虚假互动性质的流量，都会对这个度量有明显的影响。

　　像老虎的猫，终究是猫。所以流量的质量是客观的，好与不好，换个方法照样能把它甄别出来。

　　由于时间仓促，文章只将概要的思路与大家分享，欢迎大家拍砖或提问，我一一为你解答。或者不足的地方还请大家留言帮助我完善。实在留言解答不了的问题，可以 Gtalk 联系我。谢谢！

　　从事网站分析的朋友们都清楚该度量在网站分析过程中的重要作用：了解用户在 Landing Page (登陆页) 的参与度，帮助网站优化页面，帮助优化流量来源。然而，如果 Bounce Rate 不值得信赖怎么办？

　　作为网站优化过程中的重要度量 Bounce Rate，一般是可靠的。但如果有问题的流量过来的话， Bounce Rate 就会受到污染，而失去可靠性。早在2007年10月，扫地老僧就撰文写过题为《购买流量总结》的文章，描述了问题流量对 Bounce Rate 的影响。

　　我简单的总结该文章内容：在不同时期从两个流量出售网站上购买流量后，一股流量使 Landing Page 的 Bounce Rate 达到 99.73%，一股流量使 Landing Page 的 Bounce Rate 达到 46.28%。作者深入分析结果是两股流量都没有价值，前者对页面的点击互动极少，后者对页面的点击互动不合乎常理。

　　这说明 Bounce Rate 是很容易被操纵的，我称之为“被管理”。通过虚假互动的作用，可以让它很高，也可以让它很低。

如果“设置”导入的流量不做任何行为，就可以让 Bounce Rate 升高；
如果“设置”导入的流量具有点击行为，就可以让 Bounce Rate 降低。

　　让我们看看两个页面的案例，来了解 Bounce Rate 在虚假互动影响下的“腐败”：【未完，请点击上面文章标题阅读全文】

[ Tenly Wu 版权所有欢迎转载，但请事先在下方评论知会作者，并注明出处]

案例一：

　　在某年的4月至5月期间，某站的 Bounce Rate 只有66.92%，这是一个“非常好”的网站。这么好质量的网站，用户都关注了什么内容呢？我把 Top 10 Content 的数据导出来（考虑到隐私，我把页面URI进行了适当的省略）：

　　这些红色字体的内容是什么呢？经查验，大量的互动行为都点击在页面底部的：合作伙伴(hzhb)、投稿指南(tgzn)、广告服务(ggfw)、使用条款(sytk) ……

　　所以一切都非常逻辑清晰了：绝大部分流量都是没有价值的、作弊的！尽管有大量的互动点击行为，Bounce Rate “被”降低，可是这些互动行为都不合常理地点击页面的底部。

[ Tenly Wu 版权所有欢迎转载，但请事先在下方评论知会作者，并注明出处]

案例二

　　在案例一中，虚假互动行为全部集中在页面的底部。我们知道页面“头部Header”与“底部Footer”往往是一个网站共用的。这样虚假的流量通过“设置”后，无论登陆该站哪个指定页面都能进行统一的“一套虚假互动”，从而使整个大站下的所有 Landing Page 页面 Bounce Rate 得到“被优化”。

　　案例二将描述更高明的虚假互动。按照常理，一个页面最受欢迎且最容易被点击的内容都在第一二屏。所以作为 Landing Page ，页面中的大部分点击行为都会集中在页面的中上部。下边是我引用的Google的标准点击热图(Heat Map)。

　　与案例一不同，这个案例的 Bounce Rate 一点也不出众。打开GA，查看其 Bounce Rate 有87.88%，而且一直非常的稳定，这是不容易引起人们注意的。然而，最危险的欺骗，往往是在最平凡的外表下的。起初没有发现这页面的问题所在，可是当对 Landing Page 进行 Heat Map 分析的时候，问题出现了：

　　用户在点击推广广告，来到 Landing Page 后的互动行为中最受欢迎的10大点击链接如下表，分散地点击在不同的位置上。

　　于是，我把这10大点击内容标注在页面上。结果发现，这些内容都是在页面中第三屏以下的内容。令人惊讶的是，排名第一的链接居然是页面的底部偏上。后来再仔细研究，第一屏与第二屏众多链接内容，居然没有一个能排进前20名。

　　所以逻辑已经清晰：虚假互动行为是可以“被管理”的，可以分散地“被点击”页面中的多个内容，Bounce Rate 也将会“被”降低。也就是说，实际的这个页面真正 Bounce Rate 至少有99%以上，之所有能够到87.88%，完全是虚假互动行为所致。

[ Tenly Wu 版权所有欢迎转载，但请事先在下方评论知会作者，并注明出处]  

　　有人问：也许第一二屏的内容的确就不吸引人，下面的内容就足够的吸引人。事实上，在实际案例背后，分析师还有项目的更多佐证信息帮助研究判断，在此有限篇幅就不作冗余说明。主要的思想是为了说明：虚假互动行为是能够“被管理”的。

　　聪明的你也许会想到，如果虚假互动行为“管理”得好，全部集中在第一二屏的话，Heatmap 研究估计就没有作用了。那还有没有一种有效的办法可以快速识别虚假互动呢？

　　有方法的！在我被“虚假互动”持续困扰一年后，通过Google Analytics工具，找到一个不错的方法。敬请关注下周文章：《新度量——深度互动时间》

在Google Analytics中，有很多个时间度量：

Time on Page，∑ Time on Page，Avg. Time on Page；
Time on Site，∑ Time on Site，Avg. Time on Site。(Avg.是Average的缩写）

在WA的过程中，基本度量非常重要，原理一定需要百分之百清楚。我以前想当然地以为自己理解了，但事实并不是这样。下面就严谨地详细地与大家分享一 下（有些枯燥）：

说明与定义：

• 为标准化度量名称，本文相关度量均用英文表示；
• 文中的“本站”，指添加了同一UA ID Google Analytics监测代码的所有页面集合；
• “站外”，指未添加Google Analytics监测代码或“本站”UA ID不一致的页面集合。
• “站外”与“本站”的关系：本站 ∩ 站外 = 0，本站 ∪ 站外 = ∞（即整个互联网）。
• 监测部署是以标准的Google Analytics监测代码为准，不考虑使用虚拟 Pageview Tracker 或 Event Tracker 等定制化监测情况。

基于页面的时间度量

Time on Page and ∑ Time on Page：

访问者停留在某个页面的时间，所有访问者在一批页面的停留时间总和。对于跳出到站外的访问， Google Analytics将无法统计最后一个访问页面的停留时间。英文详细标准定义如下：

This field indicates how long a visitor spent on a particular page or set of pages. It is calculated by subtracting the initial view time for a particular page from the initial view time for a subsequent page. Thus, this metric does not apply to exit pages for your site.

Avg. Time on Page：

一个特定页面的平均停留时间 等于 所有访问者在该页面的停留时间之和，除以该页面的 Pageview 与 Exit（或Entrance）之差。

公式：Avg. Time on Page = ∑ Time on Page / (Pageviews– Exits)

需要说明的是：如果访问者只访问该页面一次，且这该页面是离开本站前的最后一个页面，那么他的停留在该页面时间为零。

基于网站（页面的集合）的时间度量

Time on Site：一个访问者在本站所停留的时间，即停留在本站所有页面的时间之和。如上图一个访问者，Time on Site = Time on Page A + Time on Page B + Time on Page C = 2:25。尽管 Time on Page C = 0，但它也会参与到Time on Site的求和计算过程中。下方是官方英文标准定义：

The time a visitor spends on your site.

∑ Time on Site：一类访问者在本站所停留的时间之和。

Avg. Time on Site：访问者在本站平均停留时间。公式为：

Avg. Time on Site = ∑ Time on Site / Visits

对于本站而言，Visits 的值等于所有的登陆页的 Entrances 之和。
这里的除数是包括了Bounce部分，意味着，有些Entrance并未造成停留时间增加。因为一个 Visit Entrance到登陆页，什么都没干 Bounce 走了，虽然 Entrance + 1，Pageview + 1，Visit + 1，但这个访问 Time 为 0 。而他们要在公式中与其它 Visits 分享 Time on Site。

利用自定义报告理解度量间关系

在Google Analytics的自定义报告中，左边有许多的 Dimensions 和 Metrics 供你选择，大家不妨拖拽着玩玩，了解主体与度量之间的关系。比如说：

• 当你选择 Dimensions 为 Landing Page， Exit Page 的时候，Time on Site 与 Avg. Time on Site 就会变灰（无法选择）。因为作为特定的功能页主体，是无法具有 Time on Site 这种属性度量的。
• 但是当你选择 Dimensions 为 Source， City 的时候， Time on Site 与 Avg. Time on Site 就能选择。因访问者类型作为主体时，就能使用 Time on Site 这种属性度量。
• 更奇怪的是，当你选择 Dimensions 为 Page 的时候， Time on Site 与 Unique Pageviews 两种分别为 Site Usage 和 Content 类的度量只能二选一。

最后，跑一个Dimensions 为 Landing Page 的自定义报告，大家可研究一下度量间的关系，结论公式如下：

Time on Page / Avg. Time on Page + Entrances or Exits = Pageviews

思考题

最后留一个问题让大家思考，帮助大家自己研究体会，欢迎大家留言交流解答（正确答案将在国庆节公布）：

如果再跑一个Dimensions 为 Page 的自定义报告，大家会发现，同样的 Page 01，02 的各个页面，Time on Page、Avg. Time on Page、 Exits、Pageviews、 Unique Pageviews 度量的数据都不同了。为什么呢？

期待您的回答。。。

永远不忽略URL

URL是一个重要的信息，职业敏感让分析师绝对不会忽略URL地址的特点。URL反映出网站的蛛丝马迹，直接以例子说话:

$ URL地址所在的域名

很多人在网上被骗，很大原因就是从来不关注URL所在的域名。

• 比如：http://www.taobao.ipx32.com/about.html，看似弱智的骗术却让很多网友误以为是淘宝的网站而落入圈套。这是ipx32域的网站，而不是taobao的网站。
  在浏览的过程中，时刻关注页面的URL域名，可以知道点击链接是否离开本站，而关注新到的站点域名有何特征。在许多大客户的营销过程中，跨域的链接是很常见的，不同的域意味着站长或广告主的监测工具与策略也会有所不同。
• 比如：在IT门户中常有Intel，华硕，HP等硬件厂商的专题页面（可能会添加Google Analytics或Nielsen的监测代码），这些页面中会有链接将访问者导入新的域名，如intel.com.cn，或者hp.com.cn（可能会添加Omniture、HBX或Webtrends的监测代码）。这种跨域的URL是显而易见的。

$ URL地址所包含的参数

URL中包含参数是再常见不过了，但每个参数都有含义，关注它们能够全面掌握网站的功能特点。比如：

• http://www.chinawebanalytics.cn/?p=917 这是Sidney的新博客的地址，可以分析这个博客运营了挺长的一段时间了，ID号都排到917了。
• http://adsclick.qq.com/adsclick?oid=1112901&loc=QQ_SX_JY_Test6&url=http://www.52-abc.com/ 这是QQ首页的右侧广告链接，里面丰富的参数告诉了我们对这些广告位的名称定义，以及跳转的目标地址。
• http://www.soso.com/q?sp=S&sc=web&cid=w.q.in.sb.web&ty=1&bn=&op=entry&kw=&w=WA 这是腾讯搜搜的“WA”结果页，告诉我们搜索关键词参数是用W变量。还有一些别的参数，也许一下子看不懂，如果有需要可再多次试验研究，就可以确定。

总之，对URL的参数关注是分析师的基本功。

$ URL地址所指向的文件类型

URL中会包括文件类型的信息。

• HTML/HTM：这说明这种网站的页面是经过静态化处理的，以方便搜索引擎抓取。现在大部分门户与CMS系统都会有静态化处理功能。再有一些简单的个人网页也会使用html文件名。
• JSP/PHP/ASPX/ASP：这说明这是一种动态页面，网页源文件是存在服务器端，这些文件的特性可自行搜索了解。
• 无类型：有些地址，http://www.ectend.com，这是属于服务器自定义了主页，效果其实是http://www.ectend.com/index.php
• .do：http://www.ems.com.cn/qcgzOutQueryAction.do?reqCode=gotoSearch 这种情况是jsp开发的网站。其实不需要完全知道，能辅助即可。这种网站一般有一定的技术含量，但技术实力不强，不够先进，常见于一些国资背景企业的功能型网页，或者网站的后台。因为时下好的网站，在前端页面都能将URL隐藏得很好，不会出现.do这种情况。
• 另外：还有一些开源项目的网站URL地址比较特别，如Wordpress：http://www.ectend.com/index.php/excellent-analytics/；或 Wikipedia：http://zh.wikipedia.org/wiki/Wikipedia:首页。

$ URL地址命名的特征

从URL的命名也能发现蹊跷或有趣的事，比如：

• 淘宝的URL特征就很有意思，是通过base 64编码的。（感谢money的指点，修正原来错误，很有收获，再次说明URL里有乾坤），很多“-”。我推测“–”之间代表着变量，如果中间没有值，就代表这个变量没有定义。
  http://list.taobao.com/browse/50018957-50018960/n-1-1---------------------0---------yes---------------------2-------b--40--commend-0-all-50018960.htm?ssid=r18?ad_id=&am_id=&cm_id=&pm_id=
• 凡客诚品的URL也很有特色：
  http://www.vancl.com/Product_1E10000/RuanNiuPiXiDaiXiuXianXie+HeiSe.html，产品拼音+颜色。
• 另外还能找出他们员工粗心之处：我们知道中文括号（）与英文括号()不同，URL地址中只能出现英文括号，中文括号会翻译成编码。可见Vancl的员工在产品录入时没有统一标准：
  http://www.vancl.com/CategoryList-1440-1--1/GaoJiMianTangQuanMianChenShan%EF%BC%88ZunGuiKuan%EF%BC%89.html
http://www.vancl.com/CategoryList-1324-1--1/ShangWuXiuXianKu(BiaoZhunKuan).html

网页源文件

对于好奇的网页，一定要查看网页源文件。通过源文件的快速浏览能够确定网站的技术实力、设计人员的素质，监测工具与监测方法的部署情况。一般关注以下四点：

• 代码是否干净还是冗烦
• 部署了哪些监测工具
• 监测工具的代码部署的位置与顺序
• 是否加入了可疑代码

同样的时间区间，为什么两种监测工具报告中的数据不同？

　　这个问题我从来不会回避，因为认真地回答这个问题不仅可以体现分析师的专业性，而且能巩固监测工具在客户心目中的“公正客观”的地位。

　　但话说回来，这却是一个很难回答的问题，要回答得全面而且通俗并不容易。

• 因为技术日新月异，影响数据差异的因素会越来越多，使得无法全面。
• 因为有些因素需要详细的技术说明，使得很难说得通俗。

　　本文，希望用全面而通俗的文字回答这个问题，希望成为网站分析领域回答这个问题的标准范本。（媒介监测领域也有该问题，在此文不作说明）

1. 监测工具原理(Tracking Tools Methodology)不同。

   • 数据获取方式不同。

     　　服务器日志分析工具，是通过解析服务器日志进行网站访问数据获取。如AWStats，扫地老僧做的Nihuo；
     代码嵌入分析工具，是通过在网页中加入Javascript代码，运行后向监测工具服务器发送带请求，服务器从而获取访问数据。如Google Analytics，Omniture。
     后者现在业界更为常见，两者的数据获取方式不同会造成统计数据的差异。比如：

     　　访问者输入www.g.cn发送访问请求，会经过一系列步骤：
     ①DNS解析 –>② 获得服务器IP –>③ 向服务器发送请求 –> ④服务器返回认证 –> ⑤开始下载页面数据 –> ⑤下载中和浏览器解析中 –> ⑤数据下载结束。

     　　服务器在获得“③用户发送请求”后，就会生成一条日志，日志分析工具就是对海量的日志记录进行分析。不同的服务器系统日志格式不同。常见的IIS记录，形如：

     2009-04-17 02:04:52 W3SVC9218140 61.191.191.183 GET /default.asp – 80 – 203.208.60.19 Mozilla/5.0+(compatible;+Googlebot/2.1;++http://www.google.com/bot.html) 200 0 0

     　　后者监测工具是直到“⑤下载中和浏览器解析中”阶段才开始生效。Javascript程序运行后会向服务器发送请求。有的是请求1×1象素Gif图片，如Google Analytics；有的是请求htm页面，如国产老牌统计软件CNZZ是请求http://219.232.241.164/stat.htm。共同之处是，请求都带有了访问者的各种参数，监测服务器通过截取参数获取数据。形如：

     http://www.google-analytics.com/__utm.gif?utmwv=1&utmn=970846480
     &utmcs=utf-8&utmsr=1680×1050&utmsc=32-bit&utmul=en-us&utmje=1
     &utmfl=9.0&utmcn=1&utmhn=www.gmodules.com&utmr=http://ectend.com/
     &utmp=/translate_my_page_gadget&utmac=UA-10000-1&utmcc=__utma
     %3D123692957.37202895.1245037832.1251034440.1251471692.21%3B%2B
     __utmb%3D123692957%3B%2B__utmc%3D123692957%3B%2B__utmz
     %3D123692957.1251471692.21.21.utmccn%3D(referral)%7Cutmcs
     r%3Dectend.com%7Cutmcct%3D%2F%7Cutmcmd%3Dreferral%3B%2B

     　　即使同样是代码嵌入分析工具，也会有很多因素造成数据差异，下面还有更多说明。

   • 用户端缓存机制不同。

     　　某个访问是新访还是回访？这需要将用户的信息“唯一化”地写入Cookie文件中，缓存在用户端浏览器指定目录。
     这里存在有第一方Cookie与第三方Cookie之分。虽然市面上绝大部分监测工作都是使用第一方Cookie，但不排除仍有些小型公司产品使用第三方Cookie。 第三方Cookie容易被用户浏览器屏蔽，获取的数据不够准确，且保密性差。
     有人会好奇地问，Cookie里到底写了什么？那我就贴个内容简单的第一方Cookie示例，满足你的好奇心。这是百度统计的Cookie内容，文件名administrator@hm.baidu（不要问我内容代表什么，我也不知道，要看百度开发人员对ID号的定义）：

     HMACCOUNT
     D3020343DB851C59
     hm.baidu.com/
     2147484672
     2350186496
     32111674
     1314491424
     30025681
     *

   • 监测工具分析方式不同

     　　监测工具获取了大量访问的行为数据后，就开始一系列的统计分析。

     • 度量定义不同

       　　在网站分析领域中涉及到很多度量，如Unique Visitor，Visit，Pageview，Time on Site，Bounce Rate等等。由于行业暂时还不是非常成熟，有些度量虽然有Web Analytics Association(WAA)、IAB等专业机构的定义，但仍未被标准化地广泛使用。在国内还涉及一些中文翻译标准化的问题，有造成对度量定义混淆的情况。
       从我个人的经验，迄今为止，国内外最无定义分歧的度量就是Pageview(PV)。至于Visit（Session，或访问，或访问数），是有分歧的：有的认为Visit的有效期为30分钟，有的认为1小时。更别提复杂的度量Bounce Rate的定义之争呢。

     • IP校验数据库不同

       　　访问者的IP是被监测工具获取了，但IP对应的实际地理位置数据库却不是全球通用的。IP地址数据库是时刻变化的，无权威发布机构，所以不同工具的统计报告中，地理区域划分数据也会有一定的差异。

     • 过滤与限制功能

       　　我们知道Google Analytics有丰富的过滤功能，如过滤某个IP段，过滤操作系统为Linux的访问。不同的监测工具也有类似的功能。这些功能一旦开启，设置的不同也会造成数据的差异。

2. 监测代码部署(Tracking Code Implementation)方式不同。

   • 监测代码部署的位置。

     1 2 3 4 5 6 7 8 9 10 11 12 13 14

     <html> <head> - Infomation For this page - </head> <body> - Content of This Page - Hello - </body> </html>

     　　上面示例了一个页面的结构，监测代码可以部署在第3-12行之间的任何位置。但是放置的越前，监测代码越早被运行，监测的数据越多；放置的越后，监测的数据越少，有时甚至还会因为页面中的JavaScript出错，而导致监测代码失效。

   • 监测代码的冲突。

     　　有时由于同一页面中两种监测代码间，或者监测代码与页面本身的JavaScript之间，有函数名、变量名等的冲突，会造成监测代码的失效，或者监测不准。

   • 监测代码的正确性与完整性。

     　　专业的网站分析过程中对监测代码进行定制是必不可少的，代码的定制会造成统计结果的个性化，但同时也会有定制出错的风险。这些情况的发生，会造成监测数据的差异。

3. 用户端设置(Client – End Settings)不同。

   • 浏览器功能设置

     　　浏览器种类很多，功能也不尽相同。但都具有基本的Cookie屏蔽功能，有的还支持图片、Flash、JavaScript的屏蔽功能，甚至还有的能对网页代码的关键字进行屏蔽。这些屏蔽技术的应用，会造成监测数据的差异。比如，屏蔽网页代码中的关键字“ga.js”，那么就会造成对Google Analytics的屏蔽。又比如，某浏览器禁止运行网页中的JavaScript，那么代码嵌入式监测工具将会全部失效。

   • 网络访问类型

     　　现在上网方式多样化，除了电脑上网外，用户还可以用Wii上网，可以用手机或其它手持终端上网。这些访问形式多种多样，可能是基于WAP的，可能是不支持Cookie的浏览器……不同的监测工具，对这些多种多样访问形式的支持是不尽相同。现阶段，个人观点认为Omniture在这方面最为先进，支持的访问形式最多。

     　　另外，搜索引擎的蜘蛛，或者一些特别网站发起的请求也会造成对页面的访问。一般的监测工具都会忽略掉这一块的流量。

   • 网络传输影响

     　　最后，我能想到的另外一种可能是网络传输过程中的差错，如网络丢包。还有一种情况，URL太长导致参数被截断的情况也并不少见。微软的权威解释，IE的url最大长度是2083个字节，可以用于GET传递数据的长度是2048个字节。

　　有我没有考虑的情况么？我写错或理解错误了哪个地方么？欢迎留言，或者邮件给我讨论完善此文：tenlywu邮标gmail.com。

　　另外发个广告，我又重操旧业，写写博客了www.ectend.com。由于宋星的博客有专业定位，文章主题统一，且读者对技术层面的讨论相对较少，非网站分析主题的文章和网站分析偏技术研究的文章就只在自己的博客上发表了（因为网站分析只是我染指的其中一个领域）。毕竟自己的博客写起来比较随意，给宋星写博客对文章质量要求特别高，很累的。

　　今天再次推出代码研究进阶版，与大家一起研究讨论分享。总觉得这套代码可能会有一些考虑不周的地方，还请大家给予建议。再次强列声明，我不懂代码，纯粹研究。

　　互联网流量真真假假太多，需要有针对性的进行研究分析。这套代码虽然是我东拼西凑写的，但已经可以稳定运行，实现三大功能：

1. 记录所有页面的刷新。所有的浏览器层级的刷新都会被以action/+url形式记录在GA的content报告中。
2. 标记页面刷新的次数。所有的刷新都会被统计数据，最终会以action/+url+刷新次数形式记录在GA的content报告中。
3. 监控页面的所有外链。所有的外链都会以out/+url记录在content报告中。

 <script type="text/javascript">

var url=location.href;
var pslt=url.lastIndexOf("/");
var keyurl=url.substring(0,pslt);
var a=document.getElementsByTagName("A");
var str=str1=out="";

//定义一些变量，用于下面的tenly函数

function tenly() {

 //下面会通过对window.name的操作，识别刷新，通过window.name＋＋的方式记录刷新的次数。该方法论是通过Google 搜索别人博客获得。

if(window.name!=”) {

window.name=eval(window.name)+1;

str=’/action/‘+url+window.name;

pageTracker._trackPageview(str);

 } else {

window.name="0";

 }

//下面会监测页面中的所有<a>标记，这是html语言中的链接标记。通过判断URL的根目录关系，确定页面是否外链。

for(var i=0;

i<a.length;

i++) {

a[i].onclick=function () {

 if(this.href.indexOf(keyurl)==-1) {

str1=’/out/‘+this.href;

pageTracker._trackPageview(str1);

 }

 }

 }

 }

//最基本的IE与Firefox侦听器的写法，使代码能够在不同浏览器正常侦听。

if(window.addEventListener) {

window.addEventListener("load",tenly,false);

 } else if(window.attachEvent) {

 window.attachEvent("onload",tenly);

 }

</script>

//调整后的GA代码，适用于https与http页面，只有页面第一次打开才会记录PV运行。

<script type="text/javascript">

var gaJsHost=(("https:"==document.location.protocol)?"https://ssl.":"http://www.");

document.write(unescape("%3Cscript src=’"+gaJsHost+"google-analytics.com/ga.js’ type=’text/javascript’%3E%3C/script%3E"));

 </script>

<script type="text/javascript">

try{

var pageTracker=_gat._getTracker("UA-5431245-5");

if(window.name=="") {

pageTracker._trackPageview(); 

} 

} catch(err) {}

</script>

　　这篇博客就讲点简单的技术问题吧，技术专家（如车东这样的人）可以直接忽略此文。感谢一楼评论的建议与更正。
以下GA代表Google Analytics。

<script type="text/javascript">
var gaJsHost = (("https:" == document.location.protocol) ? "https://ssl." : "http://www."); document.write(unescape("%3Cscript src=’" + gaJsHost + "google-analytics.com/ga.js’ type=’text/javascript’%3E%3C/script%3E")); </script>

<script type="text/javascript">
try { var pageTracker = _gat._getTracker("UA-4130899-1");
pageTracker._trackPageview(); }
catch(err) {}
</script>

　　上面是最基本的GA代码，分为两个部分。

第一部分(加粗部分)：

1. 通过一条(正则表达式)JavaScript三元运算符，定义了gaJsHost 变量。我们不需要非常了解正则表达式的原理，但看得出来这一行是在让GA自动辨认代码所在页面的URL地址是哪种前缀，如https等等，了解即可。
2. 通过最常用的(JS内置函数)DOM对象函数 document.write，把一串html代码写入到所在页面。（unescape 函数的用途就不细说了。）这串html代码的目的是让页面去GA的服务器下载一个叫ga.js的统计功能文件，用来进行实现GA的统计。上面的gaJsHost 变量，决定了ga.js文件的URL地址的细微不同。

　　第一部分的代码就实现了两个目的。但是我们可以看出有很多可以DIY的地方：

1. ga.js文件可以放在本地，如把ga.js放在http://www.chinawebanalytics.cn/ga.js。那么第一部分的代码可简化为：

   <script src="ga.js" type="text/javascript"> </script>
   或者是
   <script src="http://www.chinawebanalytics.cn/ga.js" type="text/javascript"></script>

   举这个例子主要是为了解析代码作用。

   实现上这样做的唯一好处是能让ga.js的加载速度＝本站速度。随着GA的连接速度越来越好，这种作法也大可不必了。另外，ga.js会不定期被GA不通知的情况更新，所以如果下载了ga.js，也许没过多久就不是最新版本了。

2. 简化GA的监测代码。如果你的网站很清楚就是http://开头的，而不是https://开头。那么第一部分可以直接这样写，四行变一行：（PS.我有电脑洁癖症）。后方有Cloudream同学的更精简方法。

   <script src="http://www.google-analytics.com/ga.js" type="text/javascript"></script>

第二部分(未加粗部分)：

1. try catch语句的作用是，在与GA服务器通信的过程中，防止意外错误造成页面停止Loading。
2. 定义 pageTracker 实例对象，并根据你的帐户ID关联上。pageTracker 类下面有很多函数，希望以后的文章里与讲几个函数的作用。
3. pageTracker._trackPageview() 函数是指记录一个PV，并把该页面的地址返回给GA服务器。

　　第二部分的代码就实现了两个目的，关联你的帐户ID，并记录页面的PV与相应的URL地址。同样，这里的DIY更是无穷无尽了：

1. 定义第一次打开该页面，才记作一次PV，如果不是，则不记。通过判断window.name是否为空值，来确定这个页面窗口在浏览器中是否第一次打开。结合地写一些其它相辅助的代码，可以实现对垃圾流量的过滤。

   try {
   var pageTracker = _gat._getTracker("UA-4130899-1");
   if(!window.name){
   pageTracker._trackPageview();}
   } catch(err) {}

2. 一个PV两处记。你可以建立与两个ID的联系，让访问数据同时记入两个ID的统计数据库。

   <script type="text/javascript">
   try {
   var pageTracker = _gat._getTracker("UA-4130899-1");
   var pageTracker1 = _gat._getTracker("UA-8888888-1");
   pageTracker._trackPageview();
   pageTracker1._trackPageview();}
   catch(err) {}
   </script>

　　抛砖引玉的内容就到此了，今晚要早睡，明天还要上班了。欢迎“流”言。PS，强烈声明，本人不是做技术的，完全不懂编程，只是瞎研究了一下。

这篇日志晚了几个月，有兴趣的可以访问从头到尾说网站分析过程中的度量(上) 回顾一下。

第二篇 合作网站（Online Coop Minisites）

　　在合作网站建立专题页面（网站）是有中国特色的线上推广方法，例如在IT门户经常会建立软硬件厂商的产品介绍活动专区。在与来自美国的Adam交流过程中，得知国外广告主极少采用合作网站的方式进行推广，而是将所有的广告指向自身官方网站。

　　在中国，为什么要经常建立合作专题页面（网站）进行推广呢？原因有很多，主要原因有三点：

1. 网站经常会给大广告主大量免费推介资源，而这些资源是不允许外链到非本站的地方。当然这也是控制网站流量不外流的手段。
2. 合作专题页（站）的建设更容易，更低成本，甚至可以通过购买广告免费赠送。对于大的广告主，更新自己的官方网站是一个比较高成本的工作。
3. 访问忠实度的心理因素。如果一个网民在一个门户上阅读，他希望所有相关的信息都在一个网站上获取完，不希望被“卖猪仔”一般被链接跳转来跳转去。

　　合作网站的的监控可以多种多样，但是唯一不能采用的监控方法是“网站日志分析法”，因为网站是绝对不可能提供日志供你分析的。所以最常采用的就是JS代码监控，如Google Analytics，CNZZ等代码监控。

需要经常使用的度量就是：

• PageView：
• Visits and Unique Visits：
• Time on Site(Page)
• Bounce Rate
• P/V

这些度量在之前的文章中都有详细地说明，网站分析的最基本度量系列文章

第三篇 本地网站

　　入口与合作网站的流量最终可能会导入到本地网站。本地网站的监测方式与度量是与合作网站是类似的。不同的是，本地网站可以使用日志方式进行网站监测，对网站的监测控制度与深入度更大。

　　为了最直接地了解本地网站与前两篇的关系。下面以一个例子，描述：入口、合作网站、本地网站的层次关系：

　　A公司的一次线上广告项目。总共有A1、A2、A3、B1、B2、C1、XXblog等多间媒体。这些媒体的入口有些直接把点击访问者导入到A公司的官方网站上（图中的B２），有的会把他们导入到不同的合作网站上（图中的A1、A2等）。有些的合作网站是博客的形式，有些是专题站的形式，有的可以监测，有的不能监测。

　　这是一个比较简单的项目，简单的三个层次反映了中国互联网市场营销的多样性。多样性，是指监测的工具很多，可供选择的媒体很多，营销的合作方式也很多。

　　但是如何评估这个项目的成功与否呢？这正是分析师的我们所需要做的，这也是以后可能会深入与大家分享的话题。我们每天周旋在数十个网站之中，采用不同的度量，平衡不同的计算方法，建立统一的评估模型，所以说网站分析其实并不简单……

　　Event的监测能实现什么呢？信中的原话：Event Tracking allows you to track interactions with Web 2.0 style content such as Flash, AJAX, Adobe Air, Silverlight, social networking apps, etc. It essentially allows you to track interactions beyond just pageviews.

　　这对于我来说是一个无比欣喜的功能，因为随着用户行为的多样化，网站设计的飞速发展，这样的监测功能可以更深入地了解访问者的Engage过程。举个例子：

　　以前，当在校内、开心这样的SNS网站，点击一个删除消息的按钮，页面并不会刷新或者新开，这意味着，用户在这个页面的这部分互动行为是不被监测的。但现在，通过Event监控功能的开放，GA都会一一记录，而且会在Content下面专门出现一个”Event Tracking”的报告项。

　　这是一个较为中级的网页开发的技术问题，涉及到网页代码的编写知识。基于我的代码水平还是中低级，我还需要更实际运用一番才能详细地与大家分享。

　　或者如果你也懂技术，我们一起去研究研究吧：http://code.google.com/apis/analytics/docs/gaJSApiEventTracking.html

　　赶快查看你的邮箱吧，估计你也收到了！我想，收到这样的信的前提是，你GA帐户下管理的网站有Web2.0元素丰富的网站，如Gmail,Tudou,Xiaonei等使用Flash/AjaX/Adobe Air/Sliverlight等技术较多的网站。最后附GA的官方博客说明地址：

http://analytics.blogspot.com/2007/10/exciting-announcements-at-emetrics.html