GA4のイベントとは？4種類の違い・イベント数と何を計測するかの決め方Column

資料ダウンロードのボタンを新設したときや、サイトをリニューアルしたとき。上司やクライアントから「GA4のイベントを設定しておいて」と言われ、設定手順の記事を何本読んでも作業に入れない方は少なくありません。手順は分かったのに、「自社サイトの何をイベントにするか」が決まっていないからです。

GA4の管理画面を開くと、イベント一覧には「page_view」や「scroll」など、見覚えのない名前がすでに並んでいます。どれが自動で取れていて、どれが誰かの設定なのか。その区別がつかないまま作り始めると、半年後には誰も意味を読み取れないイベント名の列ができあがります。しかも、過去に収集済みのイベント名は、後から遡って書き換えることはできません。

そこでこの記事では、作り方の前に決めるべきことを扱います。具体的には、「何を計測対象にするか」と「どんな名前を付けるか」を開設します。読み終えるころには、計測する行動を絞り込み、社内で守れる命名ルールを決め、エンジニアや制作会社にそのまま渡せる依頼の形まで理解できるでしょう。

GA4そのものの概要は、「GA4とは？UAとの違い・できることと最初に見るべき5つの指標」をご覧ください。

GA4のイベントとは｜「ページを見た」もすべてイベントとして記録される

GA4では、Webサイトやアプリ上で計測するユーザーの行動を「イベント」という単位で記録します。たとえば、ページが表示されたときの「page_view」、ページを一定の位置までスクロールしたときの「scroll」、ファイルへのリンクをクリックしたときの「file_download」などもイベントです。

まず押さえておきたいのは、GA4ではユーザーの行動をイベント単位で記録することと、イベントが「イベント名＋パラメータ」という構造になっていることです。細かな仕様を最初からすべて覚える必要はありません。まずはこの2点を理解してから、「自分のサイトでは、すでに何が計測されているのか」を確認していきましょう。

参考：Google アナリティクス ヘルプ 「[GA4] イベント」

GA4のイベントパラメータとは｜イベント名との違いと基本構造

イベント名は「何が起きたか」、パラメータは「その行動についての詳しい情報」を表します。たとえば、PDFなどのファイルへのリンクがクリックされると、拡張計測機能が有効な場合は「file_download」というイベントとして記録されます。

そのイベントには、

• file_name：どのファイルか
• file_extension：ファイルの拡張子
• link_url：クリックされたリンク先
• page_location：イベントが発生したページ

など、その行動を詳しく見るための情報が付随します。「何が起きたかをイベント名で記録し、その詳細をパラメータで持つ」と考えると分かりやすいでしょう。

page_viewやclickなども、基本的には同じ考え方で記録されています。レポートに表示される「イベント数」は、イベントが発生した回数を表す指標です。この「イベント名＋パラメータ」の構造を理解しておくと、イベントを自分で設計するときにも、「イベントを分けるべきか、パラメータで区別するべきか」を判断しやすくなります。

参考：Google アナリティクス ヘルプ 「[GA4] イベント パラメータ」

GA4のイベント数とは｜イベントが発生した回数を表す指標

GA4の「イベント数」は、ユーザーがイベントをトリガーした回数を表す指標です。たとえば、page_viewが100回、scrollが30回発生した場合、それぞれのイベント数として記録されます。イベント数はユーザー数やセッション数とは異なり、「イベントが何回発生したか」を確認するための指標です。なお、「セッションあたりのイベント数」は、1セッションあたりに発生したイベント数の平均です。

UAの「カテゴリ・アクション・ラベル」との違い

ユニバーサルアナリティクス（UA）を使っていた方は、イベントの考え方の違いに注意が必要です。UAのイベントトラッキングでは、「イベントカテゴリ」「イベントアクション」「イベントラベル」という3つの項目を使ってイベントを整理していました。

一方、GA4にはこの3点セットはありません。GA4では、「何が起きたか」をイベント名で表し、「何を対象にしたか」「どこで起きたか」といった詳細を必要に応じてパラメータで記録します。UAのカテゴリ・アクション・ラベルをそのままGA4へ置き換えようとすると、イベント名を必要以上に細かく分けてしまうことがあります。GA4では、まず「どの行動を1つのイベントとして数えたいか」を決め、その内訳として確認したい情報をパラメータに持たせる、と考えるのが基本です。

