GA4パラメータの設計・設定方法｜イベント・ユーザー・アイテムを区別
2026年7月1日
著者: 与謝秀作
GA4のイベントパラメータは、計測した行動に説明を添える情報です。ただし、イベントの付加情報、ユーザーの属性、商品ごとの情報は同じ扱いではありません。分析したい問いから設計し、送信、カスタム定義、レポートの検証を分けると、不要な項目や解釈の違いを減らせます。ここではコードを写す前に決める内容を、設定値の表と確認例で整理します。
イベント名・パラメータ・ユーザープロパティの違い
イベント名は「何が起きたか」、イベントパラメータは「その行動の詳細」を表します。page_viewに対するpage_locationは閲覧URLです。page_referrerは前ページURLを表す情報で、流入元のsourceと常に同じではありません。
ユーザープロパティはmembership_tierなどユーザーに関する属性です。会員ランクも変化し得るため、更新する条件を定義します。イベントパラメータを送って登録時の範囲だけをUserにしても、ユーザープロパティにはなりません。ecommerceのitems内で商品ごとに持つ情報はアイテムスコープとして別に設計します。ユーザープロパティの公式説明を確認してください。
標準で取れる情報と独自に送る情報の選び方
最初に既定のイベントパラメータとレポート項目を確認します。page_locationのように定義済みの項目を、同じ意味のカスタムディメンションとして重複登録する必要はありません。拡張計測は対象機能の設定とサイトの実装条件に左右され、オンにすればすべての操作が取れるとは限りません。
購入を扱うなら推奨イベントとvalue、currency、transaction_id、itemsなどの仕様を先に検討します。独自イベントは既定の仕組みで答えられない問いに絞ります。記事カテゴリ別に読まれ方を見たい場合はカテゴリを送り、個々の閲覧を識別するだけの大量の固有IDは分析軸にしない、といった判断が必要です。
イベント・ユーザー・アイテムの設計表を作る
次は説明用の架空設計です。名称だけでなく値を得る場所、送るタイミング、対象イベント、更新担当を決めます。会員ランクはユーザー情報を扱う仕組みで設定し、記事カテゴリはその記事を表示したイベントに付けます。
目的 | イベント・送信値 | スコープ／登録 | 確認事項 |
|---|---|---|---|
カテゴリ別閲覧 | article_view、article_category=analytics | Eventのカスタムディメンション | 公開記事の分類。個人情報を含めない |
会員区分別の行動 | membership_tier=freeというユーザープロパティ | Userのカスタムディメンション | ログイン・変更・ログアウト時の更新条件 |
商品色別の分析 | items内item_color=blue | Itemのカスタムディメンション | 各商品の値を正しい階層へ |
読了の深さ | article_view等の定義済み対象でreading_depth=75 | 数値指標なら単位を決めて登録 | 75は割合か段階か。合計値の意味も確認 |
user_idは専用のUser-ID機能で扱う予約された項目です。User-IDをカスタムディメンションへ登録しないという指針に従い、汎用的な会員IDの例として独自定義を増やしません。
Googleタグ／GTMで送信して値を検証する
直接設置のGoogleタグと、GTMで管理するGA4イベントタグのどちらを使うかは既存構成と保守担当に合わせます。GTMならイベント名、パラメータ名、値を供給する変数、トリガー条件を確認し、Googleタグの送信先と合わせます。公開前のプレビューと、実際のデータが届く検証は分けて行ってください。
- 架空のarticle_viewを1回再現し、article_category=analyticsが送られるか確認する。
- 同じ操作で直接設置とGTMの両方から送っていないか調べる。
- 本番ホストと対象プロパティ、同意状態、値の取得時点を記録する。
- DebugViewでイベント名と値を確認する。カスタム定義の登録前でも収集の確認はできる。
送信方法とDebugViewを参照し、値を送る仕組みそのものを検証します。個人情報を試験データとして送らないでください。
カスタムディメンションと指標を登録する
分類に使う文字列はカスタムディメンション、量を計算する数値はカスタム指標として検討します。管理のカスタム定義で表示名、範囲、送信側の正確なパラメータ名またはユーザープロパティ名を照合します。表示名と送信名は役割が異なり、送信名の大文字小文字も一致させます。
例えばarticle_categoryはEvent、membership_tierはUser、items内のitem_colorはItemです。reading_depthを数値指標にする場合は「75」の単位と、合計・平均が何を表すかを先に決めます。数値だから自動的に有用な指標になるわけではありません。カスタム定義の公式資料では反映の通常目安を24〜48時間としていますが、未送信や名前違いを待つだけでは直せません。
収集上限・定義上限・予約名を別々に確認する
2026年10月12日に確認した標準プロパティの例です。収集時の制約と、プロパティのレポート定義枠を別に管理します。360など異なる種別へそのまま当てはめず、実装前に最新表を確認してください。
区分 | 標準プロパティの上限例 | 判断 |
|---|---|---|
収集 | イベント当たりパラメータ25 | 不要項目を減らしイベント設計を見直す |
Userのカスタムディメンション | 25 | ユーザー属性として必要か確認 |
Eventのカスタムディメンション | 50 | 既定項目との重複を避ける |
Itemのカスタムディメンション | 10 | 商品単位の問いに限定 |
カスタム指標 | 50 | 計算する量と単位を明確にする |
根拠はイベント収集制限とカスタム定義の割り当てです。上限超過を理由に1回の行動を機械的に複数イベントへ分割すると、イベント数やキーイベント数を増やす恐れがあります。予約名と接頭辞は命名規則で確認します。
PII・高カーディナリティ・重複送信を防ぐ
氏名、メール、電話番号などのPIIを送らない設計にします。イベントの値だけでなく、URL、ページタイトル、UTM、サイト内検索語句、フォームの自由入力にも注意します。同意があることと、AnalyticsへPIIを送ってよいことは別の確認事項です。
データの秘匿化は補助機能で、すべての送信経路を包括的に保護するものではありません。入力元で不要な値を除くことを優先します。また、閲覧ごとの固有IDなど値の種類が多い分類はレポートを扱いにくくします。成功イベントの重複や計数方法も確認し、イベント件数を登録人数と同一視しません。
反映されない場合の確認と運用チェックリスト
DebugViewには値があるのにレポートが(not set)なら、登録名、範囲、登録時点、通常処理の時間、分析対象イベントを順に見ます。article_viewにしか付けない値を全イベントで分析すれば、他イベントの欠測は想定内です。定義を変えれば過去データが自由に補完されるとは考えません。
- 分析する問いと、使うイベント・指標を1文で書く。
- 名称、型、単位、許容値、取得元、対象イベント、責任者を設計表へ残す。
- 1回の操作から送信、DebugView、定義、処理後レポートの順に確認する。
- サイト改修や同意管理の変更時に、送信値と重複を再点検する。
必要なパラメータだけを選び、収集とレポート利用の両段階に合格条件を持たせることが、運用できる設計の出発点です。
関連記事
出典・仕様の確認日
仕様は2026年10月12日に以下の一次資料で確認しています。画面構成は権限やレポートコレクションによって異なります。
