客服把活動頁丟進工單，行銷把商品連結轉到 LINE 群，開發把文件網址貼進聊天——這三件事每天都在發生。複製出來的字串往往比你以為的長：utm_source=newsletter、fbclid= 後面幾十個字元、spm= 一串用點號隔開的版位碼。把整段原樣發出去，等於把投放渠道、廣告點選身分和頁面位置一併交給下一個人。
反過來說，有人圖省事把問號後面全部抹掉，結果 YouTube 打不開、商品頁回到首頁、搜尋結果變成空清單。問題不在「要不要清理」，而在先分清兩類參數：追蹤標籤可以刪；資源定位符必須留。下面用對照表、例外和能當場驗證的步驟把這件事寫清楚。MyPassGen 的隱私清洗頁依這個原則做剝離清單；本文不講工具總覽，只回答外發時哪些能刪、哪些不能刪。
問號後面並不全是垃圾
網址裡 ? 後面的部分叫查詢字串（query）。依 WHATWG URL 標準，開啟 http / https 連結時，查詢字串會進入請求列，也會出現在對端網站的存取紀錄。它和井字號 # 後面的 fragment 不是同一類東西：fragment 預設不隨 HTTP 請求送出；query 會。
查詢字串由一組 名字=值 組成，多項之間用 & 連接。瀏覽器提供的 URLSearchParams 可以依名字讀寫，不必靠手工找問號。判斷能不能刪，只看這個名字對開啟內容是否必要，而不是看值有多長、多像亂碼。
追蹤參數：給分析系統看的標籤
追蹤參數是給統計、廣告歸因和郵件系統準備的。頁面範本通常不讀它們也能渲染同一篇文章、同一個商品。刪掉之後，訪客仍應落到同一份內容；改變的是：目標站的分析報表少記一次「從哪則廣告、哪封郵件點進來」。
Google Analytics 把這類標籤寫成 UTM。官方文件 Collect campaign data with custom URLs 列出的名字包括 utm_source、utm_medium、utm_campaign、utm_term、utm_content 和 utm_id。其中 source、medium、campaign 被標成自訂活動裡應始終帶上的三項——那是給投放人員用的，不是開啟頁面的前提。
業務參數：開啟這一份內容所必需
業務參數指向具體資源。YouTube 的 v= 是影片 ID；電商的 sku= 或 id= 指向某一 SKU；搜尋頁的 q= 是查詢詞；分頁的 page= 決定第幾頁。刪掉它們，伺服器不知道你要哪一份資源，頁面會 404、回首頁或給出空結果。名字短、值像隨機字串，都不能當成「一定是追蹤」。
先問一句，再動手刪
這個名字是「告訴分析系統從哪來的」，還是「告訴伺服器開啟哪一條」？答不上來，就先只動以 utm_ 開頭的項和常見點選 ID，然後在新分頁驗證頁面是否仍是同一份內容。
可以刪的追蹤參數對照
下面這張表依來源分組。它不是全網窮盡清單——投放系統會發明新名字——但涵蓋了從廣告後台、郵件、LINE 與電商分享按鈕裡最常跟出來的一批。刪它們，通常不會改變你要開啟的那一頁。
| 分組 | 常見名字 | 刪掉之後通常怎樣 |
|---|---|---|
| UTM 活動標籤 | utm_source utm_medium utm_campaign utm_term utm_content utm_id |
同一頁面；目標站少一次活動歸因 |
| 廣告點選 ID | fbclid gclid gbraid wbraid msclkid dclid twclid |
同一頁面；廣告平台少一次點選對帳 |
| 分析與郵件 | _ga _gl mc_eid mkt_tok |
同一頁面；跨網域或郵件系統少一次身分串接 |
| 電商歸因 | spm scm pvid utparam share_token |
多數商品頁仍開啟；版位碼與分享權杖不再跟著走 |
fbclid 是 Facebook、Instagram 分享或廣告跳轉常見的點選識別；gclid 是 Google Ads 的點選 ID；msclkid 對應 Microsoft Advertising。gbraid / wbraid 出現在限制第三方 Cookie 之後的 Google 歸因鏈路上。它們的值很長，看起來像金鑰，但職責是歸因，不是定位文章或商品。台灣日常外發裡，Meta 與 Google 這兩組最常見。
淘寶系的 spm（Super Position Model）用來標記「從哪個版位點進來」。把它連同商品 ID 一起轉給同事，對方網站會把這次造訪記到你的版位上，也等於把內部投放結構洩露到工單和群組。商品 ID 要留，spm 通常可以走。蝦皮、PChome、momo 的分享按鈕則更常帶 UTM 或平台自己的分享權杖——一樣先留商品 ID，再拿掉看起來像渠道標記的名字。
還有一類灰色名字：ref、source、from。有的網站用它們做活動歸因，有的用它們決定到達頁範本。拿不準時先留著，只刪 UTM 和點選 ID，再在新分頁對照標題、正文和商品規格是否一致。
一刪頁面就打不開的業務參數
業務參數沒有統一前綴，只能依網站習慣辨認。下面幾類幾乎總是必須留：
- 資源 ID：
v=（影片）、id=/sku=/pid=（商品或物件）、doc=（文件編號）。 - 查詢本身：搜尋頁的
q=、query=、keyword=；地圖的座標或地點 ID。 - 分頁與排序：
page=、p=、offset=、sort=。刪掉會回到第一頁或預設排序，不一定 404，但已經不是你要轉寄的那一屏。 - 語言與站點：
hl=、lang=、locale=。刪掉可能跳出你正在核對的語言版本。
一個能當場做的試驗：把整段 query 先複製到記事本，只刪一個名字，在無痕視窗開啟。頁面標題、主圖、價格或正文與原文不一致，就把這個名字加回「必須留」一側。不要一次清空問號後再猜是哪一項壞了。
帶登入狀態或一次性權杖的連結更危險。token=、auth=、access_key= 看起來也像隨機字串，但它們可能是工作階段或下載憑證。這類值既不是 UTM，也不該出現在群組裡。正確做法是：不要轉寄帶權杖的 URL；需要給別人看同一份內容時，改用對方自己的登入入口，或把檔案先在本機加密再另選通道。
不要把整段問號交給來路不明的「線上清洗」
查詢字串裡可能混著工作階段權杖、預覽碼或內部物件 ID。把完整 URL 貼進會上傳原文的網站，等於把這些值寫進對方紀錄。清洗應在瀏覽器本地完成，並且列出被去掉的名字，方便你核對，而不是讓你相信一句「我們不保存」。
短網址、QR Code 和複製按鈕會把參數藏起來
看到 bit.ly、reurl.cc、t.co 或各平台自己的短網址，不要以為問號後面是乾淨的。短網址只是一層轉址：瀏覽器先請求短網址主機，再 301/302 到帶完整 query 的長址。你在聊天裡複製的是短的那一截，接收方點開後，網址列最終仍可能出現 utm_ 和點選 ID。
QR Code 同理。很多「分享」按鈕先產生帶追蹤參數的長址，再壓成碼。用手機掃開後，看的是轉址之後的網址列，不是碼圖片本身。要外發乾淨連結，應在落地之後從網址列複製，而不是從海報或後台的「複製短網址」直接轉寄。
郵件和簡訊裡的包裝更隱蔽。部分郵件服務商會把每條連結改寫成自己的點選統計網域，點開後再跳到帶 mkt_tok 或 mc_eid 的目標頁。你要轉寄的是最終到達頁，不是郵件裡那條統計轉址。操作順序：自己點開 → 等網址列穩定 → 再決定刪哪些 query。LINE 官方帳號或電子報按鈕也常先經過一層統計網域，規則一樣。
當場核對：網址列、新分頁、Network
口號無法核對，流量可以。下面這組步驟不依賴任何品牌承諾，瀏覽器自己會把結果攤開。
- 把待轉寄的 URL 完整貼到記事本，保留原始 query，避免只憑記憶刪改。
- 依上一節的對照表，先只刪除
utm_*與點選 ID（fbclid、gclid等），業務 ID 先不動。 - 用無痕視窗或新分頁開啟清理後的位址，對照標題、正文、價格或影片是否仍是同一份。
- 開啟開發人員工具的 Network 面板，勾選「保留記錄」，再重新整理一次。看文件請求的 Request URL：被刪的名字不應再出現；
v=、id=一類應仍在。 - 若頁面異常，把記事本裡剛刪的那一項加回去，一次只恢復一個名字，定位到真正必需的參數。
若你使用會在瀏覽器裡列出「去掉了哪些名字」的工具，把清單與 Network 裡的 Request URL 對讀一遍：清單上有、請求裡沒有，才算清乾淨；清單上沒有、你卻親手刪掉了 id=，那是誤刪，應加回。
MyPassGen 的隱私清洗依這個界線運作：標準模式涵蓋常見 UTM、點選 ID 以及部分電商歸因參數；保守模式主要動 UTM 與點選 ID。剝離在目前分頁完成，原文不上傳，也無需註冊。頁面會列出被去掉的參數，方便和網址列對照。單條 URL 超過 8 KB、或一次貼上超過約 100 行時，應拆開處理，而不是假設工具會吞掉任意長度的文字。
誤區：刪光問號、留下短網址、忽略權杖
「問號後面全是垃圾」是最常見的過度清理。搜尋、分頁、語言和資源 ID 都活在 query 裡。正確預設做法是：白名單刪除（只動已知追蹤名），而不是黑名單清空（刪掉一切未知名）。
「短網址已經夠短，一定乾淨」不成立。短的是轉址層，不是落地 query。要驗證，必須看到轉址結束後的網址列。
「HTTPS 已經保護隱私」只涵蓋傳輸路徑上的竊聽者。接收方開啟連結時，目標站仍然看得到完整 query。你要減少的是轉寄出去的那一份裡不必要的標籤，不是改寫 HTTPS 的職責。
「清洗連結等於個資遮罩」也不對。手機號碼、身分證字號、電子郵件和 API Key 經常寫在正文、截圖或工單表格裡，不在 URL 上。連結乾淨之後，仍要用同一套本地處理去遮罩這些欄位，而不是以為去掉 utm_ 就結束了。
從哪一步開始清理
先處理你今天就要發出去的那一條。開啟原連結，等網址列穩定，複製完整 URL，依對照表只去掉 UTM 和點選 ID，新分頁驗證，再發給別人。群組公告、知識庫和工單範本裡的舊連結可以後補，不必一次清全站。
若同一段文字裡混著多條網址，依行拆開，逐條看問號後面的名字。一條裡同時有 id= 和 spm= 時，留下 id=，去掉 spm=，再開啟確認商品未變。做完這一件，你就已經能回答本文的問題：能刪的是追蹤標籤，不能刪的是開啟內容所必需的業務參數。
需要把清理後的位址連同一段秘密一起給同事時，不要把金鑰再寫進 query。一次性短秘密用閱後即焚，金鑰放在 URL 的 # 後面；需要可反覆解密的檔案則走檔案加密盒，在本機產生 .lock / .enc。連結清洗解決的是「轉寄時少帶標籤」，不是金鑰交換。
常見問題
去掉 UTM 之後，對方開啟的還是同一頁嗎？
對絕大多數內容站和商品頁是的。UTM 給分析系統做活動歸因，頁面範本通常不依賴它們渲染正文。仍應以新分頁裡的標題和主內容為準，而不是只看狀態碼 200。
fbclid 很長，是不是金鑰？能轉寄嗎？
它是點選識別，不是登入口令，但也沒有必要轉寄出去。留下它，等於把這次點選的歸因鏈交給下一個開啟的人，並寫進對方可能保存的聊天紀錄。
短網址要不要先展開再刪參數？
要。在自己的瀏覽器裡開啟短網址，等轉址結束，從網址列複製長址，再依對照表刪除追蹤名。只轉寄短網址，接收方落地後仍可能帶上完整 query。
清洗連結需要註冊嗎？原文會不會上傳？
不需要註冊。把 URL 交給會上傳原文的網站，才有紀錄風險。本地處理時，原文留在目前分頁；你要核對的是 Network 裡有沒有把完整 URL 發到第三方，以及清單上列出的名字是否真的從網址列消失。