CRMなどの一連のカスタムプロパティーの内部名には接頭辞を付けよう

【落とし穴1】プロパティの内部名はグループに関わらずグローバル

プロパティはグループ分けことできるものの、内部名をグループごとに自動的に区切ってくれている訳ではありません。例えば会社のプロパティーで

• ラベル：設立日
• 内部名：date
• グループ：「会社情報」に属する

というプロパティーがあるとしましょう。他のグループは次のキャプチャの通りです。

会社情報グループに属していても内部名がグループ毎に区切られている訳ではないため、例えば次のプロパティー

• ラベル：最終コンバージョン日
• 内部名：date
• グループ：「コンバージョン情報」に属する

を作成しようとしても、「date」という内部名が重複するため、プロパティーを作成することができません。

【落とし穴2】内部名は後から変更できない

2つ目の落とし穴として、一度作成したプロパティーは後から内部名を変更できません。恐らく影響範囲が広すぎて、途中で内部名を変更するとシステムの正常な稼動が担保できないのでしょう。

つまり一度プロパティーを作成し、実際にそのプロパティーを使用し始めてしまえば、もう後戻りはできません（データを捨てる覚悟があれば後戻りできますが……）。最初に何も考えず「date」のように汎用的な、意味の広い内部名を作成してしまうと、のちのち作成するプロパティーと内部名が重複し、スムーズにプロパティーを作成できないことが多々でてきます。

【解決策】内部名に接頭辞を付ける

ではどうするかというと、明確にグループ化できる一連のプロパティーはグループ化するだけでなく、内部名に接頭辞を入れるのが有用です。例えば次のキャプチャのように会社のプロパティーに「ウェブサイトパフォーマンス」というグループを作る場合を考えてみましょう。

これらの内部名は全て次のようになっています。

• 00. データ更新日：pfm_update_date
• 01. スコア - 合格：pfm_score_pass
• 02. スコア - 改善：pfm_score_improve
• 03. スコア - エラー：pfm_score_error
• 04. タイトルタグ：pfm_title_tag
• 05. メタディスクリプション：pfm_meta_descpription
• 06. メタキーワード：pfm_meta_keyword

このように「pfm_」という接頭辞を付けることで、今後会社のプロパティーが増えたとしても、他のグループのプロパティーと重複することはほぼないでしょう。

それだけでなく、統一された接頭辞が付いている状態はプロパティーの検索にも役立ちます。いちいち「ウェブサイトパフォーマンス」グループをクリックしたり指定してプロパティーを絞るのが面倒くさい場合、検索ボックスに「pfm_」と入力するだけで、この接頭辞を含むプロパティーを即座に抽出することができます。

注意点・代替案・その他

注意点としては、接頭辞を付けて作成したプロパティーを後から他のグループに移動すると、接頭辞とグループの対応があべこべになってしまうことです。そのため、接頭辞を付けるプロパティーは他のグループに移動することは想定しないプロパティーに絞るとよいでしょう。

また、接頭辞まで行かずとも、なるべく内部名を長くして重複を避ける方法もあります。例えば記事中に2つのプロパティーを例として出しましたが、これらの内部名は次のように改善することができます。

• ラベル：最終コンバージョン日
  • 内部名：date → last_conversioned_date
  • グループ：「コンバージョン情報」に属する

• ラベル：設立日
  • 内部名：date → establishment_date
  • グループ：「会社情報」に属する

将来的にグループを移動しそうで接頭辞を付けるまではいかないプロパティーは、ぜひこのように内部名をできるだけラベルと一致させましょう。

最後に、プロパティーのラベルの連番について触れておきます。接頭辞を付けている例として紹介したプロパティーはラベルの頭に「01.」などの連番がついていますが、これは全てのケースに推奨する方法ではありません。

• プロパティーの追加や削除があったりすると、連番を振り直す手間が発生する
• そもそもこういった名前と値が対応するようなデータは、順番に依存すべきではない

の2点が主な理由です。

今回のケースでは外部のツールからAPI経由でHubSpotにデータを投入するフローとしており、その外部ツールの表示順と合わせるためにこのような管理の仕方をしています。ご参考までにm(_ _)m