構造が分かったところで、次は自分のサイトの現状を確認します。GA4では、自分でイベントを追加しなくても、すでにさまざまなイベントが記録されていることがあります。

参考：Google アナリティクス ヘルプ 「[UA→GA4] 移行の参考情報」

GA4イベントの4種類と自動で取れている範囲｜設定前に現状を確認する

GA4のイベントは、大きく「自動収集イベント」「拡張計測機能イベント」「推奨イベント」「カスタムイベント」の4種類に分けられます。重要なのは4種類の名前を暗記することではなく、「どこまでが自動で計測されていて、どこから自分で設定する必要があるのか」を理解することです。

GA4イベントの設定方法はイベントの種類によって異なる

自動収集イベントは、基本的に追加設定は不要です。拡張計測機能イベントは、条件を満たしていれば自分でイベントを作らなくても記録され、Webデータストリームで有効化するだけです。一方、推奨イベントとカスタムイベントは、自動では収集されないため、自分で設定・実装する必要があります。そのため、イベントを新しく作る前に、まず「すでに同じ行動が計測されていないか」を確認することが重要です。本記事では実装手順ではなく、設定前のイベント設計を扱います。

参考：Google アナリティクス ヘルプ 「イベントについて」

GA4イベントの確認方法｜まず自社のイベント一覧を開く

最初の一歩は、イベントを作ることではなく、現在記録されているイベントを確認することです。GA4の［レポート］→［エンゲージメント］→［イベント］を開くと、現在記録されているイベント名を一覧で確認できます。

※プロパティのレポート構成によっては［イベント］が表示されない場合があります。

page_viewやsession_start、scrollなど、自分では設定した覚えのないイベントが並んでいることもあります。これは必ずしも、前任者や制作会社が設定したイベントとは限りません。

次の順番で確認すると、イベントの出所を整理しやすくなります。

1. Google公式の「自動的に収集されるイベント」に掲載されているか確認する
2. 「拡張計測機能イベント」に掲載されているか確認する
3. 「推奨イベント」に掲載されているか確認する
4. いずれにも該当しない場合は、独自に設定されたイベントかどうかを確認する

たとえば、page_viewやsession_startは自動収集イベントです。scroll、click、file_downloadなどは拡張計測機能イベントです。generate_leadのように、自動では収集されないもののGoogleがイベント名や用途を定義しているものは推奨イベントです。一方、event1やcvなど、公式のイベント一覧に見当たらない名前がある場合は、前任者や制作会社などが独自に設定したイベントである可能性があります。ただし、名前だけでは発火条件までは判断できません。すぐに削除せず、GTMなどの実装内容や関係者への確認を通じて、「何を計測するイベントなのか」を確認しておきましょう。

参考：Google アナリティクス ヘルプ 「イベント レポート」

GA4の自動収集イベントと拡張計測機能イベント

自動収集イベントは、Google アナリティクスをWebサイトに設定すると、自動的に収集されるイベントです。一方、拡張計測機能イベントは、Webデータストリームで拡張計測機能が有効になっている場合に記録されます。代表的なイベントには次のようなものがあります。

ここで注意したいのが、イベント名から想像する動作と、実際の計測条件が必ずしも同じではないことです。たとえばclickは、Webサイト内のすべてのボタンクリックを自動で取得するイベントではありません。拡張計測機能のclickで計測されるのは、基本的に現在のドメインから別のドメインへ移動する「離脱クリック」です。また、file_downloadも「ファイルのダウンロードが完了した」ことを確認しているわけではありません。PDFなど、対象となる拡張子のファイルへのリンクがクリックされたときに記録されます。つまり、「イベント名だけを見て、何が計測されているかを判断しない」ことが重要です。

拡張計測機能が有効になっているかどうかは、GA4のWebデータストリームから確認できます。設定方法については、「GA4の設定方法｜後から取り返せない項目を優先する初期設定5STEP」をご覧ください。

