GA4追蹤國內AI來源流量：一套可複核的方法

核心結論：不要先照抄一份“國內AI來源域名正則”。更可靠的做法是先確認GA4採集正常，再導出網站實際收到的來源值，經過人工核對後建立分類規則。對於能夠控制的連結，用UTM補充標記；對於來源和轉化結果，再用伺服器日誌與站內事件交叉核對。

想知道AI推薦有沒有把用戶帶到網站，不能只看GA4裏有沒有出現某個AI產品的名稱。

GA4記錄的是瀏覽器和採集配置實際傳來的來源、上一頁地址、UTM參數及事件數據。來源資訊沒有傳過來時，GA4不會自動判斷訪問者此前是否使用過AI產品。

國內AI產品的App版本、跳轉方式和隱私策略並不完全相同，目前也沒有一份穩定、完整的官方國內AI來源域名清單。因此，這項工作的重點不是一次整理出所有域名，而是建立一套可以持續核對、定期更新的方法。

先弄清楚：GA4能看到什麼

GA4裏有兩類重要資訊，但它們回答的不是同一個問題。

“會話來源/媒介”回答的是：這次訪問被GA4歸到了哪個來源和渠道。它適合用於分析一次會話從哪裏進入網站，應在“流量獲取”報告中查看。分析AI帶來的訪問時，應優先使用會話範圍的來源維度，不能拿“首次用戶來源”代替。GA4流量來源維度、用戶獲取與流量獲取的區別

page_referrer回答的是：瀏覽器有沒有把上一頁網址傳給GA4。它是GA4自動收集的參數，可用於核對訪問發生前的頁面。但在App內跳轉、瀏覽器限制引薦資訊、重定向或沒有傳遞上一頁地址時，這個參數可能缺失，也可能發生變化。GA4自動收集的page_referrer

這兩個字段不能合併成同一列，也不能互相替代。

同一次AI推薦，可能留下清楚的引薦來源，也可能被記為direct / (none)，還可能因為短鏈、跨域或中間跳轉頁，被記錄成其他來源。

direct / (none)也不等於用戶一定是在地址欄裏直接輸入了網址。它只表示GA4沒有獲得明確的引薦來源。連結沒有UTM參數、重定向清除了參數、使用了短鏈或受到廣告攔截工具影響，都可能產生這一結果。GA4的direct流量説明

所以，GA4能告訴你的，是採集系統實際收到了哪些信號；它不能還原“用戶是否受到AI影響”的全部過程。

第一步：先確認GA4採集正常

在研究AI來源之前，先排除採集本身的問題。

網站需要部署Google tag，或者通過Google Tag Manager，也就是GTM，部署GA4配置。GTM中的Google tag可以發送自動收集事件和增強型衡量事件，也可以配置相關參數。在GTM中設置GA4

部署完成後，可以按下面的順序測試：

1. 為目標落地頁生成一條帶測試UTM參數的連結。
2. 通過這條連結訪問網站。
3. 在GA4實時報告中查看來源、媒介和廣告系列是否出現。
4. 打開DebugView，也就是GA4的調試視圖，核對表單提交、電話點擊等站內事件是否正常觸發。

實時報告可以查看最近5分鐘和30分鐘內的來源、媒介及廣告系列，適合快速確認數據有沒有傳進GA4。但它的歸因能力有限，正式分析仍應回到流量獲取報告和探索數據。GA4實時報告

如果自定義事件還攜帶了其他參數，需要把相應參數註冊為自定義維度或指標，才能在標準報告中穩定查看和使用。GA4事件參數

第二步：導出網站真實收到的來源值

採集確認正常後，不要急着猜哪些域名屬於AI，先看網站自己的數據。

進入“報告—獲取—流量獲取”，把主維度切換為“會話來源/媒介”，查看近30天的數據；如果業務週期較長，也可以選擇更長的時間範圍。GA4流量獲取報告

接着進入“探索—自由形式”，新建一張表格，至少加入以下內容：

