在联盟计划中，仅仅知道一笔销售发生了，还远远不够。企业需要理解它来自哪里、哪位参与者参与了这段旅程、按照什么规则去归属这一结果，以及这一归属又将如何产生一笔佣金。
正因如此，tracking、attribution 与 commission management 需要被视为彼此相关、但又各不相同的概念。
用一种简化的视角来看：
互动 → 识别 → tracking → 转化 → attribution → 验证 → 佣金。
当这些环节没有被清晰地区分开来时，就会出现重复计数、数据分歧、佣金错误以及难以审计等问题。
Tracking、Attribution 与 Commission 并不是一回事
Tracking
记录事件，并识别特定互动的来源。
它主要回答：
“发生了什么，又来自哪里？”
Attribution
应用一条规则，来确定谁将因某一结果而获得归属。
它回答：
“这次转化应当归属于谁？”
Commission
在已验证的转化之上，应用经济性规则。
它回答：
“谁应当获得报酬、金额是多少、依据的又是哪条规则？”
一项成熟的运营，需要以集成的方式掌控这三个环节。
一位联盟成员可以如何被识别？
识别可以通过不同的机制来实现，例如：
- 专属链接；
- 参数；
- 标识符；
- 促销码；
- 落地页；
- 个人商城；
- 活动；
- 由运营定义的其他引用方式。
所选择的模型取决于商业旅程。
核心在于确保参与者、互动与最终转化之间，存在一种可靠的关联关系。
Tracking 记录了什么？
视具体计划而定，可能被记录的事件包括：
- 点击；
- 访问；
- 浏览；
- 线索；
- 注册；
- 结账开始；
- 订单；
- 销售；
- 订阅；
- 其他相关的转化。
并非每一个事件都必然产生佣金。
Tracking 记录的是这段旅程。后续的规则，才决定了哪些对该计划具有经济价值。
转化需要拥有一个可靠的身份
设想一位消费者点击了一个联盟链接，随后完成了一笔购买。
要让这项运营正常运作，系统需要正确地关联：
参与者 → 互动 → 消费者或会话 → 订单 → 转化。
旅程越复杂，这种关联就越难建立。
问题尤其容易在存在以下情形时出现：
- 多个设备；
- 多个渠道；
- 互动与购买之间存在较长的时间间隔；
- 促销码；
- 同时进行的多个活动；
- 涉及不同的参与者。
什么是归因窗口？
企业可以规定，一次互动在多长时间内仍然有资格因后续的转化而获得归属。
这段时间通常被称为归因窗口。
例如，一条规则可以将某次互动在特定天数之内视为有效。
并不存在一个适用于所有业务的通用窗口。
它取决于购买周期、产品、商业策略以及计划规则。
First click、last click 及其他规则
决定谁获得归属，存在不同的方式。
First click
将结果归属于与第一次有效互动相关联的参与者。
Last click
将结果归属于转化之前、与最后一次被视为有效的互动相关联的参与者。
决定性的代码或标识符
企业可以规定，购买时所使用的某个特定代码优先于其他互动。
自定义规则
更为复杂的运营可以采用特定的业务标准。
重要的是，这条规则必须清晰、可预测且可审计。
涉及多位参与者的旅程所带来的问题
请考虑这样一种情形：
- 消费者通过参与者 A 了解到产品；
- 随后访问了参与者 B 的内容；
- 之后使用了参与者 C 的代码；
- 最终完成了购买。
那么，谁应当获得归属？
并不存在一个通用的技术答案。
答案是一项商业模型的决策。
平台需要能够一致地应用这一决策。
Client-side 与 server-side tracking
追踪可能涉及不同的技术层面。
Client-side 的方式通常更依赖于浏览器与用户体验。
Server-side 的方式则允许某些事件在系统之间被直接记录。
在现代化的运营中，不同的机制可以并存。
如何选择，取决于架构、所使用的渠道、隐私方面的需求，以及适用于该市场的规则。
不应把 cookies 当作唯一的答案
Cookies 可以成为 tracking 的一部分，但一套联盟架构从概念上不应仅仅依赖它们。
还存在其他可能的要素：
- 自有标识符；
- 已认证的数据；
- 代码；
- server-side 事件；
- 订单 ID；
- 活动 ID；
- 由平台自身持久化的关系。
运营越是关键，就越需要拥有可靠的识别与对账机制。
隐私与同意
Tracking 与 attribution 处理的是数字化的数据与行为。
因此，其实现需要考虑：
- 隐私；
- 在适用时的同意；
- 数据最小化；
- 治理；
- 市场所在地的法律法规；
- 所使用平台的政策。
并不存在一套适用于所有国家的有效配置。
架构需要允许企业以恰当的方式，履行其各项政策与义务。
Cross-device（跨设备）
一位消费者可能会：
- 在手机上发现一项优惠；
- 在平板上再次搜索；
- 在电脑上完成购买。
这段旅程给归因带来了挑战。
如果缺乏某种合法的共同识别方式，不同的设备就可能看起来像是彼此独立的用户。
因此，cross-device attribution 需要恰当的架构与数据，而不仅仅是一个联盟链接。
去重（Deduplicação）
同一笔转化，可能会通过多个来源进入系统。
例如：
- 电商集成；
- 像素（pixel）；
- webhook；
- API；
- 数据导入；
- 其他事件。
如果不存在去重机制，同一个订单就可能被计数不止一次。
一个唯一的转化或订单标识符，往往是避免这一问题的关键所在。
取消、退货与 chargeback
一笔最初被记录下来的转化，可能会不再有效。
这在如下情形中会发生：
- 取消；
- 退货；
- chargeback（拒付）；
- 欺诈；
- 无效订单。
因此，一笔佣金可能会经历如下状态：
已识别 → 已归属 → 待定 → 已验证 → 符合资格。
具体的命名可能有所不同，但对这一周期的治理十分重要。
Attribution 并不意味着立即支付佣金
一笔被归属给参与者 A 的销售，并不必然意味着这笔佣金应当被立即释放。
在此之前，可能还会存在：
- 各项验证；
- 退货期限；
- 反欺诈分析；
- 资格规则；
- 活动的特定条件。
架构需要将归属与佣金的结算区分开来。
如何处理优惠券与促销码？
代码可以作为一种额外的归因机制来使用。
企业可以规定，例如：
- 代码优先于链接；
- 链接优先于代码；
- 某个特定活动拥有专门的规则；
- 代码仅对被授权的参与者有效。
这些规则需要在计划中被正式确立，并由平台加以再现。
联盟成员与自有付费媒体
另一项挑战出现在消费者同时与联盟成员和企业自有的媒体活动发生互动时。
组织需要决定，这些渠道如何共存。
技术应当提供足够的数据，让企业能够在不重复计算结果的前提下应用其规则。
联盟成员与顾问或经销商
联盟营销与直销之间的融合，带来了更加值得关注的情形。
一笔销售可能同时拥有：
- 一位负责来源的联盟成员；
- 一位与该客户相关联的顾问；
- 一个商业架构；
- 不同的报酬规则。
平台需要知道：
- 是否只有一位参与者获得报酬；
- 是否双方都获得报酬；
- 是否存在优先级；
- 是否存在分成；
- 某些模型是否不能共存。
这同样是一项商业决策，需要由技术加以呈现。
Attribution 的审计
企业需要能够回答：
为什么这笔销售被归属给了这位参与者？
在理想情况下，历史记录能够呈现：
- 参与者标识符；
- 互动；
- 活动；
- 时间戳；
- 所应用的规则；
- 转化；
- 各项验证；
- 结果。
如果缺少这样一条追踪链，分歧就会变得难以调查。
重要的指标
Tracking 与 attribution 同样会产生用于管理的数据。
一些可能的指标包括：
- 点击；
- 访客；
- 线索；
- 转化；
- 转化率；
- 收入；
- 佣金；
- 平均客单价；
- 各联盟成员的绩效；
- 各活动的绩效；
- 已通过的转化；
- 被拒绝的转化；
- 取消；
- 历史演变。
目标不只是知道谁完成了销售，而是理解该计划的质量。
在一套 tracking 与 attribution 方案中应评估什么？
| 能力 | 评估要点 |
|---|---|
| 识别 | 如何识别参与者与互动 |
| Tracking | 可以记录哪些事件 |
| Attribution | 归属规则的灵活性 |
| 窗口 | 对归因周期的控制 |
| 去重 | 对重复转化的防护 |
| 验证 | 对取消与无效事件的处理 |
| 审计 | 对归属原因的解释 |
| 集成 | API、事件以及与 commerce 的连接 |
| 隐私 | 在适用规则内运营的能力 |
| Analytics | 对绩效的可见性 |
| 可扩展性 | 处理大量事件的能力 |
Tracking 需要与业务相连接
孤立的 tracking 只会产生事件。
孤立的 attribution 只会产生一条规则。
孤立的 commission 只会产生金额。
一项真正集成的运营，会将以下要素连接起来：
参与者 + 旅程 + 客户 + 订单 + attribution + 佣金 + 数据。
这种视角减少了对账工作，并提升了审计能力。
IDBCONNECT 与以绩效为导向的运营
IDBCONNECT 允许在同一套运营生态系统中，构建不同类型的参与者、商业规则、commerce、佣金结算、系统集成与数据。
这样的架构，为如下运营奠定了基础：联盟成员、顾问、creators 及其他合作伙伴，都可以带着各自的识别与报酬规则，参与到商业旅程之中。