Omniture SiteCatalyst

2002年推出收费 国外

虽说论资历，Omniture还比不上WebTrends，但是凭借技术上的优势，Omniture已经可以算得上Web流量分析领域的老大了，产品线非常庞大，其中SiteCatalyst是其主推的旗舰产品。最近一两年似乎也在积极开拓国内的市场。

优势1. 针对电子商务定制的监测

SiteCatalyst对于电子商务客户有专门定制的监测，可以分析例如购物车添加、移除等事件。

优势2. 提供强大的扩展机制

SiteCatalyst通过eVars（custom ecommerce variable）、props（custom insight variable）以及Custom Event达到报表扩展的目的。通过配置这三个特殊变量，客户可以实现很多自定义KPI的跟踪。

通过在后台配置变量关联，可以对在同一份报表中对数据进行关联分析。例如将页面名和省份关联，那么就可以分析每个页面在不同省份的表现情况。

优势3. 路径分析

路径分析无疑是Omniture的一大优势。这里的说的路径分析既可以是传统的页面导航分析，

也可以和KPI结合到一块来分析（下图来自Discover系统）

劣势：Omniture SiteCatalyst的最大劣势就是系统过于复杂。而部署工作非常繁琐，需要在客户网站上加上非常多的标记代码，例如为不同页面设置不同的页面名称。而后台很多报表也需要经过精心的预配置才能看到。所以一般SiteCatalyst的配置都由培训过的专业人士来负责。

Google Analytics

2005年推出免费 国外

Google Analytics（简称GA）是Google收购了老牌的付费流量分析工具Urchin之后整合推出的一款免费网站流量分析工具。GA自推出以来，以其强大优势迅速拉拢了国内外大量用户，成为人气之王。

优势1. 功能完备

由于GA的前身是付费流量工具Urchin，因此它的功能较其他免费流量分析工具来说更为完备。访客跟踪，网站热门内容跟踪，路径导航分析，流量来源分析，链接点击覆盖图以及电子商务等等，基本涵盖了Web流量分析常用的各个方面。

优势2. 数据剖析功能强大

做Web流量分析最基础的操作就是对流量进行细分，这样才能知道每个特定群体，例如来自百度和来自Google的各自的KPI效果如何。GA在报表中允许对不同数据进行交叉分析，其高级分段（Advanced Segments）功能更是允许你精心过滤出你关注的群体。关于如何使用GA高效的进行数据剖析，可以参考我以前写过的文章高效使用Google Analytics进行Web流量分析。

优势3. 代码部署简单

相比Omniture，GA部署的代码简单得多了，大多数情况只需要在全站加几行一样的js代码即可完成部署工作。然后就直接在后台看到全部的报表。只有部分特殊的功能，例如电子商务，才需要写一些特别的js代码。

劣势：相对复杂，不容易上手，适合有一定Web分析基础的人使用。同时，自从谷歌撤离大陆之后，GA收集数据的域名www.google-analytics.com就没了保障，面临偶尔甚至终生被重置的危险。

Cnzz站长统计（还有51.la、太极链等）

2007年推出免费 国内

cnzz应该算得上目前国内用户群最大的流量统计工具了。由于推出较早占有了大批用户群。

优势1. 界面对于大多数中小站长来说比较直观

国内的Web流量分析市场毕竟不像国外那么成熟，大多数中小站长们关注的东西还比较浅层次，看看pv和uv就够了。因此像cnzz的这种界面倒是非常迎合站长的需求。左侧菜单直接就可以打开各个报表。报表基本都是提供一维分析，例如搜索引擎，关键词报表，来源升降版，受访页升降版。比较好理解。

优势2. 用户群大，可以做一些行业级分析

按cnzz官网说的，目前已经有注册用户1694799人，统计站点2795581家了。拥有了这么庞大的数据，并且数据来自各行各业，因此基于数据提供的行业级报告可信度较高。

劣势. 报表简单，无法进行二维以上的交叉分析，例如剖析搜索引擎来的不同关键词的pv、uv表现如何，不同关键词又是如何着陆到不同页面。使用IP来甄别独立访客，是以前日志分析时用到的技术，不适应新形势。

国内还有好多类似的统计工具，例如51.la，太极链等，和cnzz走的路线基本差不多。

Gridsum WebDissector

2008年推出收费 国内

WebDissector是国双科技08年推出的一款基于多维度自由剖析的Web流量分析工具，在推出一年内，便摘得Adworld 2009年度最佳技术大奖，目前服务的客户有很多知名品牌，例如微软中国，可口可乐，惠普，上汽，中粮，欧莱雅集团下所有品牌包括兰蔻、巴黎欧莱雅等。

优势1. 可交互的热力图动态剖析技术

热力图是根据用户的点击密集程度绘制成的一张图，一般用来分析用户的关注点。传统的热力图只是简单的根据用户的点击数据输出为一张静态图片，仅此而已，而国双的WebDissector是全球首个也是唯一一个实现可交互的热力图动态剖析技术的工具。该工具采用了微软最新的Silverlight技术进行研发。

用户可以任意框选热力图上感兴趣的区域，然后从20多个不同维度中选择其中一个维度对此区域进行流量细分，例如分不同搜索引擎、关键词或者广告媒介查看流量情况，而且剖析不局限于当前的点击数据，用户还可以看到点击了此片区域的访客最后完成的KPI情况，例如此访客最终是否发生购买行为，是否注册转化了等等。

