GA4の推奨イベントとは？種類・設定方法・パラメータを徹底解説

GA4では、ページ表示、クリック、スクロール、問い合わせ、購入など、Webサイトやアプリで発生した行動をイベントとして記録します。ただし、すべてのイベントが同じ方法で取得されるわけではありません。GA4が自動的に取得するイベントもあれば、運営者が目的に合わせて設定するイベントもあります。

運営者が追加するイベントの中でも、Googleがあらかじめ名称と推奨パラメータを定めているものが「推奨イベント」です。問い合わせ完了を表すgenerate_lead、会員登録を表すsign_up、商品購入を表すpurchaseなどが代表例です。これらは自動では送信されないため、Googleタグ、Googleタグマネージャー、アプリ用開発機能などを使って実装する必要があります。

推奨イベントは、単にGoogleが名前を提案しているだけの仕組みではありません。指定された名称とパラメータを使用することで、既定のディメンションや指標、通販レポート、見込み顧客獲得レポート、推奨オーディエンス、将来追加される機能との互換性を高められます。本記事では、推奨イベントの種類、選び方、設定方法、パラメータ、確認方法、運用時の注意点を詳しく解説します。

1. 推奨イベントとは

推奨イベントは、GA4が自動的に収集しない重要な行動について、Googleが標準のイベント名とパラメータを用意している仕組みです。業種やサイトごとに実装する必要がありますが、独自名称を使うよりもGA4の機能を活用しやすくなります。

1.1 推奨イベントの定義

推奨イベントとは、Googleが名称と関連パラメータを事前に定義したGA4イベントです。問い合わせ、ログイン、会員登録、検索、コンテンツ共有、商品閲覧、カート追加、購入など、さまざまなWebサイトやアプリで共通して発生する行動が用意されています。

推奨イベントは、Googleタグを設置しただけでは自動送信されません。どの操作が発生した時点でイベントを送るかを決め、サイト、アプリ、Googleタグマネージャーなどへ実装する必要があります。

1.2 名称が事前に定義されている理由

問い合わせや購入のような一般的な行動に共通名称を使用すると、GA4はイベントの意味を認識しやすくなります。同じ問い合わせ完了を、サイトごとにcontact_complete、form_success、inquiry_finishなどと別々に定義するより、generate_leadへ統一したほうが分析環境を標準化できます。

Googleは、推奨イベントを指定されたパラメータとともに送信することで、レポートの詳細情報や将来追加される機能、連携機能を利用しやすくなると案内しています。したがって、同じ意味の推奨イベントが存在する場合は、独自イベントを作る前に推奨名称を検討します。

1.3 推奨イベントが自動送信されない理由

session_startやfirst_visitのようなイベントは、GA4の計測コードだけで発生条件を判断できます。一方、問い合わせが正常に完了した時点や、見込み顧客が有望と判定された時点は、各サイトや業務システムの仕組みによって異なります。

GA4側だけでは、その操作が単なるボタンクリックなのか、入力エラーなのか、正常な送信完了なのかを常に判定できません。そのため、推奨イベントはサイトやアプリの処理と連携し、意味のあるタイミングで運営者が送信する必要があります。

1.4 推奨イベントを利用する利点

推奨イベントを正しく実装すると、対応する既定ディメンションや指標へデータが反映されます。通販向けイベントは通販購入レポート、見込み顧客向けイベントは見込み顧客獲得レポートなど、目的に合った分析機能へつなげられます。

また、標準名称を使用することで、担当者が変わってもイベントの意味を判断しやすくなります。複数サイトや複数アプリを管理する場合も、イベント名を統一すれば横断的な比較や計測仕様の共有が容易になります。

1.5 推奨イベントが適しているサイト

推奨イベントは、通販サイトだけに使うものではありません。企業サイト、採用サイト、会員サイト、予約サイト、教育サービス、不動産サイト、旅行サイト、ゲームアプリなど、幅広い事業で利用できます。

問い合わせを受け付ける企業サイトではgenerate_lead、会員機能を持つサイトではloginとsign_up、サイト内検索を提供するサイトではsearchを利用できます。商品やサービスを販売する場合は、閲覧から購入までの通販向けイベントを段階的に設定します。

2. 推奨イベントが記録される仕組み

推奨イベントは、利用者の操作や業務処理をきっかけとして、イベント名とパラメータをGA4へ送信することで記録されます。送信側とGA4側の役割を区別すると、設定不良の原因を調べやすくなります。

2.1 利用者の操作から記録までの流れ

利用者がフォームを送信したり、商品を購入したりすると、Webサイトまたはアプリ側で処理が実行されます。その処理が成功した時点で、GoogleタグやGoogleタグマネージャーなどから推奨イベントをGA4へ送信します。

GA4は受信したイベントを処理し、リアルタイム、イベントレポート、探索、対応する業種別レポートなどへ反映します。実装直後の動作はデバッグ表示やリアルタイムで確認し、通常レポートへの反映には処理時間を考慮します。

