BtoB SaaS のマーケで GA4 のイベント設計に着手すると、最初に手が止まるのは設定方法ではありません。推奨イベントの一覧を前に、どれを取り、どう名前を付け、何を独自イベントにするか、という判断のほうで詰まります。実装手順はいくらでも出てきますが、判断軸を書いた記事は意外と見つかりません。
結論から書きます。GA4 のイベント設計は、KGI から逆算して命名規則を先に固め、Recommended Event と Custom Event の使い分けを判断軸として持ち、さらに BigQuery export を見据えて設計を整えることで、後段の運用が崩れにくくなります。設定の前に、この三つを決め切る工程が本題です。
この記事は、ある BtoB SaaS 企業で GA4 / BigQuery / Looker Studio を内製で回してきた立場から書きます（BtoB SaaSマーケ業務委託の経験）。計測基盤の全体設計は HUB 記事（計測基盤の全体設計）に譲り、本記事はその中のイベント単位の設計に絞ります。
私自身、ある BtoB SaaS の事業会社マーケでイベント設計を内製した時、最初に詰まったのは設定ではありませんでした。何を測るかの合意（KGI）、命名規則の社内浸透、Recommended Event の取捨選択、この三つです。設計を先に固めてから実装に入り、Looker Studio 接続まで通した順序が、結果的に手戻りを抑えたと感じています。
※本記事には、A8.net を通じたアフィリエイトリンクが含まれます。読者の支払額は変わりません。
GA4イベント設計は「KGIから逆算」で最初に詰める
GA4 のイベント設計でつまずく原因は、設定方法の難しさではありません。何を測るかを決めないまま実装に入り、後から「この数字は何の意思決定に使うのか」が抜けていたと気づく、という順序で崩れます。設計の起点は、ツールの操作ではなく KGI です。
BtoB SaaS の KGI は商談化と受注に集約されることが多く、まずこれを一つに絞ります。KGI が定まると、event_name に付ける優先順位が決まります。商談化に近いイベントから順に設計し、汎用的なクリックやスクロールは後回しにする、という順番が見えてきます。
本記事のスコープは、その命名規則の作り方、Custom / Recommended の判断、そして BigQuery export を見据えた整合の三つです。計測基盤をいつ・どう作るかという上流の議論は HUB 記事に譲り、ここではその中の「イベントをどう設計し命名するか」に絞って踏み込みます。基盤の設計とイベント単位の設計を切り分けておくと、議論が混線しません。
GA4イベントの4分類と、事業会社マーケがつまずく前提
GA4 のイベントは、自動収集イベント、拡張計測イベント、推奨イベント（Recommended Event）、カスタムイベント（Custom Event）の4種類に分かれます。網羅的な解説は公式ドキュメントや既存の網羅ガイドが充実しているので、ここでは各分類で事業会社マーケが判断を迫られる点に絞ります。
自動収集イベントは設定なしで取れますが、page_view や session_start をそのまま KGI 計測に流用できるわけではありません。拡張計測イベント（スクロール、サイト内検索など）は管理画面のトグルで一括オンにできるものの、全部オンにするか必要なものだけ残すかが最初の分岐です。不要なイベントを流したまま BigQuery export に乗せると、後段でノイズの除外作業が増えます。
推奨イベントは Google が名前とパラメータを定義したもので、命名の自由度が低い代わりに、Google 広告のキーイベント連携や将来のレポート機能との整合が取りやすい性質があります。カスタムイベントは自由に設計できる反面、命名規則を自前で統制しないとすぐに名前が分裂します。事業会社マーケがつまずくのは、この「自由度と標準化のどちらを取るか」の線引きです。
event_name の技術仕様（snake_case 推奨、予約プレフィックスや予約イベント名の制約など）は Google 公式のドキュメントに詳しいので、本記事では立ち入りません。押さえたいのは、4分類それぞれに事業会社マーケの判断ポイントが埋まっている、という前提です。次章からその判断軸を順に開きます。
Custom EventかRecommended Eventか — BtoB SaaSの判断フレーム
Custom と Recommended の使い分けは、一般には「推奨イベントを優先し、カバーできない場合だけカスタムを作る」というルールで語られます。これは原則として妥当で、私も出発点はここで良いと考えています。ただ、BtoB SaaS の計測でこのルールだけを当てると、判断が足りなくなる場面があります。
理由は、BtoB SaaS の KGI が商談化・受注という「サイトの外側」にあるためです。資料DLや無料トライアル申込といった中間ゴールは、推奨イベントの定義（EC 寄りのものが多い）と噛み合わないことがあります。推奨に無理に寄せると、後で必要な独自パラメータが持てず表現力が足りなくなる、という詰まり方をします。
そこで、推奨かカスタムかを単純な優先順位ではなく判断軸の組み合わせで考えます。業務委託経験の一例として、私が使っている判断軸を表に整理します（2026年6月時点）。
| 判断軸 | Recommended を選ぶ場面 | Custom を選ぶ場面 |
|---|---|---|
| 標準化のしやすさ | 社内外で定義を揃えたい | 独自の業務定義を反映したい |
| Google 広告・キーイベント連携 | 広告最適化に直結させたい | 連携要件が薄い |
| 表現力（独自パラメータ） | 標準パラメータで足りる | 独自の属性を多く持たせたい |
| BigQuery 展開のしやすさ | 定義済み構造で十分 | 自前で命名規則を統制できる |
| 命名の自由度 | 自由度は不要 | KGI 文脈に合わせ命名したい |
判断の本質は「標準化（Recommended）」と「表現力（Custom）」のトレードオフです。どちらが優れているかではなく、そのイベントで標準化を取りたいのか独自の表現力を取りたいのかという条件で選びます。広告連携に直結する商談化イベントは推奨寄りに、社内の業務定義を色濃く反映したいイベントはカスタム寄りに、と分けると整理しやすくなります。
マーケ実務目線でのコメント：推奨イベントに寄せすぎて後から表現力不足に陥った経験も、カスタムを増やしすぎて運用が割れた経験も、どちらもあります。前者は「広告連携は楽だが分析で欲しい切り口が取れない」、後者は「命名がチームでバラけてレポートが突合できない」という形で表面化します。どちらに振るかは、そのイベントを後で何の意思決定に使うかから逆算するのが、現場感覚として安定すると感じています。
私自身、ある BtoB SaaS の業務委託で、問い合わせと資料DLは独自パラメータを持たせたいという理由でカスタムに寄せ、購入・登録系は広告連携を優先して推奨イベントに合わせる、という線引きをしました。業務委託経験の一例として、2026年6月時点の判断ですが、標準化と表現力のどちらを取るかをイベントごとに決めておくと、後段の運用で迷いが減ったと感じています。
KGIから逆算するイベント命名規則の実体験
ここが本記事の中心です。命名規則は、event_name を思いつきで付けないために、KGI から機械的に降ろせる形にしておくのが要点だと考えています。手順は、KGI（商談化・受注）を頂点に置き、その手前の中間ゴール（資料DL、無料トライアル申込、問い合わせ）を並べ、それぞれに対応する event_name を規則的に割り当てる、という逆算です。
言葉だけだと伝わりにくいので、業務委託経験の一例として、実際に近い形の命名サンプルを示します（2026年6月時点の整理で、事業によって調整が要ります）。
| 中間ゴール | event_name 規則 | parameter 例 |
|---|---|---|
| 資料DL | generate_lead / lead_download | content_id, content_type |
| 無料トライアル申込 | sign_up / trial_start | plan_type, method |
| 問い合わせ | contact / inquiry_submit | inquiry_type, form_id |
| 商談化（CRM側で確定） | qualified_lead | source, deal_stage |
命名で最も避けたいのは、運用が始まってから規則を変えることです。event_name を途中で変えると、過去データとの連続性が切れ、時系列の分析が分断されます。だからこそ、命名は最初に時間をかけて固める工程であり、後から微修正する前提で雑に走り出すと、後でかなり痛みます。
この命名規則の感覚は、ある BtoB SaaS の事業会社マーケを業務委託で担ってきた中で固まったものです（事業会社マーケとしての実務背景）。
マーケ実務目線でのコメント：命名が個人技になっていると、担当が変わった瞬間に規則が途切れます。私は、命名案を一人で決めずに、KGI と中間ゴールの対応表をたたき台にして社内レビューで揃える形を取るようにしています。レビューを一度挟むだけで、「この event_name は何を指すのか」という後日の問い合わせがかなり減る、と現場感覚として感じています。
私自身、ある BtoB SaaS 企業の業務委託で event_name の命名規則を社内ドキュメント化した時、まず KGI（商談化・受注）から中間ゴールへの対応表を作り、資料DLと無料トライアルを別の event_name に切り分けるところから始めました。命名の根拠（なぜこの名前か）を一列添えておくと、レビューでの合意が早まります。業務委託経験の一例として、2026年6月時点の進め方ですが、命名規則を文書とレビュー運用に乗せた効果は運用が長くなるほど効いてくる、と感じています。
命名規則を社内ドキュメント化してレビュー運用に乗せる
命名規則は、作った時点で終わりにせず、運用に乗せて初めて機能します。具体的には、規則を社内のドキュメントツールに置き、誰が見ても同じ命名にたどり着ける状態を保つことです。置き場所が個人のメモやチャットの履歴だと、半年後には参照されなくなります。
ドキュメントに最低限載せたいのは、event_name の一覧、各イベントの定義（何が起きた時に発火するか）、parameter の意味、そして命名の根拠です。新しいイベントを追加する場面は運用上で定期的に発生するので、追加時にこのドキュメントへ反映するフローを最初に決めておくと、規則の分裂を防げます。
1〜数人のマーケ体制では、設計者と運用者が同じ人になりやすく、自分の頭の中だけで命名が完結してしまう構造があります。これが属人化の温床です。歯止めとして、イベント追加の際に最低一人のレビューを通す、というルールを軽く敷くだけでも、命名のブレが抑えられると感じています。
マーケ実務目線でのコメント：一度バラけた命名を後から統一し直すコストは、最初にレビュー運用を敷くコストより大きい、というのが実感です。私自身、命名が分裂した状態から揃え直す作業を経験しましたが、過去データの読み替えと関係者への説明で、想定よりかなり時間を取られました。最初の小さな手間を惜しまないほうが、結局は軽く済むと感じています。
BigQuery exportを見据えたイベント設計の整合
イベント設計は、BigQuery export を見据えるかどうかで後段の SQL の書きやすさが変わります。エクスポートされたデータは event パラメータがネストした構造で入り、分析時に unnest して展開します。命名が規則的だとカラム展開や unnest の処理をパターン化でき、不規則だと SQL 側で例外処理が増え、集計のたびに名寄せが必要になります。
もう一つ効くのが、userProperty と event parameter のスコープ選択です。user に置くか event に置くかで、後段の SQL でどの粒度まで集計できるかが決まります。ユーザー単位で長期に紐づけたい属性は user、その操作の文脈に紐づくものは event、と最初に切り分けておくと、BigQuery での分析の自由度が確保しやすくなります。
テーブル設計やパーティション選定といった基盤側の話は HUB 記事（GA4とBigQueryの連携設計）に譲りますが、その手前の「命名とスコープが BigQuery でどう効くか」までは、イベント設計の段階で意識しておくと、後の手戻りが減りやすくなります。
マーケ実務目線でのコメント：私は、parameter に表記揺れのある値を入れてしまい、BigQuery 側で CASE 文の分岐が膨らんだ経験があります。設計段階で「これは後で SQL でどう書くか」を一度想像しておくと、こうした手戻りは減らせると感じています。
私自身、ある BtoB SaaS の業務委託で BigQuery export 前提の設計を詰めた時、プラン区分を event と user のどちらのスコープに持たせるかで一度迷いました。後段の集計粒度が変わるためです。業務委託経験の一例として、2026年6月時点の判断ですが、「その属性をユーザー単位で追いたいか」を基準にすると整理しやすく、基盤全体は HUB 記事に接続して考えると見通しが良くなりました。
計測スタックでの位置づけ — GA4の定量とClarityの定性
GA4 のイベント設計は、計測スタック全体の一部として位置づけると、役割がはっきりします。GA4 と BigQuery で「何がどれだけ起きたか」という定量を押さえ、定性のデータでその背景を補う、という構成です。
定性側の代表的な選択肢が Microsoft Clarity です。GA4 のイベントで「資料DLが落ちた」という事実をつかみ、Clarity のヒートマップやセッション録画で「なぜ落ちたか」を補う、という補完関係になります。両者は競合ではなく、片方では拾えない論点をもう片方が拾う形です（Clarity と GA4 の補完関係）。
最初に仕込むイベントをどこから設計し始めるかは、サイトや LP の公開タイミングと結びつきます。LP 公開直後にどの計測を入れるかという話と、本記事のイベント設計は地続きです（LP公開後30日でやる計測設定）。公開後に慌てて計測を足すより、設計の段階で最初のイベント群を決めておくほうが、後の精度が安定します。
なお、設計したイベントを BigQuery 経由で可視化する段では、Looker Studio でのダッシュボード作成が次の論点になります（こちらは別記事で扱う予定です）。
GA4イベント設計でよくある疑問（FAQ）
Q. event_name は日本語でも設定できますか。
技術的に通る場面もありますが、snake_case の英小文字で揃えるのが現実的です。BigQuery export 後の SQL での扱いやすさや、将来のレポート機能・外部ツール連携との整合を考えると、英小文字の命名規則に寄せておくほうが後段で困りません。
Q. Recommended Event とカスタムイベント、どちらを優先すべきですか。
出発点は「推奨でカバーできるなら推奨、足りなければカスタム」で良いと考えています。ただし BtoB SaaS では、KGI が推奨イベントの定義と噛み合わない場面があるため、独自パラメータが要るイベントはカスタムに寄せる判断軸を併せ持つのが現実的です。
Q. パラメータはどこまで設計時に決めておくべきですか。
KGI と中間ゴールに直結するパラメータは設計時に決め切り、あれば便利という程度のものは後から足せる余地を残します。最初から盛り込みすぎると、使われないパラメータが BigQuery 側のノイズになります。
Q. BigQuery export を前提にすると、命名で気をつけることはありますか。
event_name と parameter を規則的に揃え、表記揺れを作らないことです。unnest やカラム展開の処理がパターン化でき、SQL での例外処理が減ります。スコープ（event / user）の選択も集計粒度を左右するため設計時に決めておきます。
Q. 命名規則を後から変えるとどうなりますか。
event_name を変えると過去データとの連続性が切れ、時系列分析が分断されます。どうしても変える場合は変更日と新旧の対応を残すのが現実的です。だからこそ最初に時間をかけて固めておく価値があります。
まとめ — BtoB SaaSがGA4イベント設計で最初に踏む順序
本記事の論点を、最初に踏む順序として束ねます。GA4 のイベント設計は、設定方法より「何を測るかを決め、どう名付けるか」で成否が分かれる、という主張に戻ります。
- KGI 合意：商談化・受注のどちらを頂点に置くかを一つに絞る
- 命名規則：中間ゴール（資料DL・無料トライアル・問い合わせ）から event_name を規則的に降ろす
- Custom / Recommended の判断：標準化と表現力のトレードオフで、イベントごとに選ぶ
- BigQuery 整合：命名とスコープが unnest・集計にどう効くかを設計段階で見据える
- 運用ドキュメント化：命名規則を社内ドキュメントとレビュー運用に乗せ、属人化を避ける
この中で最も時間をかけるべきは、KGI 合意と命名規則の二つだと考えています。残りは手順としても進められますが、この二つを後回しにした分は、運用フェーズで後から効いてきます。計測基盤の全体設計とあわせて考えたい場合は、HUB 記事（計測基盤の全体設計）に接続してください。
私自身、ある BtoB SaaS でイベント設計を社内に浸透させた経験を振り返ると、命名規則を共通言語にできた後は、「この数字は何か」を毎回確認する手間が消え、運用工数が下がったと感じています。最初に戻れるなら、やはり最も時間をかけるのは KGI 合意と命名規則の二つだと考えています。
