GA4 AI推薦流量抓不到？自訂管道群組怎麼設定才真的抓得到

多數人以為打開 GA4 內建的「AI Assistant」頻道，AI 推薦來的流量就整理乾淨了。事實上這個頻道認得的平台名單很窄，回溯不到上線之前收集的舊資料，Perplexity 這種常被讀者引用的平台也完全不在名單裡。只靠這個功能，看到的 AI 推薦流量，始終只是全貌的一小角。

AI 推薦流量，指的是使用者在 ChatGPT、Gemini 這類 AI 聊天工具的回答裡，點了一則引用連結、因此進到你的網站的那一批工作階段（session）。這批流量會不會被 GA4 正確歸類，關鍵在於瀏覽器有沒有把 referrer（來源網域）傳出來，GA4 再拿這個網域去比對規則，決定它該落進哪一個頻道。這批人現在的量體雖然還不大，但轉換品質不差，值得從 Referral、Direct 這種大雜燴裡單獨挑出來看，而不是放著不管、任由它混在裡面。

Referrer 網域比對決定 AI 流量歸屬的頻道

GA4 幫每一筆工作階段貼標籤，靠的是 referrer，也就是使用者按下連結前，瀏覽器記錄下來的來源網址。當有人從 ChatGPT 的對話畫面點擊你網站的連結進來，瀏覽器會把 ChatGPT 那個網域寫進兩個欄位：Session source（工作階段來源）與 Session medium（工作階段媒介）。GA4 再拿這兩個欄位，依照頻道規則從上到下一條一條比對，第一個吻合的規則就採用，後面就算有更精確的規則，也不會再被套用。官方文件把這個順序邏輯講得很直白，原文寫著「Traffic is included in the first channel whose definition it matches given the current order of channels in the group.」，一筆流量只會落進排序裡第一個吻合的頻道，不會同時符合多個。

沒被任何規則特別辨識的網域，會落進 Referral 這個大分類；要是連 referrer 都沒有傳出來，就會落進 Direct。這兩個分類原本就是用來承接「沒被特別處理」的流量，問題是 AI 推薦來的訪客，幾乎全部都先掉進這兩個籃子裡，沒有人特別去挑，自然也沒有人會注意到它。

這也是為什麼把 AI 推薦來的流量挑出來看這件事值得花時間處理。它現在的量體還小，但轉換品質不差，Ahrefs 分析自家網站數據時發現，AI 搜尋訪客只占它總訪客的 0.5%，卻貢獻了 12.1% 的註冊數，轉換率是自然搜尋的 23 倍。這是 Ahrefs 明講出自「our own analytics」的自家觀察，不是二手轉引。混在 Referral 或 Direct 這種大雜燴裡，你回答不了「這些人後來有沒有變成名單」這種問題，因為它們早就跟其他來源攪在一起，分不出誰是誰。

內建的 AI Assistant 頻道，只認五個平台

2026 年 5 月 13 日，Google 在 GA4 的「新版功能」公告裡，正式宣布新增一個叫做「AI Assistant」的頻道。系統只要偵測到一筆工作階段的來源符合已知的 AI 助手，就會自動把 Medium 欄位標記為 ai-assistant、Campaign 標成（ai-assistant）、整批歸進 AI Assistant 頻道，不需要你自己動手設定任何規則。

不過這裡有一個多數教學沒特別提醒的落差，公告當時列出的平台名單，跟現在官方定義頁實際寫的名單並不一樣。公告原文寫的是「識別來自 ChatGPT、Gemini 和 Claude 等聊天機器人的使用者流量」，但目前的 Default channel group 定義頁，寫的名單是 ChatGPT、Gemini、Deepseek、Copilot、Grok，原文為「AI Assistant is the channel by which users arrive at your site from sources like ChatGPT, Gemini, Deepseek, Copilot, or Grok.」。Claude 已經不在現行定義裡，Perplexity 則從一開始就沒被列進去過。這代表如果照著公告當時的說法去核對，會誤以為 Claude 的流量有被內建頻道承接，實際上打開報表一看，那批流量還是掉在 Referral 裡。這份名單顯然還在調整，操作前務必自己回頭去確認官方定義頁的當下版本，不要死背這篇文章列出的五個名字。

