GA4 新增主機名稱「只包含」篩選器，允許清單應該列哪些網域？

允許清單應該列出每一個會載入你 Google Analytics 4（GA4）代碼、並送出你想保留的事件的主機名稱：主網域、www 與非 www 版本、各個子網域，以及嵌入了你代碼的第三方預約或結帳頁面。清單列好之後，先把篩選器設為測試狀態，等 24 至 36 小時核對結果，再改為啟用。

背景是 Google 在 2026 年 9 月 21 日的 GA「What’s new」更新公布，資料篩選器的主機名稱類型新增 Include（只包含）選項，可以建立一份「獲准送出事件的網域」清單。Google 的資料篩選器說明亦寫明了「Include only」篩選器的套用次序。同一則更新另有兩個細節：經 Measurement Protocol 送出的事件不受 Include 篩選器影響；主機名稱空白的事件會被自動擋下。

這兩個細節，加上資料篩選器「一經套用、永久生效」的特性，決定了允許清單漏列一個網域的代價。被擋下的事件不會進入報表，也不會進入 BigQuery，事後無法補回。如果被擋的是預約完成或購買這類關鍵事件，廣告出價和預算分配都會建立在缺了一截的數字上，公司多花了的廣告費不會在報表上顯示出來。

本文以一張「主機名稱盤點表」為骨幹，逐欄解說每一欄要填甚麼、從哪裡取得、填錯會怎樣，最後說明怎樣按自己的網站改這張表。

（本文的功能描述以 Google Analytics 說明中心和 Google Analytics 開發者文件為準，全部於 2026 年 10 月 6 日查閱。文中品牌、網域和數字均為示範情境與示範數據，未經實測，不代表任何品牌。）

這次更新改了甚麼，和六月的排除版有何分別

兩次更新的時間線

主機名稱篩選器分兩步推出。按 What’s new 頁 6 月 11 日的紀錄，Google 先在資料篩選器加入主機名稱類型，當時只能排除（exclude）指定主機名稱的事件；Google 的主機名稱篩選步驟頁寫的亦是這個排除做法。9 月 21 日的更新加入 Include，Google 在更新說明中指出，以往只能排除，要不斷手動更新才追得上新出現的垃圾來源，改為列出獲准的主機名稱後，設定和維護都會簡單一些。

篩選器怎樣套用

資料篩選器說明寫明三點，直接影響允許清單的設計：

• 所有啟用中的「Include only」篩選器會先合併（union），作為一組先行套用，之後才按次序套用啟用中的「Exclude」篩選器。
• 篩選器只從建立當刻起評估新進的資料，不影響歷史資料。
• 效果是永久的。被排除的資料不會被處理，GA4 和 BigQuery 都不會出現。

「合併」的意思是：一個事件只要符合任何一個 Include 篩選器，就會被保留。把允許清單拆成兩個篩選器（例如一個放官網網域，一個放網店網域），效果和放在同一個篩選器內相同。Exclude 則在 Include 之後執行，所以一個主機名稱即使已列入允許清單，仍可能被另一個 Exclude 篩選器擋下。

排除和只包含的取捨

比較項目	Exclude（六月推出）	Include（九月推出）
清單內容	不想要的主機名稱	獲准的主機名稱
出現一個新的垃圾網域	照樣進入報表，直到你把它加入清單	自動被擋
你新開一個子網域或活動網站	不受影響	被擋，直到你把它加入清單
主機名稱空白的事件	更新說明沒有提及	自動被擋
Measurement Protocol 事件	更新說明沒有提及	不受影響
出錯的後果	清得不夠乾淨，報表仍有雜訊	清得太多，真實資料永久消失

（整理自 What’s new 頁 6 月 11 日及 9 月 21 日紀錄、資料篩選器說明；「出錯的後果」一列是本文按篩選器機制作出的分析。）

最後一列是整篇文章的重點。Exclude 漏列一個網域，代價是報表多了一些雜訊；Include 漏列一個網域，代價是那個網域的真實事件從此不會計入報表。兩種錯誤的性質不同，處理的謹慎程度亦應該不同。

建立篩選器的位置和限制

按 Google 的步驟頁，路徑是 Admin > Data collection and modification > Data filters > Create filter，然後選擇主機名稱篩選的範本（Web hostname traffic）。幾項容易忽略的限制：