2.2 イベント名の役割

イベント名は、どのような行動が発生したのかを示します。ログインならlogin、会員登録ならsign_up、問い合わせならgenerate_lead、購入ならpurchaseを使用します。

推奨イベントでは、文字を変更せず、公式に定義された名称をそのまま使用します。generate_leadをgenerateLeadやgenerate_leadsへ変更すると、推奨イベントではなく別の独自イベントとして扱われる可能性があります。

2.3 パラメータの役割

パラメータは、イベントだけでは分からない詳細情報を送信するために使用します。loginにmethodを付けると、メール、Googleアカウント、その他の方法など、どのログイン方式が利用されたかを区別できます。

イベントパラメータは、利用者の操作へ追加の文脈を与える情報です。Googleが推奨するパラメータを利用すると、既定のディメンションや指標へ反映されやすくなり、レポートやオーディエンスで詳細な分析を行えます。

2.4 GA4側で処理される情報

GA4では、イベント名とパラメータを受信した後、パラメータの一部を既定ディメンションや指標として利用できます。たとえば、購入金額、通貨、取引識別子、商品名などは通販レポートの生成に使用されます。

独自に追加したパラメータは、送信されただけで標準レポートの選択項目になるとは限りません。分析で継続利用する場合は、イベント単位の独自ディメンションまたは独自指標として登録します。

2.5 実装場所による違い

Webサイトでは、Googleタグのgtag()関数またはGoogleタグマネージャーから推奨イベントを送信できます。アプリでは、対応するアプリ用開発機能を利用します。

Googleタグマネージャーでは、イベント送信タグとトリガーを組み合わせます。直接実装では、送信成功処理や購入完了処理の中でgtag()を呼び出します。どちらを選ぶ場合も、同じイベントを両方から重複送信しないことが重要です。

3. すべての事業で利用できる推奨イベント

Googleは、特定業種だけでなく、多くのWebサイトやアプリで利用できる推奨イベントを定義しています。ログイン、検索、共有、会員登録など、一般的な利用行動が対象です。

3.1 loginとsign_up

loginは利用者がログインした時点、sign_upは新しいアカウントの登録を完了した時点で送信します。ログイン画面や登録画面を表示しただけではなく、認証や登録処理が正常に完了した時点が適切です。

どちらのイベントでも、利用方法を区別したい場合はmethodを利用できます。たとえば、email、google、appleなどの値を設定すると、登録方法やログイン方法ごとの利用状況を比較できます。loginのmethodは公式に定義されているパラメータです。

ログインイベントの例

gtag('event', 'login', {  method: 'email' });

会員登録イベントの例

gtag('event', 'sign_up', {  method: 'email' });

3.2 generate_leadとsearch

generate_leadは、利用者が問い合わせ、資料請求、見積もり依頼などの情報を送信し、見込み顧客として獲得された時点に利用します。送信ボタンをクリックしただけではなく、送信処理が成功したことを条件にします。

searchは、利用者がサイトまたはアプリで検索を実行した際に使用します。公式仕様ではsearch_termが必要パラメータとして定義されているため、実際に入力された検索語句を送信します。ただし、個人情報を含む検索語句が送られないように注意が必要です。

検索イベントの例

gtag('event', 'search', {  search_term: 'アクセス解析' });

3.3 select_contentとshare

select_contentは、利用者が特定のコンテンツを選択した際に使用します。記事、動画、診断、特集、商品以外の独自コンテンツなど、選択された対象の人気を分析できます。

shareは、利用者がコンテンツを共有した時点で送信します。共有方法をmethod、共有した種類をcontent_type、対象識別子をitem_idとして送信できます。SNSボタンを押しただけでなく、共有処理が実行された時点を基準にすることが理想です。

共有イベントの例

gtag('event', 'share', {  method: 'line',  content_type: 'article',  item_id: 'ARTICLE_102' });

3.4 join_groupとチュートリアルイベント

join_groupは、利用者がチーム、コミュニティ、家族グループ、オンラインサロンなどのグループへ参加した際に利用します。対象グループを区別する場合はgroup_idを送信できます。

初回利用案内や操作説明を提供するサービスでは、開始時にtutorial_begin、完了時にtutorial_completeを利用できます。登録後の利用開始率や、途中離脱が多い案内過程を把握する際に役立ちます。

3.5 purchase・refund・仮想通貨イベント

purchaseは購入完了、refundは返金処理を記録するイベントです。通販サイト以外でも、有料サービス、講座、予約商品、旅行商品など、金銭を伴う取引に利用できます。

ゲームや会員サービス内で仮想通貨を利用する場合は、獲得時にearn_virtual_currency、使用時にspend_virtual_currencyを送信できます。通貨名や値をパラメータとして指定し、仮想経済の利用状況を分析します。

4. 見込み顧客獲得向けの推奨イベント

