パートナーアトリビューションとは？

著者: Brian Tr · 更新日: 2026年10月5日

同じ案件に、2社のパートナーが関わっています。1社は9か月前に最初の紹介をしました。もう1社は先月、PoC（概念実証）を実施しました。成約させたのは自社の営業担当です。誰が貢献として評価され、誰がコミッションを受け取るのでしょうか。

この問いがパートナーアトリビューションであり、既定のままで適切に答えが出ることはめったにありません。多くの会社は、マーケティングチャネルがどう貢献として評価されるかについては明確な考えを持っています。パートナーについてそれを書き出している会社は、はるかに少数です。そのギャップが、紛争の始まる場所です。

本記事では、パートナーアトリビューションを定義し、起点（sourced）、影響（influenced）、支援（assisted）の売上を区別して、貢献を記録する仕組みを整理します。主なモデルを比較し、Microsoft、AWS、Salesforceがこの問題を自社のドキュメントでどう扱っているかを示します。最後に、アトリビューションが言い争いに発展するのを防ぐガバナンスのルールを取り上げます。

パートナーアトリビューションとは

パートナーアトリビューションとは、案件とそこから生まれる売上の貢献を、それに寄与したパートナーに割り当てる取り組みです。貢献は、案件が作られた時点で記録することも、案件の進行に合わせて更新することも、成約後に計算することもできます。

一見するとレポートの問題に聞こえますが、実際にはお金の問題です。アトリビューションの結果は、通常、次の3つに使われます。

• 支払い。 コミッション、紹介手数料、リベート、その他の報酬は、誰が貢献として評価されるかに基づいて計算されます。これらの報酬の構造についてはパートナーインセンティブをご覧ください。
• パフォーマンスの測定。 パートナースコアカード、ティア設定、プログラムの健全性レポートは、いずれも各パートナーがどれだけの売上を生んだかを把握していることが前提です。
• 投資の判断。 経営陣は、アトリビューションされた売上を使って、どのパートナー、どのパートナータイプにより多くのリソースを割くべきかを判断します。

アトリビューションは、マーケティングアトリビューションと関連はあるものの、別物です。リードから売上までのアトリビューションの仕組みが答えるのは、「どのキャンペーンとチャネルがパイプラインを生んだか」です。パートナーアトリビューションが答えるのは、「どの外部組織が、この特定の案件を生み出した、または成約を助けたか」です。パートナーがマーケティングデータ上のソースになっている場合、両者は重なり、調整が必要になることもよくあります。両チームが信頼できるアトリビューションモデルの考え方の多くは、そのまま当てはまります。

起点、影響、支援

プログラムごとに使う言葉が異なるため、自社の定義を明示してください。ここで挙げる3つは、よく使われるものです。以下の定義は本記事での実用上の定義であり、業界標準ではなく、ベンダーによって線の引き方が異なる場合があります。

「影響」と「支援」を1つの区分にまとめているプログラムもあります。ほかの人が案件を獲得した後に製品を導入または再販するパートナーのために、「履行（fulfilled）」や「納品（delivered）」という第4の区分を加えるプログラムもあります。

重要なのは、これらの区分で報酬が異なるという点です。起点の案件は、通常、最も高い報酬を得ます。パートナーが、本来は存在しなかったパイプラインを作ったからです。影響の案件は、報酬が少なくなるか、サービスマージンや固定料金のような別の種類の報酬になります。得られるものが違うため、パートナーには自分の関与をより価値の高い区分に寄せる動機があり、ルールはそれを見越しておく必要があります。

アトリビューションの仕組み

貢献はどこかに記録しなければなりません。プログラムは通常、これらの仕組みのいくつかを組み合わせます。単独の仕組みよりも、組み合わせ方が重要です。

ディールレジストレーション

