HubSpotのプロパティとセグメント設計：データが崩れない運用ルール

「HubSpotに入っているデータが、どこまで正しいのか分からない」。運用を始めてしばらくたつと、こうした声がよく聞かれます。

配信リストをつくろうとしたら、対象のはずの人が入っていない。前回のイベントの回答が、いつの間にか今回の回答で上書きされている。一括編集をしたら、ほかの担当者が付けていた値まで消えてしまった。どれも、ツールの不具合ではなく、プロパティの設計と、日々の操作のルールが決まっていないことから起きています。

この記事では、HubSpotのプロパティとセグメント（リスト）の設計を中心に、データが崩れない運用ルールを解説します。私たちが事務局として運用を担ったインキュベーションプログラムでの具体例も交えながら、実際に「ここで崩れるのか」と気づいたポイントを「現場のリアル」としてまとめました。

こんな方に向けた記事です。

• HubSpotでイベントや問い合わせのデータを管理しているが、配信リストの中身に自信が持てない
• 1つのポータルで、性質の違う複数のイベントやサービスのコンタクトを扱っている
• プロパティを追加するたびに、命名や使い分けが場当たりになっている
• 一括編集やインポートで、既存の値を消してしまった経験がある

なお、画面の表記や仕様は2026年10月時点のHubSpot日本語版のヘルプをもとにしています。仕様は更新されることがあるため、細かな操作は最新の公式ヘルプもあわせて確認してください。

データが崩れるのは「設計」と「操作」の両方から

まず、HubSpotのデータが崩れていくパターンを整理しておきます。原因は大きく、設計の段階で決めていなかったことと、日々の操作で起きる事故の2つに分かれます。

1. 設計の問題：同じ意味の項目が複数ある、種類（1行テキストか選択肢か）が用途に合っていない、内部名に規則がない、誰が値を入れるのかが決まっていない
2. 操作の問題：一括編集やインポートで既存の値を上書きする、前回のイベント用の項目を使い回して回答が上書きされる、フォーム以外の経路で入ったコンタクトに値が付かない

設計の問題は、一度決めてしまうと後から直すのが大変です。操作の問題は、ルールさえ決めておけば防げるものがほとんどです。この記事では、前半で設計、後半で操作と点検のルールを扱います。

プロパティは「4つのこと」を決めてから作る

HubSpotでは、コンタクトや会社に自由にプロパティ（項目）を追加できます。手軽に作れるぶん、必要になるたびに担当者がそれぞれ追加していくと、似たような項目が増え、どれが正しいのか分からなくなります。

プロパティを作る前に、少なくとも次の4つを決めておきましょう。

• 内部名：システムの中で使われる名前。インポートや連携で参照される
• 種類（フィールドタイプ）：1行テキスト、ドロップダウン選択、複数チェックボックス、日付など
• 誰が入れるか：フォームの回答、事務局の手入力、インポート、ワークフローなど
• 何に使うか：どのセグメントや配信、レポートの条件になるのか

私たちが支援したプログラムでは、こうした項目を次のような設計表にまとめ、関係者で合意してから作成していました。

この表があるだけで、「この項目はもうあるのか」「誰の担当なのか」を探す手間がなくなります。新しく項目を追加するときも、表に1行足すところから始めるルールにしておくと、場当たりの追加を防げます。

選択肢で絞り込む項目は、テキストにしない

セグメントや配信の条件に使う項目は、1行テキストではなく、ドロップダウン選択や複数チェックボックスにします。テキストだと「スタートアップ」「startup」「SU」のように表記がばらつき、条件に引っかからない人が出てくるからです。

1人に複数の値が当てはまる項目は、複数チェックボックスにします。たとえば、ある人が2つのイベントの両方に関わっている、審査員でありながら会員企業の担当者でもある、といったケースです。1つしか選べない種類にしておくと、どちらか一方を選んだ時点で、もう一方の情報が失われてしまいます。