見込み顧客獲得向けイベントは、問い合わせを受け付けた時点だけでなく、その後の営業対応、見込み判定、商談、受注、不成立までを計測するために用意されています。企業間取引、自動車、保険、不動産など、成果がオンラインだけで完結しない事業に適しています。

4.1 generate_lead

generate_leadは、オンラインフォームまたはオフライン経由で見込み顧客情報を取得した時点に使用します。問い合わせ、資料請求、無料相談、見積もり依頼、展示会での情報取得などが対象になります。

フォームの入力開始や送信ボタンのクリックではなく、有効な情報が正常に保存された時点で送信します。フォームが複数ある場合は、form_typeなどの追加パラメータを使用し、問い合わせ種別を区別できます。

設定例

gtag('event', 'generate_lead', {  currency: 'JPY',  value: 5000,  form_type: 'document_request' });

4.2 qualify_lead

qualify_leadは、獲得した見込み顧客が、営業対象として適切な条件を満たしていると判定された時点に使用します。問い合わせを受け付けた瞬間ではなく、内容、予算、導入時期、対象地域などを確認した後の判定です。

営業支援システムや顧客管理システムで見込み状態が変更された際に、サーバー連携などで送信する方法が考えられます。単なる問い合わせ件数だけでなく、質の高い見込み顧客を生み出した流入元や広告を評価できます。

4.3 disqualify_lead

disqualify_leadは、見込み顧客が営業対象の条件に合わないと判定された時点に使用します。対象外地域、予算不足、重複問い合わせ、営業目的の連絡など、不適格と判断した理由も送信できます。

公式仕様では、不適格理由を示すdisqualified_lead_reasonが用意されています。理由を統一した値で送信すると、広告経路や入力フォームごとに、質の低い問い合わせが多い原因を分析できます。

4.4 working_lead

working_leadは、担当者が見込み顧客へ連絡した、または見込み顧客から担当者へ連絡があり、営業対応が開始された時点に使用します。

問い合わせを受け付けただけで終わっている案件と、実際に担当者が対応した案件を分けられる点が特徴です。初回対応までの時間や、営業対応へ進みやすい獲得経路を分析するための基礎データになります。

4.5 close_convert_leadとclose_unconvert_lead

close_convert_leadは、見込み顧客が最終的に顧客へ転換した時点で送信します。契約、受注、入会、成約など、事業上の最終成果に合わせて条件を定義します。

close_unconvert_leadは、商談が終了したものの顧客へ転換しなかった時点に使用します。不成立理由を送信すると、価格、時期、競合、連絡不能などの原因別に分析できます。両方を利用することで、問い合わせ数だけでなく営業過程全体を評価できます。

5. 商品発見段階の通販向け推奨イベント

通販向け推奨イベントは、商品一覧、商品選択、詳細閲覧、販促表示、お気に入り登録など、利用者が商品を発見して検討する過程を記録します。商品購入だけでなく、購入前の行動を設定することで離脱箇所を判断できます。

5.1 view_item_list

view_item_listは、商品一覧やサービス一覧が利用者に表示された際に使用します。カテゴリーページ、検索結果、関連商品、人気商品、新着商品などが対象です。

一覧を識別するためにitem_list_idやitem_list_nameを利用し、商品情報をitems配列で送信します。どの一覧が商品詳細への移動や購入につながったかを分析できます。

5.2 select_item

select_itemは、利用者が商品一覧から一つの商品やサービスを選択した際に送信します。商品画像、商品名、詳細ボタンなど、商品詳細へ進む操作が対象です。

公式仕様ではitems配列が必要で、選択した商品を含めます。商品一覧内の位置をindexとして送信すると、上位表示された商品と下位表示された商品の選択率を比較できます。

5.3 view_item

view_itemは、商品またはサービスの詳細が表示された際に送信します。物理商品だけでなく、講座、宿泊プラン、不動産物件、保険商品など、購入や申し込みの対象となる項目にも利用できます。

一覧表示と詳細表示を分けて記録することで、「一覧では表示されたが選択されなかった商品」と「詳細まで閲覧されたが購入されなかった商品」を区別できます。

5.4 view_promotionとselect_promotion

view_promotionは、サイト内の販促枠やキャンペーンが表示された時点で送信します。トップページの大型画像、割引企画、期間限定案内などが対象です。

select_promotionは、その販促枠が選択された時点に送信します。表示回数と選択回数を比較することで、掲載位置、画像、訴求内容ごとの反応を分析できます。両イベントは通販向け推奨イベントとして定義されています。

5.5 add_to_wishlist

add_to_wishlistは、利用者が商品をお気に入り、保存一覧、検討一覧などへ追加した際に送信します。

購入には至っていないものの、強い関心を示した商品を把握できます。お気に入り登録後の購入率や、登録数は多いものの購入率が低い商品を分析し、価格、在庫、説明内容の改善に活用します。

6. 購入手続き段階の通販向け推奨イベント