用户也可以针对某个特定的群体绘制出单独的热力图，例如用户想看看从新浪和搜狐广告推介来的访客都关注那片区域，那么他可以使用“广告来源=新浪or搜狐”的条件绘制出新的热力图。

针对Flash内不同场景的跟踪，WebDissector更是通过独创的快照分析功能解决了同片区域不同内容的点击监测。

如果用户关注页面上的链接，那么可以启用链接排行榜功能，分析此页面上链接的点击情况。不过这个功能似乎已经成为很多成熟Web流量分析工具的标配了。

优势2. 多维度自由交叉剖析

很多人在GA中见识了使用两三个不同维度进行交叉剖析的功能，而在国双的WebDissector系统中，用户可以使用近70多个内置维度进行自由交叉剖析。下面四张图展示了一个自由剖析的过程。

优势3. 自定义属性

一个优秀的系统必须能够扩展，像Omniture SiteCatalyst提供的变量扩展机制，WebDissector也提供了自定义属性用于给客户自定义自己想关注的维度，例如我们可以设置一个自定义属性“性别”，在浏览器端通过网站传给的信息发送给WebDissector服务器，最后就能在后台看到不同性别的流量情况了。

优势4. 流量质量评分

如何衡量访客访问的价值一直是Web流量分析的一个重要问题，通常我们会定义一些KPI来评估这种价值，例如此访客是否注册了，是否购买了。但是对于一个内容型的网站可能定义这种指标就不是那么容易。那么我们可以给不同页面、不同的行为设置不同的分值，例如用户着陆的页面通常分值比较低，而用户进入网站一些关键页面则分值较高，那么通过这种方式我们就能直观的为每个流量打上一个分值，从而更好的评估不同渠道的质量效果。

劣势：与Omniture和GA遇到的困境类似，功能强大的系统往往用户不容易上手。路径分析功能尚不及国外优秀工具。

百度统计

2009年推出免费 国内

作为后起之秀的百度统计不容小觑，功能和界面设计上吸收了不少前辈们的优点。

优势1. 界面直观，模块清晰

和cnzz相似，百度统计直接把所有报表放到了左侧中，并将其分别归入到“趋势分析”、“来源分析”、“网站分析”、“访客分析”4个报表模块，使到界面非常清爽直观。

优势2. 百度专属功能

作为中国第一大搜索引擎的百度，自己做统计工具自然要比别的工具拥有更多天然优势，例如未来可能和竞价排名系统的对接，又例如常用工具下面的“百度收录量”，可以列出百度爬虫更新你网站的频率以及真实的收录数目，相比直接在百度中通过site语法检索更为精准。

下图是我在去年10月更新博客的时候不小心去掉百度统计代码之后的情况，可以看到收录量急速下降。这说明百度爬虫会将网站使用百度统计作为收录的一个考虑因素。这倒是人之常情，据说Google爬虫也会青睐于自己的统计工具，不过还没找到证据。

那些依赖百度带流量的站长们可得赶紧安上百度统计~~

优势3. 实时统计

百度统计可以看到最新30分钟内的PV和UV，以及最近500个访客的一些信息。这在其他流量统计工具中比较少见。可以满足一些数据控的需求。

优势4. 页面点击图

页面点击图是最近这段时间百度推出的新功能，这使得百度统计成为免费流量工具中首个带热力图功能的工具。百度统计的页面点击图包含了两部分，一部分就是热力图，和国双的WebDissector热力图有些相像，不过剖析能力有限，只有4个常见维度，也只能针对点击数进行剖析，无法剖析其他KPI数据；另外就是链接点击图，和GA的网站覆盖图差不多。

劣势：百度提供的报表最多只能提供3维的连续剖析，例如来源=>搜索引擎=>关键词，相比cnzz的单维报表来说有了进步，但是剖析路径固定，用户无法根据实际需求实现高级的交叉剖析。同时数据过滤功能相对较弱。路径分析功能也比较简单，只能看前置和后置页面，并且需要预配置才可以看到报表，不灵活。

以上就是我用过的工具介绍了，可能有描述不准确的还请指正。不知道各位做Web网站流量分析的朋友都在用什么工具，欢迎大家一起交流~

== Kevin Yang ==

你可能对下面的文章感兴趣

• Document.Referrer丢失的几个原因
• Google Analytics中的Page维度
• 当Google Analytics、Firefox和IIS走到了一起…
• 高效使用Google Analytics进行Web流量分析

使用Firefox点击AdWords广告跳转到客户网站上之后，再次刷新页面或者浏览其他页面均提示“Bad Request”的HTTP错误（错误码400）。

而IE、Chrome下则没有这个问题。

Cookie惹的祸

由于HTTP本身是无状态的，用来实现状态维持的技术一般都是Cookie。而之前我也遇到过几次因为Cookie导致的访问异常。一次是同事用Firefox死活访问不了新东方网站（参见我之前的文章：Firefox无法访问特定网站），一次是我自己死活登录不了Gmail帐号。这两个问题最终都是以清空Cookie解决的。所以这次有经验了，用web developer bar查看当前客户网站下都有哪些Cookie，一瞄，发现一个带乱码的Cookie。