1. 要在資源層級擁有 Editor 或以上權限，才能建立資料篩選器。
2. 篩選器名稱在同一資源內不能重複，最多 40 個字元，只能使用字母、數字、底線和空格。連字號不在允許之列，名稱寫成「include-hosts」會被拒絕，寫成「include_hosts」或「允許清單 2026」才可以。
3. 比對方式只有 Exactly matches 和 Contains 兩種（下文會解釋怎樣選）。
4. 狀態分 Testing、Active、Inactive 三種。

示範情境： 示範品牌甲是一間香港護膚品牌，官網、網店和預約頁共用同一個 GA4 資源。過去半年，負責數據的同事每月都要在 Exclude 篩選器加入一兩個新出現的陌生網域，清單已有十多項。Include 推出後，團隊決定改用允許清單，但先做一次完整盤點。

仍要留意的地方： 截至 10 月 6 日查閱，Google 的主機名稱篩選步驟頁仍只描述排除做法，Include 選項在介面上的實際字眼、位置和數量上限，應以你後台所見為準。Google 亦沒有在這些頁面說明一個篩選器最多可列多少個主機名稱。

盤點表範本：允許清單之前的那一步

為甚麼要先盤點

允許清單的風險在於「漏列」。要避免漏列，就要先知道目前有哪些主機名稱正在送出事件，每一個由誰負責，送出了多少關鍵事件。這些資料整理成一張表，之後每一欄的決定都有根據，日後有人問「為甚麼某個網域的資料不見了」，也有紀錄可查。

範本欄位

主機名稱	由誰、在哪裡載入 GA4 代碼	近期事件數	關鍵事件數	處理	比對方式	備註
（由報表匯出）	（向網站、網店、廣告負責人確認）	（Explore 匯出）	（Explore 匯出）	保留／不列入／先查	Exactly matches／Contains	負責人、確認日期

示範品牌甲填好的版本（示範數據）

主機名稱	由誰、在哪裡載入 GA4 代碼	近 60 日事件數	關鍵事件數	處理	比對方式	備註
www.brand-a.example	官網	182,400	1,260	保留	Exactly matches	主網域
brand-a.example	官網，部分舊連結未轉到 www	3,100	14	保留	Exactly matches	另開工作單修正轉址
shop.brand-a.example	網店	96,500	2,980	保留	Exactly matches	購買事件在此
brand-a.booking.example	第三方預約系統，按供應商指引嵌入了甲的 GA4 代碼	4,800	310	保留，啟用前再確認	Exactly matches	預約完成事件在此
staging.brand-a.example	測試站	2,200	40	不列入	不適用	測試資料本來就不應計入
www-brand-a-example.proxy.example	類似網頁翻譯服務的代理網址，真實訪客經代理瀏覽	900	3	先查	待定	見下文
free-traffic.example	不明，品牌甲從未使用	7,900	0	不列入	不適用	典型垃圾來源
空白或 (not set)	未知	650	0	先查	不適用	Include 會自動擋

（網域使用保留給示範用途的 .example，數字為示範數據，未經實測。）

示範表告訴了甚麼

八個主機名稱之中，四個要保留，兩個要擋，兩個要先查清楚。如果團隊只憑記憶列出「官網和網店」，允許清單只會有 www.brand-a.example 和 shop.brand-a.example 兩項，非 www 版本的 14 個關鍵事件和預約系統的 310 個預約完成事件會在啟用後消失。後者如果已經匯入 Google Ads 作為出價訊號，影響會由報表延伸到廣告投放。

填表次序

1. 由報表匯出主機名稱、事件數和關鍵事件數（「主機名稱」欄）。
2. 逐個找出負責人，填「由誰、在哪裡載入 GA4 代碼」。
3. 按關鍵事件和負責人決定「處理」欄。
4. 為要保留的項目選「比對方式」。
5. 設為 Testing 核對，把結果和日期寫進備註欄。

這張表的限制： 表格只反映盤點期間出現過的主機名稱。一年只用一次的活動網站、尚未上線的新子網域，都不會出現在匯出結果中，要另外向市場和網站負責人確認未來三至六個月的計劃。下面幾節逐欄說明。

「主機名稱」欄：清單從哪裡來

主機名稱的定義

按 Google Analytics Data API 的維度說明，Hostname 包含網址的子網域和網域名稱，例如 www.example.com/contact.html 的主機名稱是 www.example.com。這個定義帶出兩個實際後果：

