解决单页应用中出现Rogue Referral的几个方法

文章目录[隐藏]

什么是Rogue Referral
主流解决方法
升级版解决方法
参考资料

如果你的网站是单页应用，那么你的网站很可能会出现Rogue Referral的问题。

什么是Rogue Referral

Rogue Referral，叫混淆引荐来源，最早是David Vallejo指出这个问题，并提出了固定跟踪器的解决方案，后来Simo Ahava将这个问题命名为Rogue Referral，提出了文档位置的解决方案。

出现这个的原因是，在单页应用中做了虚拟页面跟踪，用户访问第二个页面（虚拟页面）的dl参数丢失，而Google Analytics是通过dl和dr参数去识别来源的，dl上没有utm或gclid，就不能准确识别了。

dl：全称是document.location，就是着陆页URL
dr：全称是document.referrer，就是上一级引荐来源。

下面来看个例子，假设现在有个用户是通过百度付费搜索访问GA小站，着陆页链接是：

https://www.ichdata.com/?utm_source=baidu&utm_medium=cpc&utm_campaign=Admin

这时候dl是https://www.ichdata.com/?utm_source=baidu&utm_medium=cpc&utm_campaign=Admin，dr是www.baidu.com，Google Analytics识别流量是先跟踪dl，然后在根据dr，那么这一次访问，dl上面有utm参数，那么就可以正常划分到付费搜索。

如果用户点击下一个页面，因为是SPA，页面是没有加载，虚拟页面的，所以这时候，dl上没有utm参数，而dr是www.baidu.com，表示是从百度过来的流量，这是一个新的广告系列，所以会开启新会话，并将这个会话是被为自然搜索或引荐来源（之所有会出现在引荐来源是因为Google Analytics对移动端的百度识别较差，可能会被划分到引荐来源）。

后续访问不同页面的时候，可能会出现付费搜索、自然搜索/引荐来源之间不同跳转，这个就是Rogue Referral。

在Google Analytics可以通过两种方法判断你的SPA网站是否有Rogue Referra问题：

如果你投放有百度搜索或Adwords，自然搜索的流量大幅升高，比例很不合理
在Google Analytics用户分层图报告里面看百度付费搜索或Adwords的用户的会话是否在付费搜索和自然搜索之间不停切换，如下图所示：

主流解决方法

目前市面上主要有以下几种解决方案：

David Vallejo 固定跟踪器
Simo Ahava 文档位置
Vytas Sernas 移除引荐来源

David Vallejo 固定跟踪器

固定跟踪器方法就是在所有的发送给Google Analytics的请求上（所有的页面和事件）都设置一个固定跟踪器，使得dl的信息不变,可以直接在Google Analytics分析变量里设置：

同时需要在PageView跟踪类型的代码里设置为非交互的，因为我们设置了固定跟踪器，如果前一个hit是event，下一个hit是pageview，没有设置的话，event的交互类型会影响pageview的交互类型，会导致一些数据的异常，如New Users异常变多，所以需要PageView跟踪类型的做如下设置：

值setUndefinedValue为自定义JavaScript变量：

function(){
  return undefined;
}

值不能直接填undefined，必须要用一个变量去存储，否则起不了作用。

注意点：

所有跟踪都使用固定的跟踪器
PV类型的设置需要设置为非交互类型。

Simo Ahava 文档位置

文档位置的方法就是当用户访问第一个页面的时候，就在页面上获取originalLocation，其实就是着陆页URL，然后通过数据层发送出去，这段代码需要在GTM代码之前：

  window.dataLayer = window.dataLayer || [];
window.dataLayer.push({
  originalLocation: document.location.protocol + '//' +
                    document.location.hostname +
                    document.location.pathname +
                    document.location.search
});

如果你没有服务器权限，不能讲上述代码添加到页面，那么还可以通过GTM去实现，将这段代码通过自定会HTMLT去存储，命名为Document Location HTML，不需要设置触发器：

这个代码需要在PageView之前执行，所以可以通过序列去设置，找到GA的Page View的那个代码，做如下设置：

然后通过数据层变量去获取Document Location HTML里的originalLocation，变量命名为Data Layer Variable – originalLocation，如：

然后在通过一个javasrcipt变量组装着陆页url，其实就是dl参数，命名为JS – originalLocation：

最后在Google Analytics分析设置变量里的，在“要设置的字段”里用JS – originalLocation覆盖location：

这样就完成了布署。

Vytas Sernas 移除引荐来源

移除引荐来源处理的思路是在页面打开的时候，延迟一定时间，然后通过自定义HTML移除referral，使得后面的访问没有referral，那么同个会话内，后面的访问就会划分给首个访问的来源。

<script>
function removeReferrer() {
console.log(‘Before removing referrer was:’, document.referrer);
Object.defineProperty(document, ‘referrer’, {
value: null,
});
console.log(‘After removing referrer:’, document.referrer);
}
setTimeout(removeReferrer, 300);
</script>

上面的代码用DOM read或All Page触发都可以。

升级版解决方法

上面三个方法可以解决用户在第一次访问时不会出现Rogue Referral，但如果用户在超过30分钟，或隔夜才访问的时候，新开启的会话还是会出现Rogue Referral。

如用户早上是通过baidu/cpc访问GA小站，那么早上这个会话是划分给baidu/cpc，不会出现Rogue Referral，但用户在下午直接再次访问，这时候虽然说是直接访问，但直接访问不会覆盖其他广告系列的，所以这次回访应该是划分到baidu/cpc，但实际上，如果用固定跟踪器，那么回访就没有dl，那么可能会被划分到referral（GA对百度移动端识别不好，会被划分到Referral）或自然搜索，如果用文档位置，那么是划分到直接访问，如果是用移除引荐来源，那么是划分到直接访问。

所以上面的三种方法都没发解决用户回访会话的划分。

其实，我们可以将用户的UTM参数写入到Local Storage/Cookie，用户在回访的时候，用当前时间戳和Client ID的时间戳做对比，如果事件超过30分钟，那么就拿Local Storage/Cookie里的UTM参数，通过GTM里Field to set覆盖UTM参数，那么这个回访会话就可以准确归因到原广告系列。