UTM 到了 GA4 卻顯示 direct，怎麼逐步排查？

沿著連結、轉址、頁面載入、事件與報表逐步檢查，找出 UTM 來源資料在哪一站消失。

UTM 已經放上連結，GA4 卻把造訪列為 direct / (none)，不一定代表參數無效：資訊可能在點擊前寫錯、跳轉時被移除、落地頁標籤沒讀取，或你看的報表維度與資料範圍不同。先別補造活動名稱，也不要只因一個報表欄位空白就重做連結。沿著同一個測試點擊，逐站記下網址、頁面載入和事件，再對照工作階段來源，找出資料第一次消失的位置。以下步驟也協助分開判斷「事件沒到」與「來源沒留下」這兩種問題。為避免測試路徑不同，先固定瀏覽器、連結版本與時間，每次重現一個入口；之後切換報表比較時，也保留當時所選維度。

先確認連結上的參數

UTM 到達落地頁，先查的是「使用者實際點到哪一條」，而非你記錄在試算表裡的版本。從社群貼文、電子郵件或廣告預覽複製一次連結，確認問號前是正確網域與路徑，問號後以 & 分開每組名稱和值；utm_source、utm_medium、utm_campaign 拼字要完整，值也要採一致大小寫。Google Analytics 會把大小寫不同的值分成不同來源名稱，缺欄位時則可能出現（not set）；它建議為相關活動補齊來源、媒介和活動名稱。Google 的 UTM 說明可對照欄位用途。再看特殊字元：空格、中文、&、#若未編碼，可能被當成分隔符或片段，而不是參數內容。

實際點擊後，立即看瀏覽器網址列，並保留點擊前網址作比較；不要只檢查貼文原始文字。若原始連結有 utm_source，但第一個開啟頁已沒有，先查分享平台的連結包裝或短網址；若第一頁還在、跳到正式網域後消失，問題通常在中間轉址。用瀏覽器開發者工具查看網路請求中的重新導向回應及 Location 目的網址，逐跳抄錄完整 URL，再與最後網址比對。常見原因是轉址規則只保留路徑、不允許查詢字串，或目的網址由程式重建卻漏掉參數。

再檢查參數是否重複出現，像 utm_source 在問號後、片段後或第二次問號裡各有一份，瀏覽器與程式可能讀到不同值；務必以最終 URL 的實際文字為準。若連結含錨點，片段標記 # 通常不會隨 HTTP 請求送到伺服器，所以 UTM 要放在片段之前；不可只看產生器預覽，應點開成品。若從通訊軟體複製，確認句號或右括號沒有被一併納入網址。將測試結果另存一份，避免事後改寫而失去重現線索。也檢查分享平台是否把可見文字和真正的點擊目標分開設定，兩者不一致時以點擊後的實際網址為準。

跳轉過程會移除什麼

下面是定位用的假設示例，不代表任何網站實測：

若跳轉全程都保留，勿先把同網域改寫、斜線補正或語言切換一概當成故障；這些步驟只有在實際丟掉查詢字串時才是原因。Google 將轉址移除 UTM 列為 direct / none 的可能來源，並建議檢查最終落地連結。官方說明也提到短網址可能失去來源訊息。依表找出第一個缺值的回應，修好後用同一條連結重走一次；如果到站網址完整，才把排查焦點交給頁面載入和標籤。

每一跳都需要記錄狀態碼和 Location，而不只是最終落地頁；若開發者工具已保留舊紀錄，清空後再點一次，避免把之前的導頁誤認為這次路徑。對照時先找第一個把 utm_* 移除或改寫的環節，確認它是否由網址縮短服務、網站伺服器、前端導頁、語系選擇或登入流程產生，再由該層負責人檢視保留查詢參數的設定。不要為了測試而任意關閉安全或登入機制；可在有權限的測試頁重現相同跳轉規則。若 Location 是相對網址，也要以當前網域合成完整目的地後再檢查。

若各跳都保留參數，下一個區分點不是「有沒有轉址」，而是到站請求是否仍帶完整查詢字串；只有全程保留才移至標籤診斷。如果最後一跳才改成不帶參數，修正最後一跳並不會補回前面已丟失的資料；要確認實際進站請求仍含標記。只在整條鏈路保留時才往 GA4 設定查。

頁面載入如何測試

落地頁到站後，確認頁面是否真的讀到帶有 UTM 的那次載入。先以乾淨瀏覽器視窗開啟測試連結，在網址列核對最終網址，再記錄頁面開始載入、同意選項出現、選擇後及後續導頁的先後順序。不要只看畫面顯示成功；在瀏覽器開發者工具的網路請求紀錄中，確認 Analytics 收集請求是否發出、是否被瀏覽器攔截，以及請求屬於預期的資料串流。若頁面載入後立刻以程式清除查詢字串，檢查標籤是否在清除前讀到來源；可暫時讓測試頁保留參數，或在程式中記錄讀值結果，兩者擇一驗證，不要用猜測補回 campaign。

接著把同一次測試拆成兩個問題：事件有沒有送出，來源值有沒有在送出前被記住。若沒有任何收集請求，先查標籤是否安裝在此網域、載入條件是否成立、Measurement ID 是否指向預期串流，以及同意設定是否允許分析儲存；改變同意選項只用在獲准的測試情境，不拿它推論所有訪客。若請求存在而事件資料不完整，再檢查標籤啟動時機、跨頁轉換及瀏覽器重新整理後狀態是否改變。測試時一次只改一項，保存每步的網址和時間，才能分辨是頁面清除、標籤延遲，還是請求根本沒送到。

