リンクを転送する前にトラッキングパラメータを外す理由と、外したあとに残るもの

LINE、広告管理画面、通販の商品ページからコピーしたアドレスには、疑問符の後ろに UTM、fbclid、gclid が付いていることが多いです。飾りではありません。HTTP のリクエスト行に入り、次に開く人、相手のサーバー、アクセスログが、どの流入元・どのクリックから来たかを見られます。外したあとに証明できるのは、この文字列から既知のトラッキング query が消えたことだけです。着地ページのピクセル、cookie、パス上の印は残ります。

先に結論です。共有前に外すのは、疑問符の後ろに「どこからクリックしたか」を書いたクエリです。確認方法は、リンクが短くなったことではありません。除去したパラメータの一覧を読み、pathname と id=、q= が残っているかを見ます。洗った URL はシークレット閲覧ではなく、着地ページに計測スクリプトがない証明にもなりません。

検索意図に一文で答える

リンクを転送する前にトラッキングパラメータを外すのは、クエリ文字列が HTTP のリクエスト対象の一部だからです。ブラウザが文書を取りに行くとき、疑問符の後ろの utm_source、fbclid、gclid はリクエスト行に書かれます。ホスト、リバースプロキシ、アクセスログは、設計どおりそれを見ます。この文字列ごと LINE やチケットに貼ると、流入元とクリック識別子を、次に開く人へ渡したことになります。

このノートは運用、サポート、そして資料を外へ出す前に「アドレスに何が書いてあるか」と「開いたあとに何が起きるか」を分けたい人向けです。リンク洗浄 の操作説明の代わりにはならず、「どのボタンでクリーンな URL が出るか」も繰り返しません。持ち帰るべきなのは、UTM とクリック ID がそれぞれ何を書くか、転送時に誰がそれを引き継ぐか、外したあとにまだ証明できること、除去一覧と Network でのその場の照合です。

疑問符の後ろは HTTP に入る。自分だけが見る欄ではない

RFC 3986 §3.4 は、query を最初の ? のあと、フラグメントの前までの区間と定義します。RFC 9110 は続けて、リクエストの対象 URI はパスとクエリを含み、フラグメントを含まないと定めます。アドレスバーが長いのは見た目の問題ではありません。この文書リクエストは、疑問符の後ろのキーと値を相手側へ渡します。

ハッシュの後ろのフラグメントは、デフォルトでは今のタブに残ります。照合の仕方は別のノートに書いてあります。本稿は疑問符だけを見ます。二つの規則を並べると、「サーバーは # 以降の鍵を見ない」を「サーバーは ? 以降の流入元も見ない」と読み違えません。

ブラウザの 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=vip_line&utm_campaign=refund_202609 があれば、当番、あとからチケットを検索する人、表へ書き出す人も、「どの限定キャンペーンから来たか」を読めます。

UTM 自体に、身分証番号やパスフレーズは通常入りません。漏れるのは文脈です。どのメールを開いたか、どの広告を押したか、サポート専用のリンクから来たか。その文脈が転送できる URL に入った時点で、自分のタブだけには止まりません。

クリック ID が指すのは「その一回」であり、キャンペーン名ではない

クリック ID は、キャンペーン名より「このクリック」に近い番号です。Google 広告の自動タグは、着地 URL の後ろに gclid(Google Click Identifier)を付けます。公式の形は www.example.com/?gclid=123xyz です。自動タグがオンで、サイトに Analytics があるとき、この値はサイトドメインの cookie にも書かれ、あとからのコンバージョンをそのクリックへ戻せます。根拠は Google 広告の自動タグ説明 です。

iOS 14 以降の一部では、同意がないと gclid を使いません。Google は別に gbraid(Web からアプリ寄り)と wbraid(アプリから Web 寄り)を入れ、プラットフォームの制約の下でも広告計測を続けます。これは Analytics の iOS 14+ キャンペーン計測の説明 であり、洗浄ツールが作った分類ではありません。

Meta 側でよく見るのは fbclid です。開発者向け文書は、ページ URL にこのクエリがあれば、Conversions API はそこから fbc を組み立てられると書きます。サイトに Meta Pixel があるとき、クリック番号は _fbc というファーストパーティ cookie にも入り、形は version.subdomainIndex.creationTime.fbclid です。根拠は Meta の fbp / fbc パラメータ説明 です。fbclid 付きのアドレスを同僚へ送ると、同僚が開いたとき、相手サイトは「このクリック」の印を自分の cookie と後続の計測イベントへ取り込めることがあります。

