Google Analytics的愁：跳转页面和嵌套页面的监…

【导语】我们每个人都喜欢Google Analytics，这个无价格的工具带给我们太多价值。但是，这不能说GA总是能够带给你快乐，事实上，GA同样有它自己的“忧愁”。在这个文章中，将展示GA在跳转页面和嵌套页面的监测，并看看GA在这两个情况中到底是如何让我们“郁闷”的。

在GA网站分析监测代码实施的时候，大家可能都遇到过跳转页面（redirect，或称重定向页面）和嵌套页面（frame or iframe）的情况，这两类监测如果稍有疏忽，就可能给我们带来一些意想不到的监测结果。我相信很多朋友们会有类似的经历——如果你也遇到了一些意想不到的情况，请在留言区跟我们一起分享。如果你有问题，也欢迎提出，朋友们的问题总是能启发我写一些新的博客文章。

如何用GA监测跳转页面

在很多情况下，我们要使用跳转页面，例如，我们在做某种产品的线下推广的时候，要在广告上放一个短域名：www.example.com/product，以帮助用户更容易的记住这个域名。然后让这个短域名跳转到真正的这个产品的长域名上（往往有很多个目录层级并且带有很多参数），实现对产品相关信息的访问。

页面的跳转分为两类，不同类别的跳转，GA的监测方法会有不同。这两类是：

网站服务器端的重定向，浏览器不下载（render）任何最终页面前的页面（以下称跳转前页面），例如301（永久）重定向或者非永久性的302跳转。

第二种重定向/跳转时在浏览器端完成的，例如在跳转前页面中有一段javascript的代码负责让这个页面在一定时间内（通常是极短的时间内）跳转到下一个URL的页面上去。

1. 服务器端重定向的监测

对于第一种情况，由于这种重定向并不存在一个跳转前的页面，而是我们俗话说的“URL的跳转”，因此，从GA加入代码的角度看，我们只能把GA代码加入到跳转后的最终页面上去。例如，如果www.example.com/product自动301重定向到了www.example.com/product/aspirin/？sid=123abc，那么我们不可能加入任何代码到www.example.com/product之中，而只能够把代码加入到www.example.com/product/aspirin/？sid=123abc之中去。那么，我们怎么才能知道有多少流量是通过访问www.example.com/product来到了我们的产品介绍页面的呢？

对于这个问题，实际上我们不需要对GA的监测代码做任何的定制就能实现。因为，GA会认为www.example.com/product是你被监测的产品页面的referral。这样，你通过查看referral report （在traffic source目录下）就能找到www.example.com/product的被访问量。

如果你有多个渠道的在线推广，如同在我的这个博文中所谈到的情况，你可能会一次建立多个“短URL”，例如：www.wac.cn/1; www.wac.cn/2; www.wac.cn/3，你当然还是可以通过referral report来查看各个短URL分别带来的流量。或者，你可以做的更精确一些，利用我们前面提到的UTM Tags来标识不同的短URL。比如，你可以把www.wac.cn/1的跳转目标URL（也就是跳转后的最终页面的URL）后加上UTM Tags，这样，在content目录下的campaign报告中就会显示相应渠道带来的流量，具体的添加方法请参加我的这篇文章：用Google Analytics的Link Tag深入了解流量来源（广告）的质量。请注意，不要弄混淆了，UTM Tags不是在www.wac.cn/1上加，而是设置在www.wac.cn/1跳转的目标URL上。

总体而言，这种重定向的GA监测是最简单的，也不会产生太大的问题，我喜欢这种重定向。

2. 浏览器端重定向的监测

浏览器端的重定向容易给我们带来麻烦，麻烦的程度取决于你的监测需求。

如果你只需要监测重定向之后的最终页面，而不想了解任何关于跳转前页面的情况，那么只需要在最终页面加入代码即可。这个情况类似于服务器端的重定向，跳转前页面会被认为是referral而被记录在traffic source的referral报告中。

可是，如果你想要监测跳转前页面的情况，这就有点儿麻烦了。首先，让我们看看为了实现监测需要做些什么：

在跳转前页面中加入GA代码，并且GA代码一定要在实现跳转的程序语句（例如实现跳转的JavaScript语句之前）；

设定实现跳转的JavaScript语句延迟执行至少1秒钟，2秒钟更理想；

同样，也要把GA监测代码加入到跳转后的最终页面中；

如果最终页面跟跳转前页面有跨子域（span multi-subdomains）的关系，最好设置GA的跨子域监测。如果最终页面跟跳转前页面有跨域（span multi-domains）的关系，那么当然最好设置GA的跨域监测。

这样，我们就比较完善的监测到了跳转前页面和最终页面的情况了。

那么，麻烦在哪儿呢？请大家考虑bounce rate。我们知道bounce rate的定义是single access / all entries，可是如果页面发生跳转，且跳转前后的页面访问都被监测下来，那么无论访问者是否点击了页面上的链接，这个用户的访问都不会再被计算为一个single access，也就没有可能会被计算为bounce。因此，通过这种方法监测跳转页面，bounce rate经常会低的惊人，也就不再具有指导意义了。同样，因为跳转，page view（一般我们都不认为跳转前页面算一个真正有效的页面访问），page view / visit，navigation summary以及time on site（time on site直接受bounce rate大小影响）都会因此而不再准确，这对我们最终分析数据带来了不大不小的一些麻烦。