GA4で施策を測る前に：AIで計測項目の案を出し、目的から逆算して絞る

先にGA4のイベントの種類を押さえる

AIに案を出させる前に、GA4側の分類を知っておくと、案の整理がしやすくなります。GA4のヘルプでは、自動収集イベント、拡張計測イベント、推奨イベント、カスタムイベントに分けて説明されています。自動収集には、設定時に既定で収集されるものと、拡張計測機能を有効にしたときに収集されるものがあります（イベントについて - アナリティクス ヘルプ）。

公式ヘルプでは、推奨イベントは事前に定義された名前とパラメータを持ち、カスタムイベントは他のイベントが用途に合わない場合に定義するものと説明されています。カスタムイベントは多くの標準レポートには表示されないため、分析にはカスタムレポートや探索が必要です（イベントについて - アナリティクス ヘルプ）。推奨イベントには login、sign_up などがあります（推奨イベント - Google Analytics）。

編集上の方針としては、次の順で検討するのがおすすめです。

1. 自動で取れているもので足りるか
2. 公式の推奨イベントに当てはまるものがないか
3. どちらにもなければカスタムイベント

推奨イベントの一覧には、たとえば search（必須の search_term パラメータ）や select_content（content_type、content_id）があります（推奨イベント - Google Analytics）。AIにはこの優先順位も伝えておきます。

計測設計シートの雛形

次の列を持つ表を、スプレッドシートに作ります。1行が「1つの問い」です。

• ID、書く内容：Q1、Q2…
• 問い、書く内容：判断したいこと（「〜かどうか」「どれが〜か」の形）
• 判断で変わる行動、書く内容：答えが出たら何をするか
• 指標、書く内容：見る数字（件数、率、記事別の件数など）
• イベント名、書く内容：小文字とアンダースコアで統一
• 種別、書く内容：自動／推奨／カスタム
• パラメータ、書く内容：イベントに付ける補足情報
• 発火条件、書く内容：どの操作で送るか（画面名・ボタン名で書く）
• レポート用の設定、書く内容：キーイベントにするか、カスタムディメンションに登録するか
• 確認方法、書く内容：リアルタイム／DebugViewでの確認手順
• 採否、書く内容：採用／保留／不採用と理由

「判断で変わる行動」が空欄の行は、採用しません。これが逆算の核になります。

説明用の例

架空のオンライン料理教室の「体験申込」を増やしたい担当者が、問いを先に3つ書いた状態です。

• Q1、問い：申込につながる記事はどれか、判断で変わる行動：記事の改修・広告の配分を決める、指標：記事別の申込完了数、イベント名：trial_apply_complete、種別：カスタム、パラメータ：entry_article（入口の記事名）、発火条件：申込完了画面の表示時
• Q2、問い：申込フォームのどこで止まるか、判断で変わる行動：入力項目を減らすか決める、指標：開始数に対する完了数、エラー項目別の件数、イベント名：trial_form_start、trial_form_error、種別：カスタム、パラメータ：error_field（項目名のみ）、発火条件：最初の入力時／入力エラー表示時
• Q3、問い：サイト内検索で探されている語は何か、判断で変わる行動：新しい記事の題材を決める、指標：検索語別の件数、イベント名：search、種別：推奨、パラメータ：search_term、発火条件：検索結果の表示時

Q2の error_field には項目名（「電話番号」など）だけを入れ、入力された値は送りません。

AIに任せる依頼文

AIに渡すのは、問い・サイトの構成・使えるイベントの考え方です。顧客の個人情報や実際のログは貼らず、説明用データに置き換えてください。

あなたはGA4の計測設計を手伝うアシスタントです。
以下の「問い」ごとに、計測項目の案を表で出してください。

# 前提
- サイト：（例）オンライン料理教室の紹介サイト。記事、料金ページ、体験申込フォーム
- 目的：（例）体験申込数を増やす
- 使うツール：GA4、Googleタグマネージャー

# 問い（人が決めたもの）
Q1：申込につながる記事はどれか
Q2：申込フォームのどこで止まるか

# ルール
- 自動収集・推奨イベントで足りるものは、それを優先する
- カスタムイベント名は小文字とアンダースコア、動詞を後ろに置く
- 氏名・メールアドレス・電話番号など個人を特定できる値は、パラメータに入れない
- 各行に「この数字が出たら何を変えるか」を書く
- 問いに関係しない項目は出さない。迷ったら「保留」にして理由を書く

# 出力列
ID／指標／イベント名／種別／パラメータ／発火条件／判断で変わる行動

AIの出力は、そのままシートに貼らず、「案」として受け取ります。AIは実際のサイトの画面やタグの設定を見ていないため、発火条件は推測を含みます。

判断表で候補を絞る

AIの案が増えたら、上から順に次の質問を当てます。

• 結果が出たら、変える行動を一文で言えるか、はい：次へ、いいえ：不採用
• 自動収集・推奨イベントで代用できないか、はい：代用できるなら、そちらを採用、いいえ：次へ
• 同じ問いに答える別の項目と重複していないか、はい：重複なら1つに統合、いいえ：次へ
• 個人を特定できる値を送ることにならないか、はい：値を外すか不採用、いいえ：次へ
• 実装担当者が発火条件を画面で特定できるか、はい：採用、いいえ：保留（条件を詰める）

数の目安は、1つの問いにつきイベント1〜3個です。これは編集上の目安で、GA4の仕様ではありません。

人が確認すること

実装前と実装後で、確認する内容が異なります。

実装前

• 問いと「変える行動」が、関係者の間で合意されているか
• イベント名が、既存のものと表記ゆれ（apply_complete と applyComplete など）を起こさないか
• パラメータに個人情報が混ざらないか

実装後

• 開発者向けドキュメントでは、送信したイベントを「リアルタイム」と「DebugView」で確認できるとされています（Send events）。発火条件の行ごとに、実際に操作して届くかを見ます。
• RealtimeとDebugViewでイベントを確認できます。DebugViewではデバッグモードを有効にする必要があります（イベントについて - アナリティクス ヘルプ）。
• 申込完了のように事業の成功に特に重要な行動を測るイベントは、キーイベントとしてマークできます。キーイベントにするかを決めます（イベントについて - アナリティクス ヘルプ）。

シートの「採否」列は、確認後に更新します。ここまでで、問いからイベントまでが1枚で追えます。AIの出力に頼る場面は候補出しと表の整形で、採否の判断と実機での確認は人の仕事です。