ウェビナーが終わった翌日、マーケティング担当者がやっていることはだいたい同じです。配信ツールから参加者CSVを落とし、申込者CSVと突き合わせ、参加した人としなかった人に分け、営業に渡すリストをExcelで作る。この作業は1回あたり数時間で済みますが、月に2本開催していれば年に24回発生します。しかも、その成果物はCRMの外に置かれたまま残りません。
半年後に「去年のウェビナーに3回以上参加している企業はどこか」と聞かれたとき、答えられる組織は多くありません。CSVを突き合わせて作ったリストは、作った本人のフォルダの中にあるからです。株式会社100はHubSpotの認定エリートパートナーとして、こうしたイベント運用をCRMの中に載せ替える支援をしています。
HubSpotには、この用途のためにマーケティングイベントという専用のオブジェクトが用意されています。この記事では、マーケティングイベントで何が記録され、申込から参加・フォローアップ・商談化までをどう設計するかを整理します。Zoomとの接続手順そのものはHubSpotとZoomの連携で扱っているため、本記事はイベントオブジェクトの設計に軸を置きます。
目次
「ウェビナーの参加者をHubSpotに入れる」と言ったとき、入れ先の候補は複数あります。コンタクトのプロパティにチェックを付ける、リストに入れる、カスタムオブジェクトを作る。マーケティングイベントは、この選択肢のうち標準で用意されている専用の器です。まず何が入るのかを確認します。
マーケティングイベントはイベントの概要を1か所で把握するための機能で、全プロダクト・全プランで利用できます。ただし機能ごとに条件が異なり、ワークフローでの登録にはProfessional以上、キャンペーンへの紐づけにはMarketing Hub Professional以上、アトリビューションレポートにはMarketing Hub Enterpriseが必要とされています。
器の中身を知らないまま運用設計を始めると、後から「その項目は持てません」という話になります。既定で用意されているプロパティを押さえておきます。
| 分類 | プロパティ | 設計上の使いどころ |
|---|---|---|
| 識別 | Name、Type、Description、Url、Record ID | Typeをウェビナー／セミナー／展示会で統制すると集計が揃う |
| 日程 | Start date、End date、Event cancelled | リマインドの基準日をどちらに置くかを先に決める |
| 実績 | Registrations、Attendees、Cancellations、No shows | 参加率・欠席率の分母と分子をここから作る |
| 体制 | Organizer、Owner、Created by user ID、Updated by user ID | Ownerを空にすると、後からレポートで部門別に割れない |
| 来歴 | Record source、Record source detail、Last import status、AppId | 手動作成か連携由来かを判別する軸になる |
私たちがクライアントのイベント運用を設計するときは、TypeとOwnerの2つを最初に決めます。この2つを空欄のまま運用を始めた組織は、1年後に「部門別・形式別の参加実績」を出そうとして手詰まりになります。プロパティの統制についてはマーケティングイベントのプロパティ標準化も併せてご確認ください。
出欠の管理は、コンタクト側のプロパティではなくイベントとの関係として記録されます。開発者ドキュメントでは、参加状態として REGISTERED（登録済み）、ATTENDED（参加）、CANCELLED（キャンセル）、NO_SHOW（登録したが不参加）が定義されています（Marketing events API guide）。
コンタクトレコード側では、マーケティングイベントのカードにイベント名・タイプ・ステータス・登録日・参加日・キャンセル日・開催日が表示されます（View marketing events on contacts）。過去と今後の両方のイベントが並ぶため、営業が商談前にこの画面を開けば、相手が何に興味を示してきたかが時系列で見えます。
この構造の利点は、コンタクト側にイベントごとのカスタムプロパティを増やさずに済むことです。ウェビナーを開催するたびに「○○ウェビナー参加」というチェックボックスを増やしていく運用は、半年でプロパティ一覧が破綻します。HubSpotのプロパティ設計の観点でも、関係として持てるものをプロパティにしない判断が重要です。
ここに明確な制約があります。コンタクトレコードから手動でマーケティングイベントに関連付けることはできません。紐づけの経路は3つに限られます。インポート、ワークフローの「Add participant to marketing event」アクション、そしてZoom・Microsoft Teams webinars・GoToWebinar・Eventbriteといった連携アプリ経由の参加ステータス変更です。
この制約は運用設計に直結します。オフラインのセミナーで紙の名簿を回収した場合、担当者が画面から1件ずつ追加することはできず、インポートかワークフローのどちらかを通す必要があります。インポートの運用ルールを先に整えておかないと、イベントのたびに属人的な作業が発生します。
なお、ワークフローの「Add participant to marketing event」アクションは手動で作成したイベントにのみ使え、連携経由で生成されたイベントには使えません。手動作成と連携作成を混在させる運用では、この違いが設計の分岐点になります。
作り方によって、後から変更できる範囲と自動化できる範囲が変わります。開催形式が複数ある組織では、どの形式をどの作り方に割り当てるかを先に決めておくと、運用が安定します。
Marketing配下のイベント画面から作成する方法が基本です。Marketing Hub ProfessionalまたはEnterpriseをご利用の場合は、Marketing Studioのキャンバス上からマーケティングイベントを作成・追加することもできます（Create and add marketing events in Marketing Studio）。キャンペーンの構成要素として扱えるため、施策全体の中での位置づけが明確になります。
作る前に決めるのは、名前の付け方です。私たちがクライアントと決める命名規則は「開催日_形式_テーマ_共催先」の順で、検索と並び替えが同時に効く形にしています。命名規則がないと、同じテーマの再演が3回あったときに、どれがどれか分からなくなります。
Zoom、Microsoft Teams webinars、GoToWebinar、Eventbriteのいずれかを接続している場合、ウェビナーのイベントがマーケティングイベントとして自動的に同期されます。手動で作る必要はありません。
同期の内容と間隔は、ツールによって差があります。たとえばGoToWebinarでは、登録者データはリアルタイムで、参加者データはウェビナー終了の15分後にHubSpotへ追加されると記載されています（Use HubSpot's integration with GoToWebinar）。終了直後にフォローアップメールを送るワークフローを組む場合、この遅延を見込んだ待機時間が必要です。
Microsoft Teams webinarsでは、同期されたウェビナーが登録者数・参加者数・キャンセル数・イベント名・日付・開始終了時刻・主催者・ステータス・説明を含むマーケティングイベントとして作成されます（Use HubSpot and Microsoft Teams webinars）。Eventbriteの場合はイベント画像も同期対象になります（Use HubSpot's integration with Eventbrite）。
自社の申込システムや外部のイベントプラットフォームから流し込む場合は、Marketing Events APIを使います。設計で最初に決めるのは externalEventId と externalAccountId の採番ルールです。この2つが外部システム側のイベントとHubSpot側のイベントを結ぶキーになります。
開発者ドキュメントには、イベントの作成・更新・削除のほか、参加状態を更新するエンドポイントが整理されています。コンタクトIDで更新する経路とメールアドレスで更新する経路の両方が用意されており、外部システムがHubSpotのIDを保持していない場合でも連携できます。一覧取得の limit は既定値が10で、指定できる範囲は1から100と記載されています。
私たちがAPI連携を設計する際は、参加状態の更新を冪等に組むことを必須条件にしています。再送や再実行で二重に記録されない構造にしておかないと、参加者数が実態とずれ、レポートの信頼性が落ちます。
申込フォームは、イベント運用で最も事故が起きやすい場所です。取りたい情報を増やすほど申込率が下がるという一般論ではなく、連携の仕様上、増やすと登録そのものが失敗するという実務上の制約があります。
Zoom連携が受け付けて同期する必須項目は、First name・Last name・Emailの3つだけです。他の必須項目を追加すると登録が失敗するおそれがあります。Microsoft Teams webinarsでも同様に、必須項目は3つに限られ、追加すると失敗の原因になります。
つまり「役職」「部門」「課題」を必須にした申込フォームをそのままウェビナー登録に連動させると、登録が通らない事態が起きます。設計の答えは単純で、連携に渡す必須項目は3つに固定し、それ以外は任意項目として収集することです。
フォーム自体の作り方は公式ナレッジベースのCreate formsに整理されています。社内の設計基準はHubSpotのフォームにまとめています。
必須にできないからといって、情報を諦める必要はありません。持たせ方を変えます。
どれを選ぶかは、その情報を誰がいつ使うかで決まります。営業が初回接触の前に見る情報なら申込時、ナーチャリングの分岐に使う情報なら当日以降でも間に合います。使う時点から逆算せずに項目を増やすと、入力率だけが下がります。
同一人物が別のメールアドレスで申し込むケースは必ず発生します。HubSpotはコンタクトをEメールアドレスで重複排除するため、個人用アドレスと会社用アドレスの使い分けは別レコードとして入ります。
完全には防げませんが、入口で減らすことはできます。プロパティに検証ルールを設定して前後の空白や全角英数字を弾く、会社名を自由記述ではなく企業レコードとの関連付けで持つ、といった対策です（Set validation rules for a property）。オフライン名簿をインポートする場合は、ファイルの形式要件も確認してください（Format import files）。
イベント運用の自動化は、ワークフローに集約します。ただし起点の選び方を間違えると、連携の同期タイミングに引きずられて配信が前後します。起点ごとの特徴を整理します。
選択肢は3つあります。フォーム送信を起点にする方法、マーケティングイベントの参加ステータスを起点にする方法、イベントの開催日プロパティを基準に日付で動かす方法です。
| 起点 | 向いている用途 | 注意点 |
|---|---|---|
| フォーム送信 | 申込直後の確認メール | 連携側の登録が完了する前に動く可能性がある |
| 参加ステータスの変更 | 参加者・欠席者への出し分け | 連携の同期遅延を待機時間として見込む |
| 開催日からの相対日付 | 前日・当日朝のリマインド | イベントの日程変更時に再計算されるかを確認する |
利用できるアクションと必要なサブスクリプションは公式ナレッジベースに一覧化されています（Choose your workflow actions）。日付を基準にした待機には、カレンダー日付・日付プロパティ・曜日・時刻といった指定方法が用意されています。ワークフロー設計の基本はHubSpotのワークフローに整理しています。
参加した人と欠席した人に同じメールを送る運用は、機会損失です。ステータスで分岐させると、文面も次のアクションも変えられます。
私たちが標準として置いている分岐は4つです。参加者には録画と資料、そして個別相談への導線。欠席者には録画のみと次回案内。キャンセル者には次回案内のみ。申込なしで資料請求だけした層には、別のナーチャリングへ。この4分岐を作っておくと、イベントごとの作業がテンプレートの複製で済みます。
セグメントは、アクティブなものと静的なものを使い分けます（Create active or static lists）。イベント単位の参加者名簿は静的、「直近12か月で2回以上参加」のような横断条件はアクティブにすると、運用が崩れません。
欠席者は失敗ではなく、関心を示した見込み客です。NO_SHOW として記録されているため、参加者とは別の導線を設計できます。
実務で効くのは、欠席理由を推定して文面を変えることではなく、録画の視聴行動を次の起点にすることです。録画を最後まで見た欠席者は、途中で離脱した参加者より関心が高い場合があります。視聴行動を記録したい場合は、カスタムイベントを定義する方法があります（Create custom events）。Professional以上で利用でき、1回のイベント発生につき最大50個のプロパティ、プロパティ値はURL・参照元で1024文字、その他は256文字という上限が記載されています。
イベント運用の評価が「参加者数」で止まる組織は多くあります。止まる理由は、商談への接続を測る設定が既定では有効になっていないことです。ここを設定するだけで、議論の質が変わります。
マーケティングイベントはキャンペーンに関連付けられる資産として掲載されています（Associate assets and content with a campaign）。連携由来のイベントはキャンペーンツール側からのみ関連付けできる、という条件が付きます。
紐づけると、イベント単体ではなく施策全体として実績を見られます。告知メール、ランディングページ、広告、イベント本体を1つのキャンペーンにまとめると、どの入口から申込が来たかが1画面で分かります（Analyze individual campaign performance）。
ここが最も見落とされる設定です。アトリビューションレポートの相互作用タイプには「Attended marketing event」と「Registered for a marketing event」が用意されていますが、いずれも既定ではオフになっています（Select interaction types for your attribution reports）。
オフのままレポートを作ると、ウェビナー経由で生まれた商談がイベントの貢献として計上されません。「ウェビナーは数字に出ない」という社内評価の相当部分は、この設定が原因です。設定を有効にしたうえで、コンタクト作成・取引作成・収益のどのアトリビューションを見るかを決めてください（Create attribution reports）。取引作成と収益のアトリビューションはMarketing Hub Enterpriseが対象です。
測定の前に定義を決めます。分母を申込者にするか参加者にするか、分子を商談化にするか受注にするか、計測期間を何日にするか。この3つを決めずに数字を出すと、部門ごとに別の数字が出てきます。
私たちが推奨する既定は、分母を参加者、分子をイベント後90日以内に作成された取引、としたうえで、申込者ベースの数字も併記する形です。参加率が低いイベントを「参加者ベースでは優秀」と見せてしまう問題を避けられます。収益側の集計方法は公式ナレッジベースのReport on revenue in HubSpotに整理されており、レポートの作り方はCreate custom reportsにまとまっています。ダッシュボードの考え方はHubSpotのレポートとダッシュボードをご確認ください。
どのウェビナーツールを使うかで、設計できる範囲が変わります。ツールの優劣ではなく、HubSpot側から見たときの接続点の違いとして整理します。公開されている公式ドキュメントの記述に基づく比較です。
| 観点 | Zoom | Microsoft Teams webinars | GoToWebinar | Eventbrite |
|---|---|---|---|---|
| マーケティングイベントへの同期 | 対応 | 対応 | 対応 | 対応 |
| HubSpotフォームからの登録 | 対応（必須3項目） | 対応（必須3項目） | 対応 | Eventbrite側の登録ページが基本 |
| ワークフローからの登録 | Professional以上 | 対応 | Professional以上 | 記載を確認できませんでした |
| 参加データの反映 | 終了後に同期 | 参加時間を含めて同期 | 終了15分後 | チェックインがタイムラインに記録 |
| 導入時の要件 | ウェビナーアドオンが必要 | 管理者レベルのアプリ導入とポリシー設定 | 1インスタンスにつき1アカウント | 接続ユーザーが作成したイベントのみ |
| 主な制約 | Zoom Eventsとして作成したものは非対応 | 発表者ロールは同期対象外 | 今後開催分のみ選択可能 | カスタム登録項目は同期されない |
選定で効くのは、ワークフローから自動登録できるかどうかです。ナーチャリングの流れの中で「興味を示した人を自動でウェビナーに登録する」設計を取りたい場合、この対応可否が分岐になります。
イベント管理の専用ツールを併用すべきかどうかは、必ず議論になります。公正に整理すると、分かれ目は参加者数ではなく、イベントの複雑さです。
| 観点 | HubSpotのマーケティングイベント | 専用のイベント管理ツール |
|---|---|---|
| CRMとの一体性 | コンタクト・取引と同じ基盤に乗る | 連携設計と同期の運用が必要 |
| 出欠管理 | 4つのステータスで表現 | セッション単位・複数日程に対応する製品が多い |
| 申込フォーム | HubSpotフォーム。連携時は必須項目に制約 | 条件分岐や決済を含む複雑な申込に対応 |
| 商談への接続 | アトリビューションとキャンペーンで一気通貫 | 連携経由のため、項目設計の擦り合わせが必要 |
| 向くケース | 単日のウェビナー・セミナーを定常開催する | 多日程・多トラックの大型カンファレンス、有料イベント |
私たちが判断基準にしているのは、「1人の参加者が同じイベント内で複数のセッションを選ぶか」です。選ぶ構造があるなら専用ツール、1イベント1参加の構造ならHubSpot標準で足ります。参加者数の多寡は、この判断にほとんど影響しません。
設定そのものは1日で終わります。終わらないのは運用ルールの合意です。イベントを定常開催する前に、次の5点を決めておいてください。
4つ目は特に揉めます。ツール側が入室だけで参加と判定する場合、HubSpot側の参加者数は実感より多くなります。営業に渡すリストの基準を別に持つのか、ツール側の設定を変えるのかを、運用開始前に決めてください。
マーケティングイベントもCRMのオブジェクトの一種です。どの単位をレコードとして持つかという設計の考え方は、公式ナレッジベースのHow to use objects for business processesに整理されています。権限の設計も忘れずに確認してください（HubSpot user permissions guide）。データの持ち方を1か所に揃える考え方はSSOT（信頼できる唯一の情報源）に、イベントを含むリード獲得全体の設計はBtoBリード獲得の統合設計にまとめています。
できません。コンタクトレコードから手動で関連付けることはできません。紐づけの経路はインポート、ワークフローの「Add participant to marketing event」アクション、連携アプリ経由の3つです。オフラインの名簿を取り込む場合はインポートを使ってください。
インポートで取り込めます。手動で作成したマーケティングイベントにも、参加者リストをインポートできます。既存のCSVが残っている場合は、イベント単位で遡って取り込み、過去の参加履歴をCRMの中に置き直すことができます。ただしメールアドレスが変わっている相手は別レコードになる点にご注意ください。
反論の前に、アトリビューションの設定をご確認ください。マーケティングイベントの相互作用タイプは既定でオフのため、設定していなければレポート上は貢献ゼロになります。設定を有効にしたうえで数字を出し直すと、議論の前提が変わります。これは運用の問題ではなく設定の問題です。
取引レコードとマーケティングイベントを直接関連付ける機能についての記載は、公式ナレッジベースで確認できませんでした。商談への接続はコンタクト経由となり、評価はアトリビューションレポートとキャンペーンのパフォーマンスで行う設計になります。取引側でイベントを参照したい場合は、取引プロパティに流入施策を持たせる方法を検討してください。
マーケティングイベントを使うと、イベントが増えてもプロパティは増えません。参加・欠席・キャンセルという状態も標準で表現されます。プロパティで管理する方式は、イベント数が一桁のうちは問題になりませんが、年間20本を超えたあたりからプロパティ一覧とセグメント条件の保守が追いつかなくなります。
ウェビナーツールと連携する場合は問題になります。Zoom連携は姓・名・メールアドレスの3項目のみを受け付けると記載されており、他の必須項目を追加すると登録が失敗するおそれがあります。Microsoft Teams webinarsでも同様です。必須は3項目に固定し、それ以外は任意項目として収集してください。
マーケティングイベント側で統合されるため、オブジェクトとしては1つの一覧で見られます。ただしTypeやOwnerの入り方がツールごとに異なるため、レポートの軸にする項目については手動で補正するか、ワークフローで既定値を入れる運用を決めてください。レコードソースのプロパティで、どの経路で作られたイベントかを判別できます。
設定と連携だけなら数日です。時間がかかるのは、Typeの選択肢・参加の定義・フォローアップの期限といった運用ルールの合意です。当社が支援する場合も、最初の1本を既存のやり方と並行で走らせ、2本目から完全移行する進め方を取ります。並行期間を設けないと、当日のトラブル対応ができなくなります。
この記事の内容を、着手順に整理します。
ウェビナーが数字にならない組織と、商談の起点になっている組織の差は、集客力ではありません。参加の記録がCRMの中にあるか、担当者のExcelの中にあるかの差です。記録の置き場所を変えるだけで、半年後に答えられる問いの数が変わります。
株式会社100は、世界上位1%・日本唯一のHubSpot認定エリートパートナーとして、イベント運用の設計から商談化までの導線づくりを支援しています。自社の運用をどこから移すべきか具体的にご相談がある場合は、お問い合わせからご連絡ください。
最終更新日: 2026年10月23日（本記事の記載は同日時点の公式ドキュメントに基づきます。仕様・上限・提供条件は変更される可能性があるため、実装前に一次情報をご確認ください）