兩年多前，筆者曾經在Google站長平台發布過一篇名為《數據分析：如何追踪訪客初始來源》（HubSpot One原文）的文章廣受轉載。對我們研究用戶行為來說這種方法可以“原汁原味”地保留我們和受眾的初次接觸點。訪問來源在Google Analytics中默認由Source和Medium兩個維度所構成。早在Google Analytics還是Urchin時代時，各位如雷貫耳的utm_source和utm_medium就廣泛應用，而utm即Urchin Tracking Module。 Urchin被谷歌收購十多年後的今天，它們依然活躍在網站分析界。
訪問來源是轉化歸因模型的基本輸入
當今的網站分析自然比那個時代已經有了次元級的提升，各種歸因的應用已是數字分析中的modus operandi（慣用手法）。但是要說Last Click已死，未免為時過早，起碼GA中的那些默認的報表還大量地默認為Last Click模型，包括各種e-Commerce報表。梳理好各個訪問來源成為了我們日常管理網站分析的重要內容。我們且看下面兩個場景，思考一下對訪問來源而言，它們都意味著什麼？
場景一：支付網關
當用戶通過Google推廣到你的網站後，選擇了心儀的商品。結賬時用戶選擇了“某寶”作為支付方式。頁面帶用戶到了“某寶”的支付頁面，成功支付後用戶被自動帶回你的網站，訂單顯示支付完成。
場景二：第三方登錄（或跨域名登錄）
用戶通過EDM到你的網站著陸頁，你的網站提供了各種第三方便捷登錄/註冊方式。用戶選擇QQ登錄後被帶到QQ登錄頁面，授權成功後被自動帶回你的網站。成功登錄！
被“錯愛”的訪問來源
上述兩種場景都是我們司空見慣的場景，細心的你一定會發現其中蹊蹺。是的，用戶被帶離你的網站後被再次帶回，其中再次產生了一次會話。而這次會話便成為了關鍵的最後一次訪問來源。如果不加處理，我們會看到所有通過“某寶”支付的功勞都被算到了“推介”來的“某寶”上（如下圖所示），而真實帶來這次訪問的Google推廣的功勞被直接抹殺。同理，你會發現第二種場景裡的跳出率高的離譜，而QQ來的用戶的訪問時長拔群。
這樣的問題很普遍，我們把它叫做“Referral Spam”。它雖非惡意，但的確污染了我們的數據，為我們的數據分析造成了麻煩。
暫時離站訪問來源問題的解決方法
為了避免暫時離站訪問給我們分析帶來的干擾，我們必須處理好這些訪問來源。以往我們使用Filter來純屏蔽的方法在這裡並不適用，那樣做會完全屏蔽用戶在新會話中的行為。利用初始訪問來源跟踪的方法也有缺陷，因為用戶轉化可能並非發生在首次訪問。 Google Analytics為我們提供了兩種方法：
Referral Exclusion（引薦來源排除）
第一種是Referral Exclusion。這種方法是GA升級到Universal Analytics以後提供的方法。在管理界面的Property中，選擇Tracking Info，再選擇Referral Exclusion List便可以添加你需要排除的來源域名。這樣做和Filter的方法不同，它會保留用戶的行為訊息，只不過不再另行新建一個Session而已。
（注：如果用戶返回你的源網站時會話已經過期，那麼它會新建一個direct來源的訪問。）
utm_nooverride=1
utm_nooverride（兩個o，兩個r）這個參數從一開始就是為了應對訪問來源排除而生，在沒有升級到Universal Analytics以前，utm_nooverride是解決暫時離站帶來的訪問來源的唯一手段。它的值只能為1。如今如果你仍然在經典的GA上，你依然可以用這個參數來屏蔽這些訪問來源。 utm_nooverride相對Referral Exclusion更加靈活，而且可以避免由於Referer Policy（引薦來源政策）的影響無法獲得正確Referer從而無法匹配域名的情況。雖然有這些優點，但使用utm_nooverride的前提是你必須要能夠設置一個回調URL。如果你無法設置第三方網站返回的URL地址，那麼還是使用第一種方法為妥。
假設你的網站是a.com，支付網頁在p.com。支付成功後你要指定用戶返回http://a.com/success?orderID=123456，那麼你就會指定http://a.com/success?orderID=123456&utm_nooverride=1作為回調URL。
以上就是本篇介紹的解決暫時離站（跨站跟踪）的GA設置方法。希望對你有所幫助。如果你想了解更多關於Referrer的規則，請參閱W3的Referer Policy。
感謝閱讀，感謝關注HubSpot One。