AI Assistant 頻道的後台查看位置

要親眼確認這個頻道存不存在，有兩個地方可以看。第一個是後台設定路徑，進入「管理」，在「資料顯示」區塊底下找到「頻道群組」，清單裡會有一個標示為系統維護、不能編輯的「Default channel group」（預設頻道群組），AI Assistant 就是這個群組裡的其中一個頻道。官方文件寫得很明確，「Default channel groups can’t be edited in Google Analytics.」，真正能自己動手調整的，是另外建立的自訂頻道群組。

第二個是報表，打開標準報表裡的「客戶開發」或「流量開發」報表，右上角有一個頻道群組切換器，只要維持在 Default channel group 這個選項，AI Assistant 那一行就會直接出現在清單裡，不必另外做任何設定。實際操作時可以截一張畫面對照，截「頻道群組」清單裡出現 AI Assistant 那一列，或標準報表裡 AI Assistant 那一整行的實際數字，兩張都能拿來當作這個功能確實生效的證明。

內建頻道排除在外的 Perplexity 與 AI Overviews

有兩個常被誤會「應該有算進去」的東西，其實都沒有。第一個是 Perplexity，它目前不在官方定義的 AI Assistant 來源清單裡，訪客從 Perplexity 點進站，依然會被歸進 Referral，得靠自訂管道群組才能把它獨立抓出來。第二個是 Google 自己的 AI Overviews 與 AI Mode，這兩個雖然也是 AI 生成答案的介面，但官方定義寫得很清楚，AI Assistant 頻道「excludes Google’s AI Overviews and AI Mode」，這兩塊點擊會被歸進 Organic Search，跟一般的自然搜尋結果混在一起，官方對 Organic Search 的定義原文也寫著「including Google’s AI Overviews and AI Mode」。

這條界線也順便框出這篇文章要處理的範圍，只談訪客離開你的網站、跑到第三方 AI 助手、再從那邊被引導回來這件事；AI Overviews 在 Google 搜尋結果頁裡的曝光與點擊表現，要另外用 Search Console 去看，不是 GA4 頻道分類能回答的問題。Claude 目前的狀況比較特殊，公告當時有點名過它，但目前的定義頁已經拿掉，之後會不會再被加回來，就目前查得到的文件沒辦法保證，只能照現況如實描述。

各 AI 平台目前使用的實際網址與舊網域對照

要讓 GA4 真的認得住 AI 流量，得先把每個平台目前正在使用的網域整理清楚，包含還在用的現行網域，以及偶爾還會被舊連結、舊書籤帶出來的過期網域。以下是目前查得到、普遍會出現的 AI 流量來源：

這張清單不是憑空整理出來的，Ahrefs 一篇分析 AI 流量追蹤的文章裡，示範用的 GA4 比對規則本身就列出了 chatgpt.com、perplexity.ai、gemini.google.com、copilot.microsoft.com、openai.com、claude.ai、deepseek.com 這幾個網域，可以拿來佐證這些確實是目前普遍會出現的 AI referrer 網域，不是自己編出來的猜測清單。

表格裡特別把 Grok 獨立列出來，是因為網域比對這套機制對它幾乎完全沒用，它根本不會在標頭裡傳出 referrer 資料。Statcounter 統計月度 AI 聊天機器人流量佔比時，就直接把 Grok 排除在計算之外，原文寫著「Grok cannot be included in the data, as unlike the other chatbots, it does not provide referral data in its header.」。這件事牽涉到的是 referrer 機制本身的限制，這裡先點出這個例外，提醒不要花時間去猜 Grok 的網域該怎麼寫進 regex 裡；寫了也抓不到。

抓到不該抓的網域，四個常見誤判來源

regex 寫得太寬鬆，反而會把不相干的流量也一起算進 AI 推薦流量裡，常見的誤判有四種。