不用想，也知道这是因为中文没有编码就直接塞到Cookie里头导致的乱码。看看Cookie的来头，__utmz，是Google Analytics（GA）植入的。删除此Cookie之后，访问正常。

Google Analytics的Cookie编码问题

同事测试的那个广告的Url添加了Google Analytics支持的跟踪参数，并且客户网站上也部署了GA的代码。

GA在执行时会检测当前Url中是否包含广告跟踪参数（至少必须包含utm_source），一旦发现，则认为是付费流量，这个时候它就会提取广告信息中的来源（utm_source），广告系列（utm_campaign）和广告媒介（utm_medium），对其进行解码（先尝试用decodeURIComponent函数，失败的话再用unescape函数），最后持久化存储到__utmz这个Cookie中。但是就在写入Cookie这一步，GA漏掉了编码操作。也就是说，如果我们的广告系列或者广告媒介的原始信息包含中文，那么GA就会直接往Cookie中塞入中文信息。

举个例子，我要为我的博客投一个宣传广告：

• 广告系列：Kevin博客宣传
• 广告来源：google
• 广告媒介：PPC
• 带跟踪参数的着陆页面Url：http://www.imkevinyang.com/?utm_source=google&utm_medium=ppc&utm_campaign=Kevin%E5%8D%9A%E5%AE%A2%E5%AE%A3%E4%BC%A0

那么GA在写Cookie的时候，会执行类似下面的代码（当然这里简化了__utmz的值）：

var data = "Kevin博客宣传";
// GA错误的Cookie操作
document.cookie = "_utmz=" + data;
// 正确的Cookie存储操作
document.cookie = "_utmz=" + encodeURI(data);

使用Javascript对Cookie进行存取，标准的操作应该是在存入的时候编一次码，取出的时候解一次码。这样保证存放在Cookie中的都是ASCII字符。早期JS使用escape/unescape进行编解码，现在通常使用encodeURI或者encodeURIComponent函数，这两个函数用的都是UTF-8编码。

中文Cookie潜在的问题

那么当我们直接将中文直接存到Cookie又会发生了什么事呢？IE和Firefox的行为有什么不一样的地方呢？我们在IE8和Firefox3.6下做几个实验。

IE8对中文Cookie的处理

实验步骤：

• 打开IE8，清空所有Cookie和缓存，建立干净的测试环境。
• 访问http://www.imkevinyang.com/
• 地址栏执行javascript:alert(document.cookie="mycookie=缂栫爜编码;expires=Mon, 25 May 2020 10:31:49 GMT")，写入一个持久化cookie。

这样就在我的博客上设置了一个2020年5月25号过期的cookie了。之所以要设置持久化cookie而不是会话Cookie，是因为IE会将持久化Cookie写入到硬盘上了，这样方便我们了解这个过程，而会话cookie我目前还不清楚他存储的位置。

细心的你会注意到，上面这个cookie的值很奇怪，有几个乱码。其实那段乱码是我把“编码”这两个汉字的UTF-8编码（6个字节）使用GB2312解码（每两个字节对应一个字符）后得到的字符。至于为什么要这样测试，一会我们就会知道了。

IE地址栏用的是ANSI编码，也就是说当你在地址栏输入中文的时候，IE会将中文字符以系统默认字符集进行编码。当你使用中文系统时，地址栏的“编码”字符，实际上最后会被编码为B1 E0 C2 EB四个字节，而在英文系统下，系统使用的是西方字符集作为默认字符集，没有中文字符，因此“编码”这两个字符会被替换成?，也就是3F。

IE在创建cookie文件，会自动选择最合适的编码。当我们写入“缂栫爜编码”（GB2312编码后得到二进制流E7 BC 96 E7 A0 81 B1 E0 C2 EB），由于最后四个字节无法用UTF-8解码，因此IE会将文件存储为GB2312。（如果你只测试“缂栫爜”的话，IE会将文件存储为UTF-8）。

好了，现在让我们来看看文件里头都是什么内容。

打开everything工具，搜索“www.imkevinyang txt”这样就会列出文件名包含www.imkevinyang和txt的所有文件。

打开这个文件，里头存放的就是IE持久化的cookie信息。

这个时候，我们再在地址栏通过javascript:alert(document.cookie)我们会发现，IE显示的Cookie值和我们一开始设置的是一样的。

看完了本地的Cookie信息，我们接下来看看IE发送给服务器的Cookie又是什么。

我们用Fiddler来监视整个HTTP通讯过程（这里不用HTTP Watch是因为HTTP Watch会将HTTP消息解码后显示出来，没办法看到原始二进制数据，不方便分析）。

我们再向我的博客首页发起一次访问，在Fiddler中我们会看到：

（文本形式）

（二进制原始数据）

我们很惊奇的看到，IE发送的并不是我们设置的那些字符“缂栫爜编码”（二进制是E7 BC 96 E7 A0 81 B1 E0 C2 EB），而是“编码����”（现在知道我为什么要用“缂栫爜编码”做测试了把）。对应的二进制是E7 BC 96 E7 A0 81 EF BF BD EF BF BD EF BF BD EF BF BD。注意到，IE将原始信息的后面4个字节替换成了EF BF BD.

