更新時間：2025年11月17日
在單頁應用（SPA, Single Page Application）架構中使用GA4時，很容易遇到一個常見但容易被忽略的問題：Rogue Referral（錯誤推薦來源）
這個問題會導致：
- 廣告流量被錯誤歸類
- Google Ads歸因失真
- 自然流量暴增但實際沒有成長
- 轉換來源混亂
對於做數據分析或投放廣告的團隊來說，這會嚴重影響ROI判斷。
什麼是Rogue Referral？
Rogue Referral（惡意/錯誤推薦來源）是指：GA4錯誤將原始流量來源，歸因成網站自身或第三方網域，而非真實的推廣來源。
Rogue Referral發生的原因
在SPA中，頁面切換不是「重新載入頁面」，而是透過JavaScript模擬頁面變更（虛擬頁面），這會導致GA4兩個關鍵參數錯亂：
| 參數 | 意義 |
|---|---|
| dl | document.location（當前頁 URL） |
| dr | document.referrer（上一頁來源） |
在第一次進站時：
https://www.haranhuang.com/?utm_source=google&utm_medium=cpc
GA4可以正常解析：
- dl = https://www.haranhuang.com/?utm_source=google&utm_medium=cpc
- dr = google.com
- 正確歸因：Google CPC
使用者進入第二頁（虛擬頁面）：
https://www.haranhuang.com
- dl ： https://www.haranhuang.com，變成乾淨URL（沒有utm/gclid）
- dr = google.com
- GA4判斷：這是一個「新工作階段」，來源是Google自然搜尋
結果就是：Google Ads 流量變成了自然搜尋，出現了Rogue Referral
如何判斷是否有 Rogue Referral？
方法 1：Google Ads vs Organic 異常
如果你發現：Google Ads成效沒變，但CPC流量下降，Organic Search突然暴增，比例很不合理，很可能是Rogue Referral。
方法 2：GA4 流量路徑異常
在GA4 「使用者多層檢視」中觀察：使用者在「付費 / 自然 / referral」之間跳來跳去，同一個工作階段被拆成多個來源，如下圖：
Rogue Referra解決方案
目前Google官方沒有明確解法，但業界提出了一些解決方案：
方法一：Fixed Tracker（已不適用 GA4）
GA4中沒有固定跟蹤器，所以此方法不適用。
由David Vallejo提出：固定跟蹤器方法就是在所有的發送給Google Analytics的請求上（所有的頁面和事件）都設置一個設定追蹤程式名稱，使得dl的信息不變,可以直接在Google Analytics分析變數里設置：
同時需要將跟蹤類型為網頁瀏覽的代碼里設置為非互動命中，因為我們設定追蹤程式名稱，如果前一個命中（Hit）是事件，下一個命中是網頁瀏覽，沒有設置的話，事件的互動類型會影響網頁瀏覽的互動類型，會導致一些數據的異常，如新使用者異常變多，所以需要對跟蹤類型為網頁瀏覽的做如下設定：
值setUndefinedValue为自訂JavaScript變數：
function(){
return undefined;
}
值不能直接填undefined，必須要用自訂JavaScript變數去存儲，否則起不了作用。
設定追蹤程式名稱注意點有兩個：
- 所有跟蹤都使用設定追蹤程式名稱
- 網頁瀏覽需要設置為非交互類型
方法二：Document Location（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參數：
這樣就完成了設定。
方法三：移除 Referral（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觸發都可以。
方法四（升級推薦）：Cookie 保存原始來源（最佳實務）
前面的三種方案，在使用者刷新頁面，或超過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的的比例。
總結
Rogue Referral的本質問題是：
SPA破壞了GA4判斷流量來源的「第一接觸點」
因此解法核心只有一個：保留「第一次進站的原始 URL」