• 維度：會話來源/媒介、着陸頁加查詢字符串、網頁引薦來源。
• 指標：會話數、互動會話數、關鍵事件數。
• 篩選條件：保留主要落地頁，排除內部測試和已經確認的垃圾流量。

GA4探索報告可以組合維度、指標、篩選條件和細分，並支持導出CSV、TSV等格式，便於進一步核查。GA4探索

數據導出後，不要看到陌生域名就立即標記為AI來源。每一個準備納入規則的值，都應核對以下問題：

• 這個值是否真實出現在會話來源或page_referrer中？
• 它能否在後續測試中穩定復現？
• 它是否可能來自短鏈、重定向、中間頁或普通網頁？
• 同一來源在不同訪問中是否保持相對一致？

只有經過核對的來源值，才適合進入正式的分類規則。

第三步：用已驗證的數據建立AI來源規則

確認來源值後，可以在GA4屬性中創建自定義渠道組，新增“AI助手”渠道，並把它放在Referral，也就是引薦渠道之前。這樣，已經確認的來源值可以優先匹配AI助手規則。

規則表至少應保留以下5項資訊：

字段	用途
實際來源值	保存GA4或page_referrer中出現的原始值
證據位置	標明該值來自哪份報告或導出數據
首次出現時間	記錄該來源從什麼時候開始出現
最後驗證時間	確認該值目前是否仍然有效
負責人	明確由誰複查和更新

只有已經在自家網站數據中出現，並經過人工核對的值，才應加入正則表達式。規則上線後，可以按月檢查新增來源、失效來源和誤分類情況，再更新渠道條件。

Google的自定義渠道組文檔提供了AI助手正則示例，同時也提示：URL或名單發生變化時，需要更新表達式。GA4自定義渠道組

需要特別注意：這個示例不是國內AI產品的官方域名清單，也不代表GA4能夠識別全部AI訪問。網上流傳的舊域名列表可以作為排查線索，但不能在未經驗證的情況下直接用於正式歸因。

第四步：可控連結統一添加UTM

UTM是添加在網址後面的來源標記參數。對於自己能夠控制的連結，應優先使用統一的UTM命名。

例如：

• 內容合作連結；
• AI產品內自建智能體的資料卡；
• 客服主動發送的落地頁連結。

這些連結可以統一設置為：

?utm_source=ai_assistant&utm_medium=referral&utm_campaign=geo_content

團隊內部應統一使用小寫，並固定source、medium和campaign的命名字典。連結發佈前，還要進行一次實際跳轉，確認經過重定向後，UTM參數仍然保留。

GA4會把utm_source、utm_medium和utm_campaign記錄到流量獲取報告中，而且參數值區分大小寫。AI_Assistant和ai_assistant會被記錄成兩個不同的值。GA4網址構建工具

UTM只能解決可控連結的標記問題。它不能補回第三方自然推薦中沒有傳遞的引薦資訊，也不能證明所有帶有該參數的訪問，都來自某個AI產品的自然推薦。

第五步：用伺服器日誌確認請求是否到站

GA4記錄的是分析平台收到的數據，伺服器訪問日誌記錄的則是請求有沒有真正到達網站。

建議伺服器日誌至少保留以下資訊：

• 請求時間；
• 落地URL及查詢參數；
• Referer字段；
• HTTP狀態碼；
• User-Agent。

核對時，可以把日誌裏的請求時間、落地頁和UTM參數，與GA4中的會話記錄進行對照。

如果日誌中存在Referer，可以用它確認瀏覽器傳來的上一頁資訊。如果日誌中沒有Referer，只能説明這次HTTP請求沒有提供這個字段，不能據此認定該訪問一定不是AI帶來的。

伺服器日誌能夠確認請求事實，不能説明用戶為什麼訪問網站。

如果需要從服務端補充線下事件或後端事件，可以使用GA4 Measurement Protocol，也就是GA4的服務端事件傳輸方式。但Google明確説明，它用於補充網站或App採集，不能替代正常的瀏覽器或軟件開發工具包採集。GA4 Measurement Protocol

第六步：把AI訪問與業務結果對應起來

如果只知道訪問來自哪裏，卻不知道用戶進入網站後做了什麼，就無法判斷這些訪問有沒有產生業務價值。

