affiliate-performance-dashboard

联盟营销绩效仪表板

定义联盟营销计划仪表板的衡量内容和布局方式，然后交付一份仪表板规格文档。交付物是规格文档，而不是已经构建好的仪表板；负责 BI 工具的人员会根据规格文档实施。

目前不存在公认的联盟营销仪表板框架，指标定义也尚未标准化：没有标准机构强制执行相关标准，IAB 和 PMA 只发布指导意见。务必向用户如实说明这一点；绝不要声称存在实际上并不存在的品牌化框架。

此方法仅借鉴以下四项成熟做法：

• 增量效果衡量，通过留出组和地理提升测试实现，并以对增量效果、基线转化和模型验证的明确界定为基础。
• 归因 ROAS 与归因 ROI 的区分：ROAS 用归因收入除以媒体成本，ROI 用归因收入除以媒体成本加 COGS。
• 来源与影响的区分规则。
• 分层指标体系加优质指标标准，摘自 Croll 和 Yoskovitz 的《Lean Analytics》：指标必须可比较、为比率或速率、易于理解，并能改变行为。

前两项定义所依据的平台术语表列在 references/metric-definitions.md 中，此处不再列出；无论该计划使用哪个平台，这些定义都是此技能的实际适用定义。

基本原则

• 报告已验证／已批准的佣金和净收入，绝不报告毛额——毛额数值更大，也是业内人士最常犯、提及最多的错误。
• 为每项指标提供一句话定义，说明分子、分母、时间窗口、时区和计数方法。无法用一句话说明的定义，就是装样子。
• 为每项基准数据标注来源：供应商、行业组织、综合分析，或计划自身推导的基线。几乎所有已发布的联盟营销基准数据，都来自有动机夸大该渠道成效的一方。
• 绝不汇总合作伙伴来源收入和合作伙伴影响收入；应将两者作为两个单独的、设有上限的数字报告。
• 绝不比较验证窗口不同的两个时段——撤销延迟会让较近的时段看起来虚高。
• 欺诈和合规信号必须与绩效数据放在同一视图中，绝不能放在单独的工具里——每日决策者需要同时查看两者。

访谈

在指定任何内容前，先提问，并遵循以下规则：

• 每条消息只问一个问题。

• 尽可能采用多选题。

• 跳过已回答的问题。

• B2B SaaS、B2C 电商，还是两者兼有？

• 项目规模和成熟度：活跃合作伙伴数量、每月佣金支出、项目运行时间？

• 谁会阅读仪表板——高管、运营人员，还是两者都有——仪表板应支持什么决策？

• 佣金模式是什么？其中是否有经常性佣金？

• 验证／锁定期有多长？追回政策是什么？

• 归因模型和 Cookie 窗口期是什么？

• 有哪些数据源——联盟平台、计费／订单、CRM、数据仓库——合作伙伴 ID 是否能传递到计费或订单中？

• 是否按合作伙伴记录类型／推广方式？

• 是否按转化记录新客与回头客？

• 刷新能力和工具限制是什么——实时查询、每日批处理、手动导出？

• 当前的痛点是什么：项目目前无法回答哪个问题？

• 目前的报告频率如何？已有的审查会议有哪些？

• 首个版本最迟何时必须交到读者手中？

• 一次性成果——现在就解决一个有争议的问题——还是可持续增值的资产，项目每周都以此为基础运行？

• 工作量上限：可用的分析师工时有多少、由谁负责数据关联，以及是否有经费支持持续维护？

最后三个问题的答案会重新排列本技能及其参考资料中的所有选项菜单。请明确说出哪个答案改变了哪个选项：

• 截止日期临近时，规格会限定在订单主干上，并删去所有需要尚不存在的数据关联的指标。
• 若目标是打造可持续增值的资产，则优先纳入客户文件关联、群组视图和经流失率调整的合作伙伴 LTV。
• 工作量上限较低时，直接删除建模数据仓库、品牌竞价提醒和创意细分，而不是把它们放在规格底部。

