レベニューアトリビューションのための単一の信頼できる情報源を構築する

レベニュー組織にいる3人に、先四半期に何件の案件が成約したかを尋ねれば、おそらく3通りの数字が返ってきます。マーケティングはオートメーションプラットフォームから引き出し、セールスはCRMから、財務は請求から引き出し、それぞれが自分の数字を20分間擁護できます。私たちはその会議に同席してきました。誰も正確には間違っていません。しかし基本的なカウントが食い違った瞬間、その上に構築されるあらゆるアトリビューションモデルはその食い違いを継承し、どれだけモデリングの洗練度を上げても、矛盾した事実から始まる分析を修正することはできません。

アトリビューションのための単一の信頼できる情報源は、他のすべてを信じられるものにする地味なインフラです。それはダッシュボードではなく、誰かが月末の最後の金曜日に手作業で突き合わせるスプレッドシートでもありません。それは、アイデンティティ、イベント、レベニューが毎回同じ方法で結合される、ガバナンスされたデータ層です。ここでは、それを構築するために実際に何が必要かを説明します。

なぜ数字は乖離するのか

断片化は、誰かが悪い仕事をしたことのサインではありません。それは成長するあらゆるスタックに起こることです。あなたが採用する各ツールは、独自の識別子、独自のタイムスタンプ、そして物事が何であるかについての独自の定義を持つ、現実のその一部分についてのシステム・オブ・レコードです。

• CRMはアカウントと案件を知っていますが、企業レコードは陳腐化しているか重複しています。
• マーケティングプラットフォームはコンタクトとエンゲージメントを知っていますが、しばしば人物を正しいアカウントに結びつけることができません。
• プロダクトデータベースは利用状況を知っていますが、セールス側の何にもマッピングされない内部ユーザーIDでキー付けされています。
• 請求は実際に何が請求されたかを知っていますが、CRMのものとは一致しないアカウント階層に基づいています。

これらのそれぞれは内部的には一貫しており、他とは互換性がありません。これはなぜレベニュースタックが断片化するのかの背後にあるのと同じ状況です。アトリビューションは、それらすべてを一度に横断して結合しなければならないため、単にその痛みが最も大きく現れる場所にすぎません。

3つの結合がすべてを支える

機能するSSOTは、3つのアイデンティティ問題を解決することに帰着します。それらを正しく行えば、ほとんどの下流の分析は扱いやすくなります。それらを間違えれば、あらゆるモデルが静かに損なわれ、たいてい上級者が鋭い質問をするまでそれに気づきません。

コンタクト対アカウントが最初です。すべての人物は、メールドメイン、子会社、そしてあるVPがウェビナーに登録するために使った個人のGmailアドレスを超えて、正しい企業に解決されなければなりません。それがなければ、ある一つのアカウントから6人があなたを評価していることを見ることができず、購買委員会分析は選択肢から外れます。

アカウント階層が二つ目です。親、子、買収されたブランド、地域部門。これらが一貫してロールアップされなければ、グローバルアカウントは十数個の無関係な小さなアカウントのように見え、そのレベニューは誰も結びつけないレコードに散らばります。

タッチ対レベニューが三つ目です。すべてのマーケティングとセールスのインタラクションは、それが関連する案件に、そして最終的には請求されたレベニューに結びつかなければなりません。何が案件としてカウントされ、いつそれが始まるかについての一つの定義を使って。

ここに実際のエンジニアリングが存在します。あいまいマッチング、決定論的キー、エンリッチメント、重複排除。そのすべてが一つの目標に奉仕します。あらゆるシステムが同意する、すべてのアカウントと人物のための安定した正規のアイデンティティです。

ガバナンスが賢いSQLに勝る

これを技術プロジェクトとして扱いたくなる本能があります。すべてをウェアハウスに流し込み、いくつかのモデルを書き、完了。しかし私たちの経験では、失敗するのはめったに配管ではありません。定義です。マーケティングがMQLを一つの方法でカウントし、セールスがクオリファイドオポチュニティを別の方法でカウントするなら、ストレージを統一しても、議論を別の部屋に移動させるだけです。

したがって、持続的なSSOTにはエンジニアリングと並んでガバナンスが必要です。それは、アカウント、案件、ステージ、レベニューについての合意された一つの意味を、書き留めて誰かが所有することを意味します。それは、どのシステムがどの事実に対して権威を持つか(レベニューには請求、ステージにはCRM)を決定し、もはやすべてのシステムのバージョンを等しく有効なものとして扱わないことを意味します。それは、消費者が各フィールドがどれだけ新しいか、どこから来たかを見られるようにすることを意味します。先週のスナップショットの上に構築されたアトリビューションは誤解を招くからです。そしてそれは、統一された層への広いアクセスと明確な所有権を組み合わせることを意味します。そうすれば、定義が四半期以内にまた乖離することはありません。

これはまた、数字が財務部門との接触に耐えられるようにする規律でもあり、それはなぜあなたのCFOはあなたのアトリビューションを信用しないのかの主題全体です。CFOはより美しいチャートを望んでいません。彼らはその数字が総勘定元帳と一致することを知りたいのです。

十分なアーキテクチャ、過剰ではなく

始めるために2年がかりのデータプラットフォームの取り組みは必要ありませんが、正しい形は必要です。実用的なバージョンは層状です。すべてのソースからの生の取り込み、正規のキーを割り当てるアイデンティティ解決ステップ、ガバナンスされた定義の下でイベントがアカウントとレベニューに結合されるモデル化された層、そしてレポーティングとアクティベーションの両方に供給するサービング層です。より完全な設計図はレベニュープラットフォームのためのリファレンスアーキテクチャにあります。

それが膨れ上がるのを防ぐ二つのことがあります。

レポーティングだけでなくアクティベーションのためにモデル化しましょう。ダッシュボードにしか供給しないSSOTは半分しか構築されていません。同じ統合された層が、散在するデータを次善のアクションに変えるという前提の通り、担当者にライブシグナルと次善のアクションを供給すべきです。唯一の消費者が週次レポートであれば、その層は誰も日々それに依存しないため劣化していきます。

そしてアイデンティティ解決は購入しましょう。大規模なコンタクト対アカウントのマッチングは十分に解決された問題であり、自分たちで構築することはめったにエンジニアの価値に見合いません。Revnewoのようなオーケストレーションプラットフォームはこの統合層をネイティブに提供するため、チームの時間は配管ではなく定義とアクションに使われます。

重要なポイント

• 基本的なカウントが食い違うなら、アトリビューションモデルはすでに間違っています。重み付けについて議論する前に基盤を修正しましょう。
• 断片化は正常です。すべてのツールは自分自身のその一部分にとっては良いシステム・オブ・レコードであり、他のすべてにとっては悪いものです。
• 3つの結合がほとんどの仕事をこなします。コンタクト対アカウント、アカウント階層、タッチ対レベニューです。
• 定義と所有権は、モデリングの巧妙さよりも重要です。食い違う定義を持つ統一されたストレージは、単に議論を移動させるだけです。
• レポートだけでなくアクションにも供給するように層を構築し、アイデンティティ解決をゼロから再構築しないようにしましょう。

これはどれもアトリビューションの刺激的な部分ではありません。それは他のすべてが立脚する部分です。もしあなたがあらゆる分析の前に矛盾する数字を突き合わせているなら、アイデンティティとレベニューの統合を扱うレベニューオーケストレーションプラットフォームが、それを止める方法です。