这是因为IE发送HTTP消息的时候会检测字节流是否是能够以UTF-8解码，如果不行，那么会将相应的异常字节替换成EF BF BD（也就是对应�字符）。这有点类似于我们之前提到的，英文系统对于缺失的字符会使用?号替代。

Firefox对于中文Cookie的处理

Firefox不像IE那样把Cookie直接存储为文件的形式，所以我们研究起来没那么方便。

不过我们还是按照上面同样的步骤来做实验，不过这次为了简单起见我们修改一下测试的Cookie值。

• 打开Firefox，清空所有Cookie和缓存，建立干净的测试环境。
• 访问http://www.imkevinyang.com/
• 地址栏执行javascript:alert(document.cookie="mycookie=1编码1")

第一次Firefox弹出的对话框显示我们Cookie应该是设置成功了，返回“1编码1”字符串。

但如果你再次通过Javascript:alert(document.cookie)你会发现，这次弹出的内容变了：

我们通过Web Developer Toolbar查看当前域下的Cookie，发现，目前的Cookie确实是像上面第二个对话框所示的，是带乱码的：

我们现在关心的问题是，这个乱码是怎么来的？

我们先把这串文字拷贝到Notepad++中（注意，需要将Notepad++调到UCS-2编码状态下）看一下对应的字节是什么。

31是字符“1”的ASCII码。而16和01是哪来的呢？

其实是Unicode Code Point。“编码”的Unicode码是“7F16 7801”。上面显示的16和01就是截断了Unicode码高位得到的。为了证实这个结论，我又测试了好几个中文cookie，均是如此。

也就是说，Firefox的地址栏使用的是Unicode码，也就是说当你输入“mycookie=1编码1”这样的字符串的时候，Firefox看到的是：

\u006d\u0079\u0063\u006f\u006f\u006b\u0069\u0065\u003d\u0031\u7f16\u7801\u0031

在存储中文Cookie的时候，他会将Unicode的高位截断，保留低位。然后写入Cookie存储。这也是为什么我们会看到“编码”这个Cookie变成了“16 01”。

Firefox向服务端发送HTTP请求时对于http消息的编码处理方式和IE的一样，也是判断字节流能够以UTF-8进行解码，这里就不再赘述了。有兴趣的朋友可以按照上面的方法去测试。

为什么Firefox无法访问

基于上面对IE和Firefox对中文Cookie的处理方式的了解，我们现在可以知道，对于中文Cookie，IE是用ANSI编码，也就是说Cookie中永远不会出现ASCII字符集中的不可打印字符（GB2312编码每个字节也都是从A0开始的），而Firefox采用Unicode码，却又对其进行了高位截断，导致Cookie有可能会出现ASCII字符集中的非打印字符。

IE和Firefox在构造HTTP消息的时候对于字节流序列编码问题的处理方式一样。无法使用UTF-8解码的字节流序列，将其替换成EF BF BD，这个我们在Fiddler中已经看到了。而对于ASCII字符集的非打印字符则不做任何处理，直接发送到服务器端。

所以用Firefox访问，服务端收到的HTTP Request有可能包含非打印字符，而IE访问的话，则不会出现这样的情况。

例如Firefox上设置了一个中文Cookie，“我”，Unicode码是62 11，被Firefox高位截断了，就剩下11了，对应着ASCII码表中的Device Control 1，也就是控制字符。那么当你带着这个Cookie向服务端发起请求的时候服务端有可能就会直接抛出Bad Request的异常，告诉客户端，你发过来的请求不符合HTTP规范。

所以实际上不只是Cookie不能出现这样的非打印字符，其他HTTP Header中也不能出现这样的非打印字符。我们可以直接使用WFetch来构造这样的“非法”请求：

服务端一样会抛出400 Bad Request。

IIS和Apache的不同处理方式

当客户端发起的请求存在问题时，服务端的处理方式是取决于不同服务器的实现的。我们上面讨论的这个问题，实际上只会对IIS造成影响，对那些后台采用Apache或者LiteSpeed这类的服务器不会有影响。这说明IIS的容错性还是稍微差一点，不知道从安全的角度来考虑是好事还是坏事。

总结回顾

上面讲了那么多，你可能听着有点乱了。我们重新来整理一遍整个故事。

广告代理商投了一个广告，着陆页面Url中添加了google的广告参数，其中带有中文信息，客户网站上部署了GA代码，GA读取到此中文信息之后直接扔到Cookie中而没有经过编码。Firefox内部将此中文的Unicode码高位截断保留低位存下来。当你再次刷新页面的时候，Firefox把这个截断的字符发给IIS服务器，而刚好这个截断之后的字符是一个非打印字符，IIS觉得自己无法处理，就抛出一个Bad Request，告诉客户端此请求非法，我无法处理。

整个故事就这样。

怎么办呢？建议为了保险起见，如果客户网站服务器用的是IIS，那么你还是不要在Firefox上投放那些Url跟踪参数带中文（即使是UTF-8编码过）的广告了，否则可能浪费钱，因为用户来了，再点一次可能就无法访问了，而且以后可能都无法访问了（现在终于知道为什么我那同事当时用Firefox始终访问不了新东方了...）。(update:2010-7-2)或者你在投放广告的时候，Url参数中的广告系列、广告媒介以及广告来源这三个跟踪参数不要包含中文信息（即使是UTF-8编码过的），全部使用英文，这样也不会有问题。