また、自動で取れているからといって、そのまま自社の分析に使えるとは限りません。たとえばscrollは、ページの約90％まで到達したときに発生するイベントです。そのため、「記事を読み始めた人の数」や「50％まで読んだ人の数」を知りたい場合には、そのままでは目的に合いません。イベントを使うときは、イベント名だけでなく「どの条件で発生するのか」まで確認するようにしましょう。

参考：Google アナリティクス ヘルプ 「自動的に収集されるイベント」

参考：Google アナリティクス ヘルプ 「拡張計測機能イベント」

GA4のカスタムイベントとは｜推奨イベントとの違いと使い分け

推奨イベントは、Googleがイベント名や想定する用途、パラメータをあらかじめ定義しているイベントです。自動収集されるわけではないため、自社で実装する必要があります。たとえば、ユーザーが問い合わせのためにフォームやリクエストを送信した場合に使う推奨イベントとして、generate_leadが定義されています。Googleが推奨イベントを用意している行動については、独自のイベント名を作る前に、まず推奨イベントを利用できないか確認しましょう。

一方、カスタムイベントは、自動収集イベント、拡張計測機能イベント、推奨イベントのいずれでも目的を満たせない場合に、自社で定義するイベントです。たとえば「料金ページを閲覧した」といった、自社独自の分析上重要な行動を別イベントとして扱いたい場合などが候補になります。イベントを追加するときは、

自動収集イベント → 拡張計測機能イベント → 推奨イベント → カスタムイベント

の順番で、使えるものがないか確認するとよいでしょう。Googleも、該当する既存イベントや推奨イベントがある場合は、それらを優先して使用することを案内しています。

参考：Google アナリティクス ヘルプ 「[GA4] 推奨イベント」

既に取れているものを二重に作らない

4種類の違いが分かると、イベントを設定するときに避けたいことが1つ見えてきます。

同じユーザー行動を二重に計測してしまうことです。

たとえば、拡張計測機能によって資料PDFへのリンククリックがfile_downloadとしてすでに計測されているにもかかわらず、同じクリックをGTMでも設定すると、目的によっては同じ行動を二重に数える状態になります。イベント名が異なればGA4上では別々のイベントとして表示されるため、設定直後には問題に気づかないこともあります。しかし、「資料ダウンロード数」を確認するときにどちらを使えばよいのか分からなくなったり、同じ成果を重複して集計したりする原因になります。防ぎ方は単純です。新しいイベントを作る前に、

• すでに自動収集されていないか
• 拡張計測機能で取得されていないか
• 推奨イベントとして定義されていないか

を確認します。

既存のイベントで分析目的を満たせるなら、そのイベントを利用します。既存イベントだけでは必要な情報が取れない場合に、パラメータの追加や別イベントの設定を検討します。これで、自社サイトで「すでに取れているもの」と「これから設定する必要があるもの」を整理できます。ここからが本題です。足りない行動のうち、何を計測対象にするのかを決めていきます。

BtoBサイトで計測するイベントの絞り込み｜全部をイベントにしない

自社サイトですでに計測されているイベントを確認したら、次は「どの行動を分析したいか」を整理します。ここで大切なのは、分析したい行動をすべて新しいイベントとして追加する必要はないということです。すでに収集されているイベントやパラメータで確認できるなら、それを使います。それだけでは分析できない行動について、推奨イベントやカスタムイベントの追加を検討します。最初から大量のイベントを作るのではなく、「その数字が動いたら、次の打ち手が変わるか」を基準に、重要な行動から絞り込んでいきましょう。

GA4の解説記事のカスタムイベント例が自社に当てはまらない理由

GA4の解説記事を読んでいると、スクロール率やECサイトの商品閲覧、カートへの追加、購入といった例が多く登場します。こうした例が自社サイトに当てはまらなくても、GA4の理解が足りないわけではありません。サイトの目的が違えば、見るべき行動も違うからです。特にBtoBサイトでは、Webサイトの中だけで成果が完結しないケースが多くあります。

資料をダウンロードした後に問い合わせがあり、その先に商談や受注がある。あるいは、料金ページや事例ページを何度か見た後に、営業へ直接問い合わせる。そのためBtoBサイトでは、単に「何回クリックされたか」を増やすのではなく、検討が進んだことを判断する材料になる行動は何かという視点で考えることが重要です。たとえば、月間アクセスが数百件のサイトでスクロール率を10％刻みで細かく計測しても、その数字を次の施策に使わないのであれば、イベントを追加する優先度は高くありません。

