Google Analytics的愁：跳转页面的监测和嵌套页面的监测
.jpg)
【导语】我们每个人都喜欢Google Analytics，这个无价格的工具带给我们太多价值。但是，这不能说GA总是能够带给你快乐，事实上，GA同样有它自己的“忧愁”。在这个文章中，将展示GA在跳转页面和嵌套页面的监测，并看看GA在这两个情况中到底是如何让我们“郁闷”的。
在GA网站分析监测代码实施的时候，大家可能都遇到过跳转页面（redirect，或称重定向页面）和嵌套页面（frame or iframe）的情况，这两类监测如果稍有疏忽，就可能给我们带来一些意想不到的监测结果。我相信很多朋友们会有类似的经历——如果你也遇到了一些意想不到的情况，请在留言区跟我们一起分享。如果你有问题，也欢迎提出，朋友们的问题总是能启发我写一些新的博客文章。
-
如何用GA监测跳转页面
在很多情况下，我们要使用跳转页面，例如，我们在做某种产品的线下推广的时候，要在广告上放一个短域名：www.example.com/product，以帮助用户更容易的记住这个域名。然后让这个短域名跳转到真正的这个产品的长域名上（往往有很多个目录层级并且带有很多参数），实现对产品相关信息的访问。
页面的跳转分为两类，不同类别的跳转，GA的监测方法会有不同。这两类是：
[版权归作者Sidney Song所有，欢迎转载，但请事先告知作者并注明出处]
- 网站服务器端的重定向，浏览器不下载（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的跨域监测。
这样，我们就比较完善的监测到了跳转前页面和最终页面的情况了。
[版权归作者Sidney Song所有，欢迎转载，但请事先告知作者并注明出处]
那么，麻烦在哪儿呢？请大家考虑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大小影响）都会因此而不再准确，这对我们最终分析数据带来了不大不小的一些麻烦。
如何解决这个问题？我想，如果没有必要，不监测跳转前页面就是最直接的办法。但是问题又来了，如果我们不监测跳转前页面，而一旦有不同的traffic先经由跳转前页面才访问最终页面的话，那么我们将无法在traffic source report中看到这些不同traffic的信息，因为它们首先访问的是跳转前页面，结果相关的traffic source / refferal信息都被记录成为跳转前页面了。——这是一个首尾难顾的局面。
还有别的解决方法吗？我们既想保留traffic source，又想准确记录bounce rate，page view，PV/V以及time on site等等metrics，我们能做到吗？我猜想GA的filter功能可以实现，但我没有亲自做实验，有朋友做过相关的实验吗？或者还有其他更好的方法？希望不吝赐教。
-
如何监测嵌套页面？
监测嵌套页面是我认为最大的麻烦。这个麻烦并不是我们在监测实施上的，而是工具本身仍然需要改进，或者是我自己对这个工具的了解仍然有限。首先还是看看如何监测嵌套页面，再看看我遇到了什么问题。
嵌套页面分为frame和iframe两种，后者具有更大的灵活性，但我认为它们本质上其实是一样的。GA官方的对于嵌套页面的监测方法是：
- 在嵌套的父页面（或称框架页面，frameset页面）的<head>…</head>中加入GA代码；
- 如果你想要监测到嵌套的子页面（child frame页面），那么你需要在它的<body>…</body>中加入GA代码；
- 如果嵌套页面跨域或者跨子域，当然，我会建议你做相关的跨域处理。
上面的方法可以看到，监测实施本身并不复杂。但是，监测数据会出现与浏览器端重定向的监测监测类似的问题，相信你已经看出来了。是的，没错，嵌套页面是在载入网站页面的时候，一下子打开两个或者更多个页面，这个时候，页面的PV和bounce rate立即受到影响。如果是一个父页面嵌套三个子页面的情况，那么打开这个页面，PV不是增加1，而是增加4，bounce rate也会非常低。受此影响，整个网站的大部分数据都会急剧变化，以至于我们不得不反复判断和筛查，到底哪些数据属于父页面，哪些属于子页面，整个网站的数据也需要重新计算（当然，这是不可能的任务）。这的确令人发愁。
[版权归作者Sidney Song所有，欢迎转载，但请事先告知作者并注明出处]
对于metrics因为嵌套页面而无法准确监测的问题，GA也在官方的帮助文档中有所阐述。
在我的工作中，我会强烈建议，除非万不得已，不要使用嵌套页面。而如果的确必须使用嵌套页面，我会建议选择重要的一个页面，父页面或者是某一个子页面进行监测，而不要试图监测整个嵌套结构。我曾经看到过我的客户因为极低的bounce rate而狂喜，最终当我告诉他我们因为嵌套而无法获得真正准确的bounce rate时，客户的失望之情溢于言表。
对于这两个领域，不知道大家有没有更好的办法，或者你们早已攻破难关——极度期盼大家能够畅所欲言，各抒己见。谢谢！
嵌套页面现在基本被blog、论坛代替了吧，可以基本忽略了～
回复(Reply)
我的思路是，要正确跟踪浏览器端重定向，需要修改ga.js代码。在跳转代码的那个页面上，把该页面的referrer作为参数传递，在跳转后的页面，得到这个参数，然后在ga.js中替代document.referrer。
回复(Reply)
还有别的解决方法吗？我们既想保留traffic source，又想准确记录bounce rate，page view，PV/V以及time on site等等metrics，我们能做到吗？我猜想GA的filter功能可以实现……
____________________________________
没想到怎么用filter实现
想到一个做法，笨了一点，不过能实现你的需求。
为跳转前页面单独嵌入另一套统计代码，在这个profile里查看traffic source。这样主profile的各项metrics就不会受到影响，去另一个profile又能查看traffic source了。
对于嵌套页面的监测，还有一个无法解决的问题，GA监测到的嵌套产生的流量远远低于其他统计工具（比如WebTrends）的数字，而且是数量级方面的差异，有时会达到十倍以上。这种数据差异并不是不同统计工具间正常的差异，比如，GA其他Traffic source的数据会比WebTrends少10%左右，但来自嵌套渠道的流量就会少得可怕。
回复(Reply)
回楼上的,你的方法并不能完全监测到准确的量,具体的可以看一下泡泡网或者zol,他们的框架跳转很有意思
回复(Reply)
Great post SX. I especially like the [版权归作者Sidney Song所有，欢迎转载，但请事先告知作者并注明出处] part.
You spend so much time on these post, you should be able to get the rewards “traffic”. Go kick ass
回复(Reply)
没用过这两个功能，不知好不好用。
回复(Reply)
我遇到一个网站是用shtml的#include把其他网页文件调进来，这种情况GA代码应该怎么添加呢？
回复(Reply)
[...] 客户端浏览器上发生的跳转相对而言要容易一些，由于浏览器端的跳转存在一个额外的空白页面，因此你可以把监测代码加在这个空白页面上，这样，Referrer的信息是可以被正常记录下来的。不过这个方法存在的问题在于，由于跳转前后两个页面都有代码，而且跳转是自动发生的，因此GA代码会在短时间内执行两次，造成bounce rate非人为原因的急剧偏低，即bounce rate无法正常监测。关于这一点，请见我之前的文章。 [...]
[...] 客户端浏览器上发生的跳转相对而言要容易一些，由于浏览器端的跳转存在一个额外的空白页面，因此你可以把监测代码加在这个空白页面上，这 样，Referrer的信息是可以被正常记录下来的。不过这个方法存在的问题在于，由于跳转前后两个页面都有代码，而且跳转是自动发生的，因此GA代码会 在短时间内执行两次，造成bounce rate非人为原因的急剧偏低，即bounce rate无法正常监测。关于这一点，请见我之前的文章。 [...]
Leave your response!
最近文章
最近评论
标签
分类目录
文章存档
链接
最新文章
Most Commented
最新评论
备案/许可证编号为: 京ICP备09063066号