首页 > WebAnalytics > Document.Referrer丢失的几个原因

Document.Referrer丢失的几个原因

WebAnalytics , , , , , , ,

Referrer的重要性

HTTP请求中有一个referer的报文头,用来指明当前流量的来源参考页。例如在www.sina.com.cn/sports/上点击一个链接到达cctv.com首页,那么就referrer就是www.sina.com.cn/sports/了。在Javascript中,我们可以通过document.referrer来获取同样的信息。通过这个信息,我们就可以知道访客是从什么渠道来到当前页面的。这对于Web Analytics来说,是非常重要的,这可以告诉我们不同渠道带来的流量的分布情况,还有用户搜索的关键词等,都是通过分析这个referrer信息来获取的。

但是,出于各种各样的原因,有时候Javascript中读到的referrer却是空字符串。下面总结一下哪些情况下会丢失referrer。

Referrer丢失的几个场景

修改Location对象进行页面导航

Location对象是一个用于页面导航的非常实用的对象。因为他允许你只变更Url的其中一部分。例如从cn域名切换到com域名,其他部分不变:

window.location.hostname = "example.com";

但是,通过修改Location进行页面导航的方法,会导致在IE下丢失Referrer。

IE5.5+ 下返回空字符串

Chrome3.0+,Firefox3.5,Opera9.6,Safari3.2.2均正常返回来源网页

window.open方式打开新窗口

示例:

<a href="#" onclick="window.open('http://www.google.com')">访问Google</a>

点击此链接会在新窗口打开Google网站,我们在地址栏中输入以下js代码就可以看到发送的referrer了。

javascript:alert(document.referrer)

测试结果:

IE5.5+ 下返回空字符串

Chrome3.0+,Firefox3.5,Opera9.6,Safari3.2.2均正常返回来源网页

如果是同个域名下通过此方式跳转的,那么我们可以通过访问windoww.opener对象去获取丢失的referrer信息。代码如下:

<script type="text/javascript">
    var referrer = document.referrer;
    if (!referrer) {
        try {
            if (window.opener) {
                // IE下如果跨域则抛出权限异常
                // Safari和Chrome下window.opener.location没有任何属性
                referrer = window.opener.location.href;
            }
        }
        catch (e) {}
    }
</script>

跨域的话则没辙了~

鼠标拖拽打开新窗口

鼠标拖拽是现在非常流行的用户习惯,很多浏览器都内置或者可以通过插件的方式来支持鼠标拖拽式浏览。但是通过这种方式打开的页面,基本全都丢失referrer。并且,这种情况下,也无法使用window.opener的方式去获取丢失的referrer了。

已测试:

Maxthon2.5.2,Firefox的FireGesture插件,Chrome3.0+,Opera9.6,Safari3.2。

点击Flash内部链接

点击Flash上到达另外一个网站的时候,Referrer的情况就比较杂乱了。

IE下,通过客户端Javascript的document.referrer读取到的值是空的,但是如果你使用流量监控软件看一下的话,你会发现,实际上HTTP请求中的Referer报文头却是有值的,这可能是IE实现的Bug。同时,这个值指向的是Flash文件的地址,而不是来源网页的地址。

Chrome4.0下点击Flash到达新窗口之后,Referrer也是指向的Flash文件的地址,而不是源网页的地址。

Chrome3.0和Safari3.2是一样的,都是会丢失Referrer信息。

Opera则和Firefox一样,Referrer的值都是来源网页的地址。

HTTPS跳转到HTTP

从HTTPS的网站跳转到HTTP的网站时,浏览器是不会发送referrer的。这个各大浏览器的行为是一样的。

例如,我们在HTTPS下使用Google Reader或是Gmail的时候,点击某个链接去到另外一个网站,那么从技术上来说,这样的访问和用户直接键入网址访问是没有什么分别的。

Referrer丢失对于广告流量监控的影响

