GA4のイベント設計で大切なのは、計測できる行動を片っ端から記録することではなく、事業のKPIから逆算して「成果に直結する行動」と「成果に至るまでの途中の行動」をイベントとして定義することです。PV（ページの閲覧数）やスクロールの量だけを見ていても、問い合わせや購入、登録がなぜ増えたのか、なぜ減ったのかは分かりません。事業の成果を示す行動と、その手前の段階の行動をイベントとして設計し、名前の付け方とパラメータ（イベントに添える詳細情報）を決めておくことで、GA4は事業の判断に使える道具になります。
設計の手順は、まずKPIツリーや顧客の行動の流れから計測すべき行動を洗い出し、次に命名規則を決めてイベントの名前を付け、各イベントに添えるパラメータを決め、最後に設計書（トラッキングプラン）として文書にまとめる、という流れです。設計書があれば、実装する人が変わっても、後から計測を追加するときも、名前や定義がぶれません。
この記事は、自社のWebサイトやWebサービスでGA4を導入しているが、PVくらいしか見ていない、イベントの名前がばらばらで集計しにくい、計測を整え直したい、と考えている事業責任者やマーケティング担当、開発担当の方に向けて書いています。計測すべき行動の選び方、命名規則、パラメータの設計、実装と検証の進め方、よくある失敗までを解説します。
GA4の計測はイベントが基本単位
GA4（Googleアナリティクス4）では、ページの閲覧も、ボタンのクリックも、購入も、すべて「イベント」として記録されます。ページの閲覧は page_view というイベント、購入は purchase というイベント、といった具合です。イベントには、それぞれ詳細を示すパラメータを添えられます。たとえば購入のイベントには、金額や商品の情報をパラメータとして添えます。
GA4のイベントは、大きく次の四つに分けられます。
| 種類 | 内容 | 例 | 設定の要否 |
|---|---|---|---|
| 自動収集イベント | GA4を導入すると自動で記録される | 初回の訪問、セッションの開始、ページの閲覧 | 不要 |
| 拡張計測機能のイベント | 管理画面で有効にすると記録される | スクロール、外部リンクのクリック、サイト内検索、ファイルのダウンロード | 管理画面で有効化 |
| 推奨イベント | Googleが名前とパラメータを推奨しているもの | 会員登録、ログイン、購入、カートへの追加 | 実装が必要 |
| カスタムイベント | 自社で名前とパラメータを定義するもの | 資料請求の完了、料金表の閲覧、特定の機能の利用 | 実装が必要 |
自動収集と拡張計測のイベントだけでは、事業の成果に関わる行動はほとんど捉えられません。会員登録や問い合わせの完了、資料のダウンロード、料金ページの閲覧から申込みへの進み具合などは、推奨イベントかカスタムイベントとして、自社で設計して実装する必要があります。推奨イベントに当てはまる行動は、推奨の名前とパラメータを使うと、GA4の標準のレポートで扱いやすくなります。各イベントの仕様は変わることがあるため、実装の前にGoogleの公式の説明で最新の情報を確認してください。
計測すべき行動をKPIから逆算する
イベント設計の出発点は、GA4でできることではなく、事業で知りたいことです。次の手順で、計測すべき行動を洗い出します。
- 事業のKGIと、それを分解したKPIを確認する（例：月間の新規契約数 ＝ 問い合わせ数 × 商談化率 × 受注率）。
- KPIのうち、Webサイトやサービスの上で起きる行動を特定する（例：問い合わせの完了、資料請求の完了）。
- その行動に至るまでの顧客の流れを書き出す（例：記事を読む → サービスページを見る → 料金ページを見る → 問い合わせフォームを開く → 送信する）。
- 流れの各段階を、計測するイベントの候補にする。
- 各イベントについて、「この数字を見て何を判断するか」を書き出す。判断に使わないものは候補から外す。
- 残ったイベントを、成果のイベント（KPIに直結するもの）と、途中のイベント（成果に至る段階を示すもの）に分ける。
手順5が、計測を増やしすぎないための大切な関門です。「念のため」に計測したイベントは、ほとんどの場合、見られることはありません。イベントの数が増えると、名前の管理が大変になり、本当に見るべき数字が埋もれます。KPIの分解の仕方はKPIツリーの作り方：KGIから日々の行動指標へ分解する手順で解説しています。
事業の形ごとの成果と途中のイベントの例
| 事業の形 | 成果のイベント | 途中のイベントの例 |
|---|---|---|
| BtoBのサービスサイト | 問い合わせの完了、資料請求の完了、無料相談の予約 | サービスページの閲覧、料金ページの閲覧、フォームの表示、フォームの入力開始 |
| EC | 購入の完了 | 商品の閲覧、カートへの追加、購入手続きの開始、支払い情報の入力 |
| 会員制サービス・SaaS | 会員登録の完了、有料プランへの申込み | 登録フォームの表示、初回の主要機能の利用、プランの比較ページの閲覧 |
| メディア | 会員登録、メールマガジンの登録、送客先へのクリック | 記事の読了、関連記事への遷移、登録案内の表示 |
途中のイベントを計測しておくと、成果が減ったときに、流れのどの段階で離脱が増えたのかを特定できます。段階ごとの離脱を分析する方法はファネル分析のやり方：離脱箇所を見つけて改善につなげる手順で詳しく解説しています。
命名規則を決める
イベントの名前の付け方を決めずに実装を始めると、担当者ごとに名前の付け方が違い、後から集計しにくくなります。form_submit、FormSubmit、submit_form、問い合わせ送信、といった名前が混在すると、同じ行動なのか違う行動なのかも分からなくなります。
命名規則の例
次のような決まりを、設計書の最初に書いておきます。
- すべて英小文字と数字とアンダースコアで書く（日本語や大文字、空白を使わない）
- 「対象_動作」の順に並べる（例：form_submit、pricing_view、video_play）
- 動作を表す言葉の一覧を決め、それ以外は使わない（view、click、start、submit、complete など）
- 推奨イベントに当てはまるものは、推奨の名前をそのまま使う（sign_up、login、purchase など）
- 同じ種類の行動は、名前を分けずにパラメータで区別する（問い合わせと資料請求で名前を分けるのではなく、form_submit にフォームの種類のパラメータを添える、など）
- GA4の予約語や、自動収集のイベントと同じ名前を使わない
- 名前の長さとパラメータの数には上限があるため、短く簡潔にする
最後から二つ目と最後の項目は、GA4の仕様に関わる部分です。予約されている名前や、名前の長さ、パラメータの数の上限は、Googleの公式の説明で確認してください。
名前を増やすか、パラメータで分けるか
命名でよく迷うのが、似た行動をイベントの名前で分けるか、一つのイベントにしてパラメータで分けるかです。基本の考え方は、「同じ種類の行動はパラメータで分ける」です。問い合わせフォーム、資料請求フォーム、採用の応募フォームの送信は、どれも「フォームを送信する」という同じ種類の行動なので、form_submit という一つのイベントにして、form_type というパラメータで contact、document、recruit を区別します。こうすると、フォーム全体の送信数も、種類ごとの送信数も、同じイベントから集計できます。
一方で、成果のイベントとして特に重視するものは、別の名前にした方が扱いやすい場合もあります。GA4ではイベントを「キーイベント（成果として扱うイベント）」に指定できますが、指定はイベントの名前の単位で行うため、問い合わせの完了だけを成果として扱いたいなら、generate_lead のように別の名前のイベントとして記録する方法があります。
パラメータを設計する
パラメータは、イベントに添える詳細の情報です。同じ form_submit のイベントでも、どのフォームか、どのページから送信したか、といった情報があれば、分析の幅が大きく広がります。
パラメータを決めるときの考え方
各イベントについて、「このイベントを、どんな切り口で分けて見たいか」を考え、その切り口をパラメータにします。
- どの種類か（フォームの種類、ボタンの種類、プランの種類）
- どこで起きたか（ページの種類、画面の位置、記事のカテゴリ）
- どんな内容か（選んだ選択肢、検索の言葉、商品の分類）
- どのくらいか（金額、数量、所要時間）
パラメータの値も、表記をそろえるために一覧で決めておきます。フォームの種類なら contact、document、recruit のように、取りうる値を設計書に書いておきます。値の表記がばらつくと、集計のときに同じものが別々に数えられます。
カスタムディメンションとして登録する
自社で定義したパラメータは、GA4の管理画面でカスタムディメンション（または指標）として登録しないと、標準のレポートで切り口として使えません。登録できる数には上限があるため、本当に分析に使うパラメータを選んで登録します。登録する前に記録されたデータは、後から切り口として使えない場合があるため、パラメータは計測を始める時点で登録しておくのが安全です。
個人情報を送らない
パラメータに、メールアドレスや氏名、電話番号など、個人を特定できる情報を入れてはいけません。フォームの入力内容をそのままパラメータとして送ってしまう実装は、よくある事故の一つです。GA4の利用規約でも禁止されているため、設計の段階で、送ってよい情報の範囲を明確にしておきます。個人情報の扱いや、計測に関する同意の取得の方法については、法令やガイドラインが関わるため、最新の情報を専門家や公的機関で確認してください。
設計書（トラッキングプラン）にまとめる
ここまでの内容を、一つの設計書にまとめます。設計書はトラッキングプラン（計測設計書）とも呼ばれ、計測の仕様の唯一の正本として扱います。
設計書には、イベントごとに次の項目を記載します。
- イベントの名前
- 説明（どんな行動を記録するか、いつ発火するか）
- 計測の目的（この数字で何を判断するか）
- 成果のイベントか、途中のイベントか
- パラメータの名前、説明、取りうる値
- 発火する画面や条件
- 実装の方法（タグ管理ツールか、サービスのコードに直接か）
- 実装の状況と、確認した日
表計算ソフトで一行に一イベントを書く形にすると、関係者で共有しやすく、変更の履歴も残せます。計測を追加・変更するときは、必ず先に設計書を更新し、それから実装する、という順序を守ります。
実装と検証の進め方
設計書ができたら、実装と検証に進みます。
- 実装の方法を決める。Webサイトのボタンのクリックやページの閲覧はGoogleタグマネージャー（GTM）で設定できることが多く、会員登録の完了や購入など、サービスの内部の処理に関わるものは、サービスのコードから送る方が確実な場合があります。
- 本番とは別の検証用の環境やGA4の検証用の機能を使い、設計書どおりのイベントとパラメータが送られているかを一つずつ確認する。
- 二重に送られていないか（ページの再読み込みで成果のイベントが二回記録されないか）を確認する。
- 本番に反映し、数日後にレポートで件数を確認する。問い合わせや購入など、別のシステムでも件数が分かるものは、件数がおおむね一致するかを照合する。
- 設計書に実装の状況と確認した日を記録する。
手順4の照合は特に重要です。GA4の問い合わせの完了の件数と、実際に届いた問い合わせの件数が大きくずれている場合は、計測の漏れや二重の記録、あるいは計測の同意の設定の影響が考えられます。GA4の数字は、ブラウザの設定や同意の状況などによって、実際の件数と完全には一致しないものと理解したうえで、ずれの程度と傾向を把握しておきます。
架空の例：BtoBサービスサイトのイベント設計
法人向けのサービスを紹介するWebサイトを例に考えます。これまではGA4を導入しただけで、PVと流入元くらいしか見ていませんでした。問い合わせの件数は月によって増減していましたが、その理由は分かりませんでした。
まず、事業のKPIを確認し、Webサイトの成果を「問い合わせの完了」と「資料請求の完了」と定めました。そこに至る流れを「記事の閲覧 → サービスページの閲覧 → 料金ページの閲覧 → フォームの表示 → フォームの入力開始 → 送信の完了」と書き出しました。
イベントは、料金ページの閲覧を pricing_view、フォームの表示を form_view、入力開始を form_start、送信の完了を generate_lead とし、フォームの種類を form_type のパラメータで区別しました。サービスページの閲覧はページの閲覧のイベントで、ページの種類を区別できるようにしました。記事から来た人を区別するため、最初に閲覧したページの種類もパラメータとして記録しました。
計測を始めて二か月ほどたつと、問い合わせが減った月は、料金ページの閲覧は変わらないのに、フォームの入力開始から送信の完了への進み具合が落ちていたことが分かりました。フォームの項目が増えた時期と重なっていたため、項目を減らす改善を検討するという、具体的な次の行動につながりました。
よくある失敗とその避け方
PVと自動収集のイベントしか見ていない
導入しただけの状態では、事業の成果に関わる行動はほとんど計測されていません。成果のイベントと途中のイベントを設計して実装します。
名前がばらばらで集計できない
命名規則を決めずに実装すると、同じ行動が別の名前で記録されます。命名規則を設計書の最初に書き、すべてのイベントをそれに従わせます。
何でも計測して見るべき数字が埋もれる
判断に使わないイベントを増やすと、管理の手間が増え、重要な数字が見えにくくなります。各イベントに計測の目的を書き、目的のないものは計測しません。
カスタムディメンションの登録を忘れる
パラメータを送っていても、管理画面で登録していないと、レポートで切り口として使えません。実装と同時に登録します。
計測の変更が記録されていない
いつ、どのイベントを追加・変更したのかが記録されていないと、数字の変化が計測の変更によるものか、実際の行動の変化によるものか区別できません。設計書に変更の履歴を残し、レポートにも注釈を入れておきます。
GA4イベント設計のチェックリスト
- 事業のKPIから、Webサイトやサービスの上で起きる成果の行動を特定したか
- 成果に至るまでの顧客の流れを書き出し、途中のイベントを決めたか
- 各イベントに、計測の目的（何を判断するか）を書いたか
- 命名規則を決め、すべてのイベントが従っているか
- 推奨イベントに当てはまるものは、推奨の名前とパラメータを使っているか
- 同じ種類の行動は、名前ではなくパラメータで区別しているか
- パラメータの取りうる値を一覧で決めたか
- 分析に使うパラメータを、カスタムディメンションとして登録したか
- 個人を特定できる情報を送っていないか
- 成果として扱うイベントを、キーイベントとして指定したか
- 検証用の機能で、設計どおりに送られていることを確認したか
- 別のシステムの件数と照合し、ずれの程度を把握しているか
- 設計書に実装の状況と変更の履歴を残しているか
よくある質問
Q. GA4だけで、サービスの中の利用状況まで分析できますか？
Webサイトでの行動の分析にはGA4が適していますが、ログインした後のサービスの中での詳しい利用状況（ユーザーごとの機能の利用の推移、継続率など）を分析するには、プロダクト分析の専用のツールや、自社のデータベースの記録を使う方が向いている場合があります。用途ごとのツールの選び方はプロダクト分析ツールの選び方で解説しています。
Q. 新しいサービスの立ち上げ時には、どこまで計測すればよいですか？
立ち上げ時は、成果のイベントと、そこに至る主要な段階のイベントの数個に絞るのがおすすめです。何が重要かが分かってきた段階で、途中のイベントを追加していきます。立ち上げ時の計測の考え方はMVPに最低限入れる計測：イベント・問い合わせ・利用ログの設計も参考にしてください。
Q. すでにばらばらの名前でイベントを計測しています。作り直すべきですか？
今後も使い続けるなら、命名規則を決めて作り直すことをおすすめします。ただし、名前を変えると過去のデータと続けて比べられなくなるため、切り替えの時期を決め、一定期間は新旧の両方を記録するか、切り替えの時期をレポートに注釈として残しておきます。
Q. 開発会社に実装を頼むとき、何を渡せばよいですか？
この記事で説明した設計書を渡すのが最も確実です。イベントの名前、発火の条件、パラメータと取りうる値が書かれていれば、開発会社は迷わずに実装でき、発注側も設計どおりに実装されたかを確認できます。設計書がないまま「主要な行動を計測してほしい」と依頼すると、何を計測するかの判断が実装する人に委ねられ、事業の判断に使えない計測になりがちです。
Otsumuに相談できること
計測したい成果の行動が明確で、Webサイトの構成が比較的シンプルで、タグ管理ツールを扱える担当者が社内にいる場合は、この記事の手順に沿って自社でイベントを設計し、実装することは十分可能です。まずは成果のイベントと命名規則を決め、設計書を作るところから始めてみてください。
一方で、事業のKPIとWebの計測がつながっておらず、何を計測すべきかから整理したい、Webサイトとサービスの中の行動、問い合わせ後の商談のデータまでつなげて分析したい、既存の計測がばらばらで作り直しの進め方に迷っている、といった場合は、外部の手を借りた方が早く整うことがあります。
Otsumuでは、事業のKPIの整理から、計測すべき行動の洗い出し、命名規則とパラメータの設計、設計書の作成、実装と検証、集計のダッシュボードの整備までを一貫して支援しています。計測のための計測ではなく、事業の判断に使える数字を作ることを重視しています。詳しくはKPI改善コンサルティングのページをご覧ください。
今の計測の状況を見ながら、何から整えるべきかを一緒に考えることもできます。30分の無料相談からお気軽にご連絡ください。
この記事について
Otsumu株式会社が執筆しました。統計値や他社の事例には依拠せず、進め方と判断の枠組みを中心にまとめています。法務・税務・会計などの制度は、専門家や公的窓口で最新の情報をご確認ください。
執筆：Otsumu株式会社 ／ 編集日 2026.10.01