購入手続き段階では、カート追加、カート確認、決済開始、配送情報入力、支払い情報入力、購入完了、返金を計測します。途中段階を設定すると、購入手続きのどこで離脱しているかを把握できます。

6.1 add_to_cartとremove_from_cart

add_to_cartは商品がカートへ追加された時点、remove_from_cartはカートから削除された時点で送信します。ボタンのクリックではなく、カート内容が実際に変更されたことを条件にします。

非同期通信を利用する通販サイトでは、クリック後に在庫不足や通信エラーが発生する場合があります。処理成功後にイベントを送信し、商品ID、商品名、価格、数量をitems配列へ設定します。

6.2 view_cart

view_cartは、利用者がカート内容を表示した時点に送信します。カート追加後にそのまま購入手続きへ進むサイトでも、カート画面やカート領域が表示された時点を定義できます。

カート内商品、数量、金額を送信すると、カート閲覧後に購入へ進まなかった商品や、複数商品を入れた後に削除されやすい商品を分析できます。

6.3 begin_checkout

begin_checkoutは、利用者が購入手続きを開始した時点で送信します。一般的には、カート画面から「購入手続きへ進む」を選択し、決済過程へ入った時点です。

カート閲覧と購入手続き開始を分けることで、商品をカートに入れた利用者のうち、どの程度が実際の決済へ進んだかを確認できます。クーポンや購入金額を送信すると、特典別の決済開始率も分析できます。

6.4 add_shipping_infoとadd_payment_info

add_shipping_infoは配送情報が送信された時点、add_payment_infoは支払い情報が送信された時点に使用します。それぞれ単に入力欄へ文字が入力された時点ではなく、次の段階へ正常に進んだ時点で送信します。

配送方法をshipping_tier、支払い方法をpayment_typeで区別できます。配送方法や決済方法ごとの離脱率を把握し、特定の選択肢で問題が発生していないかを確認できます。add_payment_infoでは通貨、金額、クーポン、商品情報なども送信できます。

6.5 purchaseとrefund

purchaseは、決済や注文処理が正常に完了した時点で送信します。注文確認画面を表示しただけではなく、注文がシステムへ保存され、取引が成立したことを基準にします。

refundは、購入の全部または一部が返金された時点に送信します。purchaseでは一意の取引識別子が特に重要であり、完了画面の再読み込みによる二重送信を防止する設計が必要です。

購入イベントの例

gtag('event', 'purchase', {  transaction_id: 'ORDER-20260717-001',  value: 12800,  tax: 1163,  shipping: 500,  currency: 'JPY',  items: [    {      item_id: 'SKU-001',      item_name: 'オリジナルバッグ',      price: 12300,      quantity: 1    }  ] });

7. ゲーム向けの推奨イベント

ゲーム向け推奨イベントでは、段階開始、段階完了、得点、達成項目、仮想通貨、チュートリアルなどを記録できます。これらを送信すると、ゲーム向けレポートの作成に利用されます。

7.1 level_startとlevel_end

level_startは利用者が新しい段階を開始した時点、level_endは段階を終了した時点に送信します。段階名や成功状態などをパラメータとして付けることで、難易度や離脱傾向を分析できます。

開始人数と完了人数を比較すると、特定段階での離脱率を把握できます。完了時間や試行回数を独自パラメータとして追加する場合は、分析方法も事前に決めます。

7.2 level_up

level_upは、利用者の段階やランクが上昇した時点に送信します。利用者自身の成長段階を表すものであり、個別のステージ開始を表すlevel_startとは役割が異なります。

到達した段階やキャラクターなどをパラメータとして送信すると、継続利用者がどの程度まで進んでいるかを確認できます。

7.3 post_score

post_scoreは、利用者が得点を記録または送信した際に使用します。ゲーム終了時の得点、競技結果、ランキング登録などに利用できます。

同じ利用者が繰り返し得点を送信する可能性があるため、イベント回数と利用者数を区別して分析します。極端な値や不正な送信を防ぐため、重要な得点はサーバー側で検証する設計が適しています。

7.4 unlock_achievement

unlock_achievementは、利用者が実績、称号、特別項目などを獲得した時点で送信します。達成項目を識別する値を付けることで、人気のある実績や取得が難しい実績を判断できます。

達成率が極端に低い場合は条件が難しすぎる可能性があり、極端に高い場合は利用者の継続動機になっていない可能性があります。イベントデータを難易度調整や継続施策に活用します。

7.5 tutorial_beginとtutorial_complete

tutorial_beginは初回案内を開始した時点、tutorial_completeは完了した時点に送信します。ゲームだけでなく、操作説明を持つアプリや会員サービスにも利用できます。

開始数と完了数を比較すると、初回案内の途中離脱を把握できます。段階別の離脱をさらに詳しく分析する場合は、推奨イベントを維持したまま、案内段階を追加パラメータで送信します。