パートナーは、商談が育つ前または育つ過程でベンダーに案件を申請し、ベンダーが承認または却下します。承認によって、タイムスタンプ付きの権利主張が成立します。これは最も明示的な仕組みで、起点の貢献に最もよく使われます。誰が最初に手を挙げたかを記録するため、多くの紛争を始まる前に解決します。プロセスの詳細はディールレジストレーションをご覧ください。

紹介リンクとトラッキングコード

パートナーが、リードや顧客を自分に紐づける固有のリンク、コード、フォームを共有します。アフィリエイトや小規模な紹介パートナーのような、件数が多くて接点の少ない関係に向いています。弱点は、貢献がクリックやコードの有無に依存することで、買い手が別の経路から戻ってくると崩れます。ここでは、紹介、アフィリエイト、リセラーのモデルの違いが重要になり、紹介、アフィリエイト、リセラーの違いで解説しています。

CRMのパートナー項目

ベンダーは、パートナーの関与をCRMに直接記録します。よくあるパターンは、リードや商談に置く「パートナーソース」項目、パートナーアカウントへの参照、1つの商談を複数のパートナーに結びつけて各パートナーに役割を持たせる中間レコードです。項目ベースのアトリビューションは低コストですが、入力する人の確かさ以上には信頼できません。入力規則がなければ、項目は空欄のままになったり、上書きされたりします。

タッチベースのモデル

これらはマーケティングから借りたものです。パートナーとのやり取りがすべてタッチとして記録され、計算式によって貢献がタッチに配分されます。テクノロジーアライアンスやインテグレーターのように、パートナーが複数の段階で貢献する場合に、よく使われます。

モデルの比較

マーケティングアトリビューションは、パートナープログラムに用意された語彙を提供します。以下の最初の3行はそこから借りたもので、残りはパートナー固有です。

普遍的に正しいモデルはありません。パートナーが名前を渡して手を引く紹介プログラムなら、登録ベースかファーストタッチで十分に機能します。インテグレーター、リセラー、コンサルタントの全員が同じ案件に関わるプログラムでは、通常、役割ベースかマルチタッチのルールが必要です。

マーケティングからの借用については、注意が1点あります。Google自身のドキュメントは、Google Analytics 4では、ファーストクリック、線形、時間減衰、ポジションベースのアトリビューションモデルは提供されなくなったこと（変更は2023年11月に発効）、そしてデータドリブンアトリビューションは、各キーイベントのデータに基づいて貢献を配分することを述べています。マーケティングの世界がデータドリブンのモデルへ移行してきたのは、ルールベースの分割が恣意的だからでもあります。パートナープログラムでは、恣意的であっても許容される場合があります。ルールが契約上のものであり、パートナーは予測可能性と引き換えに、定められた計算式を受け入れるからです。リスクは、ルールが単純なことではありません。文書化されていないことです。

ベンダープログラムの扱い方

大手のエコシステムベンダーは、共通の語彙を使っていません。3社がパートナーの貢献をどう構造化しているかを見ると、設計上の選択肢が分かります。

Microsoft

MicrosoftのPartner Centerは、コセリングを「Microsoftとそのパートナーエコシステムとの間のあらゆる協働的な取り組み」と説明し、コセルの商談のカテゴリを挙げています。Microsoftの営業チームとのコセル、パートナー間、プライベートディール、ソリューション評価です。アトリビューションの観点で注目すべきは「プライベートディール」のカテゴリで、パートナーが独自に進めている案件をMicrosoftと共有し、分析と予測のためにMicrosoftのレポートシステムに反映させることができます。これにより、パートナーは自力で進める案件を記録する手段を持てます。

Microsoftのドキュメントは、そのやり取りの流れも示しています。紹介に関するコミュニケーションのページによると、受信したコセルの商談は、期限日までに承認または辞退しなければならず、対応しなければ自動的に辞退となります。同じページは、案件の登録を修正のために差し戻したり、レビューのためにフラグを立てたりできる、案件検証チームについても説明しています。つまり貢献は、前提として与えられるものではなく、提示され、受け入れられ、検証されるものです。

