「製品の試用環境にログインした回数を、営業が見られるようにしてほしい」——SaaSやサービス型のビジネスでCRMを整備していくと、必ずこの種の要望が出てきます。展示会のブースに立ち寄った、見積シミュレーターを操作した、保守ポータルでマニュアルをダウンロードした。どれも商談の温度を示す行動であり、営業が知りたい情報です。
この要望を受けた担当者の多くは、まずコンタクトにカスタムプロパティを追加しようとします。「最終ログイン日」「ログイン回数」という項目を作り、外部システムから書き込む構成です。これは半年は動きます。そして半年後、「先月何回ログインしたか」「どの機能を使った人が解約したか」を聞かれた時点で行き詰まります。プロパティは現在の状態しか持てず、過去の一回一回を残していないためです。
本記事では、HubSpotのカスタムイベントについて、作り方の種類、プロパティ設計、送信上限、プラン要件、そしてカスタムプロパティではなくイベントで持つべき判断基準を整理します。本記事の数値はすべて2026年10月23日の取得時点のものです。
目次
カスタムイベントは、自社固有の行動を「いつ起きたか」という単位で記録する仕組みです。1回ごとの記録を「イベント発生（event occurrence）」と呼び、同じイベントが何度でも積み上がります。
カスタムイベントは、特定の時点に何が起きたかを捉えるもので、ユーザーの活動や行動の追跡によく使われます。カートへの商品追加、サイトのページ閲覧、アプリへのログインが典型例です。
この区別を曖昧にしたままデータモデルを決めると、後から作り直すことになります。設計の初期に言語化して、関係者で合意しておく価値のある論点です。
レコードオブジェクトがプロセスや関係の現在の状態を表すのに対し、イベント発生は時間軸上の1点を表します。この区別は、過去の活動の分析、時間経過に伴う変化の追跡、傾向の特定にとって決定的です。
実務の言い方に直すと、プロパティは「今どうなっているか」、イベントは「いつ何が起きたか」を持ちます。営業が見る画面では両者の違いが表に出ませんが、「直近90日で3回以上」のような条件を書けるのはイベントだけです。
カスタムイベントのプラン要件は、1つの数字では表せません。作る・送る・絞り込む・集計するのそれぞれで、必要なサブスクリプションが違うためです。ここを「Enterpriseが必要」と一括りにすると、見積が過大になったり、逆に契約後に使えない機能が出てきたりします。
注目すべきは、イベントを「作って送る」のはProfessional以上でできるのに対し、セグメント（旧リスト）で「絞り込む」にはEnterpriseが要る点です。行動データを溜めるだけなら上位プランは不要で、それをセグメンテーションに使う段階でEnterpriseの判断が必要になります。
| やること | 必要なサブスクリプション | 出典 |
|---|---|---|
| カスタムイベントの定義・送信・分析 | Marketing／Sales／Service／Data／Content Hub／Smart CRM／Revenue Hub の Professional、Enterprise | カスタムイベントの作成 |
| Webhookでイベントを作る | Data Hub Professional、Enterprise のみ | カスタムイベントの作成 |
| セグメント・フィルターでカスタムイベントを条件にする | Enterprise | フィルター条件の決め方 |
| プロパティ変更イベントを作る | Marketing／Sales／Service／Data／Content Hub／Revenue Hub の Enterprise | プロパティ変更イベントの作成 |
| イベントを条件にしたリードスコアを作る | Marketing Hub、Sales Hub の Professional、Enterprise | リードスコアの構築 |
| 旧イベントツールの分析 | Marketing Hub Enterprise | レガシーイベントの分析と管理 |
私たちが見積の前提を作るときは、この表の3行目を最初に確認します。「行動データで配信対象を切りたい」という要望は事実上Enterpriseの要件であり、ここを見落とすと、データは溜まっているのに使えないという状態になります。
HubSpotのイベント機能には新旧2つの系統があり、既存ポータルを引き継いだ場合は旧ツールの資産が残っていることがあります。移行の可否を先に確認しておかないと、分析の断絶が起きます。
旧カスタムイベントツールで作成されたイベントは、2025年8月1日以降は機能しません。2025年8月1日からは、レガシーの行動イベントを使っている顧客は、新しいイベント定義の作成も新しい完了データの送信もできません。レガシーイベントは新ツールへ移行できず、新ツールで作り直すことが推奨されています。旧ツールでは複数キャンペーンを追跡するのにイベントを複数作る必要があったのに対し、新しいカスタムイベントでは1つのイベントで複数キャンペーンを追跡できるためです。
作り方は複数あり、どれを選ぶかで運用の担い手が変わります。マーケティング部門が自走できる方式と、開発リソースが必要な方式が混在しているので、体制と合わせて選ぶ必要があります。
イベントの作成は2つの部分からなります。カスタムイベントプロパティを含めてHubSpot側でイベントを定義することと、イベントを発火させるJavaScriptのコードスニペットまたはAPI呼び出しを用意することです。この2段階を押さえておくと、どこで詰まっているのかの切り分けが早くなります。
Webサイト上の行動については、コードを書かずに定義できる経路が用意されています。マーケティング部門だけで完結できるので、まずここで足りるかを確認するのが実務の順序です。
「クリックされた要素（Clicked element）」と「訪問されたURL（Visited URL）」の2種類は、コードなしで作成できます。クリック要素イベントは、匿名の訪問者またはHubSpotのコンタクトがサイト上の特定の要素をクリックしたときを追跡します。無料デモのCTAやPDFのダウンロードリンクのクリックが典型例です。
制約は2つあります。第一に、クリック要素イベントは、HubSpotトラッキングコードが設置されているページでのみ作成・追跡できます。トラッキングコードの設置が前提になるので、自社の製品アプリ側にコードを入れていない場合はこの方式は使えません。第二に、1つの訪問URLイベントで追跡できるのは最大30件の異なるURL、1つのクリック要素イベントで追跡できるのは最大30件のクリック要素です。サイト全体のCTAを1イベントに詰め込む設計は、ここで頭打ちになります。
製品アプリやモバイルアプリ、基幹システムからの行動を記録する場合は、APIが基本になります。定義と送信でエンドポイントが分かれているので、権限とスコープの設計も2段構えになります。
定義は events/v3/event-definitions へのPOSTで行います。リクエストボディには、ラベル、内部名、CRMオブジェクトとの関連付け、カスタムプロパティを含めます。送信は /events/v3/send へのPOSTで、イベントの完全修飾名（fullyQualifiedName）を eventName に指定します。この値は pe{HubID}_{name} の形式になります。
レコードとの紐づけ方には優先順位があります。高いほうから順に、customMatchingId プロパティ、objectId（レコードID。推奨）、email（コンタクトのみ）、utk（コンタクトのユーザートークン。コンタクトのみ）です。複数の識別子を含めた場合、この順でマッチするレコードが探されます。私たちが設計する際は、メールアドレスではなく customMatchingId か objectId を使うようにしています。メールアドレスは変更され、重複もするためです。
過去のオフライン行動を取り込む場合と、HubSpot内の条件をトリガーにする場合で、残る2つの方式を使い分けます。どちらも向き不向きがはっきりしています。
スプレッドシートのインポートは、対面イベントの参加実績、連携していないアプリからのタイムスタンプ付きデータ、ベンダーから受け取った単発のリードデータなどの取り込みに使います。インポートできるのは、既に発生したイベントに限られます。インポートファイルにはコンタクトのメールアドレスと「Occurred at」のタイムスタンプを含める必要があり、インポート経由で作成したイベントは、現時点ではコンタクトにしか関連付けられません。
Webhookによる作成は、Data Hub ProfessionalおよびEnterpriseのみで利用でき、Webhookを発火させる条件と送信するデータをカスタマイズできます。外部からHubSpotに送るのではなく、HubSpot内の変化を起点にイベント化したい場合に向いています。
イベントプロパティは、1回の発生について「どういう発生だったか」を保存する場所です。CRMのプロパティとは別の場所に保存され、アカウント設定のプロパティ画面からは編集できません。設計の自由度が高い一方、後から変えられない項目があります。
イベントプロパティは他のCRMプロパティとは別に保存され、イベント固有です。つまり、コンタクトのプロパティ一覧には現れません。CRMの命名規則とは別に、イベント側の命名規則を決めておく必要があります。
不可逆な項目を先に洗い出しておくのが、データモデル設計の基本です。ここを現場との擦り合わせなしに決めると、後戻りのコストが高くつきます。
押さえるべき仕様は次の3点です。第一に、イベントの内部名（name）は最大50文字で、英字で始まり、小文字・数字・アンダースコアのみを含むことができ、一度定義すると変更できません。第二に、人が読むラベル（label）は最大100文字まで設定でき、長いラベルはHubSpotのUIの一部で途切れる場合があります。第三に、イベントデータを関連付けるオブジェクト（primaryObject）は、CONTACT（既定値）、COMPANY、DEAL、TICKET、カスタムオブジェクト名、または NO_OBJECT のいずれかで、イベント定義の作成後は変更できません。
この3つ目が設計上もっとも重いものです。「とりあえずコンタクトに紐づけておく」と決めた後で、会社単位の行動として集計したくなっても、同じイベントは作り直すことになります。製品の利用実績のように、本質的に契約（会社）単位の行動であれば、最初から COMPANY を選ぶ判断が必要です。
イベントプロパティには複数のフィールドタイプが用意されています。型の選択は、後からレポートで何ができるかを決めます。文字列で持ってしまうと集計も範囲指定もできません。
用意されているのは、文字列、数値、タイムスタンプ、日付、ブール値、列挙（enumeration）の各タイプです。タイムスタンプ型はエポックミリ秒またはISO8601形式で送る必要があります。列挙型は単一選択と複数選択が選べ、複数値を有効にするトグルがあります。
列挙型には運用上の注意が2つあります。第一に、データを送る前にラベルと値を設定しておく必要があり、設定しないまま一覧にない値を送ると、そのデータは使えません。第二に、複数選択の列挙型プロパティはインポートできません。APIで送る場合はセミコロン区切りで複数値を渡します。自由記述に近い値を列挙型にすると、選択肢の追加漏れでデータが欠落するので、揺れる可能性のある値は文字列型にしておくほうが安全です。
イベントを作成すると、既定のイベントプロパティが自動で付与されます。これを残すか外すかは、設計の早い段階で決める項目です。
既定のプロパティには、hs_page_url、hs_page_title、hs_referrer、hs_browser、hs_device_type、hs_country、hs_city、hs_region、hs_language、hs_user_agent、hs_utm_source、hs_utm_medium、hs_utm_campaign、hs_utm_content、hs_utm_term、hs_element_id、hs_element_class、hs_element_text、hs_link_href、hs_operating_system などがあります。API側では includeDefaultProperties を false にすると、既定プロパティが追加されず、自分で定義したカスタムプロパティだけが使えます。
Webサイト上の行動であれば既定プロパティは有用ですが、基幹システムから送るサーバーサイドのイベントでは、ブラウザやUTMの項目は常に空になります。空の項目が並ぶと、レポートを作る現場が「データが取れていない」と誤解します。私たちはサーバーサイドのイベントでは既定プロパティを外し、必要な項目だけを自分で定義する方針にしています。
上限は、設計が成立するかどうかを分ける前提条件です。とくにアカウント全体にかかる上限は、全社でイベント設計を進める前に共有しておかないと、部門ごとに作ったイベントで枠を食い潰します。
イベントデータを送信する際、次の上限のいずれかを超えるとリクエストが失敗します。いずれも2026年10月23日取得時点の値で、改定されることがあります。
1回の送信に含められる情報量には、件数と文字数の両方で上限があります。超えたときの挙動が送信方式によって違う点が、トラブルシュートで効いてきます。
| 対象 | 上限 |
|---|---|
| プロパティのラベルと内部名 | 50文字 |
| URLプロパティ・リファラープロパティの値 | 1,024文字 |
| それ以外のプロパティの値 | 256文字 |
| 1回のイベント発生に含められるプロパティ数 | 50件 |
これらの上限をHTTPのAPIリクエストで超えた場合はリクエストが失敗し、JavaScriptのAPIリクエストで超えた場合は、HubSpotがプロパティ名の値を許容長に切り詰めるか、1回のイベント発生につき50件のプロパティのみを更新します。つまり、JavaScript経由ではエラーにならず、黙ってデータが欠けます。サイト側のイベントで値が入らない事象の多くは、この挙動です。
内部名の重複にも注意が必要です。小文字化した後に同じ内部名になるプロパティは重複とみなされ、どちらか一方だけが使われます。その際、HubSpotは辞書順の昇順でソートし、最初の50件のうち最後に見たプロパティを採用します。大文字と小文字だけが違う命名は避けてください。
アカウント単位の上限は、全社でのイベント設計のガードレールになります。部門ごとに自由にイベントを作らせる運用では、ここに到達してから気づくことになります。
アカウントごとのユニークなイベント定義数の上限は500、1か月あたりのイベント発生数の上限は30 million（3千万回）です。カスタムイベント発生の送信エンドポイントは最大1250 requests per secondをサポートし、バッチエンドポイントは500件のバッチをサポートします。
月次の発生数は、消費の見え方を押さえておく必要があります。イベント管理のMonitorタブにある「This month vs last month」のチャートで使用済みのイベント完了数を確認でき、「All custom events」のテーブルで全カスタムイベントの内訳を見られます。配信エラーのページでは、エラーを伴って配信されたイベントの詳細も確認できます。ここを月次でレビューする担当者を決めておくことをおすすめします。
保持期間は、統制部門と法務部門が必ず確認する項目です。結論から書くと、ここは公式ドキュメントで確認できませんでした。
カスタムイベントの発生データが何日間・何年間保持されるかについて、HubSpot公式ナレッジベースおよび開発者ドキュメントに記載は確認できませんでした。無期限であることを示す記述も、期限があることを示す記述も見つかっていません。社内の保持方針との整合を求められる場合は、HubSpotのサポートまたは担当パートナー経由で書面での回答を取得してください。
関連して、コンタクトそのものの削除については設定が用意されています。定義した期間を超えて非アクティブなコンタクトを自動削除でき、削除後90日以内であればごみ箱から復元でき、その後は完全に削除されます。この設定を有効にする前に、レポートと分析への影響を評価することが推奨されています。イベントはコンタクトに紐づくので、コンタクトを消す運用はイベントの分析可能性にも影響します。
イベントを溜める目的は、溜めること自体ではありません。溜めた後にどこで使えるかを先に確認しておかないと、使えない形で設計してしまいます。
イベント発生はカスタムイベントツールから分析でき、カスタムレポートビルダーとアトリビューションレポートでも利用できます。コンタクトのタイムライン上にも発生が表示されます。
レポート側には、設計に直結する制約が1つあります。これを知らずにイベントを細かく分けると、レポートが作れなくなります。
カスタムレポートビルダーで使えるのは1レポートにつき1つのカスタムイベントのみで、複数のイベントのプロパティを含めようとすると、既にレポートに入れたイベントのフィールドがリセットされます。「試用開始」と「試用中のログイン」を別々のイベントとして定義すると、この2つを1枚のレポートで突き合わせられません。段階をイベントプロパティの列挙値として持たせ、1つのイベントにまとめる設計のほうが、レポートの自由度は高くなります。
分析画面で見られる指標は、発生回数（Occurrences）と、そのイベントが置かれたページへのユニーク訪問者数（Unique visitors）です。イベント発生に紐づく訪問者が、すべてCRMのコンタクトであるとは限りません。匿名の訪問者が後からコンタクトに変換された場合、HubSpotは遡ってイベントデータをそのコンタクトのタイムラインに追加します。匿名時点の行動が後から見えるようになるのは、BtoBの長期検討プロセスでは実用的な挙動です。
セグメント（旧リスト）でカスタムイベントを条件にできるかどうかは、プランで分かれます。ここは本記事でもっとも見落とされやすい要件です。
カスタムイベントに基づいてフィルターするには、Enterpriseサブスクリプションが必要です。完了したカスタムイベントでフィルターでき、日付や回数でさらに絞り込めます。たとえば、特定のイベントを2回より多く完了したコンタクトのセグメントを作成できます。アクティブリストと静的リストの作成自体は下位プランでもできますが、条件にカスタムイベントを使う部分がEnterprise要件になります。
行動データの用途として、セグメントと並んで要望が多いのがスコアリングです。こちらはセグメントと要件が異なります。
リードスコアは、プロパティ値とイベントのアクションに基づいて数値を割り当てる機能で、Marketing HubおよびSales HubのProfessionalとEnterpriseで利用できます。属性に基づくfitスコアと、行動に基づくengagementスコア、その両方を組み合わせたスコアを作れます。イベント条件は「イベントグループ」としてまとめ、イベントの種類・プロパティによる絞り込み・期間・頻度を指定します。
私たちがスコア設計を支援するときは、イベントを追加する前に「このイベントが起きた人は、起きていない人より実際に受注率が高いか」を過去データで確認しています。確認せずに重みを付けると、スコアが営業の実感と乖離し、使われなくなります。
ここが本記事の中心です。要望を受けたときに問うべきは「イベントにできるか」ではありません。ほとんどの行動はイベントにできます。問うべきは「プロパティでは足りないか」です。判定の観点は3つあります。
いずれも、現場の要望の言葉からではなく、将来のレポート要件から逆算して判断します。導入時点では差が出ず、1年後に差が出る種類の設計判断です。
最初の問いは、同じことが繰り返し起きるかです。ログイン、ダウンロード、来場、問い合わせのように、同じ人に何度も起きるものはイベントです。会社規模や業種のように、1人（1社）につき1つしか持たないものはプロパティです。
2つ目の問いは、回数や頻度で絞り込みたいかです。「直近30日で3回以上」のような条件を書きたいなら、イベントでなければ表現できません。プロパティ側に「回数」という数値項目を持たせる構成でも現在の回数は分かりますが、期間を区切った回数は出せません。
3つ目の問いは、起きた時点の文脈を残したいかです。どのページから、どのキャンペーン経由で、どのデバイスで起きたのかを1回ごとに残したいなら、イベントプロパティで持つのが自然です。プロパティで持つと最後の1回で上書きされます。
「プロパティにも変更履歴があるのだから、履歴を見ればよい」という反論を受けることがあります。これは一見もっともですが、保存件数に上限があるため、行動の記録には使えません。
月に数回のログインを記録する用途であれば、コンタクトのプロパティでも1年弱で上限に達します。古い履歴から消えていくので、年次の比較はできません。一方、イベント側はアカウントで月間30 millionまで積み上がります。行動の記録をプロパティ履歴に頼ると、必要になった時点で過去が消えているという結果になります。
プロパティとイベントの中間に位置する機能が用意されています。既存のプロパティの変化そのものをイベント化するもので、監査証跡の用途に向いています。
プロパティ変更イベントは、オブジェクトの値が変わったときに記録し、そのデータをセグメント・ワークフロー・レポートで使えます。レコードの検証状況を追跡するような監査証跡の構築に向いています。コンタクトが営業に渡される前に「検証済み」でなければならない運用であれば、is_verified プロパティを追跡することで、誰がいつ検証したかを手入力なしに記録できます。
上限と副作用は3つあります。第一に、1アカウントあたり作成できるプロパティ変更イベントは最大25件です。第二に、プロパティ変更イベントは月間30 millionの総イベント発生数の上限にカウントされます。第三に、30 millionの上限に達した後のプロパティ変更イベントは復元できません。ライフサイクルステージのように入力率の高いプロパティを対象にすると、上限に早く到達します。イベント作成時に各プロパティの入力率（fill rate）が表示されるので、選定の前に確認してください。記録を残すという観点では、アカウント全体の操作履歴を扱うHubSpotの監査ログとの役割分担も整理しておく価値があります。
仕様の確認が終わったら、運用ルールを決めます。カスタムイベントの失敗は、技術的な実装ではなく、命名と棚卸しの不在から起きます。アカウント単位の上限がある以上、部門ごとの自由設計は成立しません。
私たちがエンタープライズのポータルでイベント設計を進めるときは、最初のイベントを作る前に次の項目を文書で確定させています。どれも後から変えられないか、変えるのに全イベントの棚卸しが必要になるものです。
| 決めること | 決めないと起きること | 決め方の目安 |
|---|---|---|
| イベントの内部名の命名規則 | 内部名は変更できないため、不統一のまま固定される | 「領域_対象_動作」の3語で、小文字とアンダースコアのみ |
| primaryObject をコンタクトにするか会社にするか | 作成後に変更できず、集計軸を変えられない | 契約単位の行動は会社、個人の行動はコンタクト |
| イベントを分けるか、プロパティの列挙値で分けるか | 1レポート1イベントの制約で突き合わせができなくなる | 同じファネル内の段階は1イベント＋列挙プロパティにまとめる |
| 月間発生数の部門別の配分と監視担当 | アカウント全体の上限に到達してから気づく | event healthのMonitorタブを月次でレビューする担当を指名 |
| 使われなくなったイベントの停止基準 | 発生数だけを消費するイベントが残る | 一定期間レポートとセグメントで参照されていなければ削除 |
削除の手順も確認しておいてください。イベント管理のManageタブからイベントを削除でき、チェックボックスで複数選択した場合は一度に最大100件まで削除できます。
イベント定義では、CRMレコードに紐づけない選択肢も選べます。便利に見えますが、できなくなることが多いので、用途を限定すべき機能です。
primaryObject を NO_OBJECT に設定するとレコードに紐づかないイベントになり、送信時には objectId、email、utk を含めてはいけません。この種のイベント発生は保存されません。具体的には、イベントAPIその他のAPIで取得できず、CRMレコードやタイムライン、レポート・分析ツール、リスト、セグメント、データセット、リードスコアリングに現れず、集計もできません。それでいて、アカウントの月間イベント発生数の上限にはカウントされます。
用途はワークフローのトリガーに限られます。エージェント型の自動化ビルダーでワークフローを起動する目的に適しており、それ以外の用途で選ぶと、記録したはずのデータがどこにも残っていないという事態になります。
行動データの記録は、国内では法令上の配慮が必要な領域です。CRM側の設計だけで完結させず、Webサイトの同意管理とセットで設計してください。
HubSpot側では、Cookieトラッキング設定とプライバシーポリシーの通知で同意バナーとトラッキングの挙動を設定します。国内法については、総務省の電気通信事業法の外部送信規律が、利用者の端末に外部送信を指示するプログラムを送る際に、送信される情報の内容・取り扱う者の名称・利用目的を通知または公表することを求めています。あわせて、個人情報の取り扱い全般については個人情報保護委員会のガイドライン（通則編）を確認してください。社内の統制面では、経済産業省のサイバーセキュリティ経営ガイドラインやIPAの情報セキュリティ対策ガイドラインが参考になります。
ここからは、カスタムイベントの設計と運用で実際に受けることの多い質問を整理します。本文で扱った仕様そのものではなく、導入判断と個別状況に関するものを中心にしています。
定義・送信・分析はProfessional以上で可能です。ただし、セグメント（旧リスト）のフィルター条件にカスタムイベントを使うには、Enterpriseサブスクリプションが必要です。行動データでセグメントを切る要件があるかどうかで、必要なプランが変わります。
マーケティングイベントは、ウェビナーやセミナーといった催事そのものをオブジェクトとして扱い、登録者や参加者を紐づける機能です。カスタムイベントは、任意の行動を時点の記録として残す仕組みです。名称が似ていますが用途が異なるので、要件定義では区別して記載してください。
イベントの内部名は、一度定義すると変更できません。表示ラベルは変更できます。APIの eventName や連携先のコードが内部名を参照するため、命名規則を決めてから最初のイベントを作成してください。
判断材料は、そのデータを使って「HubSpot内で何をするか」です。セグメント・スコアリング・ワークフローの条件に使うなら、HubSpotに入れる必要があります。分析して眺めるだけなら、BIツール側に置いたままのほうが月間イベント発生数の枠を使わずに済みます。全量を入れるのではなく、意思決定に使うイベントだけを選んで入れる設計をおすすめします。
JavaScriptのAPIリクエストでは上限を超えてもエラーにならず、プロパティ名の値が許容長に切り詰められるか、1回のイベント発生につき50件のプロパティのみが更新されます。値の長さ（URLとリファラーは1,024文字、それ以外は256文字）とプロパティ件数を先に確認してください。イベント管理のMonitorタブにある配信エラーのページでも、エラーの詳細を確認できます。
イベント側にプロパティを作成せずにAPIで送った場合、Monitorタブにエラーとして表示されます。配信エラーのページでエラーログの行から「Add properties to event」を選ぶと、直近のプロパティ値をもとに候補が提示され、ラベルとフィールドタイプを確認して作成できます。
送信時に uuid を指定できます。この値はイベントタイプ内で一意である必要があり、1年以内に同じIDを持つイベントが複数あった場合は最初のものが受け付けられ、それ以外は拒否されます。外部システムの処理IDをそのまま uuid に入れておくと、再送時の二重計上を防げます。
できます。スプレッドシートのインポートは過去に発生したイベントの取り込みを前提とした機能で、コンタクトのメールアドレスと「Occurred at」のタイムスタンプが必須です。APIで送る場合も、occurredAt にISO 8601の文字列またはUNIXのミリ秒タイムスタンプを指定することで、発生時刻を遡って指定できます。
カスタムイベントの設計は、何を記録するかではなく「記録したデータで誰が何を判断するか」から逆算する作業です。私たちはHubSpotの認定エリートパートナーとして、エンタープライズのデータモデル設計と行動データの活用設計を支援しています。イベント設計の棚卸しからご相談いただけます。お問い合わせはこちらからご連絡ください。
本記事に記載したプラン要件・上限値・プロパティ仕様・API仕様は、HubSpot公式ナレッジベースおよび開発者ドキュメントの2026年10月23日取得時点の記載に基づいています。