UTM 是什麼？參數設定、GA4 歸因與實測踩坑

作者 Nick TasiAds & Code 創辦人·發布 2026-10-24·約 11 分鐘讀完

UTM 是什麼？它是加在網址問號後面、名稱以 utm_ 開頭的追蹤參數，例如 ?utm_source=facebook&utm_medium=cpc&utm_campaign=spring_sale，GA4 讀到之後，就知道這次造訪來自哪個來源、哪種媒介、哪個活動。Google 官方要求 utm_source、utm_medium、utm_campaign 三個一定要帶，而且值分大小寫，命名一亂，同一個廣告在報表裡就會拆成好幾列。

設定本身幾分鐘就會，麻煩在後面：媒介取錯名字，付費廣告會被 GA4 歸到自然社群；參數太長會被截掉；追蹤碼本身沒在跑，UTM 寫得再整齊，報表也是 0。2026 年 9 月，我們經手的一個品牌官網就因為追蹤碼包錯一層，GA4 連續 6 天一筆資料都沒有。

UTM 是什麼？常用參數各管什麼

UTM 參數是一組名稱固定的網址參數，用來標記流量從哪裡來，GA4 會把它們讀成工作階段的來源、媒介和廣告活動。Google 的網址產生器說明列了 9 個，官方寫 utm_source、utm_medium、utm_campaign 三個「you should always use」，其餘選用，最常用的是區分素材的 utm_content。

另外三個是 utm_source_platform、utm_creative_format、utm_marketing_tactic，分別記錄流量來源平台、素材類型和指定對象條件，一般網站很少用到。

Google 有免費的 Campaign URL Builder，很多人搜尋 Google UTM 產生器找的就是它，填好欄位就會組出完整網址。工具只負責把字串組起來，命名規則還是要自己定；規則沒定，每個人用同一個工具，也會組出不一樣的值。

UTM 設定怎麼做：命名規則比產生器重要

UTM 設定的重點不在用哪個產生器，而在全公司用同一套命名。Google 官方寫「Parameter values are case sensitive」，utm_source=google 和 utm_source=Google 會變成兩個來源；utm_medium 的寫法還會決定這筆流量被 GA4 歸到哪個管道，寫錯一個字，付費廣告就可能被算成自然流量。

搞懂 UTM 是什麼之後，真正花時間的是定一張固定詞彙表，建連結一律用產生器或程式組，不手打。我們給客戶的版本大致長這樣：

• 全部小寫，空格改成底線，避免大小寫不同被拆成兩列。
• utm_source 寫平台名：facebook、instagram、google、newsletter。
• utm_medium 只用少數固定值：付費廣告用 cpc 或 paid_social，自然貼文用 social，電子報用 email，合作夥伴的連結用 referral。
• utm_campaign 用活動代號加季度，例如 2026q4_launch，報表排序時才會照時間排。
• utm_content 拿來分素材；Meta 廣告直接用動態參數，不要手填。

Meta 廣告可以用動態參數自動填值，官方動態網址參數規格的範例就是 utm_campaign={{campaign.name}}&utm_content={{ad.name}}。2026 年 8 月我們在一個廣告落地頁實測，多則廣告共用同一串 UTM 沒有問題，每則都會換成自己的廣告名稱，中文名稱會被網址編碼。要注意官方寫名稱類參數「are set to the campaign, ad set or ad name used when the ad was first published」：廣告上線後再改名，網址裡的值不會跟著變，想換值只能建一則新廣告。Meta 帳號結構與追蹤的基本觀念，寫在 meta 廣告完整入門。

GA4 怎麼用 utm_medium 判斷管道

GA4 不會直接把 utm_source 當成管道，而是用來源加媒介去套預設管道分組的規則。依官方預設管道分組，手動加 UTM 的流量要算付費社群，得同時符合：來源在社群網站清單裡，媒介符合 ^(.*cp.*|ppc|retargeting|paid.*)$。媒介寫成 fb_ads，Facebook 廣告就會掉進自然社群。

