Gemini UTM 開始出現在部分 Gemini 外連後，網站經營者最先要做的不是宣布 AI 流量成長，而是保存完整落地網址、建立獨立分群，並同步觀察 Direct 流量是否下降。這個新訊號讓部分到站工作階段更容易辨識，卻還不能證明引用、排名、點擊總量或轉換增加。
目前 Google 尚未正式文件化哪些 Gemini 介面、哪些連結會附加標記。本文會把已觀察到的事件、證據限制與可回復的量測步驟分開，協助你用 Gemini UTM 建立第一版基線，又不破壞既有 Organic Search 與 Direct 報表。
Gemini UTM 事件：目前能確定什麼？
一名 Reddit 使用者回報 Gemini 外連開始加入 UTM，另一名使用者則表示在來源連結看到 ?utm_source=gemini。Google Search Advocate John Mueller 在同一討論中回覆，他也看到了這種標記；Search Engine Journal 隨後報導這項觀察。
這些證據足以支持「部分外連已出現 Gemini UTM」；但 Mueller 的回覆不是產品公告，也沒有說明推出日期、涵蓋介面與固定參數。現階段應把它視為值得開始監測的新訊號，而不是已完成全球部署的正式規格。
UTM 改善的是哪一層量測？
Google Analytics 官方文件說明，流量來源維度用來分析使用者與工作階段從哪裡來；UTM 參數可提供 source、medium、campaign 等資訊，並出現在報表與探索中。對網站營運者而言，Gemini UTM 改善的主要是「點擊後到站」這一層的來源辨識。
- AI 回答是否出現品牌或內容。
- AI 回答是否引用或連到網站。
- 使用者是否點擊連結並抵達網站。
- 到站後是否完成表單、購買或其他關鍵事件。
新標記主要幫助第 3 層。第 1、2 層仍要靠各自的 AI 能見度或引用觀察，第 4 層則要回到網站事件與轉換資料。四層不能互相代替。
Gemini UTM 還有哪些未知？
目前最重要的限制是：Google 沒有公開說明標記何時觸發，也沒有列出 Gemini 網頁版、行動 App、助理介面或不同連結類型的覆蓋範圍。Index Lab 的交叉整理因此建議把早期數字視為下限，而不是完整的 Gemini 導站總量。
Reddit 討論中有人提出行動 App 的 referrer 傳遞率約 9%，並稱 Android assistant 可能移除 referrer；Mueller 也要求提供可重現資訊。這仍是單一使用者陳述，沒有官方文件或獨立重現，因此不應把 9% 當成平台整體統計，也不應用它回推遺漏流量。
- 不能假設全覆蓋：沒有 Gemini UTM 的訪次，不代表一定不是 Gemini 帶來。
- 不能先猜參數：除了直接觀察到的值，source、medium 與 campaign 應從自己的落地網址讀取。
- 不能把分類改善當成成長：能辨識來源，只代表歸因更清楚。
先辨認分類搬移，再談流量成長
如果過去一部分 Gemini 訪次因缺少可辨識的 referrer 或 UTM 而落入 Direct，新標記出現後，報表可能看到 Gemini UTM 工作階段上升、Direct 同時下降。這種變化可能只是同一批訪次被重新分類。
| 觀察結果 | 較合理的初步解讀 | 還要檢查什麼 |
|---|---|---|
| Gemini 分群上升，Direct 近似幅度下降 | 可能是來源分類改善 | 全站 sessions、落地頁與轉換是否持平 |
| Gemini 分群上升，全站 sessions 也上升 | 可能有新增點擊，但尚未證明因果 | 同週行銷活動、季節性、事件與裝置分布 |
| Gemini 分群上升，轉換沒有變化 | 可見點擊增加或重新分類，不等於商業成果 | 轉換率、事件設定、落地頁品質與樣本量 |
| GA4 沒看到標記，log 有 query string | 可能是分析收集、同意或規則問題 | GA4 標籤、Consent Mode、重新導向與事件時間 |
因此第一週不要只截一張「Gemini 流量暴增」圖表。至少把 Gemini 分群、Direct、全站 sessions 與同一組關鍵事件放在一起，才有機會分辨新增需求與報表搬移。
用 Gemini UTM 建立可回復分群
早期規格仍可能改變，最安全的做法是先建立「可以撤回、可以改版、不覆寫歷史」的規則。這樣即使之後 Google 補充文件或參數值改變，也能更新 Gemini UTM 分群，而不必重算整套 Organic Search 報表。
第一步：保存完整落地 URL
從真實 Gemini 外連測試，保存瀏覽器抵達時的完整網址與 query string，並記錄日期、介面、裝置、落地頁及實際參數。若只看到 utm_source=gemini，就只記這個值；不要為了報表整齊自行補造 medium 或 campaign。這份原始紀錄是後續調整 Gemini UTM 規則的依據。
第二步：在 GA4 先做獨立探索分群
先在 GA4 探索中查看實際的 session source、medium 與 campaign，再建立暫時的 Gemini UTM 分群。保留規則生效日與版本，不要回寫過去的 Direct，也不要直接併入 Organic Search。等參數組合與涵蓋介面較穩定，再決定是否調整正式自訂管道群組。
第三步：比對伺服器紀錄與重新導向
確認 CDN、反向代理、重新導向與應用程式是否保留 query string，再從 server 或 edge log 找相同參數。伺服器紀錄是 HTTP request，GA4 則以 session 與事件為主，兩邊總數不會自然相等；比對重點是日期、落地頁、參數與時間窗是否能互相印證。
若伺服器沒有保存 query string，應先把狀態記成「未記錄」，不能直接解讀成「沒有 Gemini UTM 流量」。調整 log 格式前也要依網站的隱私、安全與保存政策處理，不要無限制收集個人資訊。
Gemini UTM 的四週量測基線
建議從分群規則生效日開始，先保留四個完整週作為第一版觀察窗；流量很低時可延長。四週不是平台保證的統計門檻，而是避免被單日波動牽著走的營運做法。每週固定同一天讀取同一組欄位，規則變更則另開版本。
先固定期間與規則版本
- 來源量：Gemini UTM sessions、Direct sessions、全站 sessions。
- 承接頁：landing page、裝置類別、國家／地區；只使用現有合法可用的維度。
- 結果：指定 key events、轉換數與轉換率。
- 品質註記：參數缺漏、重新導向遺失、GA4 與 log 差異、規則版本。
用三種結果判讀變化
只有分群增加：若 Direct 下降而全站與轉換近似不變，優先判斷為重新分類。總量一起增加：若全站 sessions 與相同落地頁也上升，才進一步排除其他活動與季節因素。結果一起改善：若關鍵事件與轉換率也改善，再檢查頁面、受眾與樣本量，不能只因 Gemini UTM 同期出現就斷言因果。
避免三種常見誤判
- 把標記出現當成全平台覆蓋：目前觸發情境未文件化，早期可見數量只能當下限。
- 把新分群上升當成新增流量：一定要和 Direct、全站 sessions 及固定期間一起看。
- 把可辨識點擊當成 GEO 成效：Gemini UTM 不會證明排名、引用、曝光或轉換提升，這些指標各自需要證據。
結語：先把可見度變化量準
Gemini UTM 的價值，是讓部分原本難辨識的到站點擊多一個可追蹤訊號。現在最實用的成果不是一張成長圖，而是一套能保留原始網址、區分 Direct 搬移、連回事件轉換，而且日後可撤回或改版的基線。
先用實際參數建立獨立分群，連續觀察固定期間，再等待 Google 補上正式文件。這樣即使涵蓋範圍或參數規則改變，你仍能保留前後版本，避免把報表分類改善誤當成新的市場需求。
Gemini UTM 常見問題
Gemini UTM 是 Google 已正式公告的功能嗎？
目前不是。多名使用者觀察到外連標記，John Mueller 也回覆他看到了，但 Google 尚未發布 Gemini 專屬文件，說明推出時間、介面範圍、觸發條件與完整參數。因此只能把它當成已出現、但涵蓋仍未知的量測訊號。
Gemini 流量要直接併入 Organic Search 嗎？
現階段不建議直接合併。先在 GA4 探索或獨立報表分群中保存實際 source、medium 與 campaign，並記錄規則版本。這樣不會破壞既有 Organic Search 趨勢，日後有官方文件時也比較容易調整。
為什麼要同時看 GA4 與伺服器 log？
GA4 適合分析 session、事件與轉換；server／edge log 可確認網站實際收到的 request 與 query string。兩者計算母體不同，數量不必相等，但能交叉檢查參數是否抵達、重新導向是否保留，以及分析標籤是否正常收集。
Gemini sessions 變多，就代表 AI 流量成長嗎？
不一定。若 Direct 同時下降，而全站 sessions 與轉換沒有明顯改變，較可能是原本無法辨識的訪次被重新分類。只有把 Gemini UTM、Direct、全站總量與同一組關鍵事件放在固定期間比較，才適合進一步判讀。