AWS

AWSは、APN Customer Engagements（ACE）プログラムを通じて商談の共有を運用しており、パートナーはAWSとの協業のための商談を作成、共有、受信できます。商談のライフサイクルに関するAPIリファレンスは、検証のステップがどれだけ形式化されているかを示しています。パートナーが紹介した商談では、レビューのステータスが、Pending Submission、Submitted、In Review、Action Required、Approved、Rejectedといった値を移り、承認された商談は検証されたうえでAWSのセラーのパイプラインに変換されます。ドキュメントはまた、リードは提出前に「Qualified」の商談まで育てておく必要があるとも述べています。

AWSはさらに、各商談にコセルモーションを割り当て、誰が主導するかを決めています。文書化されているモーションには、AWS Field-engaged、Agent-engaged、Partner-ledがあり、最後のものはパートナーが商談を所有して推進することを意味します。この区別は、誰が案件をもたらしたかと誰が案件を進めているかを分けるもので、起点か影響かという問いを別の形にしたものです。

Salesforce

SalesforceはCRM側を担います。ヘルプのドキュメントによると、商談では、Partnersの関連リストからパートナーを追加し、それぞれに役割を割り当て、Primaryを選択して主要パートナーを選べ、主要としてマークされたパートナーは商談レポートに表示されます。パートナーを追加すると逆方向の関係も作られ、各アカウントが互いを一覧に表示し、管理者がどの役割を設けるかを設定します。

設計上の教訓は、Salesforceを使っていなくても役に立ちます。1つの「パートナー」項目では、3社のパートナーが関わる案件は表現できません。商談と1社以上のパートナーを結ぶ中間レコードに、それぞれの役割とPrimaryのフラグを持たせれば、表現できます。

重要なポイント：パートナーアトリビューション

• パートナーアトリビューションは案件の貢献をパートナーに割り当て、その評価は通常、コミッション、紹介手数料、パートナースコアカードを左右します。
• 一般的な仕組みは、ディールレジストレーション、紹介リンク、CRMのパートナー項目、タッチベースのモデルです。
• Microsoft Partner Centerは、パートナー間やプライベートディールを含むコセルのカテゴリを挙げ、期限日までに対応されなかった受信のコセル商談は自動的に辞退となります（Microsoft Learn）。
• AWSのパートナー紹介の商談は、AWSのセラーのパイプラインに入る前に、レビューのステータス（Submitted、In Review、Approved、Rejected、Action Required）を経ます（AWS）。
• Salesforceでは、1つの商談に複数のパートナーを、それぞれの役割とともに持たせることができ、Primaryのフラグが商談レポートに表示されるパートナーを制御します（Salesforce Help）。
• Google Analytics 4は、2023年11月にファーストクリック、線形、時間減衰、ポジションベースのモデルを廃止しました（Google）。

アトリビューションが対立を生む理由

貢献はお金になるため、貢献をめぐる意見の相違は対立になります。いくつかのパターンが繰り返し現れます。

二重計上。 2社のパートナーが同じ売上の貢献として評価され、ベンダーの支払総額が本来あるべき額を超えます。パートナーAの登録が承認されたあとに、パートナーBの別の紹介が評価され、主要な貢献は1社のみとするルールがない場合に起こります。対策は、案件ごとに主要な貢献を1つに限り、副次的な貢献には上限を設け、定められた原資から支払うことです。

登録の囲い込み。 パートナーが、取り組む計画もないまま、多数のアカウントを早い段階で登録して囲い込みます。有効期限と活動の要件がなければ、古い登録がその後のあらゆるパートナーを妨げます。進捗の証拠がない限り、登録は失効させるべきです。

直販とパートナーの対立。 ベンダー自身の営業担当とパートナーの両方が、同じ商談の権利を主張します。これはチャネルコンフリクトの核心であり、アトリビューションのルールは、それが個人的な争いになる前に解決するための主要な手段です。