BtoBサイトで分析したい行動を棚卸しする

まずは「イベントを作るかどうか」を考えず、サイト上で確認したい行動を書き出します。BtoBサイトでは、たとえば次のような行動が候補になります。

ここで注意したいのは、この表に書いた行動をそのまま1つずつカスタムイベントにするわけではないことです。たとえば料金ページの閲覧は、通常の「page_view」としてすでに収集されています。ページURLなどの情報を使えば料金ページだけを絞り込んで分析できるため、分析するだけなら新しく「view_pricing」のようなイベントを作らなくても確認できます。

一方、料金ページへの到達をほかのページ閲覧とは別の重要な行動として扱いたい場合などは、既存の「page_view」を条件に新しいイベントを作る方法もあります。つまり先に決めるべきなのは、イベント名ではなく、「何を知りたいのか」です。

分析したい行動が決まったら、

1. すでに収集されているイベントとパラメータで確認できないか
2. 推奨イベントとして適切なものがないか
3. それでも足りなければカスタムイベントが必要か

の順番で考えます。

参考：Google アナリティクス ヘルプ 「[GA4] イベントの名前を変更して新しいイベントを生成する」

計測する／計測しないの基準｜その数字が動いたら、来月の打ち手が変わるか

計測するか迷ったときは、次の問いを使います。

「その数字が動いたら、来月の打ち手が変わるか」

たとえば、「scroll」のイベント数が月1,000件から1,200件に増えたとします。その変化を見ても、次に何をするか決まらないのであれば、その数字を重要指標として管理する優先度は高くありません。しかも「scroll」は拡張計測機能で取得できるため、同じ目的のイベントを追加する必要もありません。

一方で、主要な資料へのアクセスや問い合わせにつながる行動が月10件から3件に減ったのであれば、次の施策が変わる可能性があります。資料の内容を見直すのか、CTAの設置場所を変えるのか、流入しているユーザーが変化していないかを調べるのか。数字を見て「次に何を確認・改善するか」が変わる行動は、優先して計測・分析する価値があります。最初に管理する重要な行動は、5〜10個程度を目安にしてもよいでしょう。これはGA4の仕様上の上限ではありません。サイトの目的や規模によって適切な数は異なります。重要なのは数そのものではなく、担当者が「この数字を見る理由」を説明できる状態にしておくことです。

「何を分析するか」と「イベントを追加するか」を分けて考える

ここまで書き出した行動を、次の3つに分類すると整理しやすくなります。

① すでに取得できているので、そのまま分析する

例：ページの閲覧、外部リンククリック、対象ファイルへのリンククリックなど

② すでにあるイベントやパラメータを使って、条件を絞って分析する

例：料金ページだけの「page_view」、特定資料の「file_download」など

③ 現在のデータだけでは目的を満たせないため、追加実装を検討する

例：独自のボタン操作や、自社固有の行動など

この分類をしてからイベントを追加すれば、「分析したいものを全部イベント化してしまう」ことを防げます。GA4で重要なのは、イベントの本数を増やすことではありません。必要な行動を、必要な粒度で判断できる状態にすることです。

全部計測すると読めなくなる｜上司に「なぜ絞るのか」と聞かれたときの答え

「とりあえず全部イベントとして計測しておけば安心」と考えたくなるかもしれません。しかし、イベントを増やすほど、レポートを見る側が「どれを見ればいいのか」を判断する負担も増えます。イベント一覧に重要度の異なる名前が大量に並んでいると、「今月はどうだった？」と聞かれたときに、見るべき数字から探さなければなりません。重要な行動が整理されていれば、見る数字と次の判断を結びつけやすくなります。

上司や関係者から「なぜ全部イベントにしないのか」と聞かれたら、次のように説明できます。

「イベントを増やすことが目的ではなく、施策判断に必要な行動を確認できる状態にすることが目的だからです。まず既存のデータで確認できるものを使い、それでは足りない重要な行動だけ追加します」