第一種是把整個 openai.com 根網域都算進去。這個網域底下同時掛著 API 文件、開發者後台、行銷頁，工程師去讀技術文件的點擊，跟真人在 ChatGPT 裡問問題、點連結進站是兩件不同的事，真正的助手介面點擊只會出現在 chatgpt.com 或 chat.openai.com，不會出現在裸的 openai.com 上。第二種是同樣的邏輯放到 claude.ai 身上，claude.ai 才是助手對話介面，anthropic.com 是官網、部落格、徵才頁，不該一起算。

第三種最容易讓數字整個失真，是把 google.com 整個根網域也拿去比對。Gemini 雖然是 Google 的產品，但 google.com 這個字串本身就是一般 Organic Search 流量會用到的來源，如果 regex 把它整包吃進去，會連帶把所有 Google 搜尋來的流量都算成 AI 推薦流量，數字會嚴重膨脹、完全不可信。第四種是 regex 偷懶寫成只要字串裡含 ai 這兩個字母就算，這種寫法會把 gmail、domain、contain 這些完全不相干、剛好字母序列裡帶著 ai 的來源也一併抓進來，規則越懶，誤判就越多。設定 regex 時，每一條都該對應到表格裡列出的實際網域，不要用簡化的萬用字元去賭。

建立自訂管道群組，把 AI 流量獨立出來看

內建的 AI Assistant 頻道雖然方便，但它有兩個先天限制，一是抓不到 Perplexity，二是沒辦法回溯到 2026 年 5 月 13 日之前收集的資料。想要一份更完整、也能涵蓋過去資料的 AI 流量清單，就得自己動手建一個自訂管道群組。官方文件給的操作路徑是進入「管理」，在「資料顯示」區塊底下找到「頻道群組」，點選「建立新頻道群組」；這個功能需要「編輯者」以上的權限才能建立或修改，帳號權限不夠的話要先跟管理員申請。

在後台複製預設清單建立新管道群組

不必從零開始寫十幾條規則。建立新頻道群組時，系統會提供一個選項，可以直接複製一份現有的預設頻道清單當底稿，再從這份底稿上加自己要的 AI 規則就好，不用把 Referral、Organic Search、Direct 這些既有頻道的定義全部重寫一遍。

這一步操作起來很快，但值得截一張圖存下來，截「建立新頻道群組」的畫面，讓畫面上看得到「複製既有清單當底」這個選項被選取的樣子。之後如果要修改規則，或是團隊裡有其他人接手維護，這張截圖能直接對照回當初是從哪一份清單開始改的。

用 Source 欄位比對規則運算式新增 AI 頻道

複製好底稿之後，接著新增一個屬於自己的頻道。先幫這個頻道取個名字，例如「AI Referral」；接著設定條件，維度選 Source（來源），比對類型選 matches regex（符合規則運算式），再把前面整理好的網域清單組成一條正規表達式貼進去。官方文件列出來可以拿來比對的維度只有 Campaign ID、Campaign name、Default channel group、Manual ad content、Medium、Source、Source platform 這幾個，Source 是其中之一，matches regex 也是 GA4 既有的比對類型，不是額外開發的功能。

這個畫面同樣值得截圖記錄，截頻道條件設定畫面，讓 Source、matches regex、以及貼進去的 regex 字串都同時出現在畫面裡。日後 regex 清單要更新時，這張截圖能提醒自己當初的設定長什麼樣子，避免改到一半忘記原本規則寫在哪個維度上。

順序決定一切，AI 頻道沒排到 Referral 上面就抓不到

這是整個設定過程最容易漏掉、卻也最關鍵的一步。GA4 比對頻道規則是由上而下，比對到第一個吻合的規則就採用，新建的 AI 頻道如果被排在 Referral 下面，AI 推薦來的流量會先被符合任何外部網域這條寬鬆的 Referral 規則吃掉，永遠輪不到後面才比對的 AI 規則。官方文件把這個機制寫得直接，原文「Traffic is included in the first channel whose definition it matches given the current order of channels in the group.」，順序決定了誰先攔截到這筆流量，不是規則寫得多精確就會自動被優先套用。