希望整个分析过程对你有所帮助。

——Kevin Yang

你可能对下面的文章感兴趣

• 64位系统下IIS7 ISAPI处理器加载失败
• Document.Referrer丢失的几个原因
• Firefox无法访问特定网站
• Google Analytics中的Page维度
• IE中使用window.open打开新窗口时无法获取Referrer对象
• IE无法设置短域名下Cookie
• IIS中使用子目录文件作为默认文档（Default Document）替代重定向
• Javascript操纵Cookie
• Silverlight启用Assembly Caching之后铁通用户无法访问
• 【推荐】两款HTTP流量分析工具的比较

HTTP请求中有一个referer的报文头，用来指明当前流量的来源参考页。例如在www.sina.com.cn/sports/上点击一个链接到达cctv.com首页，那么就referrer就是www.sina.com.cn/sports/了。在Javascript中，我们可以通过document.referrer来获取同样的信息。通过这个信息，我们就可以知道访客是从什么渠道来到当前页面的。这对于Web Analytics来说，是非常重要的，这可以告诉我们不同渠道带来的流量的分布情况，还有用户搜索的关键词等，都是通过分析这个referrer信息来获取的。

但是，出于各种各样的原因，有时候Javascript中读到的referrer却是空字符串。下面总结一下哪些情况下会丢失referrer。

Referrer丢失的几个场景

修改Location对象进行页面导航

Location对象是一个用于页面导航的非常实用的对象。因为他允许你只变更Url的其中一部分。例如从cn域名切换到com域名，其他部分不变：

window.location.hostname = "example.com";

但是，通过修改Location进行页面导航的方法，会导致在IE下丢失Referrer。

IE5.5+ 下返回空字符串

Chrome3.0+，Firefox3.5，Opera9.6，Safari3.2.2均正常返回来源网页

window.open方式打开新窗口

示例：

<a href="#" onclick="window.open('http://www.google.com')">访问Google</a>

点击此链接会在新窗口打开Google网站，我们在地址栏中输入以下js代码就可以看到发送的referrer了。

javascript:alert(document.referrer)

测试结果：

IE5.5+ 下返回空字符串

Chrome3.0+，Firefox3.5，Opera9.6，Safari3.2.2均正常返回来源网页

如果是同个域名下通过此方式跳转的，那么我们可以通过访问windoww.opener对象去获取丢失的referrer信息。代码如下：

<script type="text/javascript">
    var referrer = document.referrer;
    if (!referrer) {
        try {
            if (window.opener) {
                // IE下如果跨域则抛出权限异常
                // Safari和Chrome下window.opener.location没有任何属性
                referrer = window.opener.location.href;
            }
        }
        catch (e) {}
    }
</script>

跨域的话则没辙了~

鼠标拖拽打开新窗口

鼠标拖拽是现在非常流行的用户习惯，很多浏览器都内置或者可以通过插件的方式来支持鼠标拖拽式浏览。但是通过这种方式打开的页面，基本全都丢失referrer。并且，这种情况下，也无法使用window.opener的方式去获取丢失的referrer了。

已测试：

Maxthon2.5.2，Firefox的FireGesture插件，Chrome3.0+，Opera9.6，Safari3.2。

点击Flash内部链接

点击Flash上到达另外一个网站的时候，Referrer的情况就比较杂乱了。

IE下，通过客户端Javascript的document.referrer读取到的值是空的，但是如果你使用流量监控软件看一下的话，你会发现，实际上HTTP请求中的Referer报文头却是有值的，这可能是IE实现的Bug。同时，这个值指向的是Flash文件的地址，而不是来源网页的地址。

Chrome4.0下点击Flash到达新窗口之后，Referrer也是指向的Flash文件的地址，而不是源网页的地址。

Chrome3.0和Safari3.2是一样的，都是会丢失Referrer信息。

Opera则和Firefox一样，Referrer的值都是来源网页的地址。

HTTPS跳转到HTTP

从HTTPS的网站跳转到HTTP的网站时，浏览器是不会发送referrer的。这个各大浏览器的行为是一样的。

例如，我们在HTTPS下使用Google Reader或是Gmail的时候，点击某个链接去到另外一个网站，那么从技术上来说，这样的访问和用户直接键入网址访问是没有什么分别的。

Referrer丢失对于广告流量监控的影响

Referrer如果丢失，Web Analytics就会丢掉很重要的一部分信息了，特别对于广告流量来说，就无法知道实际来源了。目前国内好多用了Google Adsense广告的网站，都使用了window.open的方式来打开广告链接，因此IE下会丢失Referrer，而我们知道，IE是目前市场份额最大的浏览器，因此其影响是很大的。很多流量统计工具会因此将这部分流量归入“直接流量”，和用户直接键入网址等价了。

对于这样的情况，需要让广告投放者在投放广告的时候，给着陆页面的Url加上特定的跟踪参数。

例如，某个Flash广告，点击之后到达的网址是http://www.example.com/，为了监控此流量是从哪个渠道过来的，我们可以修改此投放的着陆Url，改成http://www.example.com/?src=sina，类似这种方式，然后在着陆页面中使用Javascript代码提取此src参数，这样就可以得到广告来源信息。