もう1つ覚えておきたいのが、新しくイベントを設定しても、原則として設定前のデータにさかのぼってそのイベントが記録されるわけではないことです。そのため、「今後の判断に必要になる可能性が高いが、現在は取得できていない行動」については、優先的に計測を開始する価値があります。一方、すでに「page_view」などで取得できている情報まで、将来のために別イベントとして作り直す必要はありません。「必要なデータがすでにあるか」を確認してから追加することが、イベントを増やしすぎないポイントです。なお、計測・分析している行動のうち、どれをGA4上で特に重要な成果として扱うかは「キーイベント」で設定します。

分析したい行動が整理できたら、次は新しく設定するイベントにどのような名前を付けるかを決めます。ここからは、担当者が変わっても意味が分かるイベント名とパラメータの命名ルールを考えていきましょう。

参考：Google アナリティクス ヘルプ 「[GA4] キーイベントに関するレポート」

GA4のイベント名・パラメータの命名規則｜半年後にも読める名前の決め方

計測する行動が決まったら、次はイベント名を決めます。イベント名にはGA4側で守る必要がある仕様がありますが、その仕様を満たしていれば、すべての会社で共通する「正しいイベント名」があるわけではありません。実務で重要なのは、個々のイベント名をその場で考えるのではなく、社内で同じルールを使い続けられる状態にすることです。担当者が変わっても、制作会社へ依頼しても、同じ考え方で名前を付けられるようにしておきましょう。

まず分けて考える｜GA4の仕様と社内の命名ルールは別

イベント名を決めるときは、

• GA4の仕様として守らなければならないルール
• 自社で統一するために決めるルール

を分けて考えます。

GA4の仕様は守る必要があります。一方、単語の並べ方や略語を使うかどうかなどは、自社で決めるルールです。たとえば、Googleの仕様ではイベント名に英語以外の文字も使用できます。しかし、社内での管理やGTMなどでの実装を考え、この記事では半角英数字を使い、小文字＋アンダースコアで統一する方法をおすすめします。「GA4で使えないから」ではなく、表記ゆれを減らし、誰が見ても扱いやすくするための社内ルールです。

社内の命名ルールで決めておきたい5項目

最低限、次の5項目を決めておくと、担当者によるばらつきを抑えやすくなります。

たとえば「問い合わせCTAをクリックした」という独自イベントを作るのであれば、「click_contact_cta」のように、名前から行動が想像できる形にします。別の担当者が「contact_button」、さらに別の担当者が「cv_click」と命名してしまうと、同じような行動なのにイベント一覧で統一性がなくなります。イベントを作るたびに名前を考えるのではなく、最初に型を決めておくことが重要です。

命名規則の良い例と悪い例｜半年後に名前だけで意味が分かるか

イベント名を決めるときの判断基準はシンプルです。半年後の自分や後任者が、その名前を見て何を計測しているか想像できるか。たとえば、次のような名前を比べてみます。

※ここで挙げている名前は、独自イベントを設定する場合の命名例です。すでに自動収集イベント、拡張計測機能イベント、推奨イベントで取得できる行動について、同じ目的の独自イベントを追加することを推奨するものではありません。

悪い例に共通するのは、イベント名だけでは「何を・どうした」のか分からないことです。たとえば、前任者が作ったevent1の意味を調べるために、GTMを開いてトリガーやタグの設定を確認しなければならないのであれば、イベント名だけでは十分な情報が伝わっていません。これは命名した担当者個人の問題というより、命名ルールが共有されていなかったことに原因があります。

GA4のイベントを分けるか、パラメータで区別するか

似た行動を複数計測するときは、「イベントを分けるべきか、それともパラメータで区別するべきか」で迷うことがあります。基本的には、合計として数えたい行動をイベント名にし、その内訳として見たい情報をパラメータで持つと考えると整理しやすくなります。

たとえば、同じ「問い合わせCTAのクリック」でも、ページ上部、記事末尾、サイドバーなど複数の場所にCTAがあるとします。設置場所ごとに、

• click_header_contact
• click_footer_contact
• click_sidebar_contact

とイベントを分ける方法もあります。

しかし、「問い合わせCTAが何回クリックされたか」を合計で見たいのであれば、イベントは、「click_contact_cta」の1つにし、「cta_location」というパラメータに、