这里的所有排序都是默认方案，而非定律——它会因情境和执行者而变化。根据你对用户已有的了解重新排序：能干净导出合作伙伴分类的网络、已加载计费和 CRM 数据的数据仓库，或者完全没有分析师，这些情况都会改变不同的优先级。

工作流

1. 进行访谈；收集规格所依赖的每一项答案。

2. 确定事实来源并编写可比性约定——事件定义、日期依据、时区、币种、计数方法——然后再指定任何指标。后续每个数字都会沿用这些选择；之后若更改，将使所有历史数据失效。这里有三种数据基础可选，按单位工作量的价值排序，其中工作量指对账工作和持续维护：

   • 效率：计费／订单主干 > 客户文件关联 > 建模数据仓库
   • 价值：建模数据仓库 > 客户文件关联 > 计费／订单主干
   • 工作量（从高到低）：建模数据仓库 > 客户文件关联 > 计费／订单主干

   这三种数据基础的成本各不相同：

   • 主干：花一两天将平台导出数据与订单或计费数据对账，之后几乎没有持续成本。
   • 客户文件关联：需要一两个月，因为必须在创建订单或账户时写入合作伙伴 ID，才能计算新客户和来源型与影响型转化。
   • 建模数据仓库：需要持续运行的作业。

   默认从主干开始，只有在某项明确的决策需要时才向上升级。

   删除，而非降级：将联盟平台自身的导出数据作为事实来源。那是申报方的数据，因此节省的工作量无法弥补其问题；平台仍是点击和流量的数据来源，并与资金主干对账。

   这一顺序所牺牲的是建模数据仓库：它价值最高，却每轮都落选。当项目当前要解决的问题是增量效果而非报告，或一次重新定价决策带来的资金变动超过构建成本时，再将其提到优先位置。

3. 选择指标层级组合：业务／核心指标层、输入／驱动指标层、健康度／护栏指标层。

   有四项指标是底线而非可选项，因为不具备这些指标就无法达到通过门槛：

   • 项目净贡献
   • 销售成本
   • 头部 N 个合作伙伴的集中度
   • B2B 中由合作伙伴带来的 MRR/ARR

   超出这一底线的内容都是可选项：根据 references/metric-definitions.md 中的效率排序，选取你所在细分市场排名靠前的指标；该排序分别列出 B2B 和 B2C，并指出每种排序会舍弃什么。拒绝任何不符合四项优秀指标标准的指标，并在仪表板试图展示一切、因而什么也没能展示之前停止添加指标。删除所有 Interview 表明数据不存在的指标，并将其列在“待处理事项”下，而不是把它们作为愿望留在规格中。

4. 编写每项指标的规格行（见“输出格式”），明确解决所有相互竞争的定义——选定的分子、分母、时间窗口和计数方法都要写在行中，而不是只存在于某个人的脑海中。

5. 按照 references/layout-cadence-and-alerts.md 中的效率排序，选择项目数据实际支持的切片维度：partner > partner type > product/plan > geography > device > landing page > creative。合作伙伴类型并非成本最低的切片，也是最能带来收益的切片——仍要构建它。

6. 按受众分别规划视图：高管视图和运营人员视图在指标上应有所不同，而不只是详细程度不同。

7. 按层级设定刷新和审查频率——每个层级都有自己的自然节奏；整个仪表板使用同一个刷新频率是缺陷。

8. 为每项告警设定阈值、负责人、渠道和预期响应时间；优先采用基于滚动基线的动态阈值，而非静态阈值。按照 references/layout-cadence-and-alerts.md 中的效率排序发布告警：reversal-rate spike > single-partner share spike > click-to-conversion anomaly > EPC drop > brand-bidding flag；当团队的注意力达到上限时就停止，而不是填满整个告警栏。

