二次轉發活動連結時，UTM 和 click_id 會把什麼身分一起帶出門

行銷把落地頁丟進客戶群，客服把「活動頁」轉進工單，同事把社群分享連結再發到內部頻道：這三步很少有人先看問號後面。位址列裡那一長串看起來像亂碼，實際是查詢參數。瀏覽器把它當作請求的一部分發出；聊天軟體、郵件和工單系統則把它當作普通文字整段保存。

這和「URL 的 # 片段為什麼不進伺服器日誌」不是同一層。片段留在當前分頁，不會進入 HTTP 請求列；查詢參數會。已有文章URL 的 # 片段為什麼不會出現在伺服器日誌裡只解釋井號。本篇要補的是問號：二次轉發時，被一起帶走的通常不是頁面路徑，而是路徑後面那串可檢索、可歸檔、可被下游網站再讀一次的欄位。

Google Analytics 的 URL builder 說明寫得很直白：使用者點擊帶 UTM 的推薦連結時，這些參數會進入分析報告。對投放團隊這是功能。對二次轉發的人，這變成另一件事：你把「這次點擊從哪條活動來」的標籤，連同平台自動追加的 click ID，一併交給了下一個通道。通道並不保證只給目標接收方看一次。

第一類是 UTM。Google 文件列出的常用欄位包括 utm_source、utm_medium、utm_campaign，以及可選的 utm_term、utm_content、utm_id。值是你或投放工具寫進去的明文，例如 line、email、sep-sale。它們描述的是活動，不是某一個使用者的帳號；但二次轉發後，接收方、群裡後來進來的人、以及能匯出聊天紀錄的人，都能看見「這條連結當初是為哪場活動、哪條管道準備的」。分析系統把大小寫當成不同值：utm_source=google 和 utm_source=Google 會拆成兩行。對人來說，它們都是可讀標籤。

第二類是 click ID。廣告平台在使用者點廣告時自動追加，值是一長串不供人閱讀的權杖。gclid 由 Google Ads 自動標記產生，用來把一次點擊對回轉換；fbclid 由 Meta 追加，常被像素或轉換介面讀回；同類還有 ttclid、msclkid、twclid。你沒有選擇過這些值，也無法從字串本身讀出活動名。它們標識的是「這一次點擊」，不是「這一場活動」。把帶 fbclid 的位址再轉給同事，等於把那一次廣告點擊的查找鍵一起交出去。

第三類是分享者標識。Instagram、Threads 的分享連結若原樣轉發，問號後的參數可能讓對方頁面顯示「某某分享了這則貼文」。聯合報系科技頻道在 2025 年的報導裡寫過這個核對方法：刪掉問號及之後的字串，跳轉往往仍在，分享者帳號卻不再被帶出。Facebook、YouTube 等平台的分享連結，也常見類似的追蹤碼。本文不提供也不複述任何反查步驟；只確認一件能當場看見的事實：有些分享連結的查詢參數裡，除了活動標籤，還帶著「是誰點的分享」。

聊天視窗按「還能找回來」設計。你把完整活動連結貼進頻道後，正文、用戶端快取和伺服器搜尋索引各持一份。三個月後有人搜 utm_campaign 或 fbclid，仍可能撈到當時那條。收回通常刪不掉對端已讀推播和已同步的歷史。這和「信任同事」無關：同事需要的是落地頁，不需要那次廣告點擊的權杖。

工單和郵件把連結當成證據保存。客服把使用者發來的「打不開的活動頁」原樣貼進工單後，座席、升級單和外包檢視權限都會再次開啟完整 URL。相簿裡的整頁截圖、會議錄影裡的位址列，是另一條像素通道。金鑰不該進聊天，我們在環境變數外洩後新金鑰為什麼不該再發到聊天視窗裡寫過；追蹤參數的危險更輕，但殘留形態一樣：通道保存的是你貼上的整串字元。

該留的是讓頁面到達正確資源的欄位。id=128 指向商品，q= 是搜尋詞，page=2 是分頁，YouTube 的 t= 是時間戳。這些不是投放標籤。盲目「刪掉問號後所有內容」在社群分享連結上常常有效，在電商和後台深鏈上會跳到首頁或報錯。

該剝的是描述流量來源、標識單次點擊、或指向分享者的欄位。utm_* 整族、常見 click ID，以及電商和內容平台的歸因欄位，例如部分購物、短影音分享連結上的 spm、refer_share_id。它們不決定「開啟哪一條內容」，只決定「這次開啟被記成誰帶來的」。

取捨不確定時，先走窄的規則：只去掉 utm_* 和常見 click ID，看頁面是否仍指向同一資源。再決定要不要去掉分析欄位和平台歸因。這不是口號，是能對照結果的兩檔。