遡及的な請求。 パートナーが成約済みの案件を見つけ、数か月前に自分が影響を与えたと主張します。プログラムには、それを過ぎると貢献を請求できない請求期間が必要です。

役割の水増し。 起点のほうが報酬が高いため、パートナーは支援にとどまる貢献を「起点」と説明します。各区分に証拠の要件を設ければ、これを減らせます。

紛争を防ぐルール

ほとんどの紛争は、最初の案件より前にルールがあれば避けられます。実際に機能するルールセットは、次の点を扱います。

1. 定義。 起点、影響、支援が何を意味するかを、それぞれの例とともに書き出します。
2. 優先順位。 2つの権利主張が衝突したとき何が優先されるかを定めます。最も早く承認された登録、役割ベースの分割、または指名されたレビュアーです。
3. 案件ごとに主要は1つ。 主要な貢献の保持者は1社のみとし、副次的な貢献の仕組みを定義します。
4. 有効期限。 登録と紹介の権利主張には、定められた有効期間と更新の条件を設けます。
5. 証拠。 各区分で何が証明になるかを列挙します。登録記録、記録されたミーティング、署名済みの作業範囲記述書（SOW）などです。
6. 請求期間。 案件の成約後、パートナーがどれだけの期間、貢献を請求できるかを定めます。
7. 確定のタイミング。 貢献がいつ固定されるかを決めます。通常は受注（closed-won）の時点で、後の編集で支払いが動かないようにします。その後の変更には承認を必須にします。
8. データの所有。 CRMのパートナー項目を誰が維持し、誰が編集できるかを明示します。

これらは、パートナー契約、またはパートナーが承諾するルール・オブ・エンゲージメント（取り決め）の文書に盛り込んでください。契約面の起案については、こうした文書に通常何が含まれるかをパートナー契約で解説しています。

紛争の解決

明確なルールがあっても、争いになる案件は出てきます。プロセスを事前に決めておきましょう。

• 第1段階：パートナーマネージャー。 パートナーマネージャーが証拠を集め、書面のルールを適用します。ほとんどの紛争はここで終わります。
• 第2段階：パートナーオペレーションまたはチャネルのリーダーシップ。 どちらのパートナーのコミッションにも関わりのない中立的な立場の者が、証拠を確認して決定します。
• 第3段階：エグゼクティブスポンサー。 戦略的パートナー、または定められた案件規模を超える紛争のために取っておきます。

すべての決定と、その理由の記録を残してください。決定の記録は、プログラムが長期にわたって一貫性を保つ手段であり、ベンダーがえこひいきとの非難を受けることを防ぎます。紛争によってルールのあいまいさが明らかになったら、例外を前例のように見せるのではなく、今後に向けてルールを直してください。

レポートもここで重要です。複数のパートナーが関わる案件の割合、四半期ごとの紛争件数、解決までの時間を追跡します。紛争率の上昇は、通常、パートナーの問題ではなくルールの問題を示します。これらの指標は、パートナーKPIのプログラムレベルの指標と並べて見るべきものです。

出発点の選び方

アトリビューションをゼロから作るなら、範囲を絞って始めてください。主要な仕組みを1つ選びます。起点の貢献には、通常ディールレジストレーションです。最初から構造化されたデータになるよう、役割付きのCRMのパートナー項目を加えます。「起点」と「影響」を書面で定義します。1四半期運用し、紛争を振り返り、そのうえで初めてマルチタッチや役割ベースの分割を検討します。複雑さは、必要に後からついてくるべきものです。

関連記事

• ディールレジストレーション
• チャネルコンフリクト（チャネル間の対立）
• パートナーインセンティブ：マージン、リベート、SPIFF
• 紹介、アフィリエイト、リセラーの違い
• リードから売上までのアトリビューション
• 両チームが信頼できるアトリビューションモデル
• パートナーリレーションシップマネジメント（PRM）とは？