「区分×種別」でセグメントを組む

プロパティが整ったら、セグメント（以前の名称は「リスト」）をつくります。HubSpotのセグメントには、条件に合う人が自動で出入りする動的セグメント（アクティブ）と、保存した時点のメンバーで固定される静的セグメントがあります。配信や点検に使うものは、基本的に動的セグメントにしておくと、メンバーを手で更新する手間がかかりません。

私たちが支援したプログラムでは、同じポータルで性質の違う複数のイベントを扱っていました。そこで、コンタクトに「イベント区分」という複数チェックボックスのプロパティを作り、両方のイベントに関わる人には両方の区分を付けました。あわせて、「参加者種別」（スタートアップ、会員企業、審査員、関係者など）も複数チェックボックスにし、この2つを掛け合わせてセグメントをつくっていました。

セグメントは「目的」で分けてつくる

セグメントは、配信の対象をまとめるためだけのものではありません。目的ごとに分けて用意しておくと、運用が安定します。

配信用のセグメントは、条件を「区分×種別」の組み合わせに統一しておくと、新しい配信を準備するときも同じ考え方で作れます。名前も「区分_種別_用途」のようにそろえておくと、一覧から探しやすくなります。

イベントごとのプロパティは、流用せずに新しく作る

イベントを繰り返し開催していると、「前回の『参加希望』の項目を、今回のフォームでもそのまま使えばいい」と考えたくなります。項目が増えないので、すっきりして見えます。

ところが、同じプロパティを使い回すと、前回の回答が今回の回答で上書きされます。前回「参加」と答えた人が、今回「不参加」と答えると、コンタクトに残るのは「不参加」だけです。前回の出欠を振り返ろうとしても、もうデータは残っていません。

私たちが支援したプログラムでは、イベントごとの回答を入れるプロパティは、別のイベントのものを流用せず、表示ラベルに「【イベント名】」のような接頭辞を付けて新規に作成していました。内部名も同じように、イベントの略称から始めます。

フォームでは、接頭辞なしのラベルを見せる

接頭辞を付けると、フォームに表示される項目名が「【イベントA】参加希望」になってしまうのでは、と心配になるかもしれません。HubSpotのフォームでは、フォーム上に表示するラベルを、プロパティの名前とは別に書き換えられます。回答する人には「参加希望」とだけ見せ、管理画面では「【イベントA】参加希望」として区別できます。

一括編集とインポートで、既存の値を消さない

複数のコンタクトにまとめて区分や種別を付けるときは、一括編集やインポートを使います。便利な機能ですが、データが一度に大量に崩れるのも、たいていこの操作のときです。

一括編集は「現在の値に追加」を選ぶ

複数チェックボックスのプロパティを一括編集すると、値の付け方を選ぶ画面が出ます。HubSpotのヘルプでは、次の3つが説明されています。

• 現在の値に追加：今付いている値を残したまま、選んだ値を足す
• 現在の値を置換：今付いている値を消し、選んだ値だけにする
• 現在の値から削除：選んだ値だけを取り除く

区分のように積み重ねていく値を付けるときは、必ず「現在の値に追加」を選びます。「置換」を選ぶと、ほかのイベントの区分がすでに付いていた人から、その区分が消えてしまいます。

インポートでも、上書きの挙動を確認する

インポートで既存のコンタクトを更新するときも、ファイルに入れた値で既存の値が上書きされる場合があります。複数チェックボックスの値をインポートで足したいときは、取り込み時の設定で既存の値の扱いを確認し、本番の前に少数のテスト用ファイルで結果を確かめておくと安心です。設定画面の項目は更新されることがあるため、最新の画面は公式ヘルプで確認してください。

積み重ねたい値は、フォームの非表示項目で付けない

フォームには、回答者に見せずに値を送る「非表示の項目」を設定できます。「このフォームから送信した人には、自動で『イベントA』の区分を付けよう」と考えるのは自然な発想です。

