GA4のイベント名を設計する方法｜後から直せない前提で

「その都度わかりやすい名前を付けていたら、似た名前が並んで区別が付かなくなった」「後から名前を直せると思っていた」——計測の設定を進めた後に気づく詰まりです。イベントの名前は、後から付け替えられません。数え始めた時点の名前で、そのまま溜まり続けます。この記事では、名前に関する制約と、命名の型の決め方を整理します。

思いつきで付けた名前が積み上がる

最初に、起きている状況を整理します。

計測を追加するたびに、イベント名を決めます。その場で分かりやすい名前を付ける運用が一般的です。

半年経つと、似た名前が並んで区別が付かなくなります。

資料の申込に関する計測が3種類あり、それぞれ別の名前になっている状態です。

担当者が変わると、どれが何かを判断できません。

さらに問題なのは、名前を後から変えられないことです。

すでに記録されたデータは、その名前で残ります。

新しい名前を付ければ、別のイベントとして記録が始まります。

その結果、同じ行動が2つの名前に分かれます。

集計する際に、両方を足す作業が必要になります。

この状態を避けるには、最初に規則を決めておく必要があります。

規則があれば、名前を考える時間も短くなります。

以降では、制約、規則の作り方、管理の方法を整理します。

あわせて、名前を変えたい場合の手順も確認します。

複数人で運用する場合の統一も扱います。

なぜ後から直せないのか

仕組みの理解です。

計測の仕組みでは、イベント名が記録の単位になります。名前ごとに集計されるため、名前が識別の役目を持ちます。

一度計測を始めた名前は、後から付け替えられないとされています。

名前を変えたい場合は、新しい名前で計測を始めることになります。

この場合、変更の前後は別のイベントとして扱われます。

過去のデータとの連続性は失われます。

たとえば前年との比較をしたい場合、名前が変わっていれば比べられません。

両方の名前を足す作業が必要になります。

この作業は、期間をまたぐ集計のたびに発生します。

そのため、名前は最初に決める価値があります。

後から直せる項目と、直せない項目を区別しておきます。

画面上の表示名は、後から変えられる場合があります。

しかし記録の単位としての名前は、変わりません。

この違いを理解しておけば、判断を誤りません。

設定を始める前に、名前の規則を決めます。

急いで計測を始めたい場面でも、この作業を先に行います。

名前に関する制約

守るべき条件です。

項目	条件	補足
文字数	半角40文字未満	全角では20文字未満に相当する
先頭の文字	英字にする	数字や記号から始められない
大文字と小文字	区別される	別の名前として扱われる
使える文字	英数字とアンダースコア	空白や記号は使わない
予約された名前	使えない	既定で取得される名前と重複させない
パラメータの数	1イベントあたり25個まで	上限を超えないよう設計する

上の6項目が、名前を決める際の枠になります。特に3行目は、見落とされやすい条件です。

大文字と小文字が違えば、別のイベントとして記録されます。

同じ意味の名前が大文字と小文字で分かれると、集計が分散します。

そのため、すべて小文字で統一する形が安全になります。

1行目の文字数は、日本語を使わない前提でも意識します。

説明的な名前にすると、40文字に近づきます。

略語を使うか、単語を絞る判断が必要になります。

4行目の使える文字も、統一の対象になります。

単語の区切りは、アンダースコアで表します。

6行目のパラメータの数は、設計の段階で確認します。

後から追加していくと、上限に近づきます。

ウェブの計測では、作れるイベントの数に制限はないとされています。

ただし、数を増やせば管理が難しくなります。

予約されている名前

使えない名前があります。

計測の仕組みが自動で使う名前は、予約されています。これらと同じ名前を付けることはできません。

特定の接頭辞も、使用が制限されているとされています。

仕組みの側が使う接頭辞に該当する名前は、避けます。

既定で取得される行動にも、決められた名前があります。

ページの表示、ファイルの取得、外部への遷移などが該当します。

これらは設定を有効にすれば自動で記録されます。

同じ行動に自分で名前を付けると、二重に記録されます。

そのため、既定で取得される内容を先に確認します。

すでに取れているものを、改めて設定する必要はありません。

確認の方法は、管理の画面で取得の設定を見ることです。

有効になっている項目の一覧が表示されます。

推奨されている名前も用意されています。

よくある行動については、推奨の名前を使う形が便利です。