在投放Google Adwords的时候，后台系统有一个“自动标记”的选项，当启用此选项的时候，Google在生成所有广告的着陆页面Url的时候，就会自动加上一个gclid的参数，这个参数能够将Google Analytics后台和Adwords广告后台的数据进行整合。这样就可以知道广告流量对应于哪个广告系列，哪个广告来源和广告关键词等信息了。和上面提到的思路其实是类似的。只不过Google自动帮你做了Url的修改了而已。

如果你发现了其他丢失Referrer的情况，或是你有其他解决方案，欢迎和我交流~

——Kevin Yang

你可能对下面的文章感兴趣

• Google Analytics中的Page维度
• IE中使用window.open打开新窗口时无法获取Referrer对象
• Javascript 中的false,零值,null,undefined和空字符串对象
• 【推荐】两款HTTP流量分析工具的比较
• 当Google Analytics、Firefox和IIS走到了一起…
• 盘点国内外不同特色的Web流量分析工具
• 高效使用Google Analytics进行Web流量分析

为了说明这个区别，我引用之前一篇文章《Google Analytics中的UniquePageView和Visit的区别》中的实验数据。

实验步骤

我在自己的网站上放了三个很特殊的静态页面，并加上了ga的代码，这样可以排除其他不必要的干扰。

• gatestpage_a.html
• gatestpage_b.html
• gatestpage_c.html

实验的几点说明：

• 为了模拟不同用户访问我的网站，我会清除掉所有的Cookie
• 为了模拟同个用户的不同会话，我会重启浏览器
• 为了保证数据能够成功发送到Google服务器，我使用HTTP Watch来监视所有发送的数据

测试访问记录（测试时间2009-12-06 21:40）：

• 用户A  会话1  gatestpage_a.html 
• 用户A  会话1  gatestpage_b.html 
• 用户A  会话1  gatestpage_b.html
• 用户A  会话1  gatestpage_c.html 
• 用户A  会话2  gatestpage_a.html 
• 用户A  会话2  gatestpage_c.html 
• 用户B  会话3  gatestpage_a.html
• 用户B  会话3  gatestpage_a.html  
• 用户C  会话4  gatestpage_a.html 
• 用户C  会话4  gatestpage_b.html
• 用户C  会话5  gatestpage_c.html

报表观察

热门内容（Top Content）报表中的Page维度

我们先来看热门内容报表中用到的Page维度。

从上面的报表中的pageview数据来看，这里的页面应该指的是所有页面的访问情况。PageView指的是页面被访问的次数，包括重复访问，而UniquePageView则剔除了重复访问的成分，一次会话只计一次，这和Visit的定义是一样的。

自定义报表（Custom Reporting）中的Page维度

上面的热门内容报表中的指标是针对单个页面的，如果我们从Page维度来看访问量（Visit）指标，结果又是怎样呢？为此，我创建了一个自定义报表。

非常简单，只有一个维度和一个指标。报表汇总结果如下：

我们可以看到，这里只列出了两个页面，gatestpage_a.html和gatestpage_c.html。这两个页面有什么特别的呢？我们回去看一下实验的步骤，发现，这两个页面均是曾经“担任”过着陆页面的角色。也就是说，在这里，我们报表中选择的“页面维度”不是列出所有页面，而是列出所有着陆页面。后面的visit指标则代表着某个页面作为着陆页面的会话数。

高级群体中的Page维度

在高级群体中，也有一个Page维度，这又是代表什么意思呢？是所有页面还是着陆页面呢？还是其他？为此我创建了一个高级群体，仅包含一个条件，Page精确匹配/gatestpage_b.html。

我们回到热门内容报表中，应用此高级群体。理所当然的我们可能会认为报表中只会列出b页面的数据。

但是我们看到，报表并不是只列出了b页面的数据，其他页面的数据也有，只不过发生了一些差异。我们回过头去对比一下这里的数据和上面写的实验步骤，我们就可以得出结论，这时候看的内容，其实是b页面和b页面相关页面的报表。

如果用户没看过或者不理解我之前文章中提到的高级群体的过滤方式的话，那么可能不会容易理解这里看到的数据。

我们再将此高级群体应用在之前创建的自定义报表上面：

我们看到，报表中只列出了gatestpage_a.html页面，visits数据为2。对比实验步骤，我们就知道，这里看的内容，是访问过b页面的所有会话的着陆页面报表。

也就是说，在高级群体这里的“页面维度”，实际上也是代表“所有页面”的意思。

希望此文章能够帮你更好的理解Google Analytics工具。

——Kevin Yang

你可能对下面的文章感兴趣

• Analysis Services：你应该使用多对多维度吗？
• BIDS对于维度属性键为可变长列时存在的Bug
• Document.Referrer丢失的几个原因
• 当Google Analytics、Firefox和IIS走到了一起…
• 盘点国内外不同特色的Web流量分析工具
• 解决维度成员中的非法Xml字符导致的查询错误
• 高效使用Google Analytics进行Web流量分析

网站流量分析对于互联网企业来说非常重要。网站技术人员需要数据来告诉他用户对本网站的反馈，进而对网站页面内容以及业务流程进行改版；市场营销人员需要数据来帮助他量化不同渠道的广告效果进而调整媒体广告的投放策略，而老板呢，他可能仅仅想了解互联网是怎么给他带来收益的。