同じ系統の名前は msclkid、ttclid、twclid、li_fat_id としても出ます。それぞれ自分の広告アカウントのために使われます。共通点は単純です。query に書けばリクエスト行と一緒に送られ、転送する文字列に書けば、次に開く人が引き継ぎます。

本番の配信リンク、顧客の電話番号が入った短縮 URL、マスクしていないチケットで試さないでください。公開してよい見本を用意し、値には一度きりの印を入れてください。照合するのは query とリクエスト行であり、業務の流入元をもう一度広げることではありません。

転送すると、次の人が query 全体を引き継ぐ

共有ボタン、ブラウザの「アドレスをコピー」、チャット履歴の長押しがコピーするのは、いまの完全な URL であることが多く、サイトが表に出したい短いパスではありません。LINE、メール、広告プレビューで特に分かります。見えているのは記事や商品なのに、クリップボードには pathname の後ろに帰属欄が付いた長い列が入ります。

これらの欄は、三つの場所へ入ります。第一に、チャットやチケット本文です。スレッドの全員と、あとから検索する人が読めます。第二に、相手のアドレスバーと、そこから同期する履歴です。第三に、相手が開いたときに出す文書リクエストです。サーバーログには完全な query が残ります。自分のチャットからその一行を消しても、すでに開いた人や、すでに書いたログは変わりません。

配信の計測リンクをそのまま対外告知に貼ること、利用者がコピーした長い URL をチケットへそのまま戻すこと、再現用アドレスに gclid が付いたまま issue へ貼ること。どれも同じ動作です。自分のアドレスバーにあったクリックの文脈を、「この文字列を見た人なら再利用できる印」へ変えています。

外したあとに証明できることと、アドレスに残るもの

洗った URL が支えられる主張は狭いです。狭く書いた方が、誤読が一度減ります。支えられるのは、使った一覧と今回の実行で、既知の utm_*、クリック ID、(広いモードなら)一部の帰属欄が query から消えたことです。pathname は残ります。id=、q= のような業務パラメータは、設計どおり残します。リンクは同じ記事を開くはずです。

支えられないのは、着地ページにピクセルがないこと、相手サイトにファーストパーティ cookie がないこと、短縮 URL の飛び先が新しいパラメータを付けないこと、パス自体に追跡トークンがないこと、拡張機能がクリップボードを書き換えていないことです。「開いたあと、誰もあなたが誰かを知らない」も言えません。直したのは、これから送る文字列です。次の閲覧セッションではありません。

いちばん多い見かけ上の合格は、短縮 URL です。短縮サービスは本当の行き先を自分のリダイレクトの後ろに隠します。https://short.example/abc を洗うと query は空であることが多く、ツールは「外せるパラメータがない」と報告します。追跡は 302 のあとの長い URL にあります。照合するなら、シークレットウィンドウで短縮 URL を開き、アドレスバーの最終 URL をコピーしてください。実在の個人情報を含む短縮 URL では、この手順を踏まないでください。

見えている変化 支えられる結論 支えられない結論
リンクが短くなった query の文字が減った すでに匿名、すでに安全
除去一覧に utm_*、fbclid がある これらのキーがこの URL から消えた 着地ページが _fbc や Analytics cookie を書かない
id=、q= が残っている 業務の位置指定は設計どおり残った 残ったキーがすべて業務に必要
短縮 URL が「外せるものがない」と報告する この短いアドレス自体が一覧に当たらなかった リダイレクト後の長い URL もきれい
Network に元のリンクが出ない 今回の洗浄リクエストが原文を業務データとして送っていない 拡張機能やチャットクライアントも保存していない

その場で照合する:除去一覧と Network

スローガンは証拠になりません。この端末で終わる確認は二層です。ひとつは洗浄結果、もうひとつは外向きの通信です。捨ててよい見本を用意してください。例は次です。

https://example.com/article/42?id=42&q=aes&utm_source=line&utm_medium=social&utm_campaign=share_20260903&fbclid=IwAR0canaryfp&spm=demo.share.0