設定完新頻道之後，一定要回到頻道清單，把 AI 頻道拖曳到 Referral 的上方，再存檔。這個排序動作值得單獨截一張圖，截「重新排序」畫面，讓 AI 頻道被拖到 Referral 之上的排列結果直接呈現出來，一眼就能確認順序有沒有調對。少了這一步，前面設定的 regex 再精準也是白做工，流量根本不會走到那條規則。

用 DebugView 和即時報表核對流量分類結果

設定完不能就假設它一定有用，得真的驗證一次。作法是自己實際操作一次，在 AI 工具裡問一個問題，讓它回答時引用到你自己的網站，再點擊那則引用連結進站。接著打開 GA4 的 DebugView，看這次點擊觸發的 session_start 事件，確認裡面的 source 欄位真的寫著預期的 AI 網域，而不是空白或別的字串。

驗證完事件本身沒問題，再切到即時報表，把頻道群組的切換器換成剛剛建立的自訂群組，確認這筆工作階段真的被歸進新設的 AI 頻道，而不是還停留在 Referral 裡。這兩步都做完，才能確定 regex 規則跟排序都設定對了，不是憑感覺猜它應該有生效。這個畫面同樣可以截圖存證，截 DebugView 裡看得到 source 欄位的事件流，或即時報表裡新頻道已經出現流量的畫面。

探索報表的規則過濾，不動全站設定先驗證

如果還不想直接動全站的管道群組設定，有一個更輕量的做法可以先試，打開「探索」，建立一份自由形式（Free Form）報表，把維度換成 Session source，篩選條件選「與規則運算式相符」，貼上跟前面一樣的那組 regex，就能只看到 AI 相關的流量，不會影響任何人看到的標準報表。

這個做法跟正式建立管道群組，本質上差別很大。探索報表是私人工作區，雖然可以分享給特定人，但不會出現在別人打開標準報表時看到的畫面裡；管道群組一旦存檔，則是全公司看報表的人都會看到同一份分類，一旦分類錯了，影響的是所有人的判斷依據。也因為這樣，探索報表很適合拿來先測試 regex 寫得對不對，測試沒問題之後，再決定要不要正式做成前面談到的自訂管道群組，讓它變成大家都看得到的標準分類。

自訂管道群組能追回歷史資料，內建頻道無法回溯

這是很多教學混在一起講、卻其實完全不一樣的兩件事。自訂管道群組套用的時候，是拿現有已經收集好的 Source 欄位重新分類，也就是說，不管這筆流量是三個月前還是三年前收集的，只要 Source 欄位裡本來就寫著那個 AI 網域，建立規則的當下就能立刻套用回去。官方文件直接寫明，原文「Custom channel groups can be applied to your reports retroactively.」，這代表就算過去從沒特別處理過 AI 流量，現在建好規則，過去的資料一樣能被重新歸類。

內建的 AI Assistant 頻道則完全不是這麼運作的。它是在資料收集的當下，就把 Medium 欄位直接寫成 ai-assistant，這個標記動作發生在流量進站的那一刻，而不是事後才回頭比對。2026 年 5 月 13 日之前收集的流量，當時系統還沒有這個標記機制，自然也就沒有被寫進 ai-assistant 這個值，官方公告裡也沒有提到任何補寫或重新分類舊資料的機制。把這兩份文件放在一起看，只能推論出目前沒有回溯機制，還稱不上「官方證實無法回溯」，因為公告本身沒有正面否定回溯這件事，只是沒有提供任何回溯的做法。也就是說，如果你需要完整的 AI 流量趨勢，想看到功能上線之前的資料，那份資料只會存在於自訂管道群組重新分類之後，不會出現在內建頻道裡。

日常追蹤用內建頻道，嚴謹交代要三層一起上

前面談了這麼多做法，實際上該怎麼選，要看這份數字是拿來做什麼用。如果只是想每天打開報表、順手看一眼 AI 推薦來了多少人，內建的 AI Assistant 頻道已經夠用，它不用設定，涵蓋了官方目前認定的幾個主要平台，拿來當日常參考已經足夠。

