目次 › 第 3 部 GA4 のデータモデル

3.7 計測設計の実践

サイトの目的から逆算してイベントを設計する方法を身につけます。
基礎書籍換算 約 14 ページ

この章で学ぶこと

• ユーザー行動を洗い出して、計測すべきものを選ぶ方法
• イベント設計書のフォーマットと書き方
• 推奨イベントを優先した設計の進め方
• BtoB サイトとメディアサイトの設計例
• 設計をレビューするときのチェック観点

ユーザー行動の洗い出し

第 1 部では、KPI ツリーを作って「何を計測すべきか」を考えました。この章では、それを GA4 のイベントとパラメータに落とし込む 計測設計 を実践します。

計測設計の第一歩は、サイト上で ユーザーがどんな行動をするか を洗い出すことです。

カスタマー ジャーニーに沿って洗い出す

ユーザーの行動は、サイトを知ってから成果に至るまでの段階（カスタマー ジャーニー）に沿って整理すると、漏れが少なくなります。

計測の要否を判断する

洗い出した行動のすべてを計測する必要はありません。次の 3 つの質問で、計測するかどうかを判断します。

1. KPI ツリーに関係するか：KGI や KPI の改善に役立つ行動か
2. その数値を見て、判断が変わるか：数値がわかったら、何かを変える可能性があるか
3. 自動で計測されていないか：自動収集や拡張計測機能ですでに取れていないか

1 と 2 に「はい」、3 に「いいえ」の行動が、新たに実装すべきイベントの候補です。

ポイント 「とりあえず全部計測しておこう」は、イベントが増えすぎて管理できなくなる原因になります。「この数値を見たら何を判断するのか」を言えないものは、いったん保留にしましょう。必要になったら、そのときに追加すれば十分です。

イベント設計書のフォーマット

計測する行動が決まったら、イベント設計書 にまとめます。イベント設計書は、実装する人（開発者や GTM の担当者）と、分析する人の共通言語になる大切な資料です。

設計書の項目

設計書の運用ルール

• スプレッドシートで管理する：誰でも見られて、変更履歴が残る場所に置く
• パラメータの一覧を別シートにする：同じパラメータを複数のイベントで使う場合に、名前と意味を統一できる
• 変更したら必ず更新する：イベントの追加・変更・廃止のたびに更新する
• 廃止したイベントも消さない：「状態」を「廃止」にして残しておくと、過去のデータを見るときに役立つ

推奨イベントを優先する

第 1 章で説明したとおり、イベント名は推奨イベントを優先して使います。設計のときは、洗い出した行動ごとに「対応する推奨イベントがないか」を確認しましょう。

行動と推奨イベントの対応表

推奨イベントに独自のパラメータを加える

推奨イベントには、独自のパラメータを追加してもかまいません。たとえば generate_lead に form_name（どのフォームか）を加えると、「資料請求」と「問い合わせ」と「見積もり依頼」を同じイベントで計測しながら、フォームの種類ごとに分析できます。

gtag('event', 'generate_lead', {
    form_name: 'whitepaper_download', // 独自のパラメータ
    value: 10000,                     // リード 1 件の想定価値（任意）
    currency: 'JPY',
});

ポイント value にリード 1 件あたりの想定価値（例：過去の受注率 × 平均受注金額）を入れておくと、BtoB サイトでも「サイトが生み出した価値」を金額で比較できるようになります。

BtoB サイトの設計例

ここからは、具体的なサイトを想定して計測設計をしてみましょう。まずは、業務用ソフトウェアを販売する BtoB 企業のサイトです。

サイトの概要

• 目的：中堅企業の情報システム部門に資料請求や問い合わせをしてもらい、商談を増やす
• KGI：サイト経由の商談数
• 主な KPI：資料請求数、問い合わせ数、無料トライアル申し込み数
• 主なページ：トップ、製品紹介、料金、導入事例、ブログ、資料ダウンロード、問い合わせ

