Threads 連結怎麼加 UTM，方便辨認來源？

用一致的 UTM 欄位與命名方式標記 Threads 外連，分清活動、貼文位置與短網址轉址，並在發布前確認報表能辨認來源。

Threads 貼文把讀者帶到網站後，若每次都用不同標籤，報表便難以分辨來源。先訂一組簡單、可重複的 UTM 規則，再逐條測試，才能把連結來源整理成可用的紀錄。

UTM 欄位各自代表什麼

UTM 是附加在目的網址後的查詢參數，協助分析工具把造訪歸到你設定的來源與活動。它不會替連結帶來流量，也不會證明讀者看完貼文；它的工作是讓同一個目的頁有一致、可辨認的入口標記。常見五欄位可以這樣分工：utm_source 寫平台或來源，例如 threads；utm_medium 寫管道類型，例如 social；utm_campaign 寫這次推廣的共同活動；utm_content 區分同一活動內的貼文、版位或素材；utm_term 留給確實需要辨認的詞組。欄位可以少用，但團隊要約定何時填、何時留白。

假設一則 Threads 貼文連到教學頁，可把 source 設為 threads、medium 設為 social、campaign 設為 2026q4_utm_guide、content 設為 post_01。這些值只是分類名稱，不要把按讚數或留言數塞進網址，它們不是來源欄位。若只有一篇貼文，不必硬編 term；若同一活動另有個人檔案入口，才為該入口設不同的 content。看到報表時，先讀 source 判斷來自哪裡，再用 medium 看管道大類、campaign 看共同企劃、content 看具體位置。

欄位定義一旦固定，不同週期才有比較基礎。如果有人寫 Threads、有人寫 thread，另有人寫 threads_app，同一平台會散成多個標籤，後續就得人工辨識。上線前先確認目的頁、五個欄位各自回答的問題，以及空白欄位是否為刻意省略；這能避免把活動名稱誤當平台，或把內容版本誤放進 campaign。實務上，先建立一份欄位對照，再把網址範本放在容易找到的位置。每次命名時由目的往外想：先說明要帶人到哪一頁，再回答來自哪個來源、屬於哪類管道、參與哪個活動，最後才決定是否需要區分素材。若無法清楚解釋某個值的意思，先不要放進去；多一個欄位只有在它能回答固定問題時才有用。例如不要把「本週貼文」同時當 campaign 和 content，否則兩欄會失去區分責任。

命名規則如何先統一

命名規則的目的，是讓不同人建立的連結仍能被同一張報表讀懂。先指定一種固定寫法：英文字母全部小寫，單字以底線分隔，日期用年與月份組成，來源只用平台名，medium 只用團隊認可的管道詞。然後為 campaign 訂格式，例如「年份月份_主題」，為 content 訂格式，例如「位置_序號」。不需要把所有活動細節塞進每個欄位；名稱應短到能掃讀，又足以分辨工作。

可以先採用這套假設規則：source 只接受 threads、instagram 等平台代碼；medium 固定用 social 表示自然社群流量；campaign 由年月與企劃簡名組成；content 寫貼文位置和版本；term 預設空白。若團隊需要另分付費社群，再新增明確詞值並寫進字典，不要讓每位同事自行創造 organic、community、social_post 等近義標籤。決策時問一件事：這個差異是否會改變你要做的報表判讀？若不會，就不要增加一種命名。

正式使用前，拿兩個人各自建立同一企劃的連結，比較輸出是否一致。例如都應得到 source=threads、medium=social、campaign=2026q4_utm_guide；只有位置不同時，content 才不同。保留一份可複製的範本和允許值清單，並指派一位維護者處理新增值。若舊活動已經使用另一套格式，不要為了整齊改寫已發布網址；從新活動開始採新規則，並在字典註記舊值對應。接著把容易混淆的詞明文排除，像是大小寫混用、空白、中文與英文混搭、同一平台的多種縮寫。選一個大家看得懂的詞彙表，不要只靠建立者記憶。日期也要固定週期：若企劃以月為單位，就全部使用年月；若企劃跨季且需要獨立比較，就按實際邊界建立活動名，不要一部分使用上線日、一部分使用結束日。對新成員來說，一張填妥的範例比抽象原則更快上手。序號也要保持一致，例如 post_01、post_02，不混用 1st、v2 與 final。

活動與內容如何標記

campaign 用來把同一個推廣目的下的外連放在一起，content 則回答「這個活動裡是哪一個入口或素材」。先判斷活動邊界：若兩篇貼文都在推同一份指南、同一期間且共用一個企劃名稱，campaign 可以相同；若其中一篇已是另一個主題或不同推廣目的，就另開 campaign。再判斷是否要比較入口：同一篇內容從貼文正文與個人檔案連結進站，兩者可有不同 content；若只是改了一個標點，通常沒有必要另開版本。

以下是明確假設的命名例子，不代表實際成效：

表格中的第一、二列有相同活動名稱，content 不同，因此可比較位置；第三列推廣目的不同，campaign 也改變。別把每次發布日期都放進 campaign，否則同一企劃容易被拆成許多小群；如果確實要比較發布批次，可將日期放在 content 的尾碼，並只在分析需要時使用。也不要用 term 代替貼文序號，除非你已決定它代表什麼。發布前把每個值唸一次：能說出它回答的問題，才保留；意思重疊就合併成單一標籤。

