アトリビューションスパインの構築：技術概観

アトリビューションは、レベニューデータが議論の的になる場所です。マーケティングはパイプラインを自分の手柄だと主張し、営業は成約を自分の手柄だと主張し、パートナーチームは引き合わせを自分の手柄だと主張し、財務部門はそのどれとも一致しないため、静かに三者すべてを疑っています。よくある反応は、モデルについて議論することです。ファーストタッチ、マルチタッチ、何らかの重み付けブレンド。しかしモデルは最後の問題です。最初の問題は、ほとんどの組織にアトリビューションスパイン、つまり誰が何に、いつ、どのようなコンテキストで触れたかを記録する基盤となるデータ構造が存在せず、どのモデルでも計算できる形になっていないことです。

これは、コンセプトを扱ったアトリビューションスパインの記事のエンジニアリング版です。データモデル、アイデンティティとタイムスタンプの問題、そして雑然としたタッチポイントの流れを、クエリ可能でモデルに依存しない何かに変えるパイプラインを扱います。現代的なレベニュープラットフォームのリファレンスアーキテクチャの中で、これはインテリジェンス層の中で最も要求の厳しいテナントです。アトリビューションはあなたのデータのあらゆる弱点を見つけ出すからです。

それはレポートではなくデータモデルである

核心的な間違いは、アトリビューションを設定可能なダッシュボードのような、レポーティングの問題として扱うことです。これは一度解決すればあとはレポートが簡単になる、データモデリングの問題です。スパインには3つのプリミティブがあります。

タッチポイントは、インタラクションの原子的で不変な記録です。ウェビナーへの参加、メールへの返信、パートナー起点のミーティング、製品への申し込みなどです。それぞれに主体（誰が）、種類（何を）、タイムスタンプ（いつ）、ソースシステム（どこから来たか）があります。

エンティティは、タッチポイントが結びつくアカウントと連絡先であり、正規の識別子に解決されるため、マーケティングオートメーションからのタッチポイントとCRMからのタッチポイントが同じアカウントに着地します。

レベニューイベントは、評価が配分される対象となる結果です。パイプラインの創出、商談の進行、案件の成約、拡張の獲得などです。

この3つが整えば、ファーストタッチ、ラストタッチ、線形、時間減衰、U字型、あるいは学習された重み付けであれ、どのアトリビューションモデルも、あるエンティティの最初のインタラクションからレベニューイベントまでのタッチポイントに対する単なる関数にすぎなくなります。どのレポートが正しいかを議論することをやめ、同じ不変のデータに対して異なるビューを計算するようになります。この分離こそがすべてのポイントです。

実際にプロジェクトを破綻させる2つのこと

モデリングをめぐる意見の相違よりも、こちらの2つでアトリビューションプロジェクトが頓挫することの方が多いです。

**アイデンティティ解決。**タッチポイントは、正しいエンティティに紐づけられなければ無価値です。同じ人間がクッキーID、フォーム入力のメールアドレス、CRMの連絡先、製品のユーザーIDとして現れ、それらが縫い合わされなければ、そのタッチポイントは幻のエンティティに散らばってしまいます。共有キー（メールアドレス、ドメイン）がある場合は決定論的マッチングが、ない場合は慎重な確率的マッチングが必要です。だからこそアトリビューションは、貧弱なRevOpsのデータハイジーンを厳しく罰するのです。未解決のアイデンティティはすべてスパインの穴であり、その穴はランダムには分布しません。計器化が最も不十分なチャネルにまさに集中し、モデル全体に偏りをもたらします。

**時間の整合性。**アトリビューションは一連のシーケンスにわたって評価を配分するため、すべてのタッチポイントとすべてのレベニューイベントに信頼できる、一貫してタイムゾーンが揃ったタイムスタンプが必要です。よくある失敗は、システムがイベント時刻ではなく取り込み時刻を記録すること、ソース間でのタイムゾーンの不一致、順序が入れ替わって到着するバックフィルされたレコードです。ある案件に影響を与えたとされるタッチポイントが、その案件よりも後の日付でスタンプされているのは些細なエラーではありません。それは時間減衰モデルや位置ベースモデルを静かに汚染します。イベント時刻を正確性の契約として扱ってください。これはリアルタイム対バッチ：レベニューデータの鮮度が重要になるときでより深く扱っているテーマです。

パイプライン

機能するスパインは、それぞれ単独でテスト可能な、明確なステージを持つパイプラインです。

1. 収集。マーケティングオートメーション、CRMの活動、プロダクト分析、パートナーシステム、広告プラットフォームなど、あらゆるソースからタッチポイントを取り込みます。生のペイロードを保持してください。後で必要になるかもしれないソースの忠実度を決して捨てないでください。
2. 正規化。異種のイベントを、一貫した種類、主体、イベント時刻のタイムスタンプを持つ共通のタッチポイントスキーマにマッピングします。
3. アイデンティティ解決。上記のマッチングロジックを用いて、タッチポイントを正規のエンティティに縫い合わせます。
4. 組み立て。各エンティティのタッチポイントをタイムラインに順序付け、関連するレベニューイベントと関連付けます。これがモデルの入力となるジャーニーを生成します。
5. モデル計算。組み立てられたジャーニーに一つまたは複数のモデルを適用します。スパインはモデルに依存しないため、このステージは変更が容易で、比較のために複数のモデルを並行して実行するのも容易です。

規律とは、これらのステージを分離し続けることです。正規化のロジックがモデル計算に漏れ込んでしまうと、その下にあるデータを危険にさらすことなくモデルを入れ替えることができなくなり、この分離のメリット全体が失われます。

信頼性を確立する

スパインは説明可能性を通じて信頼を獲得します。評価された1ドルについて、それがどのタッチポイントとどの重み付けから生まれたのかを正確に遡れるべきです。モデルの出力を、それが計算されたジャーニーの隣に保存してください。そうすればアトリビューションは、数字を吐き出すだけのブラックボックスではなく、監査可能なものになります。

同じ構造は、コセルやパートナーのアトリビューションといった本当に難しいケースも扱いやすくします。ある案件に自社チーム、パートナー、そして重なり合うタッチポイントが関与しているケースです。スパインはソースシステムとタッチポイントの種類をネイティブに記録するため、パートナー起点やパートナー影響下のタッチは、手作業の脚注ではなく一級市民の行として扱われます。しかし、その結果は人々が実際に働いているシステムに戻されて初めて役立つものになります。それがライトバック層の仕事であり、評価済みの貢献度をCRMのフィールドやダッシュボードに押し戻し、営業担当者やリーダーが実際に目にする形にします。

主なポイント

• アトリビューションをデータモデルとして解決する。スパインが存在すれば、あらゆるモデルはそれに対する単なるクエリになる。
• 3つのプリミティブがある。不変のタッチポイント、正規のエンティティ、レベニューイベントである。
• アイデンティティとタイムスタンプは、モデルをめぐる議論よりもはるかに多くのプロジェクトを頓挫させ、その被害は目に見えない形で進行する。
• 収集、正規化、解決、組み立て、計算を別々のステージとして保ち、データに触れずにモデルを変更できるようにする。
• 出力を、それが由来したジャーニーの隣に保存する。それがCFOに問われたときにその数字を擁護可能にするものである。

うまく構築されたスパインは、終わりのない貢献度をめぐる争いを、クエリ可能で監査可能な基盤に変えます。これはRevnewoのようなレベニューオーケストレーションプラットフォームが依存している類のデータ層です。あなたのアトリビューションをめぐる議論がモデルのあたりをぐるぐる回っているなら、本当の解決策はたいてい一段下の層にあります。