第6章 データ構造――案件と人の紐付け
6-1. 帰属の精度は、データ構造の精度で決まる
前章で設計した効果測定――Influencedの按分、均等配分のマルチタッチ、購買グループへの貢献証明――には、共通の前提がある。「その商談に、誰が関与しているのか」がデータとして記録されていることである。
この紐付けが、多くの組織で切れている。第3章で見た通り、商談は営業の世界にあり、リードとキャンペーンはマーケティングの世界にある。両者をつなぐ「案件と人の紐付け」は部門の境界線上にあり、誰の仕事でもないために落ちる。そして紐付けが切れている限り、どれだけ精緻な帰属モデルを設計しても、計算の材料が存在しない。展示会で獲得したあの担当者が、この1億円の商談の起点だった――その事実は、現実には存在していても、データ上は存在しない。
本章は、この紐付けをデータ構造として設計する。結論を先に言えば、必要な構造は驚くほどシンプルである。3つの基軸と、2つの紐付け。それだけで、前章までのすべての測定が成立する。
6-2. 全体構造――3つの基軸と、2つの紐付け
第2章で述べた3つの基軸エンティティを思い出してほしい。アカウント（企業）、ピープル（人）、キャンペーン（施策）である。効果測定に必要なのは、この3軸の間の2つの紐付けである。
紐付け①：人とキャンペーン。 人がキャンペーンにタッチした事実の記録である。第4章で設計した通り、この記録はキャンペーンのメンバーとして、ステータス（深度）とリファーラル（経路）と日時を伴って残る。「この人は、この展示会に、ブース来場→有効回答まで進んだ。10月14日のことである」――紐付け①は、マーケティング側の活動記録として、4層モデルの運用から自然に生成される。
紐付け②：案件と人。 商談に、誰が関与しているのかの記録である。「この商談の買い手側の関係者は、この4名である」。窓口担当者だけでなく、検討に関与している人物を商談に紐づける。これが本章の主題であり、多くの組織で欠けている最後のピースである。
この2つが揃うと、第3の関係――案件とキャンペーンの紐付け――は、記録するまでもなく導出できる。商談に関与している人（紐付け②）が、商談化の前、計測期間内にタッチしたキャンペーン（紐付け①）を辿れば、それがこの商談のInfluencedキャンペーンである。人を経由して、案件とキャンペーンがつながる。Influencedは入力するデータではなく、2つの紐付けから機械的に導出されるデータなのである。
導出であることの意味は大きい。第一に、営業に「この商談に影響したキャンペーンを入力してください」と頼む必要がない（そもそも営業はマーケティング施策の全容を知らない）。第二に、導出ルール――商談化前、180日以内、といった条件――が全商談に一律に適用されるため、帰属に恣意性が入らない。第三に、ルールを変えれば過去に遡って再計算できる。帰属の議論は「入力の正しさ」の議論から「ルールの妥当性」の議論に変わり、それは合意可能な議論である。
なおSourced（起点）は、導出ではなく確定記録である。MQLを受けて商談が作成された時点で、MQLソースのキャンペーンがSourcedとして商談に刻まれ、以後書き換えない。ファーストタッチ（第4章）と同じ思想である。歴史的事実は記録し、貢献の解釈は導出する――この使い分けが、データ構造の設計思想である。
6-3. 案件と人の紐付け――購買グループを記録する
では、商談には誰を紐づけるべきか。答えは「窓口担当者」ではない。購買グループ全体である。
BtoBの購買は、一人では決まらない。当社の「BtoB購買プロセス白書2025」（企業の購買・仕入れに関わるバイヤー600名調査）によれば、購買に関与する人数は、低価格帯（300万円未満）の取引で平均5.6人、中価格帯で14.4人、高価格帯（1,000万円以上）では平均18.3人に達する。取引金額が大きいほど関与者は増え、意思決定は部門横断の「グループ購買」になっていく。当社が『GTM Engineering Playbook』『AI Ready Playbook』で示したRRFの枠組みで言えば、課題を最初に持ち込む着火役、社内の検討を推進する旗振り役、リスクを審査する番人、予算を握る金庫番――複数の役割が関与する集団意思決定である。1件の購買の背後にある接点の総数は、一人の旅路ではなく、この十数人がそれぞれ検索し、資料を読み、イベントに参加した接点の合計――集団の旅路である。
この数字は、紐付けの設計に直接の含意を持つ。仮に高価格帯の商談で、記録されている関与者が窓口の1名だけなら、残り17人分の接点――その人たちが参加した展示会も、視聴したウェビナーも――が、帰属の計算から丸ごと消えている。大型案件ほど関与者が多く、関与者が多いほど記録の欠落は大きい。つまり、最も金額の大きい商談ほど、マーケティングの貢献が最も過小評価される構造になっている。展示会が「効いていないように見える」（第1章）最大の理由のひとつが、ここにある。
だからこそ、案件と人の紐付けは、可能なら役割つきで記録する価値がある。関与者に役割の属性が付くと、帰属の分析が一段深くなる。「展示会は着火役との初回接点に効いている」「ウェビナーは旗振り役の検討推進段階で参加されている」「金庫番はどのキャンペーンにも接触していない――だから受注直前で価格の壁に当たる」。キャンペーンの評価が、単なる件数の帰属から、購買グループのどの役割に効く投資なのかという戦略情報に変わる。
もっとも、最初から役割まで求めると入力の敷居が上がる。段階論として、まずは「関与者を紐づける」だけでよい。人が紐づけば、Influencedの導出とマルチタッチの按分は動き出す。役割の記録は、運用が定着してからの第2段階で構わない。
6-4. 誰が、いつ入力するのか――紐付けを「作業」にしない
構造が正しくても、入力されなければデータは生まれない。そして「営業に入力をお願いする」という素朴な運用は、ほぼ確実に形骸化する。営業には入力する動機が薄く、繁忙期には真っ先に省略されるからである。設計の焦点は、入力の負荷を構造的に消すことに置く。原則は3つ。
第一に、引き渡しの瞬間に最初の紐付けを済ませる。 MQLが営業に引き渡され、商談が作成される瞬間、そのMQL本人を商談の関与者として自動で紐づける。起点の1名は、人手ゼロで記録される。
第二に、システムに候補を提示させる。 同じアカウントに属する人物のうち、商談化前の期間にタッチのある人を「この商談の関与者ではありませんか」と候補として営業に提示する。名寄せとシングルアカウント（『GTM Engineering Playbook』『AI Ready Playbook』）ができていれば、この照合は機械的に可能である。営業の作業は「入力」から「確認」に変わり、負荷は一桁下がる。生成AIの活用が最も効く場面のひとつでもある――商談メモやメールの宛先から関与者候補を抽出することは、既に実用の域にある。
第三に、営業に価値を返す。 紐付けはマーケティングの計測のためだけにあるのではない。関与者が紐づいた商談画面では、その4名がこれまで何に反応してきたか――どのウェビナーを視聴し、どの資料を読んだか――が時系列で見える。これは営業にとって、次の一手を考えるための顧客理解の資産である。「計測のために入力してくれ」ではなく「入力すると商談が進めやすくなる」。この価値の還流がない紐付け運用は、続かない。
6-5. 人で取れないものは、アカウントで受ける
最後に、現実的な補完を述べる。すべての接点が人単位で捕捉できるわけではない。展示会のブースで話したが名刺を辞退された。ウェビナーに会社の会議室で複数人が集まって視聴していた。Webサイトを匿名のまま回遊している。人単位の記録には、必ず漏れがある。
この漏れを受け止めるのが、アカウント軸である。欧米のABM（アカウントベースドマーケティング）の実務でも、購買グループが関与するBtoBでは、人単位の追跡に固執せず「意思決定に関わるアカウントの誰かが接点を持ったか」をアカウントレベルで捉える考え方が一般的である。「この商談のアカウントから、商談化前に誰かが展示会に来ていた」――個人まで特定できなくても、アカウント単位の接触事実として記録できれば、Influencedの導出は成立する。
人単位の紐付けを主とし、アカウント単位の接触を従として補完する。この二段構えが、理想論と現実の間の実務解である。ここでも、すべてのデータがアカウントに正しく名寄せされているという『GTM Engineering Playbook』『AI Ready Playbook』の土台が効いてくる。紐付けの設計とは、結局のところ、基軸エンティティの品質の上に建つ建築なのである。
構造は揃った。次章では、この構造を使って、第1章の問いに正面から答える。器の代表である展示会、経路の代表である広告、育成型の代表であるウェビナー――3つの投資の測定実務である。