官方另外寫「Channel definitions aren't case sensitive」，所以 Facebook／CPC 一樣會算付費社群；但在來源報表裡，facebook 和 Facebook 還是兩列，數字會被拆開。表中要特別小心的是 fb_ads 和 mail 這兩列：報表看起來有數字，管道卻不對，付費廣告的成效被算進自然流量，或掉進 Unassigned 沒人看。

Organic Search 也不等於 Google。依同一份規則，來源在搜尋引擎清單裡、或媒介等於 organic 的流量都算這格，Bing、Yahoo、DuckDuckGo 都在裡面。要講 Google 自然搜尋帶來多少人，必須拆到工作階段來源與媒介（sessionSource、sessionMedium）看 google / organic 那一列。

我們量到的數字

這些是 2026 年 8 月到 10 月，我們在幾個網站上跟 UTM、GA4 有關的實測紀錄。多數是單一網站、單一事件，代表這類錯誤確實會發生，不是固定比例。共同點是它們都不會自己報錯：頁面照開、報表照出，只有拿真的瀏覽器重跑一次、或把兩份資料並排比對，才看得出數字是錯的。

踩過的坑：追蹤碼在頁面上，資料卻是 0

GA4 的資料是 0，不一定是沒人來，也可能是追蹤碼根本沒在跑，或按鈕根本送不出去。這類錯最難發現，因為檢查程式碼時一切都在：評估 ID 寫在頁面上、事件名稱也設好了，只查字串在不在的守門會一路亮綠燈。要抓到它，得用真的瀏覽器開頁，看程式有沒有執行、請求有沒有送出。

追蹤碼包錯一層，6 天 0 筆資料。 現象：某品牌官網的 GA4 從上線起 6 天，一筆資料都沒有，2026 年 9 月 28 日才發現。原因：內嵌追蹤碼開頭在最外層寫了一行 return，一般 script 的最外層不准寫 return，Chrome 會報 SyntaxError: Illegal return statement（見 MDN 的錯誤說明），整段不執行，GA4 的設定從來沒送出。守門只查評估 ID 字串在不在頁面上，所以全綠。怎麼修：整段包進一個立即執行的函式裡，部署後照下面的驗收三件事再驗一次。

語法檢查工具也會放行。 現象：用 node --check 檢查同一段程式，退出碼是 0，看起來沒問題。原因：node --check 把檔案當成 CommonJS 模組處理，外面多包一層函式，最外層 return 反而變合法。2026 年 10 月 23 日我們用 Node 24 重跑，結果一樣：node --check 放行，vm.Script 報 Illegal return statement。怎麼修：照瀏覽器規則驗，用 Node 內建的 vm.Script 把每一段內嵌腳本編譯一次；JSON-LD 不是程式，要排除在外。

按鈕沒有目的地，上線起零轉換。 現象：2026 年 8 月 22 日查某網站，139 個加入 LINE 的按鈕從上線起一次轉換都沒有。原因：按鈕連到站內錨點，錨點區塊裡的按鈕又是 href="#"，佔位符從沒換掉；點下去只會捲到頁面另一處，看起來像正常的頁內跳轉。16 支守門一支都沒抓到，因為死鏈檢查把 # 當成合法路徑。怎麼修：加一條檢查，任何連結不准是 #、空字串或 javascript:void(0)，文字帶有轉換意圖的按鈕，連結必須是 http 或 https 網址。

疑似自家測速，灌進流量報表。 現象：某網站 2026 年 10 月 21～22 日兩天 40 個使用者裡，有 20 個螢幕是 412×823、停留 0 秒。原因：我們判斷是自家測速，412×823 正是 Lighthouse 測速預設的手機尺寸，GA4 只自動排除已知的機器人。官方已知機器人排除寫「traffic from known bots and spiders is automatically excluded」，但「you cannot disable known bot traffic exclusion or see how much known bot traffic was excluded」。怎麼修：測速時擋掉 GA4 的請求；看報表時，把這個螢幕尺寸、停留 0 秒的使用者另外篩掉再算。