カナリアは utm_campaign と fbclid の値に置きます。洗浄後、クリーンなアドレスに share_20260903 や IwAR0canaryfp は出てはいけません。id=42 と q=aes は残るはずです。

  1. 先に、除去したパラメータの一覧を読みます。utm_source、utm_medium、utm_campaign、fbclid が見えるはずです。広いモードなら、spm のような EC の帰属名も出ます。一覧が空なのに「きれいになった」と感じたら、短縮 URL か、パスに書いた印を疑ってください。
  2. 次に、クリーンなアドレスの pathname と残った query を読みます。記事番号や検索語が消えていれば誤削除です。その結果は送らないでください。
  3. 開発者ツールの Network を開き、Preserve log をオンにし、フィルタは All にします。カナリアを検索欄へ貼ります。リクエスト行、本文、解析報告に、その未洗浄のリンクは出てはいけません。

FastPwd のリンク洗浄は、この境界で動きます。解析はこのタブで行います。1件が 8 KB を超える URL は拒否し、一度に処理できるのは最大 100 行、受け付けるのは http / https だけです。保守モードが外すのは utm_* とクリック ID(fbclid、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 だけを外してください。処理後は除去したパラメータの一覧を照合し、リンクが短くなったことだけを根拠にしないでください。必要なキーが一覧に出ていれば、今回の結果は使わないでください。

短縮 URL も先にパラメータを外すべきですか?

短縮 URL 自体に UTM は付いていないことが多いです。追跡はリダイレクト後の長いアドレスに書かれます。短縮形だけを洗うと、たいてい何も外れません。シークレットウィンドウで開き、アドレスバーの最終 URL をコピーしてから外してください。実在の個人情報を含む短縮 URL で試さないでください。公開してよい見本で足ります。

FastPwd で洗うとき、元のリンクはアップロードされますか?

製品の説明どおり、解析と除去はこのタブで完了します。原文は HTTP の業務データとして送らず、アクセス解析にも書きません。アクセス解析が記録するのは「洗浄した」といったイベント名です。今回を照合するなら、カナリアを Network で検索してください。リクエスト行、本文、解析報告に、その未洗浄のリンクは出てはいけません。localhost は初期状態ではアクセス解析を送りません。実利用に近い確認なら、公開ドメインでもう一度見てください。

同じリンクを、開いてすぐ使えるツールで照合する

除去一覧を表に出したページで練習するなら、FastPwd の リンク洗浄 を開いてください。登録は不要です。上の見本を貼り、先に保守モード、次に標準モードを走らせ、二つの「除去」チップを比べてください。どちらのモードも UTM と fbclid を外し、標準モードだけが spm に触れるはずです。クリーンな結果では id と q が残ります。

同じページは、チケット本文の電話番号やメールを伏せる個人情報マスクへも切り替えられます。それは別の記事の主題です。秘密のまとまりを同僚へ渡すときは、ワンタイムリンク を使ってください。この端末で AES-256-GCM により暗号化し、サーバーが一時保存するのは暗号文だけです。鍵はリンクのハッシュの後ろに残ります。いま洗った業務リンクと、ワンタイムリンクの完全なアドレスを、同じスレッドへ並べて貼らないでください。

次に送る前に、三つ覚えてください。第一に、疑問符は HTTP に入り、流入元とクリック ID はそこにあります。第二に、外す操作が変えるのはこれから送る文字列であり、着地ページの計測は止まりません。第三に、短縮 URL、パス上の印、送信後に足されるパラメータは、それぞれ別の照合が要ります。繰り返せる観察だけが、自分たちの外向け説明に書く価値があります。

関連記事

疑問符とハッシュを混ぜないでください。鍵を # の後ろに置ける理由と、完全なリンクをチャットに貼ったときに消える層は、URLの#以降に鍵を置ける理由と、その保護が崩れる場面 にあります。チケット本文の電話番号、身分証番号、API Key を、端末を出る前に照合する方法は、チケットとログをAIに貼る前に、どの欄が端末を出るかを確認する です。洗浄そのものが元のリンクを業務データとして送っていないかを見るなら、ブラウザのローカル暗号化で、平文が端末を出ていないことを確認する のカナリア手順で足ります。