GA4のカスタム定義で決める項目一覧｜消せない設定を先に選ぶ

「この項目でも分けて見たいので、カスタムディメンションを足してください」。この依頼を受けるたびに設定を増やしていくと、1年後には枠が埋まり、使っていない設定が並んでいるのに新しく足せない状態になります。しかも、いったん作ったものは削除できません。つまりこの設定は、後から整理できることを前提に運用してはいけない領域です。この記事では、決める順番と枠の管理、値が入らない原因を実務の手順として整理します。

カスタム定義でつまずく場面

つまずき方は3つに分かれます。第1に、枠が埋まって新しく作れない。第2に、作ったのに値が入らない。第3に、何のために作った設定なのか分からなくなる。いずれも、作る前の設計が足りないことから生まれます。

第1の枠の問題は、時間が経つほど深刻になります。担当が何代か替わると、過去に作られた設定の意図が失われます。使われていないように見えても、誰かのレポートで参照されているかもしれない。止める判断ができず、枠だけが減っていきます。

第2の値が入らない問題は、解析の設定と、サイト側から送るデータの2つがかみ合っていないときに起きます。設定の画面では正しく登録されているのに、レポートを開くと値が入っていない行ばかりが並ぶ。原因の切り分けには順番があります。

第3の意図の喪失は、記録がないことから起きます。誰が、いつ、何のために作ったのか。この情報が残っていないと、後任は触れなくなります。触れない設定が増えるほど、解析の環境は硬直化していきます。

カスタム定義とは何か

解析の道具には、あらかじめ用意された切り口があります。国、端末の種類、参照元、頁の題名など。しかし、自社の事業に固有の切り口は用意されていません。自社だけの切り口を追加するのが、カスタム定義の役割です。

追加できるものは2種類あります。ひとつは、分けて見るための項目。会員の種別、資料の名称、問い合わせの種類といった文字で表される情報です。もうひとつは、合計や平均を出すための数値の項目です。

この2つは役割が違います。前者は「どの区分か」を表し、後者は「いくつか」を表します。会員の種別は前者、見積りの金額は後者。混同すると、後から集計の形を変えられなくなります。

なお、自社で送るデータを増やさなくても既に取得されている情報を使える場合があります。頁の中に埋め込まれた情報や、問い合わせの様式の項目など。新しく取り始める前に、既に届いているものがないかを確かめてください。

スコープを最初に決める

追加する項目には、適用される範囲を指定します。ひとつの行動に紐づくのか、その人全体に紐づくのか。この選択は後から変えられないため、最初に決める必要があります。

行動に紐づく範囲は、その都度変わる情報に使います。どの資料をダウンロードしたか、どの種類の問い合わせを送ったか。同じ人が違う行動をすれば、違う値が入ります。

その人全体に紐づく範囲は、変わりにくい属性に使います。会員の種別、契約の区分、業種。最後に送られた値でその人全体が上書きされる仕組みなので、頻繁に変わる情報には向きません。

判断の目安は、「この情報でその人の全ての行動を分けたいか」です。分けたいなら人に紐づく範囲、その行動だけを分けたいなら行動に紐づく範囲。迷ったら行動に紐づく範囲を選ぶのが安全です。枠も多く取れます。

上限があることを前提に設計する

追加できる数には上限があります。無償の版では、その人に紐づく範囲で25個、行動に紐づく範囲で50個です。有償の版ではそれぞれ増え、人に紐づく範囲で50個、行動に紐づく範囲で125個まで使えます。

25個や50個と聞くと十分に思えますが、実際には早く埋まります。部署ごとに要望が出て、施策ごとに1つ足していくと、2年ほどで上限が見えてきます。特に人に紐づく範囲の25個は窮屈です。

範囲	無償の版の上限	有償の版の上限	向いている情報
その人に紐づく	25個	50個	会員の種別、契約の区分
行動に紐づく	50個	125個	資料の名称、問い合わせの種類
数値の項目	別の枠	別の枠	金額、件数、所要の時間

上限に近づいたときの対処は、使っていないものを止めて枠を空けることです。この操作は削除ではなく、新しいデータの収集を止めるだけで、過去のデータには影響しません。止めた後に同じ名前で作り直すこともできます。

削除できないという制約