今天的數字還沒算完。 現象：2026 年 10 月 23 日凌晨 2 點 01 分查，GA4 一般報表只更新到前一天 22 點；前一天的人數之後從 86 補到 102。原因：官方資料更新時間寫，標準資源的當日資料約晚 2～6 小時，整天資料約 12 小時才處理完。怎麼修：要結算前一天，我們固定等到隔天下午再拉；要看今天的動靜，改用即時報表。

踩過的坑：UTM 有帶，歸因還是錯

UTM 帶了、追蹤碼也在跑，歸因還是可能錯：參數在途中被截斷、Referer 被連結屬性拿掉、自家報表的查詢把沒帶參數的訪客整批漏掉。這幾種錯都會產出一份看起來完整的報表，數字有、表格也有，只是對不上真實狀況，比完全沒資料更容易誤導判斷，因為沒有人會懷疑一份有數字的報表。

utm_content 被截在 100 字元。 現象：2026 年 9 月，我們在一個網站想用出站連結上的 utm_content 分辨同一頁不同位置的按鈕，GA4 收到的值被截在 100 字元，位置資訊不見了。原因：GA4 官方收集上限表列出，事件參數值的長度上限是 100 個字元，只有 page_title、page_referrer、page_location 例外。怎麼修：要分按鈕位置，改成每個位置用不同的按鈕文字，GA4 的點擊事件記得到連結文字；UTM 的值本身也盡量短。

順手加 noreferrer，Referer 就沒了。 現象：出站連結改完屬性後，對方網站看不到流量是從哪一頁點過去的。原因：2026 年 8 月 27 日我們在 Edge 瀏覽器做三組對照，不加屬性、加 sponsored nofollow、加 noopener nofollow sponsored，點擊、fbclid 與 utm 參數、Referer 都一字不差，nofollow 和 sponsored 只是給搜尋引擎看的；會出事的是 noreferrer，MDN 寫它會讓瀏覽器「omit the Referer header」。怎麼修：對外連結只加 nofollow 或 sponsored，不要順手加 noreferrer，也不要改動 href 本身。

自家報表按素材拆，加總對不起來。 現象：2026 年 8 月 21 日，我們在自建的廣告落地頁報表加了一段按廣告素材拆數字，各素材加總不等於總進站。原因：子查詢要求素材名不為空，沒帶 utm_content 的訪客整批消失。同一天還抓到另一個：同一支 API 新增查詢時漏套了共用的網址過濾條件，某個數字從 333 修正成 192，其中 141 筆是別的網站的。怎麼修：沒帶參數的訪客歸成一列未標記，不拿它去比哪則素材最好，偵測到它就提醒廣告網址沒帶追蹤參數；加了過濾條件，同一支程式裡每一段查詢都要逐一對照。

怎麼驗收：追蹤碼與 UTM 上線前後看什麼

追蹤碼裝好的標準，不是程式碼出現在頁面上，而是三件事同時成立：真的瀏覽器主控台 0 個錯誤、網路請求裡有送到 google-analytics.com/g/collect 的 page_view 而且回 204、GA4 即時報表收到這次造訪。三件缺一都不算裝好；再帶 UTM 走一次，確認來源與媒介歸到預期的管道，整條路才算驗完。

我們用 Playwright 開真的瀏覽器跑這四步，主控台、網路請求都直接讀出來比對，不靠肉眼看。即時報表要抓時間：官方即時報表說明寫它涵蓋「from the present moment to 30 minutes ago」，標準資源只看得到最近 30 分鐘，驗收要在開頁後半小時內查。用 GA4 Data API 查即時報表還有一個小坑：eventName 維度跟 activeUsers 指標放在同一個請求會回 400，要拆成兩次查。