互联网企业与传统企业最大的一个不同点在于，企业和用户之间并不是面对面交流的。用户来到你的网站，你看不到他在干什么，你不知道他有什么想法。Web流量分析之所以重要，是因为Web流量分析能够帮你把Web上的未知变成已知，用数据描绘出用户的想法，进而用来支撑你做出的决策。

Web流量分析流程

Web流量分析要做的事情非常简单，收集所有网站流量数据，根据某一类特征筛选出你关心的那部分流量，分析此流量的性能指标，综合对比其他流量，然后做出决策。下面的图示很好的说明了这一点。

目前市面上已经有很多Web流量分析工具了，他们之间除了收集数据的完整程度不同之外，最大的区别就在于能不能帮助你快速筛选出你想看的数据。Google Analytics是流量统计工具中功能非常强大的一款，而且还是免费的。它提供了很多数据筛选和分析手段，高效使用这些手段，能够帮你将流量数据的利用率最大化。

Google Analytics中的六大数据分析手段

内置报表

Web流量分析通常需要回答以下4个基本问题：

• 访客特征——谁访问了你的网站
• 访客来源——他们从哪里来到你的网站
• 访客行为——他们到达你的网站之后都做了什么
• 访客质量——他们是否完成了你预期的目标（KPI转化）

Google Analytics中预置了很多常用的报表，涵盖了上述4个基本问题，可以满足大部分人的常规需求。

访问者类型的报表可以告诉你的，你的用户都喜欢使用什么样的浏览器访问你的网站，你的用户都是哪些国家省市的，新老用户各占多少比例，他们访问有多频繁，等等。

流量来源类型的报表可以告诉你，你的用户群中直接键入网址（或者通过收藏夹）、通过推介网站还有搜索引擎来的各占多少比重，付费和免费的流量各是多少，用户搜索什么词来到你的网站的，等等。

内容类型的报表则告诉你，你的用户来到你网站之后都喜欢看哪些页面，他们喜欢点页面上的哪些链接，他们在你网站上搜索什么（如果你的网站有站内搜索的话），他们还做什么其他什么操作（事件跟踪），等等。

目标类型的报表则告诉你，用户最终有没有达到你的期望行为，例如停留时间超过10分钟，成功注册了会员身份，在你网站上购买了商品，等等。

如果你的网站是电子商务类的网站，那么还有专门针对商品信息的报表。

熟悉内置的各类报表的意义，能够使你快速了解你的用户群。

自定义报表

内置报表有时候和我们最终想要的报表有些偏差，例如少了某个我特别关心的指标，或者剖析路径不是我期望的，这个时候，自定义报告就很有用了。

自定义报表能够让你选择你关注的指标以及想分析的维度，这样你就不用受限于内置报表了。

不过，GA中维度和指标之间是有一定的约束关系的，也就是说，你并不是真的可以选择任意维度和指标的组合来生成最终报表。例如当我们选择了指标“唯一身份综合访问量”的时候，我们就不能再选择“跳出率”指标了，选择“网页”维度就无法选择“广告内容”、“安插广告”等维度了。这个可能是和GA后台架构的设计有关。

快速过滤器

当我们看报表的时候，有些维度可能下面成员（指标、维度、成员，这些都是商业智能方面的专业术语，你可以把成员理解为一个一个的条目即可）数目非常多，例如看“热门内容”报表的时候，会列出非常多的网页。例如像我这么小的博客，用户访问过的独立页面就有590个.

如果需要快速从这590个网页中定位到自己想看的内容，那么我们可以应用每个报表底部的快速过滤器。

我们可以输入过滤的字符串，“visual-studio”

需要注意的是，这里快速过滤器要求输入一个正则表达式。大多数人可能不知道这一点。特别是当你尝试过滤Url的时候，你很可能会输入带问号的过滤字符串，例如“search?q=cache”，你期望过滤出Google缓存页面的Url，结果出现：

这是因为？号是正则表达式中的特殊符号，不能直接这样使用。

当你输入一个非法的正则表达式的时候，GA会提示你

可能这个时候你才会意识到这里支持的是正则表达式，而不能输入普通的文本。

之前一个同事要我给他定制一份每日热门内容报表，但他要求只看某些特定页面的数据。例如：

• /products.asp?columnid=253
• /products.asp?columnid=254
• /products.asp?columnid=255
• /products.asp?columnid=258
• /products.asp?columnid=1053
• /templates/products.asp

列表太长了，我就不全部列出来，要在热门内容报表中过滤出一批特定页面的数据来，最简单的做法，就是通过这里的快速过滤器，写一个正则表达式涵盖上述这些特定页面。

(/products.asp?columnid=(253|254|255|258|1053))|(/templates/products.asp)

高级过滤器

在报表底部的快速过滤器一栏，我们还可以看到有个“高级过滤器”的按钮，这是GA在09年加入的新功能。点开“高级过滤器”，你可以看到以下编辑界面：

高级过滤器有什么高级之处呢？在这里，你除了可以对维度成员进行过滤（就像上一节讲到的快速过滤器一样）之外，你还可以根据当前报表中的指标进行条件筛选。例如，你想看包含“正则”字符串、并且跳出率小于30%的所有用户搜索关键词，那么你可以按照上图中的设置去过滤。