但如果這份數字是要交給主管、客戶，或者寫進一份要站得住腳的成效報告，就不能只靠內建頻道，得三層一起上。第一層是內建的 AI Assistant 頻道，涵蓋官方認定的那幾個平台；第二層是自訂管道群組，補上 Perplexity 這類還沒被內建頻道涵蓋的來源，也把回溯到更早的資料一併補齊；第三層則是在報表上老實加註一句「這是看得到的下限，不是全貌」，因為有一部分 AI 流量無論設定得多完整，靠 referrer 這個機制本身就抓不到。三層合在一起看，才是這件事在 GA4 裡能給出的最誠實答案，單靠任何一層都只是半張圖。

抓不到 referrer 的流量，是結構限制不是設定沒做好

不管 regex 寫得多精準、管道群組排序調得多對，AI 推薦流量的數字永遠只會是看得到的那一部分，問題不在設定，而在 referrer 這個機制本身有先天限制。行動裝置上 App 內建的瀏覽器，常常整個不會把 referrer 傳出來；使用者把 AI 回答裡附的網址複製起來、貼到瀏覽器分頁裡打開，這種操作路徑本來就沒有 referrer 可循；部分瀏覽器的隱私設定，也會主動把來源資訊擋掉，不讓它傳遞給下一個網站。這些狀況跟 GA4 設定對不對完全無關，是整個 referrer 機制本來就有的結構性缺口。

其中 Grok 是最明確的一個案例。Statcounter 自己在做 AI 聊天機器人的流量統計時，就直接把 Grok 排除在計算範圍之外，原文寫著「Grok cannot be included in the data, as unlike the other chatbots, it does not provide referral data in its header.」。這是目前查得到最明確、也最具名的一個佐證，不是憑印象說聽說很多流量抓不到這種模糊講法。也因為這樣，這裡沒辦法給出一個精確的百分比去描述抓不到的比例，查不到一份查證得過的具名數據支持某個具體數字，只能說有相當一部分 AI 流量會落在這個結構性的盲區裡，這是使用 referrer 比對這套機制時本來就要接受的限制，不是哪一步設定沒做好。

regex 清單需要跟著新平台崛起定期更新

referrer 抓不到是結構性的天花板，操作者自己能掌握的，是 regex 清單跟不跟得上市場變動的速度；而 AI 助手這個市場版圖，變動的速度比大多數 SEO 從業者習慣的節奏快得多。Statcounter 自己的月度數據就是很好的佐證，Claude 在 2026 年 2 月到 3 月，短短一個月內占比就從 1.37% 衝到 2.91%，翻了超過一倍；Gemini 的成長幅度更明顯，從 2025 年 4 月的 2.31%，一路成長到 2026 年 3 月的 8.65%；相對地 ChatGPT 則是從 2025 年 4 月的 84.21%，一路降到 2026 年 3 月的 78.16%，首度跌破八成。半年前寫好、覺得夠用的 regex 清單，半年後很可能就已經漏接了正在崛起的新平台。

實務上的做法，是定期，例如每一季，回頭檢查 Referral 報表裡有沒有出現含 chat、assistant、ai 這類字樣、卻沒被目前規則吃到的新來源，一旦發現就補進 regex 裡。同時也要記得前面提過的現象，官方 AI Assistant 頻道認定的平台清單自己也在變動，寫作當下最新的名單，不保證半年後還是同一份，實際操作時該以當下打開官方定義頁看到的現行版本為準，不要死記任何一份寫死的清單，包括這篇文章列出的這幾個平台。

GA4 能不能把 AI 推薦流量看清楚，關鍵始終是 referrer 這個機制傳不傳得出來，設定規則只是把傳得出來的那部分盡量整理乾淨。內建頻道、自訂管道群組，加上那句「這是下限、不是全貌」的老實加註，三層一起兼顧，看到的數字才站得住腳；之後市場版圖再怎麼變，定期回頭檢查 regex 跟官方定義頁，就是能持續跟上的做法。