Google Analytics的愁:跳转页面的监测和嵌套页面的监测

【导语】我们每个人都喜欢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时,客户的失望之情溢于言表。

  对于这两个领域,不知道大家有没有更好的办法,或者你们早已攻破难关——极度期盼大家能够畅所欲言,各抒己见。谢谢!

未经允许不得转载:版权归宋星及chinawebanalytics.cn所有宋星的数字观 » Google Analytics的愁:跳转页面的监测和嵌套页面的监测
分享到: 更多 (0)

评论 9

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址
  1. #-49

    嵌套页面现在基本被blog、论坛代替了吧,可以基本忽略了~

    阿石15年前 (2009-08-23)回复
  2. #-48

    我的思路是,要正确跟踪浏览器端重定向,需要修改ga.js代码。在跳转代码的那个页面上,把该页面的referrer作为参数传递,在跳转后的页面,得到这个参数,然后在ga.js中替代document.referrer。

    Oliver15年前 (2009-08-24)回复
  3. #-47

    还有别的解决方法吗?我们既想保留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%左右,但来自嵌套渠道的流量就会少得可怕。

    老菜鸟15年前 (2009-08-24)回复
  4. #-46

    回楼上的,你的方法并不能完全监测到准确的量,具体的可以看一下泡泡网或者zol,他们的框架跳转很有意思

    废小米15年前 (2009-08-24)回复
  5. #-45

    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 :)

    Florian Pihs15年前 (2009-08-25)回复
  6. #-44

    没用过这两个功能,不知好不好用。

    美心15年前 (2009-08-25)回复
  7. #-43

    我遇到一个网站是用shtml的#include把其他网页文件调进来,这种情况GA代码应该怎么添加呢?

    shazeer15年前 (2009-11-01)回复