計測設計の作り方｜目的・KPI・イベント定義をつなぐ

実画面で「設計」と「受信確認」をつなぐ

この記事は、2026年10月5日に指定のGA4プロパティをChromeで閲覧・撮影した実画面を使います。サイト名・URL・ID・アカウント表示が入る上部を撮影範囲から外しています。画面内の項目やデータは生成・描き換えをしていません。各画像はクリックして拡大できます。

以下の問い合わせの設計表は架空例です。実画面にその例が実装済みであることを示すものではありません。今回はイベント一覧・カスタム定義・DebugViewの閲覧のみを行い、イベント作成、キーイベント変更、パラメータ登録、タグ公開、問い合わせ送信は行っていません。

設定の前に「何を決めるか」を決める

計測設計は、タグを増やすための一覧ではありません。事業の目的を、観測できる行動と判断の基準へ落とす作業です。ここでは架空の法人向けサービスサイトを例に、「問い合わせ数を増やしながら商談につながる割合を確かめる」ための設計書を作ります。

必要な資料は、事業目標、サイトのページ一覧、フォームの成功・失敗条件、既存タグ一覧、データ利用の社内ルールです。サイトを設定する権限は設計だけなら不要ですが、実装・公開する担当者を決めておきます。

1．目的とKPIを分けて書く

まず目的を1行にし、月次の判断に使うKPIを絞ります。アクセス数の増加だけを事業成果と呼ばないことが要点です。

「CVR」のような略語だけでは不十分です。問い合わせイベント回数÷セッション数と、問い合わせがあったセッション数÷全セッション数は別の率です。分子・分母・対象期間を式で残します。

実画面①：事業上の成果とキーイベントを照合する

1. GA4上部で対象のプロパティを選びます。撮影画像ではこの部分を除外しています。
2. 左下の「管理」→「データの表示」→「イベント」を開きます。
3. 「キーイベント」タブを選び、イベント名と左側のスターを確認します。変更操作はせず、設計書の「キーイベントの要否」と照合します。
4. 右側の「過去28日間にアクティブだったストリーム」も確認し、設定の有無と受信状況を別々に記録します。

撮影時はclose_convert_lead、purchase、qualify_leadの3行があり、いずれも「ストリーム データが検出されませんでした」と表示されていました。これらが表示されることは、自社の商談や購入が計測された証拠ではありません。下のgenerate_leadは設計例で、この画面で受信を確認したイベントではありません。

設計書の確認欄には、たとえば「キーイベント一覧は確認済み／受付成功イベントの実装・受信は未確認」のように分けて記入します。既存のイベント名を意味の確認なしに成果へ流用しないでください。

2．成果の発生条件を決める

問い合わせでは送信ボタンを押した瞬間と、サーバーが受付を完了した瞬間を区別します。入力エラーや通信失敗でもクリックは発生します。事業上の成果を受付成功と定義したら、実装担当者に成功を判定できる箇所を確認します。

イベント名：generate_lead
目的：問い合わせの受付成功を把握する
発火条件：サーバー側の成功応答を受けたとき
発火しない条件：入力エラー、通信失敗、単なるボタンクリック
重複方針：同じ受付成功について1回。再描画で再送しない
追加項目：form_type（contact / demo の固定値）
送らないもの：氏名、メール、電話番号、自由記述、受付番号
担当・確認日・対象環境：実際の担当者が記入

これは設計例で、サイトの実装状況を保証するものではありません。自動収集されるフォームイベントを使う場合も、実際に受付成功を意味するか確認します。自動計測と独自計測の両方を同じ成果として足しません。

3．イベントとパラメータを決める

イベントの定義では、自動収集・拡張計測・推奨・独自の順に既存の意味を確認します。同じ意味に別名を付けるより、同じイベント名と固定したパラメータ値で比較できる状態を優先します。

設計書にはイベント名、意味、送信元、条件、パラメータ、キーイベントの要否、確認方法を並べます。設計・確認テンプレートを保存して埋めてください。

実画面②：追加項目の確認先は「カスタム定義」