Referrer如果丢失,Web Analytics就会丢掉很重要的一部分信息了,特别对于广告流量来说,就无法知道实际来源了。目前国内好多用了Google Adsense广告的网站,都使用了window.open的方式来打开广告链接,因此IE下会丢失Referrer,而我们知道,IE是目前市场份额最大的浏览器,因此其影响是很大的。很多流量统计工具会因此将这部分流量归入“直接流量”,和用户直接键入网址等价了。

对于这样的情况,需要让广告投放者在投放广告的时候,给着陆页面的Url加上特定的跟踪参数。

例如,某个Flash广告,点击之后到达的网址是http://www.example.com/,为了监控此流量是从哪个渠道过来的,我们可以修改此投放的着陆Url,改成http://www.example.com/?src=sina,类似这种方式,然后在着陆页面中使用Javascript代码提取此src参数,这样就可以得到广告来源信息。

在投放Google Adwords的时候,后台系统有一个“自动标记”的选项,当启用此选项的时候,Google在生成所有广告的着陆页面Url的时候,就会自动加上一个gclid的参数,这个参数能够将Google Analytics后台和Adwords广告后台的数据进行整合。这样就可以知道广告流量对应于哪个广告系列,哪个广告来源和广告关键词等信息了。和上面提到的思路其实是类似的。只不过Google自动帮你做了Url的修改了而已。

image

如果你发现了其他丢失Referrer的情况,或是你有其他解决方案,欢迎和我交流~

——Kevin Yang

你可能对下面的文章感兴趣

本博客遵循CC协议2.5,即署名-非商业性使用-相同方式共享
写作很辛苦,转载请注明作者以及原文链接~
如果你喜欢我的文章,你可以订阅我的博客:-D点击订阅我的文章

  1. 2010年4月25日07:39 | #1

    一直对GA报告中的莫名出现的not set感到疑惑。GA官方也只是说某些情况下会丢失referrer。在这里找到详细的原因了。谢谢。

  2. 2010年7月19日14:59 | #2

    不错值得学习

  3. 2010年8月9日03:35 | #3

    Referrer 很喜欢丢失的

  4. yolanda
    2010年8月25日19:07 | #4

    "从HTTPS的网站跳转到HTTP的网站时,浏览器是不会发送referrer的。这个各大浏览器的行为是一样的",如果这种跳转是发生在站内的话,那么GA会记为2个visits,其中一个visit来源是direct,对么?

    • Kevin Yang
      2010年8月25日19:42 | #5

      不是,访客以及会话相关的信息都是存在cookie中,而https和http下的cookie是共享的,所以GA不会认为这是两次访问。

  5. yolanda
    2010年8月26日10:01 | #6

    @Kevin Yang 了解了,谢谢博主!

  6. 沈欣
    2011年1月20日13:20 | #7

    有个问题啊 window。open 会丢失Referer 怎么才能硬性的添加Referer呢

  7. asdasd
    2011年3月4日16:10 | #8

    open方式那不就先的不好用了吗

  8. jerrywen
    2011年7月15日16:25 | #9

    我经常发现在流量统计中,有很多数据量很大的页面是自己站内的地址(Referer),这代表什么呢?站内的跳转记录么?而且,突然有一天站内的来源数据猛增1倍,看不太明白了~

    • Kevin Yang
      2011年7月15日19:26 | #10

      对于只有pv统计功能的工具,例如百度统计和cnzz等,来源是来自站内的话很正常。举例:
      假设用户的访问路径是,百度=>页面A=>页面B
      那么你的来源报告就会看到
      百度
      页面A

      而对于有会话统计的工具,例如GA,那么来源报表只会显示一次会话的首pv的来源,即百度。但是由于会话会有超时的逻辑,所以有时候也会出现来自站内的来源。

  9. 2011年11月7日16:02 | #11

    谢谢博主的详细介绍。对GA Referral的丢失以及Direct的不真有更进一步了解了

  1. 2010年4月25日15:25 | #1
  2. 2010年7月25日11:52 | #2
  3. 2010年9月16日09:41 | #3
  4. 2010年12月5日12:02 | #4
  5. 2011年1月13日18:43 | #5
  6. 2011年4月21日13:25 | #6