9. 根据项目自身的历史数据推导基线；不要采用任何供应商基准作为基线。已发布的数据只能用于校准预期（references/concentration-and-cohorts.md、references/roi-and-incrementality.md）。

10. 按章节与用户逐项验证规格——先验证定义，再验证视图，然后是频率，最后是告警——之后再汇总成最终文档。以 references/worked-examples.md 中相匹配的完整示例为依据。

11. 检查下方的通过标准；反复迭代，直到每项标准都满足。

12. 如果你的工具环境支持持久记忆，请记住可比性约定、已达成一致的指标定义和推导出的基线，这样后续运行就能从这些内容开始，而不必重新协商。

输出格式

每份规格都应以此为交付产物：

DASHBOARD SPEC - <program>
Header    : program, audiences, source of truth, period conventions
            (timezone, date basis, currency, validation window)
Metrics   : one row per metric -
            Metric | Definition (formula, window, counting method) | Tier | Source |
            Visualization | Target | Alert threshold | Provenance
Views     : layout per audience - KPI tiles (value + delta vs stated prior period)
            -> trend/composition charts -> leaderboard/detail table -> alert strip
Dimensions: slicing dimensions (partner, partner type/promotional method, product,
            geography, device, landing page, creative)
Cadence   : tier -> refresh rate + review ritual (who reviews, when, deciding what)
Alerts    : register - metric | trigger | owner | channel | expected response time
Open items: data gaps, unconfirmed definitions, metrics and dimensions deleted
            because the data or the effort ceiling rules them out, and what would
            make each computable; questions for the next revision

在标题中记录所选的数据基础以及促成该选择的因素——后续读者无法仅凭指标行重新推导出这一选择。

完整示例位于 references/worked-examples.md，不要内嵌在此处。

通过标准

只有当项目负责人能够一眼回答“这个项目是否盈利，由谁推动”时，规格才算通过。具体而言，以下六项必须全部满足；反复迭代，直到全部达成：

• 任何人都能根据书面公式复现每个核心数字，即使此人并未构建该仪表板。
• 项目净贡献——经验证的佣金加上网络/代理费用，再与归因净收入对比——无需离开顶层视图即可查看。
• 在同一个顶层视图中即可查看头部合作伙伴集中度。
• 仪表板上的每项指标都有明确的决策用途；否则就删除。
• 没有任何指标的定义无法用一句话说明。
• 所有未纳入规格的指标、维度和告警都必须列在“待处理事项”下，并说明使其变得可计算所需的条件——不得悄悄将其搁置在文档底部。

B2B SaaS 与 B2C 电商

以下内容对两者同样适用：

• 可比性约定
• 指标分级
• 集中度分析
• 节奏规范
• 警报设计
• 经验证而非毛额的报告

真正的差异：

• 收入对象。 B2B 跟踪合作伙伴带来的 MRR/ARR，以及经流失调整的合作伙伴 LTV；B2C 跟踪订单级 CPA、AOV 和购物篮构成。
• 漏斗。 B2B 增加试用转付费这一第二转化阶段，以及交易注册和 MQL/SQL 管道阶段；B2C 则是从点击到下单，并以新客作为额外维度。
• 窗口。 对于周期较长的业务，B2B Cookie 窗口为 60-180 天；B2C 默认为约 30 天，而优惠券/返现流量的窗口还要更短。mbfinotti/partnerships-skills@affiliate-commission-structure 负责这些范围——解读窗口时，应结合其对应的数据，切勿与此处所述的另一组数据比较。
• 冲回因素。 B2B：试用失败、退款、降级、流失——由于佣金具有经常性，冲回会按周期发生。B2C：退货窗口期内的退货和拒付。

失效模式