1. 「管理」→「データの表示」→「カスタム定義」を開きます。
2. 「カスタム ディメンション」タブで、ディメンション名・スコープ・ユーザープロパティ／パラメータを確認します。
3. 設計書に書いたform_typeをレポート等で利用したい場合は、対応する登録があるかを調べ、未登録なら実装担当者へ引き継ぎます。

この例では一覧が0件なので、form_typeが登録済みとは扱いません。ただし、カスタム定義の有無だけでパラメータが送信されているかは判定できません。送信・受信の確認はDebugView等で別に行います。

「カスタム ディメンションを作成」からの登録は、承認済みの設計と送信パラメータを確認してから行います。ここでは閲覧だけで止めています。登録手順はカスタムディメンションの記事へ進んでください。

4．成功・失敗・重複のテストを設計する

期待結果を実装前に書けば、「タグが動いたから完了」という判断を避けられます。ブラウザーの送信、GA4の受信、集計レポートへの反映はそれぞれ確認します。集計待ち時間は故障と区別します。

実画面③：DebugViewで受信を確認する準備

1. 「管理」→「データの表示」→「DebugView」を開きます。
2. 左上の「デバッグに使用するデバイス」を確認します。撮影時は0で、中央に「デバッグ イベントの待機中」と表示されていました。

この状態は、今回のテスト端末からイベントを確認できていない状態です。「成果0件」「実装ミス」と即断せず、次の順にテストを準備します。

3. 許可されたテスト環境・対象URLを決め、GTMの「プレビュー」またはTag Assistantで自分の端末のデバッグモードを有効にします。具体的な接続手順はGTM設定記事を参照してください。
4. 対象サイトでテスト操作を行い、GA4側で該当するデバイスを選択します。複数端末がある場合は別担当者の操作と混ぜません。
5. イベントが表示されたら選択してパラメータを開き、イベント名・form_type・操作時刻を設計書と照合します。
6. 上の表の正常送信・入力エラー・再描画をそれぞれ実施し、期待回数と実測回数を記録します。個人情報を含む実顧客の内容はテストに使いません。

ここで説明した3〜6はこれから実施するテスト手順で、今回の撮影では実施していません。イベントが見えない場合は、プロパティ・送信先・端末のデバッグ状態・同意状態を確認します。同意を回避して送信させる設定にはしません。成功例の画像を作るためにイベントを捏造することもありません。

5．AIには定義の抜けを点検させる

AIに渡す前提条件と合わせて、次のように依頼します。承認済みの定義だけを渡し、顧客情報は含めません。

次の計測設計をレビューしてください。未記入を補完しないでください。
目的、分子・分母、成功条件、失敗条件、重複方針、個人情報の混入、
テストの期待結果を点検し、矛盾と確認先を表にしてください。
推奨イベント名は公式資料へのリンクと照合してください。
タグの公開や既存設定の変更は実行せず、修正案を示してください。

AIがクリックを成果と提案した場合は、成功条件と照合して採否を決めます。AIの回答を設計の決定権者の承認の代わりにはしません。

完了条件と次の手順

目的から各イベントの必要性を説明でき、成功・失敗・重複の期待結果、担当者、確認日が埋まっていれば設計段階は完了です。数値目標が未合意なら「未合意」と明記します。次はGA4初期設定とGTMの実装手順へ進みます。

公式資料：GA4イベントの考え方、推奨イベント。設計表・判断例は編集上の提案です。

実画面の読み方に関する公式資料：DebugView、カスタムディメンション。

メディアサイトの計測設計へ進む

記事の改善を目的にする場合はメディアサイト版の計測設計へ進んでください。H2到達イベントの実装・本番受信を確認した例と、計測コード、設計票を掲載しています。本記事の画面はその設定前の撮影記録です。

記事メディア全体の成果・KPI・前提条件・テスト環境と社内アクセスの扱いは、メディアのCV・KPI設計ガイドでまとめて確認できます。

AI支援で制作。公式資料の確認日：2026年10月5日。次回確認予定：2027年1月5日。本記事はGA4の実画面を閲覧・撮影しました。設定変更・タグ公開・発火／受信テスト、実務者監修、第三者再現は未実施です。掲載の記入例・数値例は架空の教材であり、実績ではありません。