いったん作った項目は削除できません。これは仕様であり、回避する方法はありません。したがって、試しに作ってみる、という運用は成り立ちません。作る前に、名前と範囲と用途を決めておく必要があります。

削除できない理由は、過去のデータとの整合を保つためと考えられます。その項目で集計されたデータが残っているのに定義が消えると、過去のレポートが読めなくなります。制約には理由があるということです。

実務上の影響は2つです。第1に、名前を慎重に決める必要がある。後から名前を変えられる場合もありますが、混乱の元になります。第2に、要望が来たときに即座に作らない運用が要ります。

運用としては、要望を受け付ける窓口と、作るかどうかを判断する担当を分けます。要望は一度ためて、月に一度まとめて検討する。急いで作らない仕組みそのものが、枠を守ります。

枠を空ける操作の使い方

使わなくなった項目は、設定の画面から一覧を開き、対象の項目に対して枠を空ける操作を行います。この操作をすると、新しいデータの収集が止まり、枠が1つ空きます。過去に集まったデータはそのまま残ります。

操作をする前に確かめることが2つあります。第1に、その項目を参照しているレポートがないか。誰かが作った探索のレポートで使われていると、止めた時点から値が入らなくなります。第2に、サイト側から送るのを止めているか。

2つ目を忘れると、送っているのに受け取らない状態が続きます。無駄な通信が発生するだけでなく、後任が「送っているのに見えない」と混乱します。設定を止めるときは、送る側も止める。この対で作業してください。

止めた項目の記録も残します。いつ、なぜ止めたのか。この記録があると、後から「あの項目はどうなったのか」と問われたときに答えられます。止めた履歴も台帳の一部です。

登録する前のデータは遡れない

見落としやすいのがこの点です。サイト側から値を送り始めていても、解析の側で項目として登録していなければ、その期間のデータは後から参照できません。登録が先、送るのが後、という順序になります。

実務では逆の順序で進みがちです。開発の担当が値を送る実装を先に済ませ、解析の担当が後から登録する。この場合、実装から登録までの期間のデータは失われます。1か月遅れれば、1か月分が見られません。

防ぐには、実装と登録を同じ作業として扱います。「送る実装をする前に登録を済ませる」という順序を手順書に書く。順序が逆になると取り戻せないという事実を、開発の担当にも共有します。

なお、登録した後は遡って集計されるわけではありませんが、登録の時点から先のデータは蓄積されます。気づいた時点で登録すれば、そこから先は使えます。気づいたら即座に登録するのが正しい対処です。

命名の決まりを作る

名前は後から直しにくいので、決まりを先に作ります。決めるのは3点です。第1に、使う文字の種類。第2に、単語の区切り方。第3に、接頭辞で分類を示すかどうかです。

接頭辞は効果が大きい工夫です。「会員に関する項目」「資料に関する項目」といった分類を名前の先頭に付けると、一覧が整理されて見えます。数が増えたときの探しやすさが大きく変わります。

避けるべきは、施策の名前や日付を入れることです。「春の企画用」といった名前は、その企画が終わると意味を失います。何を表す項目なのかで名付ける。施策の情報は値の側に入れます。

• 施策の名前や年月を項目の名前に入れ、後から意味が分からなくなる
• 同じ情報に対して、部署ごとに別の名前の項目を作る
• 略語だけの名前を付け、後任が何の項目か判断できない
• 表示に使う名前と、送るときの名前を無関係にする

最後の項目も重要です。画面に表示される名前と、サイト側から送るときの名前が対応していないと、実装の担当と解析の担当の間で会話が成立しません。両者を対応づけた表を作って共有してください。

値が入らない原因を切り分ける

レポートに値が入らないときは、順に確かめます。第1に、その項目を登録した時期より前のデータを見ていないか。第2に、サイト側から実際に値が送られているか。第3に、送るときの名前が登録した名前と一致しているか。

第2の確認は、解析の道具に用意されている即時の確認の画面で行います。実際にサイトを操作して、その行動に値が付いているかを見る。ここで値が見えなければ、サイト側の実装の問題です。

第3の名前の不一致は、大文字と小文字の違い、区切りの記号の違いで起きます。見た目が似ていても別の名前として扱われるため、目で比べるのではなく、両方を並べて文字単位で確かめます。