推奨の名前を使えば、標準の集計に反映される場合があります。

独自の名前では、この恩恵が得られません。

命名の型を決める

規則の作り方です。

名前の型を決めておけば、毎回考える必要がなくなります。型は、単語の並べ方の規則です。

対象と動作を並べる形が、分かりやすい型になります。

たとえば、資料の申込であれば対象と動作を組み合わせます。

順序を統一しておけば、一覧で並べたときに整理されます。

対象を先に置く形にすると、同じ対象のイベントが並びます。

動作を先に置く形にすると、同じ動作のイベントが並びます。

どちらを選ぶかは、分析の仕方で決めます。

対象ごとに見ることが多ければ、対象を先にします。

単語の選び方も決めておきます。

同じ意味に複数の単語を使わないようにします。

たとえば申込を表す単語を1つに決めます。

複数の単語が混ざると、検索や整理が難しくなります。

略語を使う場合は、対応表を作ります。

略語の意味が分からなければ、後任者が判断できません。

この型を文書にして、社内で共有します。

イベントを増やすかパラメータで分けるか

設計の分岐点です。

似た行動を計測する場合、2つの方法があります。別のイベントにするか、同じイベントでパラメータで分けるかです。

同じ種類の行動であれば、パラメータで分ける形が扱いやすくなります。

たとえば資料の申込が3種類ある場合です。

イベントは1つにし、どの資料かをパラメータで記録します。

この形にすると、全体の件数と内訳の両方が見られます。

別のイベントに分けると、全体を見るために足す作業が必要になります。

一方で、行動の性質が違う場合は分けます。

資料の申込と問い合わせの送信は、性質が違います。

これらを同じイベントにすると、意味が混ざります。

判断の基準は、同じ指標として扱いたいかどうかです。

同じ目標に向かう行動であれば、まとめます。

別の目標であれば、分けます。

この判断を、設定を始める前に行います。

後から統合することはできません。

分けすぎると、イベントの数が増えて管理が難しくなります。

パラメータの設計

記録する内容です。

パラメータは、イベントに付随する情報です。1つのイベントあたり25個までという上限があります。

上限に近づくと、後から追加できなくなります。

そのため、必要なものに絞ります。

記録する候補は、対象の名前、種類、位置、経路です。

後から分析に使うかどうかで判断します。

使わない情報を記録しても、管理の対象が増えるだけです。

パラメータの名前にも、同じ規則を適用します。

小文字とアンダースコアで統一します。

値の形式も決めておきます。

同じ意味の値が複数の表記で入ると、集計が分散します。

たとえば資料の名前を記録する場合、表記を統一します。

全角と半角の違いでも、別の値として扱われます。

この統一は、設定する側の運用で担保します。

自動で入る値であれば、その形式を確認します。

想定と違う形で入っている場合があります。

既定で取れているものを確認する

重複を避けます。

設定を追加する前に、すでに取れているものを確認します。既定の設定で自動的に記録される行動があります。

ファイルの取得や外部への遷移は、既定で取得される場合があります。

これらを自分で設定すると、同じ行動が二重に記録されます。

集計の際に、数字が実際の2倍になります。

この誤りは、気づかないまま報告される場合があります。

確認の方法は、管理の画面で取得の設定を見ることです。

有効になっている項目と、その条件が表示されます。

条件が自社の運用と合っているかも確認します。

たとえばファイルの取得では、対象となる拡張子が決まっています。

その一覧に含まれない形式は、記録されません。

この場合は、自分で設定する必要があります。

既定の設定を無効にする判断もあります。

自分で細かく制御したい場合です。

ただし無効にすると、過去のデータとの連続性が変わります。

この判断も、記録に残します。

タグを管理する仕組みを使っている場合は、そこも確認します。同じ行動が二重に送られている場合があります。

管理の仕組み側で設定したイベントと、計測の側で設定したイベントが重なる形です。

どちらで設定するかを、あらかじめ決めておきます。

管理の仕組みに集める形にすると、変更の履歴が残ります。

複数人で運用する場合は、この形が扱いやすくなります。

設定の場所が分散すると、どこで送られているか追えなくなります。

引き継ぎの際にも、場所が1つであれば説明が短くなります。

一覧を作って管理する

設計の記録です。

設定したイベントは、一覧にして管理します。管理の画面だけでは、意図が分かりません。