缺陷	后果	修复
以虚荣指标作为标题（点击量、展示量、注册量）	仪表板看起来很忙，却无法指导决策	每项指标都必须对应一项明确决策；将计数指标降为诊断指标
报告总佣金，而非已验证佣金	项目看起来比实际更昂贵、产出也更高	标题只显示已验证／已批准的佣金；待处理部分单独显示
仅按最后一次点击计算项目 ROI	优惠券、返现和浏览器扩展合作伙伴的贡献被夸大；内容合作伙伴则资源不足	增加新客占比和增量测试；分别报告来源贡献与影响贡献
缺少集中度视图	某个合作伙伴退出后，大部分收入占比会在无人察觉的情况下消失	在高管视图中显示前 1／5／10% 的占比，并按季度审查
混合待处理和已批准状态	总数无法复现；趋势毫无意义	通过可比性约定为每项指标固定状态
忽略撤销延迟	最近时期的表现看起来好得不真实	仅比较已完成验证的时期；标记尚未成熟的时期
比较验证窗口不同的时期	产生虚假的上升或下降趋势	绝不进行比较；在每张图表上标注窗口变更
将子网络计为多个合作伙伴	合作伙伴数量和集中度都出现失真	每次转化只计入一个获得归因的实体；单独列出子网络
将来源贡献与影响贡献相加	合作伙伴收入被重复计算	使用两个设有上限的数字；若一笔交易同时符合两者条件，则来源贡献优先
销售成本中未计入网络／代理机构费用	低估项目的真实成本	销售成本包括佣金、网络、代理机构和版位费用
将供应商基准直接用作项目基线	目标和警报的校准在两个方向上都不准确	根据项目自身的历史数据推导基线；供应商数据仅标记为校准参考
警报阈值固定不变	警报疲劳；团队忽视警报条	使用滚动基线动态阈值，并指定负责人、渠道和响应时间
指标未关联任何决策	评审会议只复述数字，却不做任何决策	在规范行中注明对应决策，或删除该指标

这些行有意不按效率排序。每行都是一个缺陷及其对应的一项修复方案，而不是针对同一问题的一组选项——对它们排序，只会按读者的症状排序，而非按可选方案排序。适用的行都应采用。

调用示例

• “我们的 SaaS 联盟计划与 400 个合作伙伴合作，支付 20% 的经常性佣金。管理层每个月都会问这个计划是否盈利，而我无法回答。请为我们设计一个仪表板。”
• “我运营一个采用末次点击归因的电商联盟计划，优惠券网站看起来功劳最大。请定义指标和视图，用于团队每周审查计划仪表板。”
• “为一个每月在佣金上支出 $80K 的联盟计划编写 KPI 规格——说明我们每天和每月分别跟踪哪些指标，并列出警报阈值和负责人。”

参考资料

• 编写指标规格行时，阅读 references/metric-definitions.md——了解公式、可信来源之间的分歧、B2B/B2C 变体和来源信息。
• 指定 ROI 指标或评估接近结账环节的合作伙伴时，阅读 references/roi-and-incrementality.md——了解测试设计、代理指标和末次点击失效案例。
• 添加集中度视图、生命周期阶段和招募批次分析时，阅读 references/concentration-and-cohorts.md。
• 布局视图、选择维度以及设计更新频率和警报时，阅读 references/layout-cadence-and-alerts.md。
• 规划交付内容时，阅读 references/worked-examples.md——包含一个 B2B SaaS 规格、一个 B2C 电商规格和一个负面示例。
• 有关单次付款发放前的准确性，请参阅 mbfinotti/partnerships-skills@affiliate-payout-audit——此技能跟踪持续运行的计划，而非单次发放。
• 有关欺诈规则集，请参阅 mbfinotti/partnerships-skills@affiliate-fraud-detection——此仪表板会呈现相关信号，但不会定义规则。
• 有关 B2B 渠道合作伙伴评分卡和季度业务回顾结构，请参阅 mbfinotti/partnerships-skills@partner-performance——不在本文范围内。
• 有关验证窗口和追回款项背后的合同条款，请参阅 mbfinotti/partnerships-skills@affiliate-program-terms。