高级群体

上述的快速过滤器和高级过滤器只能应用在当前报表中，也就是说当你切换到另外一张报表的时候，过滤器就失效了，如果你需要在各个报表中共享此过滤条件的话，那么你可以使用“高级群体”特性。

高级群体的界面和上面一节中说的高级过滤器类似。你可以选择维度作为过滤条件，也可以选择指标作为过滤条件。

只不过在这里，你可以使用的条件更多，不用受限于你所看的报表。上一节中讲到的快速高级过滤器中，你只能针对当前报表中用到的维度和指标进行过滤，并且过滤条件之间都是And的关系，无法指定更灵活的逻辑关系。在高级群体设置中，你可以使用or和and来构造你想要的逻辑表达式。

但是高级群体和上述过滤器在过滤数据的方式上还有一个非常大的区别，如果你不理解这个区别的话，那么你很容易对过滤之后得到的报表产生迷惑。

在上面的快速高级过滤器中，我们的过滤条件都是针对每个维度成员，例如浏览器维度的firefox、ie6、ie8等成员，这里过滤的手段是，遍历每一个维度成员，然后判断每个维度成员的名称是否符合用户设置的维度条件，例如关键词维度成员中含有“silverlight”字符串的；或者，判断每个维度成员的某个指标是否符合用户设置的指标条件，例如关键词维度成员中跳出率小于50%，停留时间>10秒的，等等。

而在高级群体中，我们的过滤条件都是针对每个会话的。页面访问（PageView），会话（Session）和访客（Visitor）是Web分析的三大核心概念。这里不做特殊解释，如果有不清楚的，可以参考GA帮助文档。高级群体过滤的手段是，遍历所有的会话，然后判断会话的特定维度是否符合用户设置的维度条件，或者，判断单个会话的指标是否符合用户设置的指标条件。

例如找出所有浏览器名称包含“ie”字符串的会话，或者停留时间>10秒的会话，等等。一定要注意，这里针对的是会话。当你使用此高级群体看报表的时候，实际上会先选出符合条件的所有会话，然后在这些会话的基础上进行报表的汇总。下图展示了高级过滤器（快速过滤器也是类似的）和高级群体在过滤上的不同。

配置文件数据过滤器

上述说到的几种数据过滤方式都是针对报表的，你所做的任何过滤手段都不会影响底层的数据。而在配置文件级别上设置的过滤器，是会真正影响底层数据。Google在将数据导入到数据仓库之前会先应用这里设置的各种过滤器。过滤器主要有两个作用：

1. 决定数据的取舍

2. 修改数据

数据取舍指的是根据用户设定的一系列条件来决定数据是否展示给最终用户。你可以使用GA预定义的常用过滤器，例如排除来自某个特定IP的流量，仅包含某个特定域的流量，等等。你可以用它来过滤掉垃圾流量。

如果预定义的过滤器不能满足你的需求，那么你可以使用自定义过滤器。

在这里，Google直接把底层各种数据字段暴露出来，你可以选择任意一个字段，例如用户请求的Url，然后写一个正则表达式进行模式匹配。满足要求的，你可以选择保留下来或者排除在外。

GA不但允许你筛选数据，还允许你修改或者合并数据。例如请求Url中可能包含了一些GA无法识别的广告跟踪参数，这样看热门内容报表的时候，同一个页面就会显示为多个Url，这不是我们期望看到的。那么我们可以使用上图中自定义过滤器的“搜索和替换”选项。选择“请求URI”，然后写正则表达式将此跟踪参数替换成空字符串即可。

又或者，我们可能希望取几个不同字段中的部分内容，然后将其拼接成一个新的字段。那么你可以使用上图中自定义过滤器的“高级”选项。

在上图中，我将访客的操作系统和浏览器合并到“浏览器”字段中，这样，以后我看“浏览器”报表的时候，就不是看到ie6，ie7这样的数据了，而是看到"Windows xp : ie6”,"linux:firefox”这样的数据。

注意，在配置文件上设置的过滤器，只会影响新数据，旧数据不会受此影响。

在配置文件上新建的过滤器非常适用于创建数据的不同视图。例如，我有三个域名（同一个根域），上面埋的GA代码都是一样的，但是不同域可能由不同的同事来负责，因此你可以新建三个一样的配置文件（创建的时候，选择从已有的域中创建，这样新的配置文件就和旧的配置文件使用同一份跟踪代码），然后应用不同的过滤器，这样看到的数据就不一样了。

OK，Google的几大特色数据过滤功能都已经介绍完毕，希望对那些还不熟悉Google Analytics的人能有所启发。如果你使用Google Analytics有什么其他心得，也欢迎大家一块交流~

——Kevin Yang

你可能对下面的文章感兴趣

• 4行Greasemonkey代码最大化Google Reader的阅读空间
• Android手机初体验
• Document.Referrer丢失的几个原因
• G1手机与笔记本实现Wifi互联共享上网
• Google Analytics中的Page维度
• Google Analytics中的UniquePageView和Visits的区别
• Google Wave为什么这么火
• Google和微软的一大不同
• Google工程师Matt Cutts谈SEO
• Google排名更新