• header
• footer
• sidebar

などの値を送る方法があります。こうすれば、問い合わせCTA全体のクリック数を1つのイベントとして確認しながら、必要に応じて設置場所ごとの内訳も分析できます。イベント名を細かく増やしすぎないためにも、「イベントで数えたい単位」と「内訳として見たい情報」を分けて考えることが重要です。

GA4のパラメータ名にも命名ルールを決める

独自に追加するパラメータについても、イベント名と同じように表記を統一しておきます。たとえば、

• cta_location
• content_type
• document_name

のように、小文字＋アンダースコアにそろえます。「location」、「place」、「position」のように、担当者ごとに似た意味のパラメータ名を作ってしまうと、後から分析するときに扱いにくくなります。イベント名だけでなく、どのような情報をどのパラメータ名で持つかも、計測設計の段階で決めておきましょう。

なお、GA4にはあらかじめ用意されているイベントパラメータや、それに対応するディメンションがあります。既存のものが使える場合は、新しいカスタムパラメータやカスタムディメンションを作る必要はありません。

独自パラメータをレポートで使うならカスタムディメンションも確認する

独自に追加したイベントパラメータは、GA4へデータを送信しただけで、すべてが通常のレポートでそのまま分析項目として使えるわけではありません。たとえば独自に「cta_location」というパラメータを送信し、「header」「footer」などの値ごとにレポートや探索で継続的に分析したい場合は、イベントスコープのカスタムディメンションとして登録する方法があります。

一方で、GA4に標準で用意されているディメンションがある場合は、同じ情報をカスタムディメンションとして重複して登録する必要はありません。「パラメータを送ったのに、分析したいディメンションとして選べない」という場合は、

• 標準のディメンションが用意されていないか
• 独自パラメータをカスタムディメンションとして登録する必要がないか

を確認してみましょう。

参考：Google アナリティクス ヘルプ 「[GA4] イベント パラメータ」

参考：Google アナリティクス ヘルプ 「[GA4] イベント スコープのカスタム ディメンションを作成する」

GA4側で決められている命名規則と上限も確認する

ここまでは主に社内ルールについて説明しましたが、GA4側で決められている仕様もあります。主なものは次のとおりです。

また、イベント名では大文字と小文字が区別されます。たとえば、click_contact_ctaとClick_Contact_Ctaは、別のイベントとして扱われます。そのため、GA4の仕様上は大文字を使用できても、この記事では表記ゆれを防ぐために小文字へ統一することをおすすめします。

注意したいのが「予約済み」の扱いです。Webのイベント名には、page_view、scroll、file_downloadなど予約済みのイベント名があり、新しい独自イベントの名前として自由に使用できるわけではありません。また、予約済みの名前や接頭辞の一覧は変更される可能性があります。

一方、イベントパラメータについては、「_」、「firebase_」、「ga_」、「google_」、「gtag.」などで始まる名前が使用できないなど、イベント名とは別の制約があります。

イベント名とパラメータ名では制約が異なるため、実装前にはGoogle公式の最新情報を確認してください。

参考：Google アナリティクス ヘルプ 「イベントの命名規則」

参考：Google アナリティクス ヘルプ 「イベント収集の制限」

「ルールを決めてから作る」が後から効いてくる

イベント名は、設定した後でも今後送信するデータの名前や計測方法を変更することはできます。しかし、変更したからといって、すでに収集された過去のイベントデータまで新しいイベント名に書き換わるわけではありません。たとえば半年間cvという名前で収集した後にgenerate_leadや別の名前へ変更しても、過去半年分のcvが自動的に新しい名前へ統一されるわけではありません。そのため、イベントを実装してから命名ルールを考えるのではなく、
何を計測するかを決める→ 命名ルールを決める→ イベントを実装する

という順番で進めることが大切です。

ここまで決めておけば、担当者が変わっても、制作会社やエンジニアへ依頼しても、同じルールで計測を続けやすくなります。

決めたGA4のイベント設計をエンジニア・制作会社に依頼する際の注意点

ここまでで、

• 何を分析したいか
• 既存のイベントで確認できないか
• 新しいイベントが必要か
• どのような名前とパラメータを使うか