ただ、フォームの送信で複数チェックボックスの値が、既存の値に足されるのではなく置き換わる場合がある、という報告があります。そうなると、別のイベントの区分がすでに付いていた人から、その区分が消えてしまいます。

私たちが支援したプログラムでは、この点を考えて、区分のように「積み重ねたい値」はフォームの非表示項目で付けず、インポートや一括編集の「追加」で付けるようにしていました。フォームの挙動は設定や仕様の更新で変わることもあるため、採用する前にテスト用のコンタクトで確かめるのが確実です。

フォーム以外から入ったコンタクトを拾う

HubSpotのコンタクトは、フォームからだけ作られるわけではありません。共有受信トレイに届いたメールやチャットなど、フォーム以外の経路でも自動的に作成されます。

こうしてフォーム以外から作成されたコンタクトには、区分も種別も付いていません。配信用のセグメントには入らず、一覧で絞り込んでも出てこない「見えないコンタクト」になります。問い合わせのメールを送ってきた大切な関係者が、案内の配信から漏れてしまうこともあります。

私たちが支援したプログラムでは、前に紹介した「区分未設定」の確認用セグメントで、こうしたコンタクトを定期的に拾っていました。中身を見て、どのイベントの関係者なのかを判断し、一括編集の「追加」で区分を付けます。関係のないコンタクトであれば、その判断も記録しておきます。

一覧ビューにも、区分の条件を足しておく

担当者が日々開くコンタクトの一覧（保存済みビュー）にも、区分の条件を足しておくと、見間違いを防げます。複数のイベントを同じポータルで扱っていると、絞り込みをしていない一覧では、別のイベントの関係者が混ざって表示されます。

週次の点検と、運用ルールの残し方

ここまでのルールは、決めただけでは続きません。点検の時間を決め、ルールを文書にして残しておくことで、担当者が替わっても同じ品質を保てます。

週次で点検したいこと

• 確認用のセグメント（回答済みなのに区分なし、区分未設定）が0人になっているか
• 新しく作られたプロパティが、設計表に載っているか
• 内部名が、決めた命名規則に沿っているか
• 一括編集やインポートを行った日と内容、選んだ操作（追加・置換など）が記録されているか
• 担当者が使う保存済みビューの条件が、今のイベントに合っているか

運用ルール文書に残しておくこと

• プロパティの設計表（項目名、内部名、種類、誰が入れるか、何に使うか）
• 内部名と表示ラベルの命名規則
• セグメントの一覧と、それぞれの目的
• 一括編集・インポートの手順（「1件で試す」「現在の値に追加」を含む）
• 自動化してよい値と、手で付ける値の区別

まとめ

• HubSpotのデータが崩れる原因は、設計で決めていなかったことと、日々の操作での上書き・付け漏れの2つ
• プロパティは、内部名・種類・誰が入れるか・何に使うかを決めてから作る。内部名は作成後に変えられないので、命名規則を先に決める
• 1人に複数当てはまる「区分」や「種別」は複数チェックボックスにし、「区分×種別」でセグメントを組む
• セグメントは配信用だけでなく、「0人であるべき」確認用もつくり、週次で点検する
• 回ごとに変わる回答は、別のイベントの項目を流用せず、接頭辞を付けて新規に作る
• 一括編集は「現在の値に追加」を選び、1件で試してから全件に行う
• 積み重ねたい値はフォームの非表示項目で付けず、人が意図して追加する。フォーム以外から入ったコンタクトは、確認用セグメントで拾う

DADAでは、スタートアップイベントやプログラムの事務局運営の経験をもとに、HubSpotのプロパティ設計やセグメントの組み立て、配信と点検の運用ルールづくりをご支援しています。データの中身に自信が持てない、複数のイベントやサービスを1つのポータルでうまく扱えていない、といったお悩みがあれば、HubSpotの導入・活用支援のページからお気軽にご相談ください。