多方交易的归因模型

翻出上个季度一笔已成交的企业级交易，数一数涉及的各方。一个转介合作伙伴牵了线，一家系统集成商负责实施，一家 ISV 的集成能力是让你进入候选名单的技术门槛，一家云计算巨头的应用市场处理了这笔交易，而你自己的客户经理从头到尾主导了整个过程。五个贡献方，CRM 里却只有一个"合作伙伴"字段和一个"商机负责人"字段。

这个落差就是多方归因问题，而它早已不再是边缘案例。一旦有四方触碰同一笔交易，"到底是谁带来的？"就没有干净的答案，默认做法（谁先填了那个字段算谁的）会产生一个没人信任的数字。解决办法不是去寻找那个唯一真正的归属人，而是有意识地选择一种归因模型，理解它牺牲了什么，并且每次都用同样的方式去应用它。

为什么单一归属的归因方式会失灵

人的本能是指认出责任最大的那一方，把全部功劳都给他。但在一笔真正涉及多方的交易中，这种做法带来的误导会不断累积。

它抹去了贡献。只把功劳记给来源合作伙伴，系统集成商和 ISV 看起来就像什么都没做，尽管没有他们这笔交易根本不会成交。连续几个季度这样做，这些合作伙伴就会不再出现。

它会诱发博弈行为。当功劳是赢家通吃时，每一方都会争着当赢家，无论实际发生了什么，谁掌控了 CRM 字段谁就赢。我们之前在无人谈论的联合销售归因难题一文中写过这种机制。

它还掩盖了交易实际达成的方式。如果你的数据显示每笔交易都恰好只有一个合作伙伴，你就永远看不出哪些合作伙伴组合能带来你最好的结果。而这恰恰是你在决定投资方向之前最想知道的事情。

单一归属在交易简单的时代是说得通的，但现在已经不是了，所以你需要一种能够表达共享的、差异化功劳的模型，而且你需要主动去选择它，而不是全盘接受 CRM 出厂自带的那一套。

各种模型，以及每一种的代价

上述模型没有哪一种在抽象意义上是"正确的"。每一种都在不同的地方，用简单性去交换公平性。

**首次触达（First-touch）**把全部功劳记给发起这笔交易的一方，通常是转介或来源合作伙伴。简单，而且奖励了需求创造，这是合作伙伴能为你做的最难、也最有价值的事情。但它忽略了所有推动或促成成交的人，所以联合销售和实施合作伙伴什么也得不到。如果你最需要购买的行为是净新增的销售管道，这种模型是合理的。

**末次触达（Last-touch）**把全部功劳记给成交时参与的一方，往往是联合销售或交付合作伙伴。它奖励了那个把交易推过终点线的人，同时把来源合作伙伴的功劳彻底抹去。根据我们的经验，这通常是所有可选方案中最不公平的结果，也很少适合作为主要模型。

**平均多点触达（Equal multi-touch）**把功劳平均分给每一个实质性触碰过这笔交易的一方。每个人都得到了认可，争夺唯一功劳的动机也随之下降。问题在于，它把一次促成交易的引荐和一次微不足道的协助等同看待。平均不等于公平。

加权，即基于角色的模型，按角色分配功劳：为来源设定一个份额，为影响设定一个份额，为交付设定一个份额。这是最接近多方交易实际创造价值方式的模型。代价是你必须提前定义并商定好这些权重，并且要在数据中捕捉每一方的角色。

大多数成熟的项目最终都会采用加权模型，因为它直接对应了影响型与来源型合作伙伴收入之间真实存在的区别。你可以在同一笔交易中，给来源合作伙伴和影响合作伙伴都记上有意义的功劳，而不必假装其中只有一方存在。

选定一个模型，并坚持下去

选择哪种模型，其重要性不如以下两件事：有意识地做出选择，并且每次都一以贯之地应用它。一个平庸但统一应用的模型，胜过一个每逢提成攸关就被重新协商的"完美"模型。

让模型指向你所欠缺的行为。需要更多净新增销售管道？就为来源赋予更高权重。需要合作伙伴帮忙促成成交？确保成交贡献能获得功劳。模型本质上是一种激励，所以要瞄准目标去设计它。

在季度开始之前就做出决定，而不是事后。趁大家都还冷静、谁的收入都还不取决于结果的时候，商定好模型及其权重。到季度末才裁定的归因问题，最终都会演变成政治斗争。

功劳汇报要与提成分开。用于理解业务（哪些合作伙伴驱动了收入）的归因，可以、也往往应该与实际支付的提成有所不同。把两者混为一谈，你最终会为了迁就其中一个而扭曲另一个。

有意为之的重复计入。出于项目衡量的目的，同一笔金额完全可以合理地记在多个合作伙伴名下，只要每个人都明白总数并不应该等于总预订额。要清楚地标注这一点，以免财务部门产生困惑。

底层的数据模型

如果没有能够支撑它的数据，上述每一种模型都会崩溃。你无法在一个只有单一合作伙伴字段的 CRM 上运行加权的、基于角色的模型。这种架构从字面意义上就无法表达一笔交易上有两个角色不同的合作伙伴。每笔商机你需要的是：

• 多个参与方
• 每一方明确的角色（来源、影响、联合销售、交付）
• 每次触达的时间戳，在发生时就被捕捉，而不是事后重构

没有这些，你就只剩一个下拉菜单和一场季度末的争论。搭建这个基础，并让它在 CRM、合作伙伴门户、应用市场以及联合销售实际发生的 Slack 会话线程之间持续得到更新，这是一个收入编排问题：把多方信号汇入一个带时间戳的统一模型，这样无论你选择哪种归因逻辑都能基于它运行。把这一步做对，切换或调整模型就会变成一次配置调整，而不是一次数据迁移。

关键要点

• 大多数企业级交易如今都有多个贡献方，而单一归属字段要么抹去贡献者，要么奖励打字最快的那个人。
• 首次触达、末次触达、平均分配和加权分配各有代价。加权模型是大多数认真的项目最终的归宿。
• 一致性胜过精确性。在季度开始前商定模型，不要在提成压力下重新讨论它。
• 让项目归因和提成计算保持独立的计算方式，并坦然接受项目功劳总和会超过预订额这一事实。
• 这一切都无法运行在一个只有单一合作伙伴字段的 CRM 上。先修好数据模型。

一旦多方归因运转起来，合作伙伴数据就不再是每季度的一场争吵，而会开始向你展示收入究竟是如何产生的。如果你正在为涉及四个贡献方的交易设计归因模型，Revnewo 处理多方功劳的方式是一个合理的起点。