UTM 的部分，用帶參數的網址開一次頁，先看 g/collect 請求裡的頁面網址有沒有把參數完整帶到，再等一般報表處理完，到流量開發報表確認來源、媒介、管道是不是你預期的那一格。管道對錯直接對照上面那張規則表；如果落在 Unassigned，通常是 utm_medium 用了詞彙表以外的寫法。

GA4 之外，再留一本自己的帳

GA4 的數字會延遲、會被過濾、只排除已知機器人，廣告平台回報的又是它自己的歸因口徑。我們在廣告落地頁上另外留一本帳：伺服器端記下每次進站的去識別特徵與點擊識別碼，不存原始 IP，後台出現新註冊時，用時間窗把註冊對回進站紀錄。這本帳不靠 GA4 也不靠 Meta，三份數字可以互相對照。

2026 年 8 月 14 日首次實測，當天 3 筆註冊裡配出 2 筆來自廣告，其中一筆從進站到註冊只隔 1 分 46 秒，另 1 筆判定不是廣告帶來的。樣本只有 3 筆，能證明的是這條路走得通，不是配對率。Meta 那一側的事件怎麼雙送去重，寫在 Pixel 與 CAPI 雙送去重實作。

我們的數據追蹤方案

從 UTM 是什麼、怎麼命名到上線驗收，上面這些都是我們幫客戶裝追蹤時固定會做的事：GA4 資源與資料串流、關鍵事件對應、UTM 命名規範與連結產生器、Pixel 與轉換 API 的轉換事件雙送，上線後用真的瀏覽器跑驗收三件事，並留一份驗證紀錄。所有追蹤資產都登記在客戶名下，合作結束帶得走，不會因為換廠商就從零開始。

數據追蹤（GA4、Pixel、CAPI）一次性建置 $150 起，規格與交付時程在數據追蹤與歸因設定。廣告要導去的落地頁也可以一起做，每頁 $250，見落地頁製作；落地頁本身該怎麼規劃，可以先看一頁式網頁是什麼。更多追蹤主題整理在廣告投放與追蹤知識庫。

常見問題

UTM是什麼意思？ UTM 是一組名稱以 utm_ 開頭的網址參數，用來告訴 GA4 這次造訪從哪裡來。最常用的是 utm_source（來源）、utm_medium（媒介）、utm_campaign（活動），Google 官方建議這三個每次都要帶。

utm_source 的大小寫有差嗎？ 有差。Google 官方寫參數值分大小寫，utm_source=google 和 utm_source=Google 在來源報表裡是兩列；管道規則本身不分大小寫，兩者會歸到同一個管道，但來源數字會被拆開。建議全部用小寫。

Facebook 廣告的流量為什麼被 GA4 算成 Organic Social？ 多半是 utm_medium 的寫法不符合付費規則。依 GA4 預設規則，付費社群要求媒介含 cp、等於 ppc 或 retargeting，或以 paid 開頭；寫成 fb_ads 這類值、來源又是 facebook，就會被歸到自然社群。

Meta 廣告改了名稱，utm_content 會跟著變嗎？ 不會。Meta 官方寫名稱類動態參數取的是廣告首次發布時的名稱，之後改名，網址裡的值不變；要換值只能建一則新廣告。

GA4 今天的數字為什麼比較少？ 因為還沒處理完。官方寫標準資源的當日資料約晚 2～6 小時、整天資料約 12 小時；我們 2026 年 10 月 23 日凌晨 2 點查，報表只更新到前一天 22 點。要看今天的動靜用即時報表，它只涵蓋最近 30 分鐘。

連結加 rel="nofollow" 會讓 UTM 失效嗎？ 不會。我們 2026 年 8 月用三組對照實測，加 nofollow 或 sponsored 之後，點擊、utm 參數和 Referer 都一字不差。要避開的是 noreferrer，它會讓瀏覽器不送 Referer，歸因就斷了。