8. 推奨イベントのパラメータ

推奨イベントは、イベント名だけでなく、公式に定義されたパラメータと組み合わせることが重要です。パラメータが不足すると、イベントは記録されても、対応レポートで十分な情報を利用できない場合があります。

8.1 必須パラメータと任意パラメータ

推奨イベントの仕様には、必須パラメータと任意パラメータがあります。たとえば、searchのsearch_termは必須です。一方、loginのmethodは任意ですが、設定することでログイン方法を比較できます。

必須と書かれていない値でも、分析に必要であれば送信します。ただし、独自パラメータを無計画に増やすのではなく、レポートや改善施策で使用する値に限定します。

8.2 valueとcurrency

valueは、イベントへ金銭的な価値を設定する数値パラメータです。問い合わせの推定価値、購入金額、見込み顧客の価値などを表すために使用できます。

valueを金額として送信する場合は、通貨を示すcurrencyも適切に設定します。公式仕様では、valueを設定した際に正確な収益指標を計算するため、currencyが必要になるイベントがあります。

金額を含む問い合わせイベントの例

gtag('event', 'generate_lead', {  currency: 'JPY',  value: 10000 });

8.3 items配列

通販や見込み顧客向けの一部イベントでは、商品やサービスの情報をitems配列で送信します。一回のイベントに複数の商品を含められるため、カートや注文全体を表現できます。

各商品では、item_idまたはitem_nameの少なくとも一方が必要です。価格、数量、ブランド、分類、一覧名、位置なども設定できます。商品ごとに独自パラメータを追加する場合、公式仕様ではitems配列内へ最大27個の独自パラメータを追加できます。

8.4 独自パラメータの追加

推奨イベントには、公式で定められたパラメータに加えて、独自パラメータを追加できます。たとえば、searchへsearch_locationを追加し、ヘッダー検索と記事内検索を区別する方法があります。

独自パラメータをレポートや探索で継続的に利用する場合は、独自ディメンションまたは独自指標として登録します。分類用の文字列は独自ディメンション、金額や数量などの数値は独自指標が適しています。

8.5 パラメータ名と値の統一

同じ意味を持つ情報には、すべてのイベントで同じパラメータ名を使用します。問い合わせ種別を、あるイベントではform_type、別のイベントではcontact_kindとして送ると、横断分析が難しくなります。

値の表記も統一します。email、Email、e-mailが混在すると別の値として集計されます。小文字、下線、内部識別子などの規則を決め、設計書へ記録します。

9. 推奨イベントと他のイベントの違い

GA4には、推奨イベント以外にも、自動収集イベント、拡張計測イベント、独自イベント、キーイベントなどがあります。それぞれの違いを理解し、同じ行動を重複設定しないことが重要です。

9.1 自動収集イベントとの違い

自動収集イベントは、GA4の計測環境を導入すると基本的な操作によって自動送信されます。推奨イベントは、サイトやアプリの業務上の意味を理解しなければ送信できないため、運営者による実装が必要です。

たとえば、GA4はセッションの開始を自動的に判断できますが、問い合わせが正常に受理されたかは自動的に判断できません。そのため、session_startは自動収集、generate_leadは推奨イベントです。

9.2 拡張計測イベントとの違い

拡張計測イベントは、Webデータストリームの画面で機能を有効にすると、原則としてコードを追加せずに送信されます。スクロール、外部リンク、ファイル取得などが対象です。

推奨イベントは、管理画面で有効にするだけでは動作しません。購入や会員登録など、サイト側の処理と連携して送信します。

9.3 独自イベントとの違い

独自イベントは、自動収集、拡張計測、推奨イベントのいずれにも合うものがない場合に、運営者が独自名称で作成します。Googleは、他のイベントで目的を満たせない場合に独自イベントを利用する考え方を案内しています。

推奨イベントは既定名称と推奨パラメータを利用できるため、標準レポートや将来機能との互換性があります。独自イベントでは、必要に応じて独自レポートや探索を作成します。

9.4 キーイベントとの違い

推奨イベントは、イベントの名称とデータ構造に関する分類です。キーイベントは、収集しているイベントの中から、事業上特に重要な行動として指定したものです。

推奨イベントであるpurchaseやgenerate_leadをキーイベントにできますが、すべての推奨イベントをキーイベントにする必要はありません。また、独自イベントも重要であればキーイベントに指定できます。

9.5 Google広告のコンバージョンとの違い

推奨イベントは、GA4へ送信する行動データです。そのイベントをGA4でキーイベントに指定し、さらにGoogle広告の最適化へ利用する場合は、Google広告のコンバージョンとして作成します。

現在の関係は「イベント、キーイベント、Google広告コンバージョン」という流れです。GA4のキーイベントは全流入経路の重要行動を評価し、Google広告コンバージョンは広告レポートや入札最適化に利用されます。

10. 推奨イベントの選び方

