这有什么区别？

有的童鞋可能会说，这有什么难的，只要在两个网站上都部署了网站分析工具的跟踪代码，用相同的帐号或者ID，两个网站的数据不就会整合到一起吗？但实际的情况没有这么简单。

我们访问网站的时候，是通过HTTP协议，而HTTP协议是一种无状态的协议。换句话说，当你访问一个页面的时候，服务器不会记得你是谁，你之前看过些什么页面。为了能够记录一些重要的信息，HTTP中专门定义了Cookie的概念。Cookie可以用来在浏览器中记录一些信息。为了保护隐私，Cookie中的信息是加密存储，并且是属于特定的域名的，只有这个域名才能够读写。

所以，当两个网站下的Cookie都属于各自的 域的时候，也就是都使用第一方Cookie的时候，A网站和B网站虽然都能被监控到，但他们之间是没有关联的。因为A网站和B网站会分别有两个Cookie，而这两个Cookie存储的用户的ID也是不同的。

这样会有什么问题？

首先，同一个访问者在两个网站上产生的行为无法产生关联，就像文章开头那里的例子，我们无法知道链接到A网站的广告对最后B网站上的购买贡献有多大。这对很多两个关联很紧密的网站的分析来说是致命的。其次，网站分析工具的测量结果将不正确。因为不同的域名各有一个Cookie，网站分析工具会在这两个Cookie中存储分配的两个不相同的用户ID，当一个用户在一次访问中浏览了两个网站，则会产生两次Visits和两个Visitors。

那网站分析到底如何进行跨域名的跟踪呢？

关于这个问题，有趣得紧，网站分析工具中大名鼎鼎的两个，Omniture的SiteCatalyst和Google Analytics，分别给出了两个不同的答案。让我们看看他们分别是如何工作的吧。

先说说Omniture的SiteCatalyst的解决方案

SiteCatalyst默认情况下使用的是第三方的Cookie，Cookie的域是Omniture数据接收服务器的域名。也就是说，不管你把SiteCatalyst装到多少个网站上，使用的Cookie的域都是同一个，不会发生变化。这就保证了，在不同网站上使用同一个Cookie。SiteCatalyst就能够知道不同网站上的访问是否来自同一个访问者。

不过SiteCatalyst使用的第三方Cookie的接受率相对第一方Cookie略低，准确度会有影响。所幸国内网民对隐私的保护并不重视，两种Cookie的接受率差异很小。

再来看看Google Analytics是如何解决的

Google Analytics是使用第一方Cookie的，Cookie的域都是被监控的网站的域名，所以各个域名之间是无法关联的。针对跨域跟踪的这种情况，Google Analytics提供了一组函数。在部署的时候，所有遇到域名之间跳转的情况，不管是链接、表单提交还是框架等，都需要加入特定的代码。可以参考Google Analytics的官方文档。那么它的工作原理是什么样的呢？当我们第一次访问网站A的时候，这个网站上部署的Google Analytics的代码会在保存一些Cookie，记录包括在Google Analytics中唯一标识这个用户的ID在内的信息。当点击一个链接到网站B的时候，在链接上的特定代码会做一个处理，将网站A中的Google Analytics的Cookie的指都取出来，作为参数传递链接的目标页面。目标页面上的Google Analytics的代码会把这些值放置到自己Cookie中。这样以来，即使两个域名还是使用两个Cookie，但Cookie中的信息是一致的，Google Analytics还是可以认定跨越两个域名的访问是否来至同一个访问者。

Google Analytics的优点在于使用第一方Cookie所带来的更高的接受率。缺点也显而易见，因为需要在所有网站间跳转的地方增加额外的代码，增加了部署和维护的难度和成本。

快速链接

你之前有过这样的经历吗？在SiteCatalyst的后台中，建立了报表，进行了各种设置，各方面都很满意。然后，你打算把这个报表和公司的其他平时不使用SiteCatalyst的同事分享。这个同事并不熟悉SiteCatalyst，你需要告诉他如何登录SiteCatalyst的后台，然后再教他如何打开某个报表等等，很麻烦，不是吗。有可以采用功能板（Dashboard）和书签（Bookmark）再共享的办法，同样很麻烦，需要告诉你的同事如何找到这份报表。也许，将报告通过Email发送给对方是个不错的办法，不过他收到Email后不能作一些设置，比如增加量度、排序等。

SiteCatalyst新的快速链接的功能，可以很好的帮助你将你的报表共享给其他人。生成快速链接，只要在配置好报表以后，点击工具中的“此报表的链接”按钮，则会生成一个简短的快速访问链接就可以。

然后把这个链接分享给其他人，别人就可以通过这个链接快速的定位到你所制定的报表。

更新功能板（Dashboard）中的缩图报表

在此更新以前，针对已建立好的功能板，需要修改过滤条件或者调整显示的量度，所需的操作效率比较低：

1. 打开功能板
2. 打开缩图报表到完整的视图
3. 做需要的修改
4. 点击增加到功能板的按钮
5. 对缩图报表作必要的设置
6. 确认并等待功能板打开
7. 删除旧版本的缩图报表
8. 把新版本的缩图报表移动到正确的地方

更新以后，我们只需要：

1. 打开功能板
2. 打开缩图报表到完整的视图
3. 做需要的修改
4. 点击新的更新按钮，更新功能板中的缩图报表。

你还有什么新的发现，给我留言吧！