例如某個假設中的指南活動，第一篇貼文與個人檔案都指向同一頁。要回答「哪個入口帶來造訪」時，兩者保留相同 campaign，改用不同 content；要回答「哪個主題企劃值得延伸」時，再讓不同企劃各自使用 campaign。先寫下報表問題，再決定欄位，會比先堆標籤後猜用途可靠。若貼文沒有外連，不必產生未使用的標籤；若連結位置不會分開檢視，也可以共用 content，不必為每次發布創造新碼。content 以可讀的入口為主，例如 profile_link、post_01；若要比較不同文案，再加版本，例如 post_a、post_b。不要把貼文全文當參數，長字串難以複製，也可能包含不需要傳遞的資訊。

短網址會影響哪些環節

短網址會多一個轉址環節，方便貼文呈現或人工辨認，但不能假設每種縮址服務都會保留追蹤參數。建議先組好完整長網址與 UTM，再把整條網址交給你選用的外部縮址工具；縮址後實際點開，確認最後落地網址仍看得到預期參數。若先縮短裸網址、之後才把 UTM 加到短網址後面，參數可能落在轉址服務而非目的頁，最後報表便讀不到你要的來源。

檢查時留意三個位置：短網址是否能開啟、轉址後的網域與頁面是否正確、最終網址是否仍含 source、medium、campaign 等值。網址中若有井字號片段，查詢參數應放在片段之前；井字號之後通常是頁面內位置，不會按一般查詢參數送出。含空格、中文或特殊符號的值，最好交由可靠的網址產生器編碼，不要手動拼接百分比字元。每次改目的頁、縮址工具或轉址規則，都重新測一次。

縮址平台可能另記點擊數，分析工具則記錄到站工作階段，兩種數字的定義與計算入口不同，不能直接當成相同指標。預覽機器人、重複點擊或離開前未完成載入，也可能讓兩邊數字不同；先確認各自代表「短網址被開啟」還是「網站收到造訪」，再決定看哪個數字。若目前不需要縮短、完整網址也能清楚呈現，保留長網址可少一個故障點；若要縮短，就把最終目的頁與參數保留測試紀錄。如果縮址工具會先跳出提示頁、追蹤頁或安全檢查，也逐層點到最終頁；從短網址複製貼上後，別只看畫面顯示的短字串，還要確認實際開啟後瀏覽器最後停在哪個網址。若無法檢視或穩定測出參數是否保留，先用完整網址發布，待工具通過測試再換用。

發布前如何測試連結

發布前先把完整網址貼進測試表，逐項核對目的頁、source、medium、campaign、content，並確認沒有拼字錯誤、重複欄位或多餘空格。接著用與貼文相同的路徑點一次：如果正式貼文會用短網址，就測短網址，不只測原始長網址；如果連結要經過中間頁，也要確認最後停在預期頁面。檢查瀏覽器網址列的最終結果，並確認頁面能載入，避免只看到縮網址可點就當作追蹤正常。

第二步要確認分析工具真的收到標記。若有即時或測試檢視，開啟測試連結後檢查來源、媒介和活動值是否依預期出現；若報表稍後才更新，記錄測試時間，隔一段時間再查，不要因為即時畫面暫時沒有資料就立刻重發。若目前沒有可用的測試環境，使用專用的測試標記，例如 content=test_click，並註記不要把它混進活動成效；避免反覆點擊正式連結，免得測試造訪污染判讀。

最後做一次「從報表倒推」：看到 threads / social / 2026q4_utm_guide 時，團隊能否知道它來自哪個入口？若 source 變成 referral 或直接流量，先檢查參數有沒有在轉址中消失、目的頁是否換網域，以及分析工具是否正讀取該流量。若網址正確但報表仍沒有預期值，把問題記在測試列，確認工具收到事件或工作階段的方式後再調整。完成後將測試連結、最終落地網址和核對者留存，發布時複製已通過檢查的版本，不要重新手打。建立一個簡單的發布前清單，例如手機可開、頁面無誤、參數可見、來源詞拼寫正確、短網址到站後仍保留參數、測試列已標記。連結文字描述的目的也要與落地內容一致。把核對結果附在排程或內容紀錄旁，發現錯誤時就能指出是哪個網址、哪一步出問題。

如何整理命名字典

命名字典不是一份漂亮的文件，而是讓每次建立連結都能照著做的操作表。建議至少記錄欄位、用途、允許值、格式範例、禁止用法、負責人與新增日期。source 列出平台代碼及大小寫規則；medium 列出團隊實際採用的管道分類；campaign 寫年月與主題格式；content 寫位置和版本格式；term 說明預設留白，以及何種情況才啟用。每列再放一個完整網址範例，讓使用者不必靠猜測組合欄位。

遇到新平台或新入口時，先查字典是否已有能表達相同意思的值。若有，就沿用；若沒有，提交一個簡短提案，寫出它要回答的分析問題、預計套用範圍和範例，再由維護者核准後加入。定期整理拼字不同但意思相同的舊值，建立「舊值／標準值／採用日期」對照；報表若能篩選或分組，可用對照說明歷史資料，但不要宣稱改字典就會回頭改變已記錄的網址或資料。

字典也要保留變更紀錄：何時新增了付費社群分類、誰核准，以及從哪個活動開始套用。舊連結仍照原樣保留，避免貼文已外流後改目的地造成失效；新連結則使用現行規則。每次新企劃建立前，讓負責人依範本產生一個例子，另一位同事只檢查命名和落地網址；若兩人解讀不同，就先補清楚定義再大量複製。新增前先確認不是只為單次報表想出的臨時詞；若確有一次性比較需求，可先使用 content 的版本欄位，事後註記是否保留。允許值應方便複製，而不是只放在說明文件中；範本更新後通知實際製作連結的人，並把更新日期寫在表頭。下一步可把這份規則貼進團隊連結登記表，替下一篇 Threads 貼文建立一筆測試列。若你也在整理 Threads 相關工具，可前往 ThreadScout 查看。