「このコンタクト、どのキャンペーン経由なのか一覧で出せますか」
営業やマーケティングの担当者から、こんな依頼を受けたことはないでしょうか。
「代理店経由で接点を持ったコンタクトだけリストにしたい」 「複数のキャンペーンに接触している人を抽出したい」 「スプレッドシートに書き出して、キャンペーンごとの内訳を見たい」
レコードの詳細画面を開けば、紐づいているキャンペーンは一覧で表示されています。データはHubSpotの中にある。それなら難しくないはずだ、と思って作業を始めます。
ところが、ワークフローで関連レコードの値を持ってこようとすると、選択肢が「最初に関連付けたレコード」と「最も最近関連付けたレコード」しかありません。3件紐づいていても、取得できるのは1件だけです。
リストの絞り込み条件を見ても、関連レコードのプロパティは出てきません。レポートビルダーでも同じです。
結果として、こういう対応になりがちです。
- 依頼者に「レコードを1件ずつ開いて確認してください」と伝える
- 書き出したデータが実態の一部しか反映していないまま渡してしまう
- 手作業で突き合わせた一覧を、定期的に作り続ける
これは設定ミスではありません。HubSpotの仕様上の制約です。ただし、回避する方法があります。
なぜ「最初」か「直近」しか取れないのか
HubSpotは関連付けを順序でしか識別していません。「1番目」「最後」という位置は指定できますが、「2番目」や「特定の条件に合うもの」を指す手段が標準では用意されていません。
そして標準のリストやレポートは、基本的に1つのレコードを1行として扱う設計になっています。1件のコンタクトに3件のキャンペーンが紐づいているという「1対多」の関係を、1行の中に展開する仕組みがありません。
つまり課題の本質は、データが無いことではなく、1対多の情報を1行で扱える形に変換する手段が無いことです。
コードを書く前に:標準機能で足りるかの見極め
先に確認しておきたいことがあります。やりたいことによっては、標準機能で解決します。 ここを飛ばしてコードを書くと、不要な保守対象を抱えることになります。
ケース1:件数や合計だけが必要 → ロールアップ計算プロパティ
「紐づく契約の件数」「関連する商談の金額合計」のように、数を数えるか合計するだけなら、計算プロパティのロールアップ機能で対応できます。コードは不要です。
ケース2:特定の1件を取りたい → 関連付けラベル
「主キャンペーンの名前だけ欲しい」「初回接触のものだけ欲しい」といった場合、関連付けにラベルを付けるのが有効です。
先に触れたとおり、HubSpotは関連付けを順序でしか識別できません。逆に言えば、ラベルという別の識別軸を用意すれば、順序に依存せず狙った1件を指定できるようになります。「主キャンペーン」「初回接触」といったラベルを運用ルールとして定義するほうが、コードよりも保守が軽く済みます。
ケース3:選択肢が固定的 → 複数チェックボックスへの追加
集約したい値の種類が限られていて、今後増えないなら、複数のチェックボックス型プロパティを使う方法があります。ワークフローの「レコードを編集」には、複数チェックボックスに対して既存の値を消さずに追加する設定があるためです。
ただし選択肢を事前に登録しておく必要があるため、外部システム連携などで値が増え続ける場合には向きません。
コードが必要になるのは
上記に当てはまらない場合、つまり
- 紐づく全件の情報が必要
- 値の種類が事前に確定していない(外部連携で増えるなど)
- 関連付けの解除にも追従させたい
このときに、ワークフローのカスタムコードを使います。以降がその方法です。
集約プロパティを持たせると、扱えるようになる
考え方はシンプルです。関連レコードの情報を、親レコードのプロパティ1つにまとめて保持しておく。
コンタクトに「累積キャンペーン名」というプロパティを用意し、紐づく全キャンペーン名を区切り文字でつないで格納します。
テキストのプロパティになった時点で、HubSpotの標準機能がそのまま使えるようになります。
| できること |
具体例 |
| リストで絞り込む |
「累積キャンペーン名に『代理店』を含む」でコンタクトを抽出レポートの軸にする |
| レポートの軸にする |
接触キャンペーンの組み合わせパターン別に件数を集計 |
| 書き出す |
スプレッドシートやCSVに、紐づく全件を含めて出力 |
| 一覧で確認する |
ビューの列に追加し、レコードを開かずに把握 |
管理者側の変化としては、「その依頼はHubSpotの仕様上できません」と答える場面が減るのが実際のところだと思います。一度作れば、以降の類似依頼は標準機能の範囲で対応できます。
実装の前に決める、3つの設計方針
手順に入る前にここを押さえておくと、後で作り直しになりません。運用してみると効いてくる部分です。
方針1:「追記」ではなく「作り直し」にする
いちばん自然に見えて、いちばん壊れやすいのが追記型です。関連付けが増えたときに、既存の値へ名前を足していく方式です。2つの理由で必ず実態とズレます。
- 関連付けを解除しても値が残る。 しかも間違っていることに気づけません
- 並び順が追加順になる。 同じ組み合わせでも文字列が一致せず、突合や比較に使えません
そこで、処理が走るたびに関連レコードを全件読み直し、文字列をゼロから作り直す方式にします。何回実行しても同じ結果になるため、ズレが原理的に発生しません。追加にも解除にも自動で追従します。
処理量は増えますが、後述のとおり実務上のコストはわずかです。正しさが自動で保たれる設計を選ぶほうが、長期的には安く済みます。
方針2:区切り文字にカンマを使わない
CSVやスプレッドシートに書き出したときに列が割れます。値そのものにカンマが含まれている場合、元の区切りが復元できなくなります。|(縦棒)や ;(セミコロン)を使ってください。
方針3:値が取れなかったときは書き込まない
APIの一時的なエラーなどで取得件数がゼロになったとき、そのまま書き込むと蓄積していた値を空で上書きしてしまいます。「取得ゼロなら何もしない」という分岐を1つ挟んでおいてください。
設定手順
前提条件
- Data Hub Professional以上(旧Operations Hub)が必要です。ワークフローの「カスタムコード」アクションを使います
- コードは40行程度です。ゼロから書く必要はありませんが、冒頭の設定値が何を指しているかは理解しておく必要があります