若站內有多個網域，從來源頁到結帳或登入頁逐頁走一次，確認跨網域轉換後仍是同一個預期工作階段；看到新網域本身不等於 UTM 丟失，只有參數、工作階段或來源識別實際改變才有診斷價值。也要比較直接開落地頁與經跳轉到達的結果：前者成功、後者失敗，指向跳轉或連結包裝；兩者都沒有來源而頁面事件也缺席，先回頭查標籤。把測試做在不影響正式轉換的環境或低風險頁面，避免為追蹤而更改訪客同意、付款或登入流程。

GA4 報表要看哪些維度

到 GA4 後先選 Traffic acquisition（流量開發）類報表，將主維度切到 Session source / medium，並同看 Session campaign。它們描述工作階段來源；User acquisition 使用首次使用者來源，回答的是另一個問題，兩者不同不代表其中一份資料壞掉。Google 對兩份報表的範圍說明可協助選對維度。用測試 URL 中唯一且易辨認的活動名稱篩選，再核對 source、medium 是否成對出現。若只看預設管道群組，UTM 的值可能被歸進規則分類；若看到 direct / none，代表這次工作階段沒有清楚可用的來源訊號，不能單憑它判定訪客手動輸入網址。

另一個常見誤判，是在落地頁或頁面路徑維度找 UTM。Google 說明 UTM 不會出現在 Landing page + query string 或 Page path + query string 這兩個維度，參數資料會在 Page location 維度；因此頁面報表看不到 utm_source，不足以證明 GA4 沒收到它。URL builder 說明列出此差異。對照報表時也固定日期範圍、資料串流、篩選器和比較條件；確認沒有排除測試流量的篩選，並留意最近才發生的造訪尚未出現在非即時報表。若來源在工作階段維度正確、僅頁面維度空白，應先改檢視方式，而不是重寫 UTM。

建議用一個簡單判斷順序：工作階段來源正確，事件或轉換數字才是下一層；source 有值但 campaign 空白，回查 utm_campaign；整組是 direct / none，回看轉址、同意和載入；工作階段尚未出現，先看即時驗證與時間範圍。若同一瀏覽器重複測試，先清楚標示每次的來源與時間，避免把前一次工作階段或不同報表範圍混在一起。建立自己的對照記錄即可，不要用不同維度的指標互相硬湊成一個因果結論。若以事件來源欄位回答工作階段問題，答案可能和 Session source 不同；先確認問題是新工作階段的入口，再選對欄位。

事件接收怎麼單獨驗證

來源排查與事件接收要分開驗證。用一次受控造訪檢查即時報表或 DebugView 是否出現預期頁面事件，並同步記下實際網址和事件發生時間；可見事件表示至少有資料送到所看的資源，但不等於工作階段來源也正確，更不表示轉換歸因已完成。若即時看不到事件，回到前一節檢查標籤、串流和同意條件；若事件出現卻仍是 direct，回到 URL 與來源維度，不要把事件數為零當成 UTM 錯誤。先確認報表指向同一個 GA4 資源，否則測試事件可能被送往別處。

若網站是用 Measurement Protocol 補送伺服器事件，官方驗證端點只能檢查請求格式，送到驗證端的事件不會出現在報表，所以不能以成功回應作為正式資料已接收的證據。Google 的事件驗證文件明確說明這個限制。一般網頁標籤的檢查則回到瀏覽器請求和 GA4 即時呈現，不要為這篇排查任意新增伺服器追蹤。每次驗證只記三項：預期事件、實際收到的事件、同次工作階段來源。如此可定位故障是在網頁未送出、送錯資源，還是來源標籤未被接收。

觀察延遲時，別用「我剛點完但報表還沒變」直接判作失敗。先在測試當下確認請求已送出，再看即時資料；之後回到流量報表檢查該日期與工作階段維度。若事件先到、歸因欄位後續仍空白，保存測試時間、完整落地網址、報表維度與篩選條件，請有權限的分析管理者核對資源設定。若只有特定瀏覽器或同意狀態失敗，記錄該條件並重複一次作交叉比較；若所有測試都失敗，先比對資源與標籤，而非把指標變動解釋成流量來源變了。

哪些情況仍無法歸因

有些造訪本來就不會留下可用來源線索。使用者可能手動輸入網址、從書籤或離線文件開啟；轉址、短網址、隱私保護或瀏覽器擴充功能也可能移除參照資訊或阻擋分析請求。GA4 將沒有明確參照來源的工作階段列為 direct / none，並指出參數缺漏、轉址和阻擋追蹤都可能造成這種結果。官方說明因此應視為可能原因清單，仍需依前面步驟找出本次流量的證據，不能只憑通道名稱斷言是哪一項。

跨網域、從應用程式內建瀏覽器切到外部瀏覽器、同意尚未給予、工作階段中途再訪，都是應分別記錄的情境；不要將它們一律歸為 UTM 格式錯誤。對每個無法判定的樣本，標出「連結缺值」「跳轉移除」「頁面未送事件」「事件到達但報表維度不同」或「現有訊號不足」，只在觀測支持時選類別。來源不明時保留 unknown，比把 direct 強行分配給某個活動可靠。再依營運需要決定未來是否採更嚴謹的命名、轉址保留或同意後測試流程；這是量測品質改善，不會替已流失的來源補造證據。

若同一支連結只有部分瀏覽器能歸因，按瀏覽器、同意狀態和入口分組記錄，不要把測試結果外推到全部訪客。若目前只能看到報表匯總、無法對應單次點擊，就說明「尚不能確認」；待下次活動加上可辨識標記，累積新證據再評估。

最後一步是拿一條真實待檢連結，保存原始 URL、逐跳目的網址、落地頁讀值、事件接收和 Session source / medium；找到第一個缺失點，只修該層，再完整重跑一次。查看 ThreadScout 公開資訊：ThreadScout