イベント設計

設計のポイント

• フォームの種類は form_name で区別する：資料請求と問い合わせを別のイベント名にせず、同じ generate_lead で計測する。キーイベントの合計で「リードの総数」が、form_name 別で内訳がわかる
• コンテンツ グループを設定する：ページを「製品」「事例」「ブログ」などに分類しておくと、「事例を読んだ人の問い合わせ率」などの分析がしやすい（第 4 部）
• 料金ページの行動を計測する：BtoB では、料金ページでどのプランに関心を持ったかが、商談の質を考えるヒントになる

メディアサイトの設計例

次に、子育て情報を発信するオウンドメディアの例です。

サイトの概要

• 目的：子育て中の保護者に記事を読んでもらい、ブランドの認知と会員登録を増やす
• KGI：会員登録数
• 主な KPI：記事の読了数、会員登録数、メルマガ登録数、回遊率（1 セッションあたりの記事閲覧数）
• 主なページ：トップ、記事、カテゴリ一覧、著者ページ、会員登録

イベント設計

設計のポイント

• 記事の属性を page_view のパラメータにする：カテゴリ・著者・公開日を送っておくと、「どのカテゴリがよく読まれるか」「公開から何日たった記事が読まれているか」が分析できる
• 「読了」を独自に定義する：拡張計測機能の scroll（90%）だけでは、本文の長さによって意味が変わる。記事本文の末尾の要素が表示されたときに article_read を送るなど、サイトに合った定義を作る（第 9 部）
• 回遊は既存の指標で見る：「1 セッションあたりの表示回数」は標準の指標で計算できるので、独自のイベントは不要

設計のレビュー観点

設計書ができたら、実装に進む前にレビューを行いましょう。次の観点で確認すると、よくある失敗を防げます。

チェックリスト

• 目的がある：すべてのイベントに、目的や関係する KPI が書かれている
• 推奨イベントを使っている：推奨イベントで表せる行動に、カスタム イベントを使っていない
• 命名がそろっている：イベント名・パラメータ名が小文字のスネークケースで統一されている
• イベント名に値を入れていない：ボタン名やページ名をイベント名に含めず、パラメータにしている
• 重複がない：拡張計測機能などと同じ行動を二重に計測していない
• 個人情報を含まない：パラメータの値に、氏名・メールアドレス・電話番号などが入る可能性がない
• カスタム定義の上限内に収まる：登録予定のカスタム ディメンションの数が上限を超えない
• 値の種類が多すぎない：ID やタイムスタンプなど、値の種類が膨大なものをカスタム ディメンションにしていない
• キーイベントが絞られている：事業の成果に直結するものだけがキーイベントになっている
• 確認方法が決まっている：実装後に、誰がどの方法で確認するかが決まっている

実装後の確認

実装が終わったら、次の手順で確認します。

1. DebugView で、設計どおりのイベント名とパラメータが送られているかを確認する
2. 想定外のタイミング（ページの再読み込み、戻るボタンなど）で、イベントが重複して送られないかを確認する
3. 翌日以降に、標準レポートや探索レポートで数値が表示されるかを確認する
4. 設計書の「状態」を「実装済み」に更新する

まとめ

• 計測設計は、カスタマー ジャーニーに沿ってユーザーの行動を洗い出すことから始める
• 「KPI に関係するか」「判断が変わるか」「自動で取れていないか」の 3 つの質問で、計測するかを判断する
• イベント設計書に、目的・イベント名・パラメータ・発生条件・キーイベント・確認方法などをまとめる
• 推奨イベントを優先し、違いはパラメータで表す
• 実装前にチェックリストでレビューし、実装後は DebugView とレポートで確認する

これで第 3 部は終わりです。理解度クイズ で確認してみましょう。次の第 4 部では、レポートに並ぶ指標とディメンションの意味を一つずつ理解し、数値を正しく読み解く力を身につけます。