BtoB SaaSのGA4イベント設計｜KGIから命名・検証まで

GA4のイベント設計では、名前を考える前に「どの意思決定に使うデータか」を決めます。設定できるイベントを増やしても、KGIとの関係、発火条件、担当者が曖昧なままでは、数字の意味を説明できません。

この記事では、BtoB SaaSで使うイベントをKGIから逆算し、推奨イベントとカスタムイベントを選び、設計台帳へ残して検証するまでを順番に整理します。BigQueryへの連携条件や費用は、GA4 + BigQuery連携の記事で扱っています。

結論：KGIからイベント台帳へ落とす

最初に決める順番は、KGI、ユーザー行動、イベント名です。商談や受注に近い行動から設計し、ページ閲覧やスクロールのような補助指標は、その後に追加します。

推奨イベントに適切な名前がある場合は、その名前と規定パラメータを優先します。該当しない行動だけカスタムイベントにします。この方針なら、標準レポートや今後の連携へつなぎやすく、独自イベントの増殖も抑えられます。

設計前に決める3項目

イベント名を検討する会議の前に、次の3項目を合意します。

「問い合わせボタンのクリック」と「問い合わせ完了」は別の行動です。フォーム完了が成果なら、クリックだけを完了イベントとして扱うとフォーム離脱を含んだ数字になります。実装方法より先に、何を完了とみなすかを決めます。

GA4イベント4分類の使い分け

GA4のイベントには4つの分類があります。すでに取得できている行動を確認してから、追加実装の要否を判断します。

分類	例	実装時の判断
自動収集イベント	first_visit、session_start	Googleタグの設置後に自動収集される
拡張計測イベント	scroll、file_download、サイト内検索	データストリームの設定とサイトの挙動を確認する
推奨イベント	generate_lead、sign_up	公式のイベント名と規定パラメータを確認して実装する
カスタムイベント	独自の業務行動	上の3分類で表現できない場合に作る

拡張計測をすべて有効にすること自体を目的にしません。たとえば自動取得のファイルダウンロードが、自社で「資料請求」と定義している行動と一致するとは限りません。発火条件を実際のサイトで確認します。

BtoB SaaSで使う推奨イベント

GA4には、リード獲得から成約までを表す推奨イベントがあります。「推奨イベントはEC中心なのでBtoBでは使いにくい」と決めつけず、まず公式のリード獲得イベントに対応できるかを確認します。

ファネル上の状態	推奨イベント	発火場所の例
問い合わせ・資料請求が完了した	generate_lead	フォーム送信成功時
有望なリードと判定した	qualify_lead	CRMでの判定時
営業が対応を開始した	working_lead	CRMのステージ変更時
顧客へ転換した	close_convert_lead	契約・受注の確定時

サイト上で取得できるのは、フォーム送信などのオンライン行動が中心です。商談化や受注をGA4へ戻す場合は、CRMとの接続、Measurement Protocol、データインポートなどを含めた別の設計が必要です。ブラウザのGTMタグだけでCRM上の状態まで取れるとは考えません。

generate_leadでvalueを送る場合は、currencyもセットで設計します。リード獲得用のイベント名やパラメータは変更される可能性があるため、実装時点の公式リファレンスを確認してください。

推奨イベントとカスタムイベントの判断

判断基準は、標準化と業務固有性です。

推奨イベントを使うことは、独自パラメータを一切持てないという意味ではありません。レポートで独自パラメータを使う場合は、カスタムディメンションやカスタム指標の登録も検討します。必要な切り口だけを追加し、使わない属性を先回りして増やさないようにします。

イベント名は大文字と小文字が区別され、文字・数字・アンダースコアを使用し、文字から始める必要があります。予約名と予約プレフィックスも使えません。本サイトでは、仕様とは別に、読み間違いを減らす社内ルールとして英小文字のsnake_caseへ統一します。

イベント設計台帳を作る

設計台帳は、名前の一覧ではなく、計測目的と実装条件を引き継ぐための文書です。最低限、次の列を持たせます。

項目	記入例
事業目的	問い合わせ完了数を把握する
発火条件	フォームの送信成功コールバック
event_name	generate_lead
parameters	form_id、lead_type
キーイベント	対象
実装場所	GTMのGA4イベントタグ
担当者	マーケ担当／実装担当
検証状況	Preview、DebugView、本番確認済み
変更履歴	変更日、変更理由、新旧対応

パラメータの値にも定義を付けます。lead_typeへdocumentとdownloadが混在すれば、BigQuery側で名寄せが必要になります。値の候補を台帳に列挙し、自由入力を避けます。

メールアドレス、氏名、電話番号など、個人を識別できる情報をイベント名、URL、パラメータへ送信してはいけません。フォーム入力値をdataLayerへ渡す実装では、送信項目を特に確認します。

GTMからBigQueryまで検証する

設定完了の判定を「GTMを公開した」にしません。次の順序で、発火、受信、集計を確認します。

同じ送信完了で2回発火する、SPAの画面遷移で発火しない、任意項目がundefinedになるといった問題は、集計後では原因を追いにくくなります。公開前に正常系と異常系を試し、検証したURL、操作、日時を台帳へ残します。

キーイベントに指定するのは、事業上の成果として継続評価するイベントです。すべてのクリックをキーイベントにすると成果の優先順位が見えなくなるため、問い合わせ完了などKGIに近い行動から設定します。

命名変更を運用する

イベント名を後から変えても、過去のデータは新しい名前へ書き換わりません。変更が必要な場合は、既存イベントを急に置き換えず、影響先を確認します。

追加・変更の申請者と承認者を決めておくと、似た名前のイベントがチームごとに作られることを防げます。小規模な体制でも、実装者以外が台帳を一度確認する運用を置きます。

よくある質問

Q. イベント名は日本語でも設定できますか。

日本語の文字も使用できます。ただし、外部ツールやSQLで扱うことを考え、このサイトでは英小文字とアンダースコアへ統一する運用を採用します。これはGA4の必須仕様ではなく、管理上のルールです。

Q. 問い合わせ完了はカスタムイベントにするべきですか。

公式定義と合う場合は、まずgenerate_leadを検討します。フォームの種類はform_idなどのパラメータで分けます。独立した業務行動で推奨イベントに合わない場合に、カスタムイベントを検討します。

Q. ボタンクリックをキーイベントにしてもよいですか。

クリック自体が事業上の成果なら対象になります。フォーム完了が成果の場合は、クリックではなく送信成功を計測します。両方必要なら、クリックは途中行動、完了は成果として役割を分けます。

Q. イベントを実装した日にBigQueryで確認できますか。

Daily exportだけの場合は日次テーブルの生成を待ちます。Streaming exportを有効にしている場合は当日のevents_intraday_YYYYMMDDを確認できます。連携方式はGA4 + BigQuery連携の記事を参照してください。

※上記リンクはA8.netを通じたアフィリエイトリンクです。読者の支払額は変わりません。

公式情報