網址列裡的完整連結，並不等於可以外發的連結
行銷把到達頁傳給同事、客服把使用者申訴裡的網址貼進工單、開發把重現步驟寫進 LINE——這三件事裡，最省事的動作都是：從網址列全選、複製、貼上。網址列展示的是目前文件的完整 URL。按 WHATWG URL 的拆法，它至少包含通訊協定、主機、路徑、查詢字串（? 後面）和片段（# 後面）。片段預設不進 HTTP，上一篇已經寫過；查詢字串會進請求行，也會跟著複製一起走。
問題出在查詢字串經常不是業務必需。你點開的可能是一封帶追蹤的電子報、一則付費廣告，或社群平台自動追加了點擊識別的卡片。到達頁本身只需要 /product/42，網址列卻變成 /product/42?utm_source=summer-mailer&utm_medium=email&utm_campaign=summer-sale&fbclid=…。對分析系統來說，這是一次可歸因的造訪；對下一個讀到這串字元的人來說，這是一份不該出現在工單裡的側寫：從哪條活動進來、是不是剛點過廣告、電子報服務商有沒有替這名收件人編過號。
HTTPS 只保護傳輸過程中的竊聽。它不會清掉網址列、瀏覽器歷史、聊天紀錄、截圖和伺服器存取紀錄。OWASP 對「查詢字串資訊暴露」寫得很直：即使用了加密通道，查詢字串仍會出現在 Referer、Web 日誌、共用系統、瀏覽器歷史、快取和旁人窺視場景。外發前要處理的，不是「這個站安不安全」，而是「這一串問號後面有沒有不該離開目前分頁的標籤」。
UTM 寫的是活動，點擊 ID 寫的是這一點擊
兩類參數經常混在同一條 URL 裡，職責不同，外發時的風險也不同。第一類是你（或投放平台）主動寫上去的活動標籤。Google Analytics 說明中心把它們叫 campaign parameters，並給出標準例子：https://www.example.com/?utm_source=summer-mailer&utm_medium=email&utm_campaign=summer-sale。官方說明要求：只要加參數，就應當同時使用 utm_source、utm_medium 和 utm_campaign；另外還有 utm_id、utm_term、utm_content、utm_source_platform 等擴充項。值區分大小寫：utm_source=google 和 utm_source=Google 在報表裡會拆成兩列。
這類標籤通常不編碼單一使用者。它們描述的是管道和活動：來自哪封電子報、哪次夏季促銷、信件裡的上連結還是下連結。即便如此，把它們貼進對外聊天仍然會洩漏內部投放結構。接收方能讀出你在推哪條活動、用的是電子報還是付費點擊，也能據此猜測你的獲客路徑。對競品或無關第三方，這已經超過「開啟這個頁面」所需要的資訊。
第二類是廣告或電子報平台自動追加的點擊識別。常見名字包括 Google Ads 的 gclid、Display & Video 360 的 dclid、iOS 場景下的 gbraid / wbraid、Meta 的 fbclid、Microsoft Ads 的 msclkid、X 的 twclid，以及電子報服務商常用的 mc_eid。它們的設計目標是把「這一點擊」縫回平台自己的投放紀錄，而不是給你看一句人話。值對接收方無法判讀，對平台可讀。把帶 fbclid 或 gclid 的整串轉傳給別人，等於把一次可拼接的點擊憑證交了出去；mc_eid 一類則更接近「這封信發給了哪一筆收件人紀錄」。
還有第三層：網站自己的歸因或分享參數。台灣常見的是 Facebook、Instagram、Shopee 自動加上的點擊或分享識別；跨境或中文電商頁則常見 spm、scm、pvid、share_token、refer_share_id。它們不是 Google 的 UTM 規範，但同樣會讓一條「看起來只是商品頁」的連結帶上分享路徑或推薦人痕跡。外發策略如果只刪 utm_*，這一層仍會留下。
| 類型 | 常見鍵名 | 外發時的問題 |
|---|---|---|
| 活動標籤 | utm_source、utm_medium、utm_campaign |
洩漏管道和活動名稱，不是開啟頁面所必需 |
| 點擊 / 收件識別 | gclid、fbclid、mc_eid、msclkid |
可被平台拼回單次點擊或收件人紀錄 |
| 站內歸因 | spm、pvid、share_token |
帶出分享路徑或推薦痕跡 |
| 業務參數 | id、q、sku、page |
通常要保留，刪了頁面會打不開或結果不對 |
查詢字串會落到哪些地方
CWE-598（目前標題是 Use of HTTP Request With Sensitive Query String）把問題寫成：敏感資訊放進了查詢字串。它會進瀏覽器歷史、經 Referer 傳給其他網站、寫進 Web 日誌，或在別的紀錄裡留下副本。條目在 2026 年 4 月的 4.20 版裡改過名稱，強調不只 GET 會帶查詢字串，POST、PUT、DELETE 同樣可以。緩解建議寫得很具體：敏感資料放進請求主體或請求標頭，而不是查詢字串。
行銷參數多數算不上密碼或工作階段權杖，但暴露面是同一套。你把完整 URL 貼進即時通訊，至少會產生這些副本：聊天服務商的訊息儲存、接收方的本機紀錄、若再被轉傳則是下一跳的儲存。若接收方點開它，目的站的存取紀錄會記下帶參數的請求行；若該頁再載入第三方指令碼或圖片，還可能把完整 URL 放進 Referer，送給廣告或分析網域。OWASP 列舉的「共用系統」在公司內部尤其常見：工單、文件、錯誤監控、工作階段回放。一條本該只用於重現的連結，會在這些系統裡按明文搜尋得到。
這也是為什麼「我們網站用了 HTTPS」回答不了外發問題。HTTPS 讓路徑上的觀察者更難讀出明文；它不阻止你自己把明文貼進下一個系統。CWE-598 舉過的真實缺陷包括：監視器把密碼放進查詢字串、通訊產品把存取權杖放進 GET。那些是更嚴重的同類錯誤。UTM 和點擊 ID 的危害通常更輕，但機制相同：問號後面的內容預設會被人複製、被系統記錄。
不要用帶登入態、重設密碼或一次性權杖的真實連結做示範。需要對照參數時，用已經公開的商品頁或文件頁，自己在查詢字串後追加可丟棄的測試值，例如 utm_campaign=canary-2026。
Referer 會把問號後面的內容帶給第三方
複製貼上是主動外發。還有一種被動外發：接收方開啟頁面之後，瀏覽器按預設策略把「我從哪來」告訴後續請求。這個標頭的標準名字是 Referer（少一個 r）。MDN 的 Referer 隱私說明舉過典型例子：重設密碼頁尾有社群連結，點出去就可能把帶權杖的地址交給社群網站；頁面裡嵌入的第三方圖片，也可能把目前完整 URL 送給圖片所在的網域。
瀏覽器用 Referrer-Policy 決定送多少。Chrome 等引擎的預設值是 strict-origin-when-cross-origin：同源請求可以帶完整 URL（含路徑和查詢字串），跨來源且不降級時只送來源（通訊協定 + 主機 + 連接埠），從 HTTPS 跳到 HTTP 則不送。web.dev 的 Referrer 實踐把這條寫成兼顧隱私和可用性的預設。它能擋住「把完整查詢字串送給另一個網域」的一部分情況，擋不住同源分析請求，也擋不住網站把政策設成 unsafe-url 或完全不設、而舊版用戶端仍送出完整 URL 的情況。
對「我只是把連結傳給同事」這件事，Referer 的意義是：同事一點開，你貼出去的 utm_* 和點擊 ID 可能再走一程。若到達頁有第三方像素、客服小工具、CDN 上的字型，策略一旦允許送出完整 URL，這些參數就會出現在那些網域的日誌裡。外發前先清掉查詢字串裡的追蹤項，等於同時減少兩跳洩漏：聊天紀錄裡的明文，以及開啟之後可能發出的 Referer。
和片段的對比值得再寫一句。金鑰如果放在 # 後面，按 HTTP 報文設計不會進請求行，也就不會進 Referer 的一般實作。查詢字串沒有這層保護。把活動標籤和點擊 ID 放在 ? 後面，是為了讓伺服器和指令碼讀到它們；這也正是它們會進日誌的原因。需要核對「問號進請求、井號預設不進」時，步驟見URL 的井號後面為什麼適合放金鑰，以及什麼時候會失效。
系統會自動清一部分，但不能當成外發策略
從 iOS 17、iPadOS 17 和對應的 macOS 開始，Apple 提供連結追蹤保護。台灣官網的寫法是：在「訊息」中分享連結時，部分網站附加在 URL 的額外資訊會被移除，防止這些網站追蹤你或分享連結的對象；Safari「私密瀏覽」也會移除在你瀏覽時新增至 URL 的追蹤。Apple 的隱私功能把這件事寫成系統能力，而不是給你一份參數名單。
Apple 沒有公布完整剝離清單。社群測試（例如 PrivacyTests.org 一類對照）常提到 gclid、fbclid、mc_eid、twclid、dclid；utm_source 等活動標籤通常會留下。涵蓋範圍也有邊界：一般 Safari、第三方瀏覽器、App 內 WebView 並不等於「訊息」分享或 Safari 私密瀏覽這兩條路徑。對方用 Android、用桌面 Chrome、從 Slack 或 LINE 點開，都不會自動替你清。
所以「手機已經會清掉追蹤參數」只能寫成：在特定系統、特定 App 裡，一部分點擊識別可能在開啟前被刪。它不能寫成：你貼進工單的那一串已經被處理過。外發發生在複製的那一刻，發生在作業系統還沒介入的地方。要控制的是剪貼簿裡的字元，不是接收方裝置會不會再清一次。
該清什麼，該留什麼
一條可執行的規則是：先問「沒有這個鍵，頁面還打不打得開」。商品 id、搜尋 q、分頁 page、語言 lang、文件錨點對應的業務查詢，刪了會改變資源。活動標籤、點擊識別、電子報收件人編號、分享權杖，刪了通常只改變歸因，不改變頁面本身。
第二問是「這條連結要完成什麼任務」。傳給同事重現缺陷，對方需要的是穩定的資源地址，不需要知道你來自 utm_campaign=summer-sale。傳給使用者「請開啟這個商品」，對方需要 sku，不需要你剛剛點過的 gclid。只有當你的任務就是「請對方從這條帶參活動連結進入，以便我們統計這次轉發」，才應該保留 UTM；即便如此，也不該附帶你自己的點擊 ID。
手動刪很容易漏。一條真實投放連結可能同時有五六個 utm_*、一個點擊 ID、兩三個站內歸因。肉眼從右往左擦，經常擦掉 id，卻留下 fbclid。更穩的做法是按鍵名規則處理：凡是 utm_ 前綴一律去掉；再去掉已知的點擊 ID 表；若任務允許，再去掉常見分析鍵（_ga、_gl、mc_eid、mkt_tok）和常見電商歸因。路徑、主機、業務查詢保留。做完之後對照「已刪除鍵名清單」，而不是只看結果是不是「短了一些」。
保守和標準是兩種不同的風險偏好。保守：只動 UTM 和點擊 ID，盡量不動站內自訂鍵，避免把尚未認得的業務參數誤刪。標準：再加上常見分析和電商歸因，適合把連結發到公司外部或公開區域。兩種都不能聲明「已經匿名」。頁面路徑本身可能含使用者名稱，查詢字串裡的 email= 也不在 UTM 表裡。規則清洗解決的是已知追蹤鍵，不是任意敏感欄位。文字裡的手機號碼、身分證字號、金鑰要另做遮蔽，不能指望清 URL 參數一次做完。
寫給同事的最短可用句子：重現用路徑 + 業務參數；統計用 UTM，且不要附帶自己的點擊 ID。拿不準時先清 utm_* 和 *clid，再人工看剩下的鍵。
當場核對：對照剝離清單，再搜 Network
口號寫「本機清洗、不上傳」無法自證。能當場看到的是三樣東西：哪些鍵被刪了，哪些鍵還在，以及你的原始 URL 有沒有作為業務資料出站。
先準備一條金絲雀。開啟一個不會涉及真實客戶的公開頁，在網址後追加 ?utm_source=canary-share&utm_medium=email&utm_campaign=canary-2026&fbclid=canaryclid&id=42。把整串貼進清洗輸入。跑完後，結果裡應當看不到四個追蹤鍵，應當仍看得到 id=42。若工具給出「已剝離」清單，逐項核對這些名字，不要只看最終 URL 變短了。
再開啟開發人員工具的 Network，勾選 Preserve log，在篩選器裡貼上 canary-share 或整段金絲雀查詢字串。XHR / Fetch 的請求行、查詢字串和請求主體都不該出現它；造訪統計的 query 與 body 同樣不該出現。靜態資源、樣式和指令碼可以出現——那是頁面自己的檔案。原文作為業務欄位出站，才算失敗。標題或路徑裡出現「隱私」「清洗」字樣是預期，輸入框全文不是。
- 構造帶
utm_*、fbclid和業務id的金絲雀 URL，不要用真實客戶或未公開活動名。 - 清洗後核對對照表：追蹤鍵應在「已刪除」一側，
id應在結果 URL 裡。 - 用金絲雀字串搜尋 Network；命中任何業務請求即說明原文離開了分頁。
這套步驟證明的範圍很窄：這一次操作裡，已知追蹤鍵依規則消失，業務鍵還在，原文沒有作為已觀察到的 HTTP 欄位離開目前分頁。它不證明擴充功能沒有讀取輸入框，也不證明未列入規則的自訂追蹤鍵已被處理。換瀏覽器或換規則表之後，值得再跑一遍金絲雀。
用開啟即用的清洗頁把規則練熟
若你希望用一個把剝離清單寫在頁面上的工具來練習，可以從 MakePwd 的隱私清洗開始。開啟即可使用，無需註冊，也沒有帳號。URL 解析和參數剝離發生在目前分頁；原文依產品說明不作為請求發出，也不會寫入 analytics。標準模式清掉 utm_*、廣告點擊 ID、常見分析參數，以及 Shopee、Facebook、Google 廣告等場景裡常見的歸因鍵；保守模式只清掉 UTM 和點擊 ID。路徑和 id、q 這類業務參數會保留。一次最多 100 條，單條超過 8 KB 會被拒絕，只接受 http 或 https。
練習時用上面的金絲雀，不要用正在投放的真實點擊 ID。跑完同時看兩處：右側或結果區的剝離清單，以及 Network 裡有沒有原文。清單是給「刪對了沒有」用的；Network 是給「有沒有上傳」用的。兩處都過，才能向同事說明：我刪的是這些鍵，我搜過金絲雀沒有出站。
清洗只處理連結形態。聊天紀錄或工單正文裡的手機號碼、身分證字號、電子信箱、API Key，要切到同一頁的個資遮蔽，依模式做遮罩，並且仍然需要人工覆核。MakePwd 不聲稱符合個資法或 GDPR 認證。若清洗完仍是一段必須保密的內容，用閱後即焚一次性發送，金鑰留在 URL 的 # 片段；整份檔案則用檔案加密盒在本機做成 .lock / .enc 再走雲端硬碟或電子郵件。這些步驟都不要求登入。
常見問題
清掉 UTM 之後，接收方還能開啟頁面嗎？
能，只要業務參數和路徑還在。UTM 和點擊 ID 服務歸因，不服務路由。刪掉 utm_campaign 或 fbclid，到達頁仍應依路徑和 id 開啟。若刪完 404 或結果變了，代表誤傷了業務鍵，應退回保守模式並逐個對照。
HTTPS 是不是已經保護了這些參數？
沒有保護到外發這一步。HTTPS 降低傳輸中被竊聽的風險，不會清掉網址列、歷史紀錄、聊天和日誌。OWASP 寫明：即便走加密通道，查詢字串仍會出現在 Referer、Web 日誌、共用系統和瀏覽器歷史裡。該不該貼完整連結，和網站有沒有憑證是兩件事。
Apple 會自動清掉追蹤參數，我還要自己清嗎？
要。系統能力作用在「訊息」分享和 Safari 私密瀏覽等路徑，且不公布完整名單；UTM 通常會留下。你把連結貼進工單或 Android 裝置上的 LINE 時，這些保護不會替你執行。外發策略看的是剪貼簿內容，不是接收方系統會不會再清一次。
乾淨連結會不會把商品 id 也刪掉？
依鍵名規則時不應該。id、q、sku 不是 utm_ 前綴，也不在常見點擊 ID 表裡。核對方法是金絲雀裡同時放追蹤鍵和業務鍵，看結果是否只少了前者。若某站把追蹤寫進自訂鍵名，規則表不會認得它，需要人工刪或擴充名單。
下次外發前記住的三件事
第一，網址列全選不等於可以外發。問號後面先分成活動標籤、點擊 ID、站內歸因和業務參數，只有最後一類預設該留。第二，HTTPS 和系統自動剝離都不代替你檢查剪貼簿；查詢字串會進歷史紀錄、工單、日誌，並可能經 Referer 再走一程。第三，核對看兩處：已刪除鍵名清單，以及用金絲雀搜尋 Network。
若你還要繼續追問「明文有沒有作為業務資料離開這個分頁」，請讀線上加密安全嗎？怎麼當場核對明文沒有離開本機。本文只把「完整連結裡哪些查詢字串不該跟著外發」收成可以寫進結論的範圍。