可以通過GTM或站點代碼追蹤以下動作：

• 提交表單；
• 點擊電話號碼；
• 複製聯繫方式；
• 下載資料。

事件採集完成後，再把真正代表業務結果的動作標記為關鍵事件。

最終看板至少應保留4類證據：

證據類型	回答的問題	常用字段或工具	不能單獨證明什麼
GA4會話歸因	這次會話被歸到了哪裏	會話來源/媒介、廣告系列	不能識別所有受到AI影響的訪問
UTM標記	可控連結採用了什麼來源名稱	source、medium、campaign	不能覆蓋不可控的自然推薦
伺服器日誌	請求是否真正到達網站	URL、Referer、狀態碼、User-Agent	沒有Referer不等於不是AI訪問
站內轉化	訪問後完成了什麼動作	表單、電話、複製、下載	不能補回已經缺失的來源資訊

復盤時，先查看會話來源，再核對落地頁和伺服器日誌，最後分析關鍵事件。只有這些數據能夠互相對應，結論才經得起復查。

結論：追蹤AI流量，關鍵不是一份域名錶

國內AI產品的來源域名、App跳轉方式和隱私策略都可能變化。試圖用一份固定正則一次解決全部識別問題，結果很容易失真。

更可靠的做法，是把整個過程拆成6步：

1. 驗證GA4採集和站內事件是否正常；
2. 導出網站實際收到的會話來源與引薦資訊；
3. 人工核對來源值，再建立自定義渠道規則；
4. 為可控連結統一添加UTM；
5. 用伺服器日誌確認請求是否到達；
6. 用關鍵事件判斷訪問是否產生業務結果。

這套方法不能識別所有受到AI影響的用戶，但它能明確告訴你：哪些結論有數據支持，哪些來源仍然無法確認，以及當前的分類規則依據什麼建立。

FAQ

GA4能識別所有AI流量嗎？

不能。GA4只能處理實際收到的來源、page_referrer、UTM和事件數據。App內跳轉、隱私策略、缺少引薦資訊及重定向等情況，都可能讓來源缺失或發生變化。

direct / (none)就是用戶直接輸入網址嗎？

不一定。它表示GA4沒有得到明確的引薦來源。缺少UTM、重定向剝離資訊、使用短鏈和受到廣告攔截工具影響，都可能讓訪問進入direct。

會話來源和page_referrer有什麼區別？

會話來源是GA4對一次會話的歸因結果；page_referrer是瀏覽器傳來的上一頁網址。排查時可以同時查看，但不能把它們當成同一個字段。

能直接使用網上的國內AI域名正則嗎？

不建議。目前沒有穩定、完整的官方國內AI來源域名清單。應先從自己網站的流量獲取報告和探索數據中導出真實的會話來源及page_referrer，經過人工驗證後再維護正則。

UTM能解決所有AI來源識別問題嗎？

不能。UTM只能覆蓋可控連結。第三方自然推薦、App內跳轉，或者被重定向清除的參數，仍可能無法按照預期歸因。

為什麼實時報告和流量獲取報告結果不同？

實時報告主要展示最近發生的活動，歸因能力有限，更適合驗證採集是否生效。正式分析應以流量獲取報告和探索數據為準。

伺服器日誌沒有Referer，能判斷不是AI流量嗎？

不能。沒有Referer只説明這次請求沒有提供該字段。還需要結合落地頁、UTM、GA4會話記錄和站內行為判斷。

AI來源規則多久複查一次？

可以按月檢查新增來源、失效來源和誤分類。AI產品的跳轉方式、活動連結或網站重定向策略發生變化後，也應重新檢查。

官方來源

1. GA4流量來源維度
2. 用戶獲取與流量獲取的區別
3. GA4流量獲取報告
4. GA4自動收集的page_referrer
5. GA4的direct流量説明
6. GA4網址構建工具
7. GA4實時報告
8. GA4探索
9. GA4自定義渠道組
10. 在GTM中設置GA4
11. GA4事件參數
12. GA4 Measurement Protocol