• www.brand-a.example 和 brand-a.example 是兩個不同的值，允許清單要分別處理。
• 路徑不在主機名稱之內，同一網域下的不同頁面不需要逐頁列出。

匯出清單的步驟

1. 在 Explore 建立一份 Free form 探索。
2. 維度加入 Hostname 和 Event name；指標加入 Event count 和 Key events。
3. Hostname 放入列，Event count 和 Key events 放入值；日期範圍盡量拉長。
4. 匯出結果，貼進盤點表的「主機名稱」「近期事件數」「關鍵事件數」三欄。
5. 再把 Event name 加入列，逐個主機名稱查看送出了哪些事件，特別留意 purchase、generate_lead 或你自訂的關鍵事件。

日期範圍受甚麼限制

按 Google 的資料保留說明，資料保留設定只影響探索（Explore）和漏斗報表，不影響標準的彙總報表；標準資源的事件資料保留期可選 2 個月或 14 個月。如果資源的保留期設為 2 個月，探索最多只看到大約兩個月的資料，季節性活動用過的網域很可能不在其中。補救方法是在標準報表（例如 Pages and screens 報表）加入 Hostname 作為次要維度，用較長的日期範圍再核對一次。

示範情境： 品牌甲的資料保留期是 2 個月，所以示範表寫的是「近 60 日」。同事再用標準報表把日期拉到去年同期，找到一個 2025 年聖誕活動用過的 xmas.brand-a.example。網站負責人確認今年 12 月會再用，於是這個主機名稱也加入盤點表，處理欄填「保留」。

容易出錯的地方： 如果同一個 GA4 資源接收多個網站或應用程式的資料，匯出時要按資料串流（stream）分開核對，避免把另一個業務單位的網域誤判為垃圾來源。Hostname 是網頁資料的維度，應用程式串流的事件不在這張表的範圍內。

「處理」欄：保留、不列入、先查清楚

為甚麼這一欄最花時間

Include 篩選器的規則很簡單：不在清單上的主機名稱，事件全部被擋。所以「處理」欄填的每一個「不列入」，等於一個永久生效的刪除決定。判斷的依據有三個：這個網域是否由公司或公司授權的供應商營運；它送出的事件是否反映真實顧客的行為；它是否帶來關鍵事件。

四類常見的主機名稱

• 公司自己的網域： 主網域、www 與非 www 版本、網店、會員區、網誌、各個活動網站。原則上全部保留。
• 嵌入了你代碼的第三方頁面： 預約系統、活動報名頁、登陸頁製作工具、外部結帳或付款完成頁，只要供應商頁面載入了你的 GA4 代碼並送出事件，主機名稱就會是供應商的網域。這類頁面經常帶來關鍵事件，漏列的代價最大。
• 測試站和開發環境： staging、dev、本機測試等。測試資料本來就不應該進入正式報表，不列入即可，Include 會順帶把它們擋下。
• 不明網域： 公司從未使用、沒有關鍵事件、事件模式異常（例如只有 page_view、沒有任何互動）的主機名稱，通常是垃圾來源，不列入。

判斷的次序

1. 先看關鍵事件數。大於零的，一律先標「保留」或「先查」，不直接排除。
2. 再找負責人。屬於公司或公司授權供應商的，保留。
3. 找不到負責人、關鍵事件為零、事件只有 page_view 的，不列入。
4. 其餘標「先查」，在測試期間再判斷。

判斷「先查」的項目

示範表中有兩項填了「先查」。代理網址那一項，訪客是真實的人，只是經翻譯或代理服務瀏覽，主機名稱因此變成代理的網域；保留與否，視乎團隊想不想把這類瀏覽計入。主機名稱空白那一項，下文另有一節說明。

示範情境： 品牌甲的預約系統供應商曾在去年更換網域。同事翻查舊報表，發現預約完成事件曾經同時出現在兩個供應商網域。新網域列入允許清單之前，同事先向供應商確認舊網域已停用，避免日後供應商切換回舊網域時，預約事件被擋。代理網址那一項，近 60 日只有 3 個關鍵事件，團隊決定保留，並在備註欄寫明「真實訪客，經代理瀏覽」。

