イベント参加者のインテントデータとは、本人が書いた申込・アンケートと、本人が動いた記事閲覧・資料ダウンロードを、同じ人の関心として結び直したものです。この結び直しは、技術的にはほぼ何でもできます。だから設計で最初に決めるべきなのは、何ができるかではなく、どこで止めるかです。
イベントだけは、匿名ではなく顕名から始まる
BtoBのオウンドメディアでインテントデータを扱うとき、ふつうは匿名から始まります。誰か分からない訪問者が記事を読み、資料請求のフォームで初めて名前が分かる。そこで過去のログが遡って一人の人物に結びつく。この順序を前提にした設計は、すでに広く共有されています。
イベントは、この順序が逆です。申込フォームの時点で、氏名・会社名・メールアドレスが手に入っている。匿名の訪問者を実名にする工程が要らない代わりに、最初から個人情報を預かった状態で、そのあとの行動が積み上がっていきます。
この逆転は小さな違いに見えて、設計の問いを入れ替えます。匿名から始まる場合の問いは「どうやって実名に結びつけるか」でした。顕名から始まる場合の問いは「本人が知らないうちに、どこまで結んでよいか」に変わります。前者は技術の問題ですが、後者は約束の問題です。
顕名から始まるのに営業へ渡らないのは、2つの層で詰まるから
イベントは最も条件が良いはずなのに、参加者データが営業に渡らない。原因は1つではなく、上下2層で別々に詰まっています。
表層：申込フォームと行動ログが、別々の場所に置かれている
申込データはフォームツールに、アンケートは表計算に、記事閲覧は解析ツールに入っている。それぞれ管理者が違い、書き出しの形式も違う。ここまでは、よく指摘される話です。手を動かせば繋がるので、詰まりとしては浅い層にあります。
深層：同意の範囲を列として持っていないので、繋いでよいかを誰も判断できない
深いのはこちらです。仮に3つのデータが1か所に集まったとして、次に必ず「これ、繋いでいいんでしたっけ」という問いが出ます。そして答えられません。申込フォームのチェックボックスには「今後のご案内をお送りしてよろしいですか」としか書かれておらず、それが記事閲覧の履歴と結びつけてよいという意味なのか、営業から電話してよいという意味なのかが、どこにも記録されていないからです。
判断できないと、人は止まります。止まったデータは死蔵され、次の開催でまた同じ場所で止まる。表層の統合をいくら進めても、深層に判断の材料が無ければ、データは動きません。イベントデータが営業に渡らない本当の理由は、統合されていないことではなく、同意の範囲が記録されていないことです。
参加者データは「書いた・動いた・推定した」の3つに分けられる
出どころで分ける区分（自社で取得したか、外部から購入したか）はすでにあります。1st-partyデータとは？3rd-partyとの違いで扱っている軸です。ただしイベントの設計では、この軸だけでは足りません。同じ1st-partyの中で、扱いを変えるべきものが混ざっているからです。
そこで、取り方で3つに分けます。
書いた ── 本人が入力したもの
申込フォームの氏名・会社・部署、アンケートの回答、質疑で本人が発言した内容。本人が自分の意思で差し出したものです。本人はそれを渡した自覚があり、何のために渡したかもフォームの説明文で見ています。3つの中で、最も扱いやすい層です。
動いた ── 本人の行動が残したもの
イベントレポートを読んだか、どの記事を読んだか、資料をいつダウンロードしたか、アーカイブを何分見たか。本人は「見た」だけで、記録されている自覚は薄い層です。単体では誰のものか分からないことも多く、Cookieなどの端末識別子に紐づいた形で残ります。
推定した ── こちらが計算したもの
関心テーマの推定、確度のスコア、検討段階のラベル。本人が一度も口にしていない層です。本人は自分にどんなスコアが付いているかを知らず、間違っていても訂正できません。3つの中で最も強力で、最も慎重に扱うべきものです。
3つの層で、法の扱いが変わる
この3分類が有効なのは、そのまま制度上の扱いに対応するからです。
「書いた」は個人情報そのものです。利用目的をできる限り特定し、本人が合理的に予測・想定できる程度の具体性で示したうえで、公表または通知することが求められます（個人情報保護法第17条・第21条）。「ご案内をお送りします」とだけ書いた利用目的で、営業からの個別連絡までを読み取らせるのは無理があります。
「動いた」は、単体では個人を特定しないことがあり、その場合は個人関連情報として扱われます。個人情報保護委員会のQ&Aでは、Cookieなどの端末識別子やメールアドレスが個人関連情報に該当しうることが示されています。そして、これを第三者に提供し、提供先が個人データとして取得することが想定されるときには、本人の同意が得られていることなどを確認する義務があります（同法第31条）。自社の中で自社の顧客データと突き合わせる場合と、外部のツールや取引先に渡す場合とでは、必要な手当てが変わります。
「推定した」は、それ自体を直接名指しした条文があるわけではありませんが、元になったデータの利用目的の範囲を超えていないかという問いが残ります。詳しくはガイドライン（通則編）とガイドラインに関するQ&Aを確認してください。実務では、法務の確認を通すことが前提になります。ここで述べているのは、確認に持ち込む前に自分たちが何を持っているかを3つに仕分けておくという設計の話です。
繋げられることと、繋ぐべきことは違う
3つに分けると、繋がなくてよいものが見えてきます。
イベントレポートの質を上げたい、という目的を考えます。どのセッションが最後まで読まれ、どこで離脱したかが分かれば十分です。これは「動いた」層を集計すれば分かることで、誰が読んだかを知る必要はありません。ここで顕名と結びつけると、目的に対して過剰な情報を持つことになり、管理の負担とリスクだけが増えます。
一方、営業に渡すという目的なら、「書いた」層の同意が要ります。同意が無ければ、どれだけ濃いインテントが観測できても渡せません。渡せないデータを見て「惜しい」と思うのは自然ですが、そこで例外を作ると、次から線引きが機能しなくなります。
目的ごとに、どの層まで使うかを先に決める。これが3分類を持つ最大の利点です。技術的に繋げられるかどうかは、判断の材料になりません。総務省の令和7年版情報通信白書が示すように、データの利活用は年々進んでいますが、進むほど「どこで止めるか」を自分で決めておく必要が出てきます。
イベントレポート担当が、記事を書く前に決めておく3つのこと
レポートを書く人は、たいてい設計の下流にいます。それでも、書く前に3つだけ決めておくと、後工程が変わります。
1つ目は、このレポートの計測を、誰のためにやるのかです。記事の改善のためなら「動いた」層だけでよく、営業のためなら「書いた」層の同意まで遡って確認が要ります。
2つ目は、登壇者と参加者の発言を、どちらの層として扱うかです。質疑での発言は本人が書いた（話した）ものですが、レポートに実名で載せるなら、その場での了解とは別に、公開の同意が要ります。
3つ目は、イベントを識別する記号を決めておくことです。どの回のデータかが後から辿れなければ、同意の取得時期も確認できません。
インテントデータの実装そのもの、つまり観測したシグナルをどう営業に渡すかは、インテントデータでコンテンツ読者を営業に渡すで別に扱っています。イベント全体の循環についてはEvent-Led Growthとはを参照してください。
線引きで実務が止まりやすい場所
Q. インテントデータを扱うと個人情報保護法に触れるのですか？
インテントデータという区分そのものが違法という規定はありません。問題になるのは、何を集め、何と結び、誰に渡すかです。本人が入力した情報は個人情報として利用目的の特定と公表が要り、Cookieなどに紐づく行動データは個人関連情報として第三者提供時の確認義務がかかる場合があります。区分ではなく、扱い方が判断の対象です。
Q. 自社の中で行動ログを申込データに紐づけるのも、同意が要りますか？
第三者への提供ではないため、法第31条の確認義務が問題になる場面とは異なります。ただし、当初示した利用目的の範囲を超えていないかという問いは残ります。利用目的に「ご案内の送付」としか書いていない状態で、行動履歴に基づく営業活動まで行うのであれば、利用目的の書き方を見直すのが先です。
Q. アンケートを匿名にすると、営業には一切使えなくなりますか？
その回の集計としては使えますが、個人単位で営業に渡すことはできません。だからこそ、匿名で聞くべき設問と顕名で聞くべき設問を、最初から分けて設計します。満足度や改善点は匿名の方が本音が出ますし、それはレポートの改善という目的には十分です。
Q. 推定したスコアを、本人に開示する必要はありますか？
一律に開示義務があるという話ではありません。ただ、本人に説明できない推定は、社内でも根拠として弱いという実務上の問題があります。スコアの根拠を1行で言えるかどうかを、設計の目安にしてください。言えないスコアは、営業に渡しても信用されません。
考え方は以上です。実際の項目設計は別に書きました
繰り返しになりますが、イベントは顕名から始まる珍しい接点です。だから恵まれている一方で、線引きを後回しにすると、預かった個人情報の上に判断できないデータが積み上がっていきます。書いた・動いた・推定したの3つに分け、目的ごとにどこまで使うかを先に決める。順序はそれだけです。
では、実際にどの列を持てばよいのか。参加者1人を1行にする具体的な項目表と、記入の手順はセミナー アンケート項目｜営業に渡すデータ設計チェックリストにまとめました。この記事で決めた線引きを、そのまま表の列に落とし込めます。
