URLパラメータとは?付け方・UTM・GA4計測の注意点
2026年6月22日
著者: 与謝秀作
URLパラメータは、URLのクエリ部分で検索条件や識別用の値を渡す仕組みです。商品の絞り込みなどページの動作に使うものと、UTMのように流入を区別するものがあります。構造を理解せずに付け足すと、ページの機能や計測を壊すことがあります。ここでは基本の読み方からGA4での確認まで、2026年10月11日確認の公式資料に沿って説明します。
URLの?・&・=・#とパラメータの構造
例として https://example.com/guides?category=analytics&utm_source=newsletter#checklist を読みます。/guidesはパス、最初の?以降から#の前までがクエリ、#checklistはフラグメントです。クエリ内のcategory=analyticsのように、名前と値を=で組にして、複数の組を&でつなぎます。
部分 | 例 | 意味 |
|---|---|---|
パス | /guides | 対象となるページや資源 |
クエリの開始 | ? | ここからクエリが始まる |
名前と値 | category=analytics | categoryという名前にanalyticsを指定 |
次のパラメータ | &utm_source=newsletter | 既存のクエリに別の組を追加 |
フラグメント | #checklist | ページ内の位置など。クエリとは別の部分 |
クエリがあるURLへ二つ目の?を加えると、意図した名前・値として扱われないことがあります。#の後ろへUTMを書いても通常のクエリにはなりません。仕様上の扱いと、そのサイトがどの名前を受け付けるかは別なので、元ページの動作も確認します。
検索・絞り込みとUTMなどの計測パラメータを分ける
検索語、カテゴリ、並び順、ページ番号などは、サイトの処理に必要な場合があります。一方、UTMはキャンペーンの流入を識別するために使います。見慣れないパラメータをすべて不要と判断して削除しないでください。決済や認証のURLでは、独自の値が動作に関係することもあります。
URLパラメータがあれば必ずページの内容が変わるわけでもありません。同じ記事に異なるUTMを付けても、通常は流入の区別を目的としています。サイト側の実装によって処理は異なるので、機能用パラメータと計測用パラメータの管理者を明らかにしましょう。
GA4で使うUTMの役割と命名ルール
Google公式のキャンペーンURLの案内を基に、まず配信元・方法・キャンペーンを一貫して識別できるようにします。すべてのURLパラメータでutm_sourceやutm_mediumが必須という意味ではありません。UTMを運用する場合の基本項目と、用途に応じた項目を分けます。
項目 | 架空の値 | 使い道 |
|---|---|---|
utm_source | newsletter | 配信元の区別 |
utm_medium | 配信方法の区別 | |
utm_campaign | october_guide | 施策名の区別 |
utm_id / utm_source_platform | guide_2026_10 / 配信基盤の管理名 | 施策IDや配信プラットフォームを必要な用途に合わせて記録 |
utm_content / utm_term | header_link / 管理対象のキーワード | クリエイティブ・掲載位置や検索語等の区別。不要なら無理に埋めない |
newsletterとNewsletterのような表記揺れを避け、担当者が台帳で選べる値を用意します。媒体の既存設定や自動タグとの併用は、その配信仕様を確認してください。命名は見た目の統一だけでなく、レポートでどの単位を比較するかから決めます。
既存のクエリや日本語を含むURLに安全に追加する
元URLが https://example.com/guides?category=analytics#checklist なら、追加例は https://example.com/guides?category=analytics&utm_source=newsletter&utm_medium=email&utm_campaign=october_guide#checklist です。既存のcategoryを残し、UTMをクエリ内へ追加し、フラグメントを最後に保っています。これは架空例であり、実際の配信先に置き換えてテストします。
値に空白、日本語、&などの意味を持つ文字が含まれる場合は、適切なエンコードが必要です。「日本語は絶対に使えない」ということではありません。URLSearchParamsの仕様などを使う実装では、名前と値を個別に渡して組み立てます。エンコード済みの値を再度処理する二重エンコードや、同じ名前の重複にも注意してください。
- 元のURLで対象ページと機能が正しく開くことを確認する。
- 既存のクエリとフラグメントを分け、必要なパラメータを残す。
- 管理した値を追加し、文字列を手で無理につなぎ替えない。
- 完成したURLを実際の配信経路で開き、表示と遷移を確認する。
リダイレクトとGA4の取得結果を確認する
URL作成ツールで生成できても、計測できるとは限りません。短縮URL、メールのリンク処理、転送、認証を通った最終ページでUTMが残るかを確認します。ページが開くこと、タグが送ること、目的のGA4に届くことを別々に確かめます。
- 配信するURLと最終的な着地URLを比較し、必要な値の消失・書換えを調べる。
- 対象プロパティと本番ホストを確認し、許可されたテストで受信を調べる。
- DebugViewなどでイベントとパラメータを確認し、同意等による見え方の制約も記録する。
- 処理後のレポートでセッションとイベントのスコープを分けて確認する。
GA4のキャンペーンと参照元の処理では、セッション途中に新しいキャンペーン情報が来ても、それだけで新しいセッションを開始しません。UAの挙動をそのまま当てはめず、UTMを付けたクリック数、セッション数、ユーザー数を同一視しないことが大切です。
内部UTM・個人情報・運用台帳の注意点
サイト内の関連記事やボタンへUTMを付けると、イベントに関係する流入情報の解釈を汚す可能性があります。「必ず新規セッションになるから禁止」と説明するのもGA4では不正確です。内部の移動を測るなら、外部キャンペーンのUTMと分けて内部クリック等のイベントを設計し、成功への到達まで検証します。
Googleの個人情報送信防止ガイドに沿い、メールアドレスや氏名などをURLやページタイトル、送信パラメータに含めない設計を優先します。データ編集機能は補助となる仕組みで、全経路の個人情報を必ず除く保証ではありません。ウェブタグ以外の送信も含めて収集元で確認します。
運用台帳には配信日、配信元、リンク先、UTM、担当者、確認日を記録し、個人を特定する値を埋め込みません。登録への貢献を測る場合も、遷移と受付成功、重複、同意、本番・認証ドメインを確認します。UTM付き訪問やイベント件数を登録人数と読み替えず、観測できる範囲を示しましょう。
次に確認する内容