网页加载时间的数据，可以分析些什么呢？网页加载的时间越长，说明用户连接到服务器的速度越慢。访客一般都是缺乏耐心的，如果5、6秒钟还不能加载页面，他们就开始考虑关闭这个浏览器的窗口了。再细化到不同的地域分析，那么可以考虑在打开速度慢的地方增加镜像服务器。如果各处加载页面都很慢，那就可以看是不是服务器端的接入和本身负载的问题了。

那应该如果做才能跟踪到这个数据呢？这需要一点JavaScript的代码。

首先在页面的HTML的头部，记录一个时间：

var date = new Date();
var startstamp = date.getTime();

然后，在底部，在得到一个时间，两个时间的差值，就是页面打开的时间了：

date = new Date();
var endstamp = date.getTime();
var interval = endstamp – startstamp;

我们只需要知道一个大的范围，不用很精确，所以做如下的判断：

var scope;
if(interval<50) {
scope = “0 – 50 ms”;
}
else if(interval < 100) {
scope = “50 – 100 ms”;
}
else if(interval < 200) {
scope = “100 – 200 ms”;
}
else if(interval < 500) {
scope = “200 – 500 ms”;
}
else if(interval < 1000) {
scope = “500 – 1000 ms”;
}
else if(interval < 2000) {
scope = “1000 – 2000 ms”;
}
else {
scope = “2000+ ms”;
}

最后，要用到Google Analytics的_setVar()函数，把值放到User Defined报表中：

pageTracker._setVar(scope);

如果你在使用Omniture的SiteCatalyst也没有问题，只要建立两个自定义变量来跟踪就可以了：

s.propx＝scope;
s.eVarx=s.propx;

修改好了，就等着看报表吧：

站内搜索的分析有些什么意义呢？

1. 了解用户需求

   通过对用户搜索的关键字进行分析，可以精确的了解用户的需求。很多网站会精心设计调查问卷，期望了解用户的需要，会通过访问路径来分析用户的心理，那么，用户在站内搜索中输入的关键字这样直接体现用户需求的机会当然不应该忽视。
   对于新闻为主的媒体类网站，可以了解到用户关心的热点新闻是哪些？对于某些非常热点的新闻，是不是需要考虑增加不同角度的更多报道，甚至可以制作一个专题。对于电子商务类网站，可以了解用户都喜欢什么样的产品，可以考虑是不是可以在搜索框附近列出这些热门的搜索关键字，对一些用户搜索较多的产品，可以考虑在首页通过Banner、Flash等形式做一些内部的推广，对网站暂时还没有的产品，可以考虑设计生产。

2. 站内搜索功能优化

   想象一下，我们现在新开张了一个服装类的电子商务网站，专门在线零售时尚的男女服装。网站上实现了站内搜索的功能，能够对产品名称进行模糊的查询。运营了一段时间，通过分析报告，我们可能会发现，用户很多时候不一定是搜索具体的产品，而是搜索一些服装的风格，比如“百搭”、“可爱”这种关键词。这时因为产品名称中不会包含这类的关键词，会出现没有结果的搜索，那这部分用户很多就可能因为没有找到合适的款式而放弃了购买。
   发现了这个情况，我们改良了设计，对产品增加了描述性的语句，在搜索的时候会对描述性的语句进行查询。那么，很多本来没有结果的关键词，因此能够匹配到合适的产品，整个网站的转换也因此有提高。我们再深入分析，也许又会发现，有一些产品，用户浏览了这些产品的产品详细页，了解产品的详情，最后达成购买的比例比较大，而另外一些产品，可能被浏览的次数很多，但是真正销售的情况却不佳。
   撇开产品详细页的设计不谈，我们这里也可以针对这些产品的差异，对站内搜索再进一步优化。我们现在站内搜索的排序是按产品名称排序的，很糟糕的排序，对吧？有一些产品，可能只要用户找到它，就比较容易卖出去，却排在了几页以后。我们调整了搜索结果的顺序，越容易卖的产品排在前面。这样，站内搜索对销售的贡献又应该有所增强。

3. SEO和SEM优化

   站内搜索的关键词，对SEO和SEM也有借鉴的意义。用户在网站内部搜索中使用的关键词，反映了用户寻找目标的思路和想法。同样的，在使用搜索引擎的时候，多半也会使用类似的关键词。我们通过分析工具，了解到，一些站内搜索的关键词效果很好，能够带来很多的销售，那么在做SEO和SEM的时候，可以针对这些关键词进行优化。这种有依据的SEO优化和SEM的投入，肯定比盲目的选择有更好的效果。

站内搜索功能如何实现？

1. 使用Omniture的SiteCatalyst

   SiteCatalyst默认的报表并没有对站内搜索的支持，不过SiteCatalyst有很强的自定义扩展能力。在SiteCatalyst中，可以在搜索结果页面上设定一个自定义的变量，用来记录搜索的关键词。同时，根据是否有搜索结果触发两个自定义的事件，就可以跟踪到关键词被搜索的情况，以及后续对转换的贡献。

2. 使用Google Analytics

   Google Analytics要实现站内搜索的支持，也需要一些设置。
   

在Google Analytics中后台中，修改配置文件。根据网站的实际情况，设置传递查询关键字的参数。比如在我的这个网站分析博客，使用的是“s”作为参数。只要在对应的地方填入参数，保存后即完成设置。之后只要保证在搜索的结果页面上已经部署了Google Analytics的代码，搜索的关键词就会出现在报告里。