先記結論：轉發前要清的，是問號後面那些把「你從哪點過來」寫進網址的查詢參數。核對方法不是看連結變短了，而是對照已移除名單，再確認 pathname 與 id=、q= 還在。清完不能當成無痕造訪，也不能證明落地頁沒有統計指令碼。
一句話先回答搜尋意圖
轉發連結前要先清掉追蹤參數，是因為查詢字串屬於 HTTP 請求目標的一部分。瀏覽器去拉文件時，問號後面的 utm_source、fbclid、igshid 會寫進請求行；託管端、反向代理和存取紀錄按設計都能看見。把帶這些欄位的整串貼進 LINE 群組或工單，等於把渠道和點擊標記一併交給下一個開啟的人。
這篇文章給營運、客服，以及要把資料外發之前想先分清「網址裡寫了什麼」和「開啟之後還會發生什麼」的人。它不代替 隱私清洗 的操作說明，也不重複「怎麼點按鈕得到乾淨網址」。你要帶走的是：UTM 和點擊 ID 各寫什麼、轉發時誰繼承了它們、清完還能證明什麼、用已移除清單和 Network 怎麼當場對照。
問號後面的字會進 HTTP，不是只給你看
RFC 3986 §3.4 把 query 定義成第一個 ? 之後、fragment 之前的那一段。RFC 9110 接著規定：請求的目標 URI 含路徑和查詢，不含 fragment。所以「網址列很長」不是觀感問題，是這次文件請求會把問號後的鍵值對交給對端。
井號後面的片段預設留在目前分頁，上一篇已經寫過核對方法。這一篇只盯問號。把兩條規則放在一起，才不會把「伺服器看不見 # 後面的金鑰」誤讀成「伺服器也看不見 ? 後面的渠道」。
瀏覽器提供的 URLSearchParams 可以把 query 拆成鍵值對，按名字刪除後再拼回網址。清洗工具做的就是這一層：改的是字串，不是落地頁上的指令碼。刪掉 utm_campaign，並不會關掉對方網站的統計像素。
UTM 寫的是渠道，不是裝飾性後綴
Google Analytics 把手動標記寫成一組 utm_* 查詢參數。說明文件列出的常用對應是：utm_source 對應來源，utm_medium 對應媒介，utm_campaign 對應活動名稱，另外還有 utm_term、utm_content、utm_id 以及較新的 utm_source_platform 等欄位。官方範例長這樣：http://www.example.com/?utm_source=google&utm_medium=cpc&utm_campaign=summersale。這不是猜測，是 Analytics 流量來源說明 裡的寫法。
這些值對投放的人有用：同一篇內容從電子報、影片簡介和群組公告點進來，可以分開計數。對下一個開啟連結的人，它們是明文備註。工單裡出現 utm_source=line_oa&utm_campaign=refund_202609，值班的人、搜尋工單的人、以後匯出表格的人，都能讀出「這是從哪條官方帳號活動點過來的」。
UTM 本身通常不含身分證字號或口令。它洩露的是脈絡：你看過哪封信、點過哪則廣告、是不是從客服話術裡的專屬連結進來。脈絡一旦寫進可轉發的 URL，就不會只停在你的分頁裡。
點擊 ID 寫的是哪一次點擊，不是活動名稱
點擊 ID 比 UTM 更接近「這一次點擊」的編號。Google Ads 的自動標記會在落地頁網址後追加 gclid（Google Click Identifier）。官方說明給的形態是 www.example.com/?gclid=123xyz。開啟自動標記並且網站裝著 Analytics 時，這個值還會被寫入網站網域下的 cookie，用來把後續轉換對回那次點擊。見 Google Ads 自動標記說明。
在 iOS 14 之後的部分場景裡，沒有使用者同意時不再使用 gclid。Google 另外引入 gbraid（偏 web 到 app）和 wbraid（偏 app 到 web），用來在平台限制下繼續做廣告度量。這是 Analytics 對 iOS 14+ 活動度量的說明，不是清洗工具自己發明的分類。
台灣常見的還有 Meta 側的 fbclid，以及 Instagram 分享時加上的 igshid。開發者文件寫明：頁面 URL 裡如果帶著 fbclid，Conversions API 仍可用它構造 fbc；網站若裝著 Meta Pixel，點擊編號還會被寫進名為 _fbc 的第一方 cookie，格式是 version.subdomainIndex.creationTime.fbclid。依據是 Meta 的 fbp / fbc 參數說明。你把帶 fbclid 的網址轉給同事，同事開啟時，對方網站仍可能把「來自這次點擊」的標記收進自己的 cookie 和後續回傳。
同一類名字還會以 msclkid、ttclid、twclid、li_fat_id 等形式出現。它們各自服務自己的廣告帳戶，共同點是：寫在 query 裡，就會隨請求行走；寫進你轉發的字串裡，就會被下一個開啟的人繼承。
不要用真實投放連結、含客戶手機號碼的短網址或未遮蔽工單做實驗。準備一條可以公開的範例網址，參數用一次性標記。核對的是 query 和請求行，不是把業務渠道再擴散一遍。
轉發時，下一個人繼承了整串 query
分享按鈕、瀏覽器「複製網址」和從聊天紀錄裡再次長按，複製的常常是目前完整 URL，而不是網站希望對外展示的短路徑。LINE、Facebook、Instagram 和電商商品頁尤其明顯：你看見的是一篇文章或一件商品，剪貼簿裡卻是 pathname 後面掛著一串歸因欄位。
這些欄位會跟著連結進入三個地方。第一，聊天和工單正文，群組成員和搜尋紀錄都能看見。第二，對方瀏覽器的網址列，以及可能同步出去的歷史。第三，對方開啟時發出的文件請求——伺服器紀錄裡會出現完整 query。你刪掉自己聊天裡的那一條，改不了已經開啟過的人、已經寫下的紀錄。
營運把投放監測連結直接丟進對外公告，客服把使用者複製來的長連結原樣貼回工單，開發把帶 gclid 的重現網址貼進 issue，都屬於同一類動作：把一次點擊的脈絡，從「給你自己看的網址列」變成「任何能看見這串字元的人都能復用的標記」。
清完能證明什麼，網址裡還剩什麼
清追蹤參數能支持的結論很窄，寫清楚反而能少一次誤判。它能證明：在你使用的這份名單和這一次清洗裡，已知的 utm_*、點擊 ID 以及（如果開了更寬模式）部分歸因欄位，已經從 query 裡消失。pathname 還在，id=、q= 一類業務參數按設計應留下，連結應仍指向同一篇內容。
它不能證明：落地頁沒有像素，對方沒有第一方 cookie，短網址轉址後不會再掛上新的參數，路徑片段裡沒有追蹤記號，瀏覽器擴充功能沒有改寫剪貼簿。更不能證明「開啟之後沒人知道你是誰」。清的是你準備轉發出去的這一串字元，不是下一次瀏覽工作階段。
短網址是最常見的假通過。短網址服務把真正的目標藏在自己的轉址裡；你清洗 https://short.example/abc，query 往往是空的，工具會報告「未發現可剝離參數」。追蹤寫在 302 之後的長網址上。要核對，先在無痕視窗開啟短網址，再複製網址列裡的最終 URL。不要用含真實隱私的短網址做這一步。
蝦皮、momo 一類分享出來的長網址，還可能帶著名單洗不掉的鍵。那些欄位不一定叫 utm_* 或 fbclid。清完之後若乾淨結果仍然很長，用眼睛對照留下的鍵，不要假設「變短了一點就夠了」。
| 你看見的變化 | 能支持的結論 | 不能支持的結論 |
|---|---|---|
| 連結變短了 | 少了一些 query 字元 | 已經匿名、已經安全 |
已移除名單裡有 utm_*、fbclid、igshid |
這些鍵從目前 URL 裡刪掉了 | 落地頁不會再寫 _fbc 或 Analytics cookie |
id=、q= 還在 |
業務定位參數按設計保留 | 所有留下的鍵都對業務必要 |
| 短網址「未發現可剝離參數」 | 這一串短網址本身沒有匹配到名單 | 轉址後的長網址同樣乾淨 |
| Network 裡沒有原連結 | 這次清洗請求沒把原文當業務資料送出 | 擴充功能和聊天用戶端也沒保存過它 |
當場對照：已移除清單和 Network
口號不能當證據。能當場做完的檢查有兩層：一層看清洗結果，一層看出站流量。準備一條可以丟棄的範例，例如：
https://example.com/article/42?id=42&q=aes&utm_source=line&utm_medium=social&utm_campaign=share_20260903&fbclid=IwAR0canaryfp&igshid=canaryig&spm=demo.share.0
金絲雀放在 utm_campaign、fbclid 和 igshid 的值裡。清洗之後，乾淨網址裡不應再出現 share_20260903、IwAR0canaryfp 或 canaryig；id=42 與 q=aes 應還在。
- 先讀已移除參數清單。應看到
utm_source、utm_medium、utm_campaign、fbclid、igshid；若使用更寬的模式，spm一類歸因名也應出現。清單是空的，卻感覺「連結乾淨了」，先懷疑短網址或參數寫在路徑裡。 - 再讀乾淨網址的 pathname 和留下的 query。少了文章編號或搜尋詞，說明誤傷，不要轉發。
- 開啟開發人員工具的 Network，勾選 Preserve log，篩選器用 All。把金絲雀貼進搜尋框。請求行、請求體和分析上報裡都不該出現那條髒連結。
FastPwd 的乾淨連結按這條邊界實作：解析發生在目前分頁，單條網址超過 8 KB 會拒絕，一次最多處理 100 行；只接受 http / https。保守模式只清掉 utm_* 與點擊 ID（包括 fbclid、igshid、gclid、gbraid、wbraid、msclkid 等）；標準模式再清掉 _ga / _gl、郵件裡的 mc_eid / mc_cid、淘寶 spm / scm、拼多多 _x_*、抖音 share_token 一類歸因欄位，以及未勾選保留時的 ref / referrer。pathname 與 id=、q= 留下。工具開啟即用，沒有帳號。造訪統計只記「做了清洗」這類事件名，不寫原文。承諾仍然只是承諾，以你這一次在清單和 Network 裡看到的為準。
不確定某個鍵是不是業務參數時，改用保守模式。先保證 UTM 和點擊 ID 離開轉發串，再人工決定 spm、ref 要不要留。名單洗不掉的鍵，用眼睛刪，不要指望一次「變短」解決所有問題。
三種看起來乾淨、其實沒洗到的情況
第一，追蹤寫在路徑裡。有的分享頁用 /s/xxxx 或帶渠道前綴的 path，query 是空的。按名字刪查詢參數，網址幾乎不變。你要對照的是「開啟後落地的正規化網址」，不是分享按鈕剛吐出來的轉址外殼。
第二，清洗工具只動 searchParams，不動 hash。追蹤偶爾被寫進井號後面時，query 清洗會報告通過。對照方法仍然是把網址列整串和結果整串並排看，不要只看問號前面。
第三，你清洗了準備轉發的那一條，聊天軟體又在送出時補參數。有的用戶端會給外連加上自己的點擊標記。送出之後，在另一個視窗開啟自己剛發的訊息，再看一次網址列。清洗發生在貼上之前；送出之後還要抽查。
常見問題
清掉 UTM 之後，開啟連結的人還能被追蹤嗎？
能。清的是你轉發的這一串 query。落地頁仍可能有像素、第一方 cookie 和登入狀態。Meta 的文件也寫過：即使 URL 裡暫時沒有 fbclid，網站若早已寫過 _fbc，後續事件仍可能帶上它。清完只證明這條 URL 少了已知追蹤參數，不證明下一次造訪是匿名的。
清洗會不會把文章 id 或搜尋詞也刪掉？
按名單清洗時，pathname 與 id=、q= 一類業務 query 應留下。不確定時用保守模式，只清掉 utm_* 與點擊 ID。清洗後對照已移除清單，不要只看連結變短了。清單裡出現了你需要的鍵，就不要用這一次的結果。
短網址要不要先清參數？
短網址本身往往沒有 UTM。追蹤寫在轉址後的長網址裡。只清洗短網址，通常什麼也剝不到。先在無痕視窗開啟，把網址列裡的最終 URL 複製出來再清。不要用含真實隱私的短網址做實驗；實驗用可以公開的範例即可。
在 FastPwd 清洗時，原連結會不會被上傳？
依產品說明，解析和剝離都在目前分頁完成，原文不作為 HTTP 業務資料送出，也不寫入 analytics。造訪統計只記「做了清洗」這類事件名。要當場核對，把金絲雀參數搜進 Network：請求行、請求體和統計上報裡都不該出現那條髒連結。localhost 預設不傳送造訪統計，換到正式網域再複測一次更接近真實使用。
把同一條連結用開啟即用的工具對照一次
若你希望用一個把剝離名單寫清楚的頁面來練習，開啟 FastPwd 的 隱私清洗 即可，無需註冊。貼進上面那條範例，先跑保守模式，再跑標準模式，對比兩次「已移除」標籤。你應看到：兩種模式都會拿掉 UTM、fbclid 和 igshid；標準模式才會動 spm。乾淨結果裡 id 與 q 仍在。
同一頁還可以切到個資遮蔽，處理工單正文裡的手機號碼和電子郵件；那是另一篇文章的主題。必須把完整機密交給同事時，改走 閱後即焚：本機用 AES-256-GCM 加密，伺服器只暫存密文，金鑰放在連結的井號後面。不要把剛洗乾淨的業務連結，和焚鏈的完整網址一起貼回同一個群組。
下次轉發前記住三件事。第一，問號會進 HTTP，渠道和點擊 ID 都寫在那裡。第二，清完只改變你準備送出的字串，不關閉落地頁的統計。第三，短網址、路徑標記和送出後再追加的參數，都要另做一次對照。能重複的觀察，才值得寫進你們自己的外發說明。
延伸閱讀
問號和井號不要混為一談。金鑰為什麼能放在 # 後面、以及把完整連結貼進聊天時會丟掉哪一層保護，見 URL 的井號後面為什麼適合放金鑰，以及什麼時候會失效。工單正文裡的手機號碼、身分證字號和 API Key 怎麼在離開本機前對照，見 把工單和日誌貼進 AI 之前，怎麼先核對哪些欄位會離開本機。若還要確認清洗過程本身有沒有把原連結當業務資料送出，用 瀏覽器本地加密怎麼核對明文沒有離開本機 裡的金絲雀步驟即可。