GA4 のイベント名を決めて壊れていないか確かめる、自社アプリの計測データ品質の手順

自社のアプリに GA4 のイベント計測を入れるとき、何を計測するかは決めても、イベントをどう名付けるか、入れた計測が正しく動いているかは後回しになりがちです。名前の揺れや抜けは、数か月分のデータがたまってから気づくことが多く、あとから直しても過去のデータは戻りません。

前の記事（SaaS の「使い始めた」をどう定義するか）では、何を計測するかを決めるところまでを扱いました。この記事では、その先の実装と検証に絞ります。命名のルール、Google が定める上限、公開前の確認、公開後に計測が壊れたことに気づく運用を、事業責任者が開発チームに依頼するときの観点でまとめます。

1. 命名ルールを実装の前に文書にする

Google のヘルプ（イベント名とパラメータ名のルール）によると、GA4 のイベント名には次のルールがあります。

• 大文字と小文字は区別されます。my_event と My_Event は別のイベントとして扱われます。
• 文字で始め、使えるのは文字、数字、アンダースコアだけです。スペースは使えません。
• 予約済みのプレフィックスやイベント名は使えません。

特に注意したいのは、大文字と小文字が区別される点です。開発者が複数いると、sign_up と signUp が混ざることがあります。この 2 つは別のイベントとして集計されるため、レポート上では同じ操作が分かれて見えます。

私たちは、次のような点を実装の前に 1 枚の文書にしておくとよいと考えています。

• 表記は、英小文字とアンダースコアに統一します。
• 名前の形は、「何を」と「どうした」を並べます（例：invoice_download、team_invite_send）。
• 粒度は、画面の名前ではなく、利用者の行動の名前にします。
• 新しいイベントを足すときは、この文書に先に書いてから実装します。

この文書は、開発を外部に頼む場合は納品物に含めておくと、担当が変わっても名前の規則が引き継がれます。

2. 予約された名前と上限を先に確かめる

同じヘルプには、予約済みのイベント名が挙げられています。ウェブでは click、error、file_download、form_start、form_submit、page_view、scroll、view_search_results などです。独自のイベントにこれらと同じ名前を付けるのは避けます。問い合わせフォームの送信を form_submit と名付けたくなっても、この名前は予約済みです。ヘルプによると、予約済みの一覧は網羅的ではなく、定期的に更新されることがあるため、実装の時点で最新の一覧を見直します。

パラメータ名も同様で、user_id や session_id などの名前や、_、firebase_、ga_、google_ で始まる名前はカスタムディメンションや指標には使えません。

上限については、Google のヘルプ（収集の上限）に次の数値があります。標準のプロパティの場合の上限です。

項目	上限
イベント名の文字数	40 文字
イベントごとのパラメータ数	25
パラメータ名の文字数	40 文字
パラメータ値の文字数	100 文字（page_title は 300 文字など、例外あり）
異なる名前のイベント数	ウェブは制限なし、アプリはユーザーごとに 500

実務では、イベント名を 40 文字以内に収める、パラメータに長い文字列をそのまま入れない、という点がよく効きます。パラメータ値には 100 文字の上限があるため、利用者が入力した自由記述のような長い文字列は入れません。個人情報の観点からも、自由記述は計測に入れない設計のほうが安全です。

3. 公開前に DebugView で 1 つずつ確かめる

計測の確認には、GA4 の DebugView を使います。Google のヘルプ（DebugView）によると、DebugView は、ウェブサイトやモバイルアプリから収集したイベントとユーザープロパティをリアルタイムで表示します。使うにはデバッグモードを有効にする必要があります。

ウェブでは、自分の端末だけで確認するなら Tag Assistant やプレビューモードを使います。gtag.js では debug_mode を true にする方法があり、無効にするときは false を設定するのではなく、パラメータそのものを削除する必要がある、とヘルプに書かれています。

確認のときは、次の順で見ます。

1. 決めた行動を実際に操作して、イベントが 1 回だけ記録されるか。
2. イベント名が命名の文書どおりか（大文字と小文字、スペルの揺れがないか）。
3. パラメータの名前と値が想定どおりか、空や未設定の値が入っていないか。
4. 画面の遷移やボタンの連打で、同じイベントが二重に記録されないか。

ここで一つ注意があります。ヘルプによると、同意モードで利用者が Analytics Cookie に同意していない場合や、クライアント側でプライバシー制御を実装している場合は、イベントが DebugView に表示されません。同意の取得を実装しているアプリでは、同意した状態と同意しない状態の両方で確認する項目を、チェックリストに入れておきます。

また、同じヘルプでは、デバッグ中の開発者のトラフィックはフィルタで除外することが推奨されています。テスト中の操作が本番のデータに混ざらないようにします。

4. 公開後に「計測が壊れた」と気づく仕組みを作る

公開前に確認しても、機能の追加や画面の改修で、計測は静かに壊れます。ボタンの作り直しでイベントの送信処理が消える、といった形です。エラーが画面に出るわけではないため、気づくのが遅れます。

次のような運用を、無理のない範囲で入れておくことを勧めます。

• 重要なイベント（登録、主要機能の初回利用など）だけは、リリースのたびに DebugView で 1 回確認する項目を、リリース手順に入れます。
• 重要なイベントの 1 日あたりの件数を、週に 1 回見ます。急に 0 になる、半分になる、といった変化に気づけます。
• 計測に関わる変更（イベント名の変更や追加）は、日付と理由を記録します。数字が変わったときに、アプリの変更が原因かを後から切り分けられます。

利用者が少ないうちは、件数が日によって大きくぶれます。そのため、変化の基準は「平均の何割」と決めるより、「ゼロになったら調べる」のように単純にしておくほうが運用しやすいと考えています。

まとめ

• 命名のルールを実装の前に文書にして、大文字と小文字、予約済みの名前、40 文字などの上限を踏まえる。
• 公開前に DebugView で、1 回だけ記録されるか、名前とパラメータが想定どおりかを確かめる。同意の有無の両方で確認する。
• 公開後は、リリースごとの確認と件数の定点確認で、計測が壊れたことに早く気づく。

自社 SaaS の立ち上げや、業務アプリの新規開発・リプレイスをご検討の場合は、弊社の SaaS・業務アプリ開発 をご覧ください。要件定義から公開後の改善まで対応しています。