取捨： 把所有不確定的網域都列入，允許清單會漸漸變回一份「甚麼都收」的清單，失去意義；把不確定的網域都排除，則可能誤刪真實數據。上面的次序偏向保留有關鍵事件的網域，代價是報表可能留下少量雜訊，換來的是不會誤刪成交數據。

「比對方式」欄：Exactly matches 還是 Contains

兩種比對方式的機制

按 Google 的步驟頁，Exactly matches 要求主機名稱和你輸入的字串完全一樣，前後不能多一個字元；Contains 只要求主機名稱在任何位置包含你輸入的字串。

放在排除清單，Contains 的寬鬆是方便：輸入「free-traffic」就能擋下這個詞的所有變體。放在允許清單，寬鬆會變成漏洞。假設允許清單用 Contains 輸入「brand-a.example」，以下主機名稱全部會被保留：

主機名稱	Contains「brand-a.example」	是否你的網域
shop.brand-a.example	符合	是
brand-a.example.free-traffic.example	符合	否
notbrand-a.example	符合	否

Contains 無法限定字串必須出現在結尾，所以冒用你網域名稱作為前綴或後綴的垃圾來源，可以通過允許清單。

選擇的步驟

1. 盤點表中每個要保留的主機名稱，預設用 Exactly matches 逐個輸入。
2. 只有當子網域經常新增、逐個輸入無法維持時，才考慮 Contains，並接受上表的風險。
3. 用了 Contains 的話，在備註欄寫明原因，並在每季檢查時查看 Hostname 報表是否出現冒用名稱的網域。

示範情境： 品牌甲每季都會開一兩個活動網站，網站負責人擔心漏報。團隊最後保留 Exactly matches，改為在活動網站的上線清單加入一項「上線前一星期，把新主機名稱加入 GA4 允許清單」。這樣做多了一個步驟，但避免了 Contains 的漏洞。

限制： Google 的步驟頁只列出這兩種比對方式。部分第三方文章提到可以用正規表示式，本文查閱的 Google 頁面沒有這個說明，應以後台實際提供的選項為準。

空白主機名稱與 Measurement Protocol

Google 更新說明寫了甚麼

按 9 月 21 日的更新說明：

• Include 篩選器會自動擋下主機名稱空白的事件。Google 的理由是，缺少主機名稱通常代表垃圾或異常流量；說明在括號內以「gtag.js traffic」為例，沒有進一步解釋。
• Include 篩選器不會套用在經 Measurement Protocol 送出的事件，這部分資料不會被擋。

兩個實際後果

第一，經 Measurement Protocol 進入的垃圾事件，允許清單擋不住。按 Measurement Protocol 開發者文件，以 Measurement Protocol 送出事件需要在 GA 介面產生的 api_secret。如果懷疑有人用外洩的 api_secret 送入垃圾事件，處理方法是在資料串流設定中檢查並更換 api_secret，主機名稱篩選器無法處理這種情況。

第二，你自己的事件如果主機名稱空白、又不是經 Measurement Protocol 送出，啟用 Include 後會被擋。哪些事件屬於這一類，視乎你的設定，例如經 Google Tag Manager 伺服器端容器轉送、但沒有帶頁面網址的事件，是否會出現空白主機名稱，要在測試期間按自己的資料核對。這一點是本文的推斷，Google 的頁面沒有逐一列出哪些情況會產生空白主機名稱。

核對步驟

1. 在上一節的 Free form 探索中，把 Hostname 篩選為空白或 (not set)。
2. 加入 Event name 和 Key events，查看這些事件是甚麼。
3. 如果全部是沒有互動的 page_view，大多屬垃圾，可以讓 Include 擋下。
4. 如果出現 purchase、退款或你的關鍵事件，啟用前先查出送出這些事件的工具，改為帶上頁面網址，或改用 Measurement Protocol 送出。
5. 如果公司已用 Measurement Protocol 送出線下訂單或客戶管理系統的更新，可以放心，這部分不受 Include 影響。

示範數據： 品牌甲近 60 日有 650 個主機名稱空白的事件，全部是 page_view，平均互動時間為零，關鍵事件為零，判斷為垃圾，讓 Include 擋下。品牌甲的門市銷售經 Measurement Protocol 每日上傳，按 Google 說明不受影響，盤點表備註欄寫明這一點。

未能確定的部分： Google 沒有說明 Include 篩選器在 Testing 狀態下，會否把空白主機名稱的事件標示出來。啟用前如果無法確認，可以先把關鍵事件的空白主機名稱問題修好，降低不確定性。

