解決單頁應用追蹤中出現Rogue Referral的幾個方法

文章目錄

如果你的網站是單頁應用做了虛擬頁面跟蹤，且有付費流量，如Adwords，那麼你的網站很可能會出現Rogue Referral問題。

什麼是Rogue Referral

Rogue Referral，叫混淆引薦來源，最早是David Vallejo發現這個問題，並提出了設定追蹤程式名稱（Fixed Tracker）的解決方案，後來Simo Ahava將這個問題命名為Rogue Referral，提出了文檔位置的（Document Location）解決方案。

出現這個的原因是，在單頁應用中做了虛擬頁面跟蹤，用戶訪問第二個頁面（也就是虛擬頁面）的dl參數丟失，而Google Analytics是通過先dl參數去識別流量來源，如果dl上沒有utm或gclid參數，再通過dr參數去識別來源的，由於第二個頁面dl參數丟失，那麼只能通過dr去識別，從而導致引薦來源識別錯誤。

dl：全稱是document.location，就是著陸頁URL
dr：全稱是document.referrer，就是上一級引薦來源。

下面來看個例子，假設現在有個用戶是通過Adwords付費搜索訪問www.haranhuang.com，著陸頁鏈接是：

https://www.haranhuang.com/?utm_source=google&utm_medium=cpc&utm_campaign=Admin

這時候

dl是https://www..haranhuang.com/?utm_source=google&utm_medium=cpc&utm_campaign=Admin
dr是www.google.com，Google Analytics

識別流量是先跟蹤dl，然後在根據dr，那麼這一次訪問，dl上面有utm參數，那麼就可以正常劃分到付費搜索cpc。

如果用戶點擊瀏覽第二個頁面，因為是SPA，頁面是沒有載入，所以這時候，dl上沒有utm參數，而dr是www.google.com，表示是從谷歌過來的流量，這是一個新的廣告系列，所以會開啟新會話，並將這個會話是被為自然搜索或引薦來源。

後續訪問不同頁面的時候，可能會出現付費搜索、自然搜索/引薦來源之間不同跳轉，這個就是Rogue Referral。

在Google Analytics可以通過兩種方法判斷你的SPA網站是否有Rogue Referral問題：

如果你投放有Adwords，自然搜索的流量大幅升高，比例很不合理。
在Google Analytics用戶分層圖報告裡面看Adwords的用戶的會話是否在付費搜索和自然搜索之間不停切換，如下圖所示：

主要解決方法

谷歌目前對這個問題沒有官方的指導意見，但有些第三方的開發者提出了一些解決方案：

David Vallejo的設定追蹤程式名稱（Fixed Tracker）
Simo Ahava 的文檔位置（Document Location）
Vytas Sernas的移除引薦來源

David Vallejo 設定追蹤程式名稱

固定跟蹤器方法就是在所有的發送給Google Analytics的請求上（所有的頁面和事件）都設置一個設定追蹤程式名稱，使得dl的信息不變,可以直接在Google Analytics分析變數里設置：

同時需要將跟蹤類型為網頁瀏覽的代碼里設置為非互動命中，因為我們設定追蹤程式名稱，如果前一個命中（Hit）是事件，下一個命中是網頁瀏覽，沒有設置的話，事件的互動類型會影響網頁瀏覽的互動類型，會導致一些數據的異常，如新使用者異常變多，所以需要對跟蹤類型為網頁瀏覽的做如下設定：

值setUndefinedValue为自訂JavaScript變數：

function(){
  return undefined;
}

值不能直接填undefined，必須要用自訂JavaScript變數去存儲，否則起不了作用。

設定追蹤程式名稱注意點有兩個：

所有跟蹤都使用設定追蹤程式名稱
網頁瀏覽需要設置為非交互類型

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，不需要設置觸發條件：

Document Location HTML需要在網頁瀏覽之前執行，所以可以通過代碼觸發順序去設定，同時將代碼觸發優先順序的數值設置999，數值越大表示越快執行，找到GA的網頁瀏覽的那個代碼，做如下設定：

然後通過數據層變數去獲取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觸發都可以。

升級版方案

前面的三種方案，在使用者刷新頁面，或超過30分鐘在回訪，都有可能還是會出現Rogue Referral問題，當然，不是說前面的三種方案沒作用，它還是有作用的，只不過有些特定的情形，還是會出現Rogue Referral問題，我使用前面三種方案，Rogue Referral出現的比例從30%降低到2~3%。

但我仍然覺得有降低的可能，使用者第一次訪問網站的時候，如果著陸頁有utm或gclid參數，那麼將頁面Page URL寫入到cookie，當用戶超過30分鐘的回訪時，做些判斷，如果Referral是空，那麼用cookie的Page URL去覆蓋Location參數，那麼這次回訪就會用之前的utm或gclid參數，會劃分到之前的那個來源，這種方式能進一步降低Rogue Referral的的比例。

参考资料

如果您在操作上仍有任何疑問，歡迎留言交流，或加入：Google Analytics 4交流社團發問