推奨イベントを導入する際は、イベント一覧から無差別に選ぶのではなく、事業の成果と利用者行動に合わせて選定します。イベント数を増やすことより、条件と意味を正確にすることが重要です。

10.1 計測したい行動を明確にする

最初に、何を改善するためにイベントを計測するのかを決めます。問い合わせを増やしたい場合は、問い合わせ完了、営業対象判定、商談開始、成約など、改善に必要な段階を選びます。

単に「ボタンが押された回数を知りたい」という目的でも、ボタンの役割を確認します。会員登録完了ならsign_up、問い合わせ完了ならgenerate_lead、独自診断の開始なら独自イベントなど、行動の意味に合う名称を使用します。

10.2 公式一覧から該当名称を探す

自動収集イベントや拡張計測で取得できない場合は、公式の推奨イベント一覧から意味の合うイベントを探します。全業種、通販、見込み顧客獲得、ゲームの分類を確認します。

名称が完全に同じ言葉でなくても、行動の意味が一致するかを判断します。たとえば、資料請求は「購入」ではなく見込み顧客獲得であるため、通常はgenerate_leadが適しています。

10.3 発生時点を定義する

イベント名を選んだら、どの時点で発生したと判断するかを定義します。フォームの場合は、ボタンクリック、送信処理開始、送信成功、顧客管理システムへの保存など、複数の候補があります。

成果を表すイベントは、可能な限り処理成功時に送信します。クリック時点で送ると、入力エラーや通信失敗も成果として記録される可能性があります。

10.4 必要なパラメータを決める

イベントを選定した後は、公式仕様に記載された必須パラメータと任意パラメータを確認します。さらに、自社の分析に必要な独自パラメータを検討します。

パラメータは「取得できるから」という理由だけで追加しません。どのレポートで、誰が、どの判断に使用するかを決め、不要な情報や個人情報を送信しないようにします。

10.5 独自イベントへ変更する判断

意味の一致する推奨イベントがない場合は、独自イベントを作成します。推奨イベントの名称を、本来とは異なる行動へ無理に当てはめる必要はありません。

たとえば、料金計算結果の表示は、問い合わせ獲得や購入ではありません。このような場合は、price_calculator_completeなどの独自イベントを作成し、推奨イベントと明確に区別します。

11. Googleタグマネージャーで設定する方法

Googleタグマネージャーでは、GA4イベントタグとトリガーを組み合わせて推奨イベントを送信します。クリック、ページ表示、フォーム、データレイヤーなど、サイトの仕組みに応じた条件を設定できます。

11.1 設定前の準備

GA4プロパティ、Webデータストリーム、GTMコンテナ、Googleタグが正しく設定されていることを確認します。また、対象コンテナの編集権限とGA4プロパティへの必要な権限を確認します。

すでに直接コードや別プラグインから同じ推奨イベントを送信していないかも確認します。GTMへ移行する場合は、旧設定を停止する時期と新設定を公開する時期を合わせます。

11.2 GA4イベントタグを作成する

GTMのタグ画面で新しいタグを作成し、GoogleアナリティクスのGA4イベントタグを選択します。測定先とイベント名を設定し、必要に応じてイベントパラメータを追加します。

推奨イベントを作成するときは、公式一覧の名称をそのまま入力します。Googleの公式手順でも、推奨イベントを作成する場合は事前定義されたイベント名を使用するよう案内されています。

11.3 トリガーを設定する

トリガーは、イベントを送信する条件です。完了ページを表示したときはページ表示トリガー、特定リンクの操作はクリックトリガー、独自処理の完了は独自イベントトリガーを利用できます。

問い合わせや購入のような重要なイベントでは、単純なクリックトリガーよりも、処理成功後のデータレイヤーイベントを利用するほうが正確です。

11.4 データレイヤーと連携する

Webサイト側で処理が成功した時点に、必要な値をデータレイヤーへ追加します。GTMでは、eventの値を独自イベントトリガーとして使用し、他の値をデータレイヤー変数として取得します。

問い合わせ成功時の例

window.dataLayer = window.dataLayer || []; window.dataLayer.push({  event: 'contact_form_success',  form_type: 'general_contact',  lead_value: 5000 });

GTM側ではcontact_form_successを条件にgenerate_leadを送信し、form_typeやlead_valueをパラメータへ設定します。サイト内の処理名とGA4へ送る推奨イベント名を分けることで、実装を管理しやすくなります。

11.5 プレビューと公開を行う

設定後はGTMのプレビューモードで対象サイトへ接続し、必要な操作を行います。対象操作でタグが一回発火し、対象外の操作では発火しないことを確認します。

確認後は、変更内容が分かるバージョン名と説明を入力して公開します。Googleの公式手順でも、プレビューによる検証後にバージョンを作成して公開する流れが案内されています。

12. Googleタグで直接設定する方法

GoogleタグをWebサイトへ直接実装している場合は、gtag()関数を使用して推奨イベントを送信します。イベント名とパラメータをJavaScriptで指定します。