値が入っていない行が混ざる場合は、その行動では値を送っていない、ということを意味します。全ての行動で送る必要はないので、混ざっているのが正常な場合もあります。入っていない行の割合が想定と合っているかで判断してください。

何を登録すべきか

法人向けのサイトで有用な項目は、おおむね決まっています。第1に、ダウンロードした資料の名称。どの資料が商談につながるかを見るために使います。第2に、問い合わせの種類。第3に、様式で選ばれた業種や規模です。

第4に、記事の分類。頁の題名だけでは束ねて見られないので、分類を項目として送ると記事群ごとの成果が見えます。第5に、会員の登録の状態。登録前と後で行動がどう変わるかを見られます。

反対に、登録する価値が薄いのは、既に標準で取得されている情報の重複です。端末の種類、参照元、国。これらは標準の切り口で見られるので、枠を使う必要はありません。

判断の基準は、「その項目で分けて見た結果、行動が変わるか」です。分けて見ても打ち手が同じなら、登録する必要はありません。見たいという要望と、必要という判断は別です。

登録の優先順位をつけるなら、成果に近い情報から入れます。資料の名称と問い合わせの種類は、どちらも商談の入口に直結する情報です。入口に近い情報より、成果に近い情報を先に押さえる。記事の分類のような広く効く項目は、その次に足していくと無駄がありません。限られた枠を、成果の説明に使える順に埋めていく発想です。

また、部署をまたぐ項目は早めに決めます。営業と広報が同じ情報を別の名前で欲しがると、枠を二重に使うことになります。複数の部署に関わる情報は、名前と粒度を先に合意しておく。合意の場を持たないまま個別に対応すると、似た名前の項目が並ぶ台帳になり、後から統合するのは事実上できません。

個人を特定できる情報は送らない

絶対に避けるべきなのが、個人を特定できる情報を値として送ることです。氏名、メールの宛先、電話の番号。これらを解析の道具に送るのは、利用の条件に反する行為とされています。

問題になりやすいのは、様式の入力内容をそのまま送ってしまう実装です。「送信された内容を記録しておこう」という善意の実装が、宛先や氏名を含んだまま送る形になっている。実装の確認では、何が送られているかを1項目ずつ見る必要があります。

頁の所在に情報が含まれる場合もあります。問い合わせの完了の頁に入力内容が付いた形で遷移している場合、頁の所在としてそのまま記録されてしまいます。この形は設計から見直す必要があります。

• 氏名、メールの宛先、電話の番号などは値として送らない
• 様式の入力内容をそのまま送る実装は、含まれる項目を1つずつ確かめる
• 頁の所在に個人の情報が含まれていないかも併せて点検する

代わりに使えるのが、自社側で作った識別のための符号です。個人を直接示さない符号を送り、突き合わせは自社の側で行う。解析の道具の中に個人の情報を置かない設計にしておけば、後から問題になりません。

誤って送ってしまった場合は、まず送信を止め、そのうえで該当のデータの扱いを確かめます。すでに蓄積されたデータを個別に消すのは容易ではありません。だからこそ、実装の確認の段階で送られている項目を1つずつ見る作業を省かないでください。確認は数十分で終わりますが、後始末には比べものにならない時間がかかります。

数値の項目の使いどころ

文字で区分を表す項目とは別に、数値を集計するための項目も追加できます。見積りの金額、選ばれた席の数、入力にかかった時間。合計や平均を出したい情報は、こちらで扱います。

よくある間違いは、数値の情報を文字の項目として登録してしまうことです。金額を文字として送ると、合計が出せず、「1万円」「2万円」という区分の一覧としてしか見られません。集計したいのか、分けて見たいのかを先に決めてください。

逆に、数値であっても区分として使いたいものは文字の項目にします。従業員の規模を「50名未満」「50から300名」といった段階で見たいなら、段階の名前を文字として送るほうが扱いやすくなります。そのまま集計するか、段階に区切るかで選び方が変わります。

数値の項目にも枠の上限があり、文字の項目とは別に数えられます。こちらも削除はできないため、作る前の判断は同じように慎重に行います。使う場面が限られる分、本当に合計や平均が必要かを確かめてから作るのが基本です。

探索のレポートで使うときの注意

追加した項目は、標準のレポートだけでなく自由に組み合わせて見る画面でも使えます。ただし、組み合わせによっては値が正しく出ない場合があります。範囲の違う項目を掛け合わせたときに起きやすい現象です。