何のために作ったイベントかを、文書に残します。

一覧に書く項目は、名前、意味、発生する条件、パラメータ、作成日です。

担当者の名前も書いておくと、後から確認できます。

この一覧が、指標の定義としても機能します。

報告で使う数字が、どの記録に基づくかが分かります。

一覧の置き場所は、社内で共有される場所にします。

個人の端末に置くと、担当が変わったときに失われます。

更新の担当も決めます。設定を追加した人が書く形が自然です。

書かないまま設定を増やすと、一覧が実態と合わなくなります。

定期的な確認も行います。半年に1回程度で足ります。

使われていないイベントが見つかれば、記録します。

削除するかどうかは、過去のデータへの影響で判断します。

記録自体は残るため、慎重に判断します。

一覧があれば、この判断もしやすくなります。

レポートで使える形にする

記録した後の作業です。

イベントを設定しても、それだけでは分析に使えない場合があります。パラメータを分析で使うには、登録の作業が必要になります。

この登録を忘れると、記録はされていても画面に出ません。

登録できる数には上限があるため、必要なものに絞ります。

上限に達すると、新しいものを登録できません。

登録の前に、分析で使うかどうかを判断します。

登録した内容は、その時点以降のデータから使えます。

過去に遡って使えるわけではない場合があります。

そのため、設定と同時に登録する運用が望ましくなります。

登録の名前も、規則に沿って付けます。

画面に表示される名前になるため、分かりやすさも必要です。

記録の名前と表示の名前を、対応表で管理します。

使われていない登録は、整理の対象になります。

上限に近づいた場合、不要なものを外す判断が必要です。

外すと、その内容は分析で使えなくなります。

影響を確認してから判断します。

名前を変えたい場合

すでに付けてしまった場合です。

規則を決める前に付けた名前がある場合、扱いを決めます。変更はできないため、選択肢は限られます。

そのまま使い続けるか、新しい名前で計測を始めるかです。

そのまま使う場合は、一覧に意味を書いておきます。

名前が分かりにくくても、意味が記録されていれば運用できます。

新しい名前にする場合は、切り替えの時期を記録します。

いつから名前が変わったかが分かれば、集計で対応できます。

切り替えは、期の区切りに合わせる形が扱いやすくなります。

年度の途中で変えると、期間の集計が複雑になります。

両方を並行して記録する期間を設ける方法もあります。

この期間があれば、数字の整合性を確認できます。

ただし二重に記録されるため、集計では注意が必要です。

切り替えの判断は、影響の範囲を見てから行います。

報告で使っている数字であれば、影響が大きくなります。

使っていない記録であれば、切り替えの負担は小さくなります。

優先順位を付けて、順に整理します。

複数人・複数サイトでそろえる

統一の作業です。

複数の人が設定を追加する場合、規則の共有が必要になります。規則がなければ、人ごとに名前の付け方が違います。

同じ行動に別の名前が付くと、集計が分散します。

共有する内容は、型、単語の一覧、略語の対応表です。

新しく設定する際は、既存の一覧を確認する手順にします。

似た名前がある場合は、既存のものを使う判断をします。

複数のサイトを運用している場合も、規則をそろえます。

同じ行動を同じ名前で記録すれば、横断した比較ができます。

サイトごとに名前が違うと、比較のたびに対応表が必要になります。

外部に設定を委託している場合も、規則を渡します。

委託先が独自の規則で設定すると、後から統一できません。

設定の変更を行う際は、記録を残す手順にします。

誰がいつ何を変えたかが分かる状態にします。

数字が急に変わった場合、設定の変更が原因の場合があります。

記録があれば、原因の切り分けが速くなります。

この記録は、一覧と同じ場所に置きます。

設定した直後の確認も、手順に入れます。意図した名前で届いているかを、実際に操作して確かめます。

動作を確認する仕組みが用意されており、送られた内容をその場で見られます。

名前の綴りやパラメータの値を、この段階で確認します。

集計の画面に反映されるまでには、時間がかかる場合があります。

翌日に確認する形では、誤りに気づくのが遅れます。

確認する項目は、名前、パラメータの名前、値の3つです。

値が空になっている場合は、取得の設定に誤りがあります。

この確認を省くと、数か月分のデータが使えない状態になります。

確認する項目

設定の前後で見ます。

