繁體中文当前位置: 首页 > 图文教程 > 网站运营 > 建站经验 > Google Analytics的愁：跳转页面和嵌套页面的监测
- 建站经验
- 推广经验 利用QQ推广网站的方法
- google 恶意软件网站 警告后 怎么办
- 站长浅谈 运营网站切勿盲目跟风
- 远离垃圾站 做一个有用的站 让人们需要你
- 站长想把网站做好需要专心
- 让百度蜘蛛认为你的网站是一个好网站
- 企业网站 建设目标分析
- 问答推广的实施步骤与问答推广方法和技巧
- SEO B2B行业网站优化经验
- 搜索引擎算法调整和被搜索引擎惩罚的解决方法
- 选择不知名网站源码来建站选择技巧
- digg 创始人经验分享 发展网站用户的9个方法
- 智能查询域名的10个国外网站
- 成功网站的法则 简单的直击人最基本需求
- 网站 邀请机制的使用说明
- 成功网站=充实的内容+勤奋的站长+运气
- 网站内容的主动组织和展示技巧
- 百度K站和降权原因大收集 看看你占了哪一条
- 网络媒体 让资讯与服务融为一体
- 网站运营 SNS社区产品设计思想
建站经验 中的 Google Analytics的愁：跳转页面和嵌套页面的监测
出处:互联网 整理: 软晨网（RuanChen.com） 发布: 2009-10-17 浏览: 160 ::
收藏到网摘: n/a
【导语】我们每个人都喜欢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大小影响）都会因此而不再准确，这对我们最终分析数据带来了不大不小的一些麻烦。
如何解决这个问题？我想，如果没有必要，不监测跳转前页面就是最直接的办法。但是问题又来了，如果我们不监测跳转前页面，而一旦有不同的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也会非常低。受此影响，整个网站的大部分数据都会急剧变化，以至于我们不得不反复判断和筛查，到底哪些数据属于父页面，哪些属于子页面，整个网站的数据也需要重新计算（当然，这是不可能的任务）。这的确令人发愁。
对于metrics因为嵌套页面而无法准确监测的问题，GA也在官方的帮助文档中有所阐述。
在我的工作中，我会强烈建议，除非万不得已，不要使用嵌套页面。而如果的确必须使用嵌套页面，我会建议选择重要的一个页面，父页面或者是某一个子页面进行监测，而不要试图监测整个嵌套结构。我曾经看到过我的客户因为极低的bounce rate而狂喜，最终当我告诉他我们因为嵌套而无法获得真正准确的bounce rate时，客户的失望之情溢于言表。
对于这两个领域，不知道大家有没有更好的办法，或者你们早已攻破难关——极度期盼大家能够畅所欲言，各抒己见。谢谢！
作者：Sidney Song 出处：网站分析在中国
原文：http://www.chinawebanalytics.cn/?p=794
评论 (0) All