人に紐づく項目と行動に紐づく項目を並べると、人に紐づく側は最後の値で上書きされているため、過去の行動にも最新の値が付いた形で集計されます。「契約前の行動」を見たいのに契約後の区分が付いている、という状態が起こりえます。

これを避けるには、時点の情報を行動に紐づく項目として別に持つ方法があります。その行動の時点での区分を行動側に記録しておけば、後から上書きされない形で残ります。設計の段階で決めておく必要があります。

また、値の種類が極端に多い項目を使うと、集計の上限を超えて「その他」としてまとめられる場合があります。頁の所在をそのまま項目にすると起きやすい現象です。値の種類が増えすぎない粒度にまとめて送るのが対処になります。

組み合わせを試すときは、少ない期間で先に確かめます。1週間分で意図した集計になるかを見てから、長い期間に広げる。長い期間で作ってから誤りに気づくと、作り直しの手間が大きくなります。共有するレポートを作る前に、自分の手元で一度形を確かめる習慣をつけておくと、誤った数字が社内に回ることを防げます。

作るまでの手順を決める

削除できない設定だからこそ、作るまでの手順を決めておきます。要望を受ける、必要性を判断する、設計を固める、登録する、実装する、確認する。この6段階を飛ばさない形にしておけば、使われない項目は増えません。

2つ目の段階で止まる要望が多く出ます。それは正常な状態です。要望のすべてを設定にしないことが、枠を守る唯一の方法です。止めた要望も台帳に残しておくと、同じ依頼が繰り返されたときに「複数の部署が求めている」という判断材料になります。

台帳を作って管理する

最後に運用の話です。作った項目は台帳で管理します。書くのは、表示される名前、送るときの名前、範囲、用途、依頼した部署、作った日、そして止めたときはその日と理由です。

台帳があると、枠の残りが一目で分かります。新しい要望が来たときに、既にある項目で代替できないかも確かめられます。同じ情報を別の名前で二重に登録する事故も防げます。

棚卸しは半年に一度行います。使われていない項目を洗い出し、依頼した部署に確認したうえで止める。確認せずに止めると、誰かのレポートが壊れます。連絡の相手を台帳に書いておく理由がここにあります。

台帳の置き場所も決めます。解析の担当の手元にあると、実装する開発の担当が見られません。解析、開発、施策の担当の3者が同じものを見られる場所に置いてください。表計算の1枚で足ります。凝った仕組みを作ると更新されなくなるので、簡素な形のほうが続きます。

加えて、台帳には枠の残りを自動で数える欄を作ります。止めていない項目の数を範囲ごとに数え、上限との差を表示する。残りが5個を切ったら棚卸しを始める、といった目安を決めておけば、埋まってから慌てることがなくなります。枠は突然なくなるのではなく、少しずつ減っていくものです。

確認する項目一覧

作る前と作った後に確かめる点をまとめます。この一覧を作業の手順に組み込み、全て埋まってから設定を作る形にしてください。削除できない設定なので、確認は作る前に済ませます。

• その項目で分けて見た結果、打ち手が変わるかを確かめたか
• 標準の切り口で既に見られる情報ではないか
• 範囲（人に紐づくか行動に紐づくか）を決めたか
• 枠の残りを台帳で確認したか
• 命名の決まりに沿った名前になっているか
• 解析の側で登録してから、送る実装を始めたか
• 個人を特定できる情報が含まれていないか
• 台帳に用途と依頼した部署を記録したか

この8点のうち、最初の2点が最も省かれます。要望を受けたらまず作る、という進め方をすると、使われない項目が枠を埋めます。見たいという要望を、必要かどうかで一度濾す工程を必ず入れてください。

まとめ

カスタム定義は、削除できない設定です。枠を空ける操作はありますが名前は残り、上限は人に紐づく範囲で25個、行動に紐づく範囲で50個。したがって、試しに作る運用は成り立ちません。決める順番は、打ち手が変わるかの確認、標準の切り口との重複の確認、範囲の決定、命名、そして登録してから送る実装。登録より前に送っていた分は遡れないので、この順序は必ず守ってください。個人を特定できる情報は送らず、作ったものは台帳で管理して半年ごとに棚卸しする。この運用があれば、数年後も触れる解析の環境が保てます。

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