「測試狀態」欄：啟用前怎樣核對

三種狀態的分別

按 Google 的步驟頁：Testing 狀態下，GA4 會用「Test data filter name」維度標示符合篩選條件的資料，資料本身不會被刪；Active 會對新進資料作出永久改動；Inactive 則代表篩選器不被評估。設為 Testing 後，要等 24 至 36 小時才核對；改為 Active 後，亦要 24 至 36 小時才開始過濾。Data API 的維度說明亦把 Test data filter name 定義為測試狀態中資料篩選器的名稱，並寫明篩選器可以包含或排除事件資料。

核對用的探索

Google 的步驟頁提供了一個做法：Free form 探索，維度加入 Test data filter name 和 Event name，指標加入 Event count，再以 Test data filter name 篩選你的篩選器名稱。建議另外加入 Hostname 維度，結果會直接按主機名稱分組。

Include 的讀法要多一步

Google 的步驟頁以排除篩選器為例，被標示的是「會被擋下」的資料。Include 的邏輯相反，本文查閱的頁面沒有寫明，Testing 狀態下被標示的是「符合清單、會被保留」的事件，還是「會被擋下」的事件。實際做法是兩邊都看：

1. 先看被標示的主機名稱是哪些。
2. 如果被標示的全是允許清單上的網域，代表標示的是「會被保留」的資料，未被標示的就是啟用後會消失的部分。
3. 如果被標示的全是清單以外的網域，代表標示的是「會被擋下」的資料。
4. 無論哪一種，都把「會消失」的那一組逐個對照盤點表，確認裡面沒有任何關鍵事件。

示範數據： 品牌甲把篩選器設為 Testing，36 小時後核對。被標示的主機名稱是允許清單上有事件的五個網域，事件合共約 7,200 個；未被標示的是 free-traffic.example、staging 和空白主機名稱，合共約 270 個事件，關鍵事件為零。團隊確認後改為 Active，並在內部紀錄寫下啟用日期，之後解讀報表趨勢時，可以知道事件數下降的一部分來自篩選。

Testing 做不到的事： Testing 只能預覽「篩選器啟用後的新資料」會怎樣，不能預覽歷史資料，因為篩選器本來就不影響歷史資料。測試期如果剛好遇上低流量的週末，某些主機名稱可能沒有出現，建議至少覆蓋一個完整的工作日。

怎樣按自己的網站改這張表

盤點表的欄位可以保持不變，按網站類型調整重點：

• 單一網域的品牌網站： 清單通常只有兩三項（www、非 www、網誌子網域）。重點放在「比對方式」欄，用 Exactly matches，並在轉址修正後檢查非 www 版本是否仍有事件。
• 網店加第三方預約或結帳： 重點放在「由誰、在哪裡載入 GA4 代碼」欄。向每個供應商確認他們的頁面是否載入你的代碼、用哪個網域，供應商更換網域時要通知你。
• 多個品牌或業務共用一個資源： 先按資料串流分開盤點，每個業務單位指定一名負責人確認自己的主機名稱。允許清單可以按業務拆成多個 Include 篩選器，按資料篩選器說明，多個 Include 會合併套用。
• 代理商管理多個客戶資源： 把盤點表做成範本，每個客戶資源一份，在交接文件註明允許清單的位置和上次檢查日期。
• 經常開活動網站： 把「加入允許清單」寫進活動上線清單，負責人和截止日期與網站上線工作並列。

不論哪一類網站，盤點表都應該定期重做，例如每季一次，或在網站改版、更換預約或結帳供應商之後。每次重做時，比較新舊兩份表：新出現的主機名稱逐個查明，消失了的主機名稱確認是否真的停用。

主機名稱只是量度可信度的其中一環。想按次序檢查來源歸因、關鍵事件和成交對帳，可以參考 GA 量度自查清單。

相關文章

2026-10-28 · GA 量度

【Meta CAPI 設定後轉換反而變多？去重與事件比對自查表】

2026-10-27 · GA 量度

【Meta 10/28 預設開「商品瀏覽」：點廣告進站內頁還是官網？轉換對帳先問這題】

2026-10-26 · GA 量度

【廣告平台轉換加總超過實際訂單？對帳五步找出重複計算】

免費 GA 量度自查（訂閱後解鎖完整步驟）