12.1 基本的な送信形式

推奨イベントを送る基本形式は、gtag('event', 'イベント名', {パラメータ})です。公式のイベント仕様にも、各イベントのGoogleタグ向け設定例が掲載されています。

基本形式

gtag('event', 'イベント名', {  パラメータ名: '値' });

イベントを送るコードは、Googleタグが正しく読み込まれる構成で実行します。共通処理や同意管理との実行順序も確認します。

12.2 会員登録を送信する

会員登録が正常に完了した後、sign_upを送信します。登録画面を表示した時点や送信ボタンを押した時点ではなく、利用者アカウントが作成された時点を条件にします。

設定例

function onRegistrationComplete(methodName) {  gtag('event', 'sign_up', {    method: methodName  }); }

methodNameには、emailやgoogleなど、事前に統一した値を渡します。

12.3 問い合わせを送信する

問い合わせフォームの送信成功処理からgenerate_leadを呼び出します。フォームの種類や見込み価値を追加すると、問い合わせ経路ごとの質を比較できます。

設定例

function onContactComplete() {  gtag('event', 'generate_lead', {    currency: 'JPY',    value: 5000,    form_type: 'general_contact'  }); }

この関数は、実際のフォームシステムが提供する送信成功処理から呼び出します。単独で記述しただけでは、フォームの成功状態と自動的に連携されません。

12.4 商品選択を送信する

商品一覧から詳細ページへ進む操作では、select_itemを使用できます。選択された商品と、表示されていた一覧を送信します。

設定例

gtag('event', 'select_item', {  item_list_id: 'related_products',  item_list_name: '関連商品',  items: [    {      item_id: 'SKU-101',      item_name: 'ビジネスバッグ',      index: 2,      price: 14800    }  ] });

select_itemではitems配列が必要であり、商品IDまたは商品名の少なくとも一方を設定します。

12.5 購入処理と重複を防ぐ

購入イベントは、注文番号を一意のtransaction_idとして送信します。完了ページを再読み込みした場合でも、同じ注文イベントが繰り返し送信されない仕組みをサイト側で用意します。

画面に表示された注文番号や金額をHTMLから読み取る方法は、デザイン変更の影響を受けやすくなります。サーバー側で確定した注文情報をJavaScriptへ安全に渡し、その値からイベントを送信する方法が安定します。

13. サイト別の実装例

同じ推奨イベントでも、Webサイトの種類によって発生条件が異なります。イベント名だけを共通化し、条件やパラメータは実際の事業処理に合わせて設計します。

13.1 企業サイトの問い合わせフォーム

企業サイトでは、問い合わせフォームの送信成功時にgenerate_leadを送信します。一般問い合わせ、資料請求、見積もり、採用応募などをパラメータで区別します。

問い合わせボタンのクリックは、問い合わせ意向を示す補助イベントとして独自計測できますが、generate_leadは送信完了へ限定したほうが成果を正確に評価できます。

13.2 会員制サイト

会員制サイトでは、登録完了時にsign_up、ログイン成功時にloginを送信します。登録画面表示やログイン画面表示は別のページ表示イベントとして確認できます。

ログイン方法や登録方法をmethodで区別すると、外部アカウント連携とメール登録の利用割合を分析できます。退会や契約変更に合う推奨イベントがない場合は、目的に応じた独自イベントを検討します。

13.3 メディアサイト

メディアサイトでは、サイト内検索にsearch、共有にshare、コンテンツ選択にselect_contentを利用できます。記事閲覧自体は通常、page_viewで取得します。

記事カテゴリー、著者、掲載位置などを独自パラメータとして追加する場合は、必要に応じて独自ディメンションへ登録します。ただし、既定のページ情報と重複する項目を不用意に登録しないようにします。

13.4 予約サイト

予約サイトでは、プラン一覧をview_item_list、プラン詳細をview_item、予約手続き開始をbegin_checkout、予約と決済の完了をpurchaseとして設計できます。

無料相談予約など、金銭を伴わず見込み顧客獲得を目的とする場合はgenerate_leadが適することもあります。事業上の取引として成立するのか、営業見込みの獲得なのかを基準に選択します。

13.5 不動産・保険・自動車サイト

物件、保険商品、車両などの一覧はview_item_list、詳細表示はview_itemとして計測できます。問い合わせや査定申し込みはgenerate_leadを使用します。

その後の営業状況を顧客管理システムと連携し、qualify_lead、working_lead、close_convert_leadなどを送信すれば、広告クリックから成約までの長い過程を分析できます。見込み顧客向けイベントは、オンラインとオフラインを含む過程の計測に推奨されています。

14. 推奨イベントを確認する方法

推奨イベントは、設定しただけで正しく動作しているとは限りません。イベント名、発生条件、パラメータ、送信回数、GA4側の受信状況を確認します。

14.1 GTMプレビューで確認する