• イベント名を小文字とアンダースコアで統一する規則を決めたか
• 半角40文字未満で、先頭が英字になっているか
• 予約された名前や接頭辞と重複していないか
• 既定で取得される行動と二重になっていないか
• 同じ種類の行動を、パラメータで分ける設計にしたか
• 一覧に名前・意味・条件・パラメータ・作成日を記録したか

この6項目を、設定のたびに確認します。1行目は、最初に一度決めれば足ります。

大文字と小文字が混ざると、別のイベントとして記録されます。

2行目と3行目は、名前を決めた時点で確認します。

条件に反する名前は、記録されない場合があります。

4行目は、数字が二重になる事故を防ぎます。

既定の設定を確認せずに追加すると、この事故が起きます。

5行目は、後から変えられない設計の判断です。

分けすぎると管理が難しくなり、まとめすぎると内訳が見えません。

6行目の記録が、担当交代のときに効きます。

記録がなければ、設定の意図が分かりません。

この6項目を、設定の手順書に入れておきます。

計測を始める前の準備

順序の確認です。

計測の設定は、目的から逆算して決めます。何を知りたいかが決まっていなければ、名前も決まりません。

先に指標を決め、そのために必要な記録を洗い出します。

たとえば資料の申込数を追いたい場合です。

必要な記録は、申込の完了と、どの資料かの情報になります。

この整理をしてから、イベントとパラメータを決めます。

設定できることから考え始めると、使わない記録が増えます。

記録が増えれば、管理の負担も増えます。

目的に合った最小限の設計にします。

あわせて、報告の形も決めておきます。

毎月どの数字を報告するかが決まれば、必要な記録が絞れます。

報告に使わない記録は、優先度を下げます。

この順番で進めれば、設計が目的に沿います。

計測の設定を先に進めると、後から目的に合わないことが分かります。

その時点では、名前を変えられません。

だからこそ、順番が重要になります。

やりがちな失敗

実際に起きている例です。

• 大文字と小文字を混ぜて設定し、同じ行動が2つに分かれて記録される
• 既定で取得される行動を自分でも設定し、数字が二重になる
• 似た行動を別のイベントに分けすぎ、全体の件数を足す作業が必要になる
• パラメータを登録せず、記録はされているのに画面で使えない
• 一覧を作らず、担当が変わったときに設定の意図が分からなくなる

1行目は最も多い失敗です。すべて小文字で統一する規則にします。

2行目は、報告の数字を誤らせます。既定の設定を先に確認します。

3行目は、同じ指標として扱う行動はパラメータで分けます。

4行目は、登録の作業を設定と同時に行えば防げます。

5行目は、引き継ぎで問題になります。一覧を作って共有します。

どれも、設定を始める前に規則を決めておけば防げます。

進める5工程

順番に進めます。

• 一度計測を始めた名前は変更できないため、設定の前に規則を決める
• 名前を変える場合は、切り替えの時期を記録して集計で対応する
• 複数のサイトを運用する場合は、同じ行動を同じ名前にそろえる
• 設定を外部に委託する場合は、規則を先に渡す
• 設定の変更は、誰がいつ何を変えたかを記録に残す

この5工程と5つの注意で、後から困らない設計になります。

3工程目を飛ばすと、名前が人ごとに変わります。

規則は一度決めれば、以降の判断が速くなります。

1工程目と2工程目は、無駄な設定を減らす工程です。

4工程目は、後から変えられない判断になります。

5工程目の一覧が、担当交代のときに効きます。

この5工程を、計測の追加のたびに通します。

慣れれば、30分程度で終わります。

まとめ

GA4のイベント名には制約があります。半角40文字未満、先頭は英字、大文字と小文字は区別される、予約された名前は使えない、といった条件です。使える文字は英数字とアンダースコアに絞られるため、すべて小文字で統一する形が安全になります。

最も重要な前提は、一度計測を始めた名前を後から変更できないことです。名前を変えれば新しいイベントとして記録が始まり、変更の前後は別のものとして扱われます。過去との比較が必要な場合、両方を足す作業が発生します。

そのため、設定を始める前に規則を決めます。命名の型と単語をそろえ、同じ指標として扱う行動はパラメータで分けます。パラメータは1イベントあたり25個までです。名前・意味・条件・作成日を一覧に記録しておけば、担当が変わっても運用が続きます。

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。