を整理してきました。

実装をエンジニアや制作会社へ依頼するときは、口頭で「このボタンのクリックをGA4で取りたい」と伝えるだけではなく、計測条件を具体的に書いて渡します。最低限、次の3点を決めておきましょう。

• イベント名
• 発火条件
• パラメータ

さらに、実装後に「正しく設定できたか」を判断できるよう、確認条件まで書いておくとスムーズです。

たとえば次のように整理します。

※「generate_lead」はGoogleが定義している推奨イベントです。独自イベントを作る前に、推奨イベントを利用できないか確認してください。

発火条件は「誰が見ても同じ動作を再現できる」ように書く

実装依頼で特に曖昧になりやすいのが、発火条件です。たとえば、「資料ダウンロードをクリックしたとき」だけでは、どのページの、どのリンクを対象とするのか判断できない場合があります。

必要に応じて、

• 対象ページのURL
• 対象となるボタンやリンク
• クリック時なのか、送信完了時なのか
• 特定条件だけを対象とするのか

まで具体的にします。

たとえば、「/contact/ページの問い合わせフォームが正常に送信され、完了画面が表示されたとき」のように書いておけば、依頼する側と実装する側で「どのタイミングを成果として数えるか」がずれにくくなります。

パラメータは「名前」だけでなく「どんな値を入れるか」も決める

パラメータを使う場合は、パラメータ名だけでなく、どのような値を送るのかも決めておきましょう。たとえば問い合わせCTAの設置場所を「cta_location」で取得する場合、

• header
• sidebar
• article_end

など、値の付け方までそろえておきます。同じ場所を、ある担当者は「footer」、別の担当者は「bottom」と送ってしまうと、後から集計するときに別々の値として扱われます。イベント名と同じように、パラメータの値にも表記ルールを決めておくと管理しやすくなります。

実装したら、公開前に正しく発火するか確認する

イベントは、設定しただけで終わりではありません。GTMを使って実装する場合は、公開前にプレビュー機能を使い、

• 想定した操作でイベントが発生するか
• 想定していない操作では発生しないか
• 1回の操作で重複して発生していないか
• 必要なパラメータと値が送信されているか

を確認します。GA4側でも、リアルタイムレポートやDebugViewを使ってイベントを確認できます。特に確認したいのが、「発火するか」だけでなく「余計な場面で発火していないか」です。正しいボタンを押したときにイベントが発生していても、別のボタンを押したときにも同じイベントが発生していれば、集計結果は正しくありません。そのため実装依頼には、可能であれば「どうなれば設定完了と判断するか」まで含めておきましょう。

参考：Google アナリティクス ヘルプ 「[GA4] データ収集の確認」

まとめ｜GA4のイベントは、作る前の設計が重要

GA4のイベント設定では、イベントをたくさん作ることが目的ではありません。重要なのは、自社に必要な行動を、後から正しく分析できる状態にすることです。この記事で紹介した流れを整理すると、次のようになります。

1. 自動収集イベントや拡張計測機能イベントなど、すでに取得されているデータを確認する
2. 「何を知りたいのか」を基準に、分析したい行動を整理する
3. 既存のイベントやパラメータで確認できるものは、そのまま利用する
4. 足りない場合は、推奨イベント、カスタムイベントの順に検討する
5. 独自イベントを作る場合は、社内の命名ルールを決める
6. 発火条件やパラメータ、確認条件まで整理して実装を依頼する
7. 公開前に、想定どおり計測できているか検証する

迷ったときは、「その数字が動いたら、次の打ち手が変わるか」という基準に戻ってみてください。分析に使わないイベントを増やすよりも、施策判断に必要な行動を正しい条件で計測できていることの方が重要です。また、新しく設定したイベントは、設定前のデータにさかのぼって同じイベントとして記録されるわけではありません。今後の施策判断に必要で、まだ取得できていない行動があるなら、早めに設計して計測を始めましょう。一方、すでに「page_view」や「file_download」などで必要な情報が取得できている場合は、同じ目的のイベントを新しく作る必要はありません。まず現状を確認し、必要なものだけを追加する。この順番を守ることが、半年後、担当者が変わった後も使い続けられるGA4の計測設計につながります。