GTMを利用している場合は、プレビューモードでタグの発火状況を確認します。対象操作を行い、どのイベントでタグが動作したか、トリガー条件が一致したかを調べます。

発火したタグだけでなく、発火しなかったタグの条件も確認できます。問い合わせ成功前に発火していないか、同じ操作で複数回発火していないかを確認します。

14.2 デバッグ表示で確認する

GA4のデバッグ表示では、デバッグ対象端末から送信されたイベントを時系列で確認できます。推奨イベントの名称を選択し、パラメータと値を確認します。

Googleは、推奨イベントの設定後にデバッグ表示を使用して監視する方法を案内しています。GTMでタグが発火していても、測定先の誤りなどでGA4へ届いていない場合があるため、両方を確認します。

14.3 リアルタイムで確認する

リアルタイムレポートでは、実際の利用者から送られたイベントを確認できます。テスト端末から対象操作を行い、イベント名が表示されるかを確認します。

ただし、リアルタイムで名称が表示されたことだけでは、すべてのパラメータが正しいとは判断できません。詳細値はデバッグ表示や探索でも確認します。

14.4 イベントが表示されない原因

推奨イベントが表示されない場合は、イベント名、測定先、トリガー、同意状態、内部アクセス除外、広告遮断機能などを確認します。

大文字と小文字、下線、単数形と複数形の違いにも注意します。generate_leadとgenerate_Leadは同じ名称ではありません。

14.5 二重計測の原因

イベントが二重に記録される場合は、GTMと直接コードの併用、複数プラグイン、複数トリガー、完了画面の再読み込みなどを確認します。

GA4管理画面で既存イベントを基に新しいイベントを作成し、同時にGTMから同じ名称を送信している場合も重複の原因になります。どの場所でイベントを生成しているかを設計書へ記録します。

15. 推奨イベントを安全に運用する方法

推奨イベントは、一度設定して終わりではありません。フォーム、決済、会員機能、商品構造などが変更されると、イベントの発生条件やパラメータも見直す必要があります。

15.1 計測設計書を作成する

イベント名、目的、発生条件、パラメータ、実装場所、キーイベント指定、確認方法を一覧化します。担当者が変わっても、設定の意味を判断できる状態にします。

イベントを停止または変更した場合も、設計書の状態と変更日を更新します。

15.2 推奨名称を変更しない

公式に定義されたイベント名は、そのまま使用します。社内で分かりやすい日本語名称は、GTMのタグ名や計測設計書へ記載し、GA4へ送信する名称は変更しません。

たとえば、GTMのタグ名を「GA4_お問い合わせ完了」とし、送信するイベント名をgenerate_leadにします。管理画面の表示名と送信値を分けると、標準仕様と社内の分かりやすさを両立できます。

15.3 個人情報を送信しない

氏名、メールアドレス、電話番号、住所、問い合わせ本文などを、イベント名やパラメータとしてGA4へ送信しないようにします。

フォームの入力値を自動的に取得する変数や、URLへ入力内容が含まれる仕組みでは特に注意が必要です。送信前に、実際のパラメータ値とページURLを確認します。

15.4 独自定義を増やしすぎない

独自パラメータを分析するために、独自ディメンションや独自指標を作成できます。ただし、標準プロパティでは作成数に上限があります。イベント単位の独自ディメンションは50個、商品単位は10個、独自指標は50個です。

利用者ごとの一意な識別子、セッション識別子、時刻など、値の種類が非常に多い項目は避けます。高カーディナリティの項目はレポートの「その他」行を増やす可能性があります。

15.5 定期的に点検する

フォーム変更、決済改修、テーマ変更、アプリ更新、顧客管理システム変更の後は、主要な推奨イベントを再確認します。画面上の処理が正常でも、イベント連携だけが停止している場合があります。

イベント回数の急増や急減も確認します。発生件数が事業側の問い合わせ数や注文数と大きく異なる場合は、二重送信、計測漏れ、テストデータ、返金処理などを調査します。

おわりに

GA4の推奨イベントとは、問い合わせ、会員登録、検索、購入などの一般的な利用者行動について、Googleが名称とパラメータを事前に定義したイベントです。自動収集イベントや拡張計測イベントとは異なり、推奨イベントはGoogleタグ、Googleタグマネージャー、アプリ用開発機能などを使って実装する必要があります。

推奨イベントを選ぶときは、最初に計測したい行動の意味と発生時点を決めます。その後、公式一覧に適切な名称があるかを確認し、定義された名称とパラメータを使用します。適切な推奨イベントが存在しない場合に限り、独自イベントを作成すると、計測環境を標準化しやすくなります。

実装後は、GTMプレビュー、GA4のデバッグ表示、リアルタイムレポートを使い、名称、パラメータ、発生回数を確認します。重要な推奨イベントはキーイベントとして指定し、流入経路、広告、ページ、商品、営業過程などの成果分析へ活用することが大切です。