行銷活動歸因教學，GA4 的跨網域追蹤與自我推薦(referral) 排除設定
- 最後更新日期：
🚀 讀者專屬工具
立即開啟 →
在開始閱讀前，先用 AI 自動生成您的網站架構圖？
廣告成效明明有在跑，GA4 報表卻一直看到「來源變成你自己的網域 referral」，轉換被切成兩段，ROAS 也跟著失真，這種感覺就像把接力賽的接棒點弄丟了，跑得再快也算不出誰立功。
要把歸因救回來，核心通常只有兩件事：GA4 跨網域追蹤把同一個人跨站的工作階段接起來，或是把不該出現的自我推薦與金流推薦排除掉。
下面用可照做的設定路徑、欄位規則、測試方法，搭配 example-a.com 與 example-b.com 的範例，讓你把「來源被洗掉」這個老問題一次處理乾淨。
先判斷：你需要跨網域追蹤，還是只要排除 referral？
跨網域追蹤適合「使用者旅程必然跨不同根網域」的情境，例如官網在 example-a.com，但結帳在 example-b.com。沒有設定時，使用者一跳轉就像換了一個新訪客，工作階段被切斷，原本的 utm_source 也容易被後面的 referral 覆蓋。
只排除 referral 則適合「你無法控制對方網域」或「不需要把人接起來，只是不想被推薦來源蓋掉」的情境，最常見就是外部金流 example-c.com。你通常不能在金流頁上裝 GA4，也很難保證參數能完整帶回，因此目標是避免金流域名變成新的來源。
跨網域追蹤在 GA4 的原理是用網址參數把識別資訊帶到下一個網域，GA4 官方文件把它稱為跨網域評估，會透過 _gl 這類參數協助維持同一個使用者與工作階段，你可以先看一下 Google 官方的跨網域設定說明 對照你的情境。
一個簡單判斷法：
- 只要「結帳或會員」在另一個根網域，而且你期待購物漏斗是同一段旅程，就做跨網域追蹤。
- 只要「外部服務」只是中繼點(例如金流)，回到你站上才完成轉換，優先做 referral 排除，必要時再搭配跨網域。
GA4 跨網域追蹤設定步驟(含 example-a.com 與 example-b.com)
以下路徑截至 2026 年 2 月的 GA4 介面仍通用，GTM 或 gtag 皆適用。
逐步操作(跨網域清單怎麼填)
- 進入 GA4，點左下角 管理(齒輪)。
- 在「資料收集和修改」找到 資料串流，點你的 網站資料串流(Web)。
- 往下找到 進行代碼設定 或 更多代碼設定，點進去。
- 點 設定網域(Configure your domains)。
- 在「納入符合下列條件的網域」新增網域，輸入：
example-a.comexample-b.com
- 按 儲存。
欄位規則(最常填錯的點)
- 只填「根網域」，不要加
https://、不要加路徑(例如/checkout)。 - 不要只填子網域當成跨網域解法(例如 checkout.example-a.com 通常屬同一根網域，多數情況不需要跨網域清單)。
- 兩邊都要在同一個 GA4 資源下被量測，才能在報表裡完整接起來。
如何確認成功(三個檢查點)
- 走一次真實流程：從廣告或帶 UTM 的落地頁進 example-a.com，再點到 example-b.com/checkout。
- 看網址：跳到 example-b.com 時，連結常會被自動「裝飾」帶上
_gl參數(不一定每次都肉眼可見，但常見)。 - 看 GA4 報表：
- 即時：同一位使用者在不同網域間事件持續出現。
- 流量開發：轉換的工作階段來源仍是原始的 utm_source，不是 example-a.com referral。
如果你想再對照一篇圖文版流程，可參考 跨網域追蹤圖解教學，用來跟工程師溝通會更快。
自我推薦(referral)排除：原理、設定路徑、以及常見風險
所謂自我推薦，常見是「A 網域跳到 B 網域後，B 把 A 當成推薦來源」。另一種是「金流回跳」把 payment 網域當成推薦來源。GA4 的排除本質是告訴系統「這些 referral 不要拿來重寫本來的來源」，避免工作階段被錯誤改寫。
但它也有風險：排除會掩蓋真實推薦。如果你把某個合作夥伴或內容平台的網域也排除掉，日後你就看不到它帶來的真流量與轉換，報表會變乾淨，但決策會變盲。
逐步操作(不需要的推薦 Unwanted referrals)
- GA4 左下角 管理。
- 資料串流 > 選你的 網站資料串流。
- 進行代碼設定(或更多代碼設定) > 設定網域。
- 找到 不需要的推薦(Unwanted referrals)。
- 新增要排除的網域，例如：
example-a.com(避免自我推薦)example-c.com(金流網域，常見需要排除)
- 儲存。
如何確認成功(看哪裡最準)
- 到 流量開發，用「工作階段來源/媒介」維度看購買或送出表單的那一段，來源不該變成 example-c.com referral。
- 若你有用 DebugView 或 Tag Assistant，走一次「官網 > 結帳 > 回到完成頁」，完成頁那次工作階段的 source 應保留原始廣告來源。
如果團隊在討論「只做單邊設定有沒有用」，可以讀一下 跨網域追蹤情境討論 來對齊觀念，避免用錯方法硬救數據。
電商常見流程(官網→結帳→金流→完成頁)的建議做法與問題排查
建議做法很務實，先把你能控制的網域接起來，再把不能控制的網域排除掉：
- 官網 example-a.com 與結帳 example-b.com，都在你的控制下：
- 先做 GA4 跨網域追蹤，清單同時包含
example-a.com、example-b.com。
- 先做 GA4 跨網域追蹤，清單同時包含
- 金流 example-c.com 你通常無法裝標記：
- 把
example-c.com加到 Unwanted referrals。
- 把
- 完成頁最好回到你的網域(通常是 example-b.com/thank-you 或 example-a.com/thank-you)：
- 盡量避免完成頁停在金流網域，這會讓歸因更難救。
- 測試一定要用「真實跳轉」：
- 不要只在同一頁刷新，歸因問題多半出在跳轉與回跳。
最後用一張表把最常見的症狀整理起來，方便你對照排查。
| 問題症狀 | 可能原因 | 解法 |
|---|---|---|
| 轉換來源變成 example-a.com referral | 官網與結帳是不同根網域，未做跨網域 | 設定網域加入 example-a.com、example-b.com，並用即時報表驗證 |
| 轉換來源變成 example-c.com referral | 金流回跳覆蓋原始來源 | 將 example-c.com 加到 Unwanted referrals |
| 同一位使用者被算成兩個使用者 | 跨網域未接起來，識別在兩站各自重置 | 依官方方式設定跨網域，確認跳轉時參數能傳遞 |
| 報表看到大量 direct / none | 進站連結沒帶 UTM 或被中途洗掉 | 先把 UTM 規格統一，再處理跨網域與排除 |
| 設了還是出現自我推薦 | 只設一個網域，或填了帶協定/路徑的錯格式 | 只填根網域，兩個網域都加入，同步檢查資料串流 |
如果你的站是 WordPress 或 WooCommerce，多網域結帳常牽涉外掛、快取、結帳頁重導與 GTM 事件一致性，這種時候讓工程與行銷一起把追蹤規格寫死，通常比事後補救更省錢。需要有人把 GA4 與網站維運一起顧到位，可以從 WPTOOLBEAR 的 WordPress 維護服務 先把追蹤與站點穩定性打底。
結語
行銷活動歸因要準，先把「人」跨站的旅程接起來，再把不該出現的推薦來源擋掉。做對 GA4 跨網域追蹤 與 Unwanted referrals，你會發現報表突然變好讀，投放優化也更敢加碼。下一步就用 example-a.com → example-b.com 的流程跑一次，對照即時與流量開發報表，把來源是否被洗掉這件事，今天就結案。
