mcpField
A
affiliate-commission-structure

affiliate-commission-structure

github.com/mbfinotti营销与增长214.6k 次安装3 天前更新
代码仓库

关于 affiliate-commission-structure

这是一项依据项目经济数据设计联盟佣金与付款条件的营销技能。它涵盖费率模型、合作伙伴差异、持续佣金期限、验证和付款机制,并以单位经济效益推导费率,而非照搬行业基准。

主要功能

  1. 01通过访谈收集经济数据
  2. 02依据单位经济效益推导佣金上限
  3. 03选择费率模型及伙伴费率
  4. 04规划分级与持续佣金期限
  5. 05设定归因和付款条件

适用场景

  1. 01为新计划设定佣金费率
  2. 02按合作伙伴类型调整费率
  3. 03设计 SaaS 持续佣金付款
  4. 04检查拟议付款是否符合利润空间

安装

复制下面的命令,在终端中运行。

$npx skills add https://github.com/mbfinotti/partnerships-skills --skill affiliate-commission-structure

安装后在 Claude Code 中输入/affiliate-commission-structure确认已加载。

包含的文件

除 SKILL.md 外,安装时一起下载的参考资料和脚本。

evals/
evals.json
references/
benchmarks.md
partner-types-and-tiers.md
rate-derivation.md
spec-and-examples.md

详细介绍

联盟佣金结构

设计联盟营销计划的佣金和支付结构:费率模式、费率水平、阶梯、持续支付时长、归因窗口,以及验证、追回和支付条款。

这一领域不存在具名的专有框架。Robert Glazer 的 Performance Partnerships(2017)和 Geno Prussakov 的 Affiliate Program Management: An Hour a Day(2011)讲授的是原则和流程,而非某种品牌算法。Prussakov 的“5/80 规则”(5% 的联盟伙伴完成 80% 的工作)是唯一真正有出处的专有说法。

实际存在的是一种趋同的实践,各行业教授的内容几乎完全相同:

  • 根据单位经济效益推导佣金上限。
  • 将标价设在上限以下。
  • 根据合作伙伴类型和增量效果进行区分。
  • 通过验证和追回机制提供保障。
  • 通过阶梯奖励表现优异者。

这套推导是本技能的核心——根据利润率计算费率,绝不照搬基准费率。

访谈

设计方案前,先遵循以下规则:

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

  • 尽可能提供多选答案。

  • 用户已回答的问题就跳过。

  • 是 B2B SaaS 还是 B2C 电商?订阅制还是一次性购买?

  • 毛利率是多少?每笔订单的可变成本是多少(销货成本、履约、运费、支付处理费、平台费用)?

  • 预计退货/退款率(电商)或月流失率(SaaS)是多少?

  • 平均订单价值(AOV)或入门方案价格是多少?不同产品或方案之间的 AOV/ACV 差距有多大?

  • 客户生命周期价值(LTV)是多少?目标 CAC 和当前综合 CAC 分别是多少?

  • 现有佣金率(如有)是多少?目前哪些合作伙伴适用这些费率?

  • 已加入或希望招募哪些类型的合作伙伴:内容/评测/比较网站、优惠券/返现/忠诚度平台、代理机构/顾问、创作者/网红?

  • 是否有竞争对手的计划条款可供校准?

  • 财务部门是否设定了支付预算上限?

  • 追踪系统能归因哪些数据:末次点击 Cookie、服务器端事件、新老客户标记、每个推荐账户的周期性账单事件?

  • 新结构必须在什么日期前上线并开始显现成效?

  • 是一次性修复(让本季度的支付额回到上限以内),还是打造可持续增长的资产(制定一份能经受三年方案和产品目录变动的费率表)?

  • 工作量上限是多少:谁负责每周管理计划?联盟平台实际支持哪些设置——按产品设定支付表、增加第二档费率以实现递减、新客户标记、按合作伙伴设置归因窗口?

缺少利润率、流失/退货率和 CAC 答案时,无法推导费率——提出任何费率前,都要先要求对方提供估算值。

最后三个答案会重新排列本技能中的每个选项菜单,而每种排序都会指出:

  • 截止日期紧迫时,优先选择在平台上只需修改一个字段的方案,降低需要协商或更改追踪设置的方案的优先级。
  • 若目标是打造可持续增长的资产,则优先选择费率推导和按合作伙伴类型区分的方案;若目标是一次性处理,则优先选择能在本周期内落实的持续时长和门槛调整。
  • 工作量上限较低时,直接删除平台无法实现的选项,而不是仅仅降低其优先级。

以下所有排序均为默认方案,并非铁律:具体排序会随情境和执行者而变。请根据你已了解的用户情况重新排序:

  • 现有已发布的费率表若因联盟网络规则而难以削减。
  • 平台无法设置递减费率。
  • 订单金额的差距较小。
  • 公司内部有合作伙伴经理,能够负责默认排序未考虑的逐个合作伙伴协商工作。

工作流

  1. 进行访谈。在涉及任何数字前,收集所有经济数据。
  2. 根据单位经济效益推导佣金上限——绝不根据竞争对手的费率来定:
    • 电商:毛利 → 扣除可变成本 → 得出贡献毛利 → 扣除预期退货 → 支付退货后贡献毛利的三分之一到二分之一。合理性参考范围:总佣金占毛利的 20-30%。
    • SaaS:将佣金计入 CAC。确保 LTV:CAC ≥ 约 3:1,且 CAC 回本期 ≤ 约 12 个月。每位客户的终身佣金总额:占 LTV 的 5-15%,且绝不超过毛利的 30-40%。
    • 完整计算示例见 references/rate-derivation.md。
  3. 选择费率模式——按效率排序:收入/订单百分比 > 固定 CPA > 混合模式。完整评估维度、各模式下的利润率表现,以及会排除某个选项的限制条件,见下文“费率模式”一节。
  4. 对于经常性收入分成(SaaS):先确定期限规则,再确定醒目的百分比——期限对实际成本的影响远大于百分比。默认设置为 12 个月上限。排序和成本计算见下文“经常性期限(SaaS)”一节。
  5. 根据增量贡献按合作伙伴类型区分费率:
    • 内容和创作者合作伙伴的增量贡献率约为 78-82%。
    • 优惠券/返现合作伙伴的非增量贡献率通常为 66-71%:他们会获取其他人创造的需求所带来的末次点击归因。
    • 按效率从高到低应用以下控制措施:新客户门槛 > 低于内容合作伙伴的费率上限 > 更短的归因窗口 > 专属代码。
    • 如果追踪系统没有新客户标记,就从选项中删除该门槛,将费率上限提升为首选措施。
    • 同样适用于 B2B 和 B2C:只有合作伙伴组合不同。
    • 评估维度见 references/partner-types-and-tiers.md。
  6. 确定分层方案——按效率排序:统一费率 > 边际分层 > 追溯分层。上线时采用统一费率:没有历史业绩数据,就无从设定分界点,因此应排除两种分层方案,而非仅降低其优先级。评估维度和机制见 references/partner-types-and-tiers.md。
  7. 设定与方案结构相匹配的结算条款(详情如下):
    • 归因窗口
    • 验证/锁定期
    • 净付款期限
    • 最低付款门槛
    • 追回条款
  8. 检查是否达到通过门槛(如下)。按照 references/rate-derivation.md 中给出的效率顺序调整杠杆,直至达标。如果仍不达标,应先将计划范围缩小到高利润率的 SKU 或套餐;只有在缩小范围后仍无法达到合作伙伴愿意接受的上限时,才建议不予上线。
  9. 先推导费率,再与基准对照——见 references/benchmarks.md。推导出的费率远低于该垂直领域的惯例,意味着招募合作伙伴会遇到困难,而不是计算有误。如果可以浏览网页,请在竞争对手的实时页面上核实其公开条款——第三方目录中的 Cookie 窗口和费率往往已经过时。
  10. 每次只展示一个部分的决策——选项、权衡、建议——并在进入下一部分前向用户确认。获得批准后,输出完整的佣金结构规范(如下)。
  11. 如果你的运行环境支持持久化记忆,请记住已批准规范中的关键决策和经济数据(上限、各合作伙伴类型的费率、期限、窗口),以便后续修订时直接沿用,而无需重新访谈。

费率模式

这三种模式的规模都受第 2 步设定的上限约束——模式决定上限内的收益如何分配,而不是项目的总成本。因此,应根据投入和可逆性来排序,而不是看表面上有多慷慨。

  • 效率:订单金额/收入百分比 > 固定 CPA > 混合模式
  • 价值:订单金额范围较窄时,百分比 > 固定 CPA;范围较宽时,固定 CPA > 百分比;只有当发布商拒绝纯绩效合作时,混合模式才优于两者
  • 投入:混合模式 > 固定 CPA > 百分比
  • 合规成本:混合模式 > 固定 CPA == 百分比——发布任何费率表都已构成合同承诺,且受网络下调规则约束,因此前两者成本相同;只有混合模式还需额外签署带有独立期限的版位合同
模式带来的价值投入对利润率的影响
订单金额/收入百分比(默认)使整个合作伙伴群体的激励保持一致几乎为零——在每个平台上设置一个字段有效费率按设计保持恒定,因此在任何订单金额下都不会超过第 2 步设定的上限
固定 CPA当按百分比付费会导致大额订单支付过高时,保护单位经济效益花一小时制定付款表;之后每当套餐价格或商品目录变动,都要重新制定有效费率随订单金额反向变化——如果商品目录价格范围相差 25 倍,同一笔付款在低价端会远超上限,在高价端则远低于上限
混合模式(固定版位费 + 较低百分比)获得不接受纯绩效合作的高权威发布商每个合作伙伴需要一周时间谈判,之后每个结算周期都要在平台外开票并对账费用在产生任何转化之前就已支付,因此只有这种模式的成本不受上限推导过程约束

这种排序会使混合模式难以胜出。只有它能争取到拒绝纯绩效合作的发布商,这是它在价值方面唯一的优势。但它需要每个合作伙伴耗费一周谈判时间,还要在每个结算周期进行平台外开票,因此只要它符合参评条件,每一轮都会被其他模式压过。

当某个具名的高权威发布商已拒绝纯绩效合作,且项目有足够的谈判时间时,应主动将其提升优先级,而不是等它在注定无法胜出的轮次中胜出。要明确说明,费用不计入第 2 步设定的上限:本节其他内容都没有这一点。

限制条件会直接排除某个选项,而不是降低其优先级:

  • 订单金额范围较窄,或者平台没有按商品设置付款表:固定 CPA 退出候选项——不要将其作为备选方案。
  • 没有发布商要求支付版位费:混合模式退出候选项——它只适用于这类谈判。
  • 如果上线日期确定,只剩下百分比模式:混合模式无法在期限内敲定。

周期性佣金期限(SaaS)

应先确定佣金期限规则,再协商百分比——它对实际成本的影响远大于表面佣金比例(计算方法见 references/rate-derivation.md)。

  • 效率:12 个月封顶 > 递减佣金 > 续约奖金 > 终身佣金
  • 成本:以 30% 的表面佣金比例和 20 个月的客户留存期为例,终身佣金相当于客户收入的 30.0%,封顶方案为 18.0%,递减佣金为 13.5%——续约奖金的成本最低,因为它只对实际续约的收入支付
  • 价值(招募吸引力):终身佣金 > 12 个月封顶 > 递减佣金 > 续约奖金——合作伙伴会综合比较表面佣金比例和期限,而递减佣金会在前 6 个月内用尽其表面佣金比例
  • 工作量:续约奖金 > 递减佣金 > 终身佣金 == 12 个月封顶——最后两者并列,因为都只需设置一个期限字段,不需要其他设置;递减佣金需要增加一个佣金比例档位,续约奖金需要设置续约事件触发器,而许多平台无法配置这些功能,因此需要持续手动核对
  • 合规成本:终身佣金 > 续约奖金 > 递减佣金 == 封顶方案——已公布的终身佣金条款会带来无期限的责任,此后撤销条款时会受到网络佣金下调上限的限制,还必须为所有已加入该方案的合作伙伴保留原有条款

这种排序会牺牲递减佣金和续约奖金。两者的单客获客成本都低于封顶方案。同样采用 30% 的表面佣金比例时,递减佣金占客户收入的 13.5%,而封顶方案为 18.0%;续约奖金则只对续约收入支付。

但封顶方案的性价比最高,因为它只需设置一个期限字段。其他两种方案都需要增加一个佣金比例档位或设置续约事件触发器;如果平台无法配置这些功能,还需要持续手动核对。当佣金预算而非管理人员工时是主要限制,且平台原生支持相应机制时,应优先选择递减佣金或续约奖金,而非封顶方案。

  • 默认采用 12 个月封顶。若要与佣金条件优厚的竞争对手争夺合作伙伴,可采用 24 个月期限。
  • 除非以下三项条件全部满足,否则不考虑终身佣金:毛利率 > ~80%、月流失率 < ~5%,且竞品方案采用终身佣金。低于这条门槛时,应直接取消该选项,而非降低优先级——不要为其定价,也不要将其作为优厚选项提供。
  • 如果平台无法配置第二档佣金比例,就取消递减佣金。改用续约奖金,或直接采用普通的封顶方案。
  • 与无期限的终身佣金相比,优先选择续约奖金(续约金额的 5-10%)——这样既能让合作伙伴在封顶期后继续参与,又不会带来无期限的责任。
  • 在账单确认后再支付周期性佣金,这样客户流失后会自动停止支付。
  • 对客户黏性较高的产品,无期限的终身佣金会成为资产负债表陷阱:一位留存 7 年的客户,可能让联盟伙伴获得超过该客户利润的佣金。
  • B2C 电商:佣金通常按订单一次性支付,很少涉及周期性期限。除非产品是订阅盒,否则可跳过本节。

结构中的支付条款

这些条款是费率设计的一部分,而非法律套话——每一项都会改变实际成本和计划的竞争力。

  • 归因/Cookie 窗口:因流量类型而异。

    • 冲动型和优惠券流量为 24 小时至 7 天。
    • 30 天是电商的默认值。
    • 对销售周期较长的 B2B SaaS,为 60-180 天。
    • 优惠券/返现合作伙伴的窗口应短于内容合作伙伴。

    特意不做排名:这些是针对不同流量类型的默认值,并非对同一个问题的相互竞争的答案——优惠券合作伙伴和 B2B 内容合作伙伴绝不会在任何工作量预算下使用相同的窗口。

  • 验证/锁定:将佣金暂扣 30-60 天。B2C:与退货/退款期限挂钩。B2B SaaS:与试用转付费转化时间及退款期限挂钩。

  • 付款条款:默认 net-30。注意叠加成本:30 天验证期加上 net-30,意味着联盟合作伙伴要等约 2-4 个月才能拿到款项。

  • 最低门槛:$50-100。

  • 追回佣金:退款、拒付或窗口期内取消会使佣金作废。如果佣金已支付,则从下一笔付款中扣除,并将负余额结转。支付渠道很少会自动撤回已支付的佣金——必须明确触发追回流程,因此应将其机制写入运营流程,而不仅仅是条款。

  • B2B 和 B2C 的净付款期限、门槛和追回机制相同。只有窗口时长和验证触发条件不同。

付款速度是招募筹码——付款较慢会让合作伙伴转向付款更快的竞争对手——有三个杠杆可以影响付款速度。缩短任何期限之前,先对它们排序:

  • 效率:降低最低门槛 > 缩短净付款期限 > 缩短验证期
  • 价值(合作伙伴实际感受到的速度):缩短验证期 > 缩短净付款期限 > 降低门槛
  • 工作量:缩短净付款期限 > 降低门槛 == 缩短验证期——后两者并列,因为各自只需修改一个字段,而净付款期限会改变每个周期的财务节奏
  • 可逆成本:缩短验证期 > 缩短净付款期限 > 降低门槛——缩短验证期会导致退款到账前就支付佣金,而已支付的佣金只能通过手动追回收回

降低门槛完全不会增加风险——无论如何,这笔钱都应支付——而且这是小型和新合作伙伴最先能感受到的杠杆。最后再缩短验证期,并且只有在退单率经过测量且较低时才这样做。

迁移现有费率表

  1. 先推导目标结构——照搬费率进行迁移,只会重蹈原来的覆辙。
  2. 每次公告都要先说明哪些内容保持不变。
  3. 提前通知:费率等级或费率变更需提前 60 天通知。绝不要悄悄更改费率——有记录显示,静默迁移是导致合作伙伴流失的原因之一。
  4. 让现有联盟合作伙伴继续享有旧费率;对于高绩效合作伙伴,至少维持一个周期。
  5. 分阶段推广,优先面向头部合作伙伴,并在群发公告前直接沟通。
  6. 降低费率前,先检查网络平台的限制——网络平台会通过合同限制降费幅度、频率和通知期限(逐字示例见 references/partner-types-and-tiers.md)。

佣金结构规范

将每次合作都交付为以下文档——这是一份每行都有理由的决策记录,可直接用于财务和合作伙伴沟通文档:

COMMISSION STRUCTURE - <program>, <date>
Rate model        : % of order | flat CPA | recurring rev-share | hybrid, and why
Headline rates    : per partner type (content / coupon-cashback / agency / creator), each with its reason
Tiers             : marginal breakpoints + measurement window + reset rule, or "flat - revisit when <condition>"
Recurring duration: cap (e.g. 12 months) or taper or lifetime + renewal bonus, with the margin/churn justification
Attribution       : cookie/window length per partner type, new-customer gating
Validation        : locking period + what event releases it (return window / trial-to-paid)
Payment           : net terms, minimum threshold, clawback clause + negative-balance carry-forward
Economics         : ceiling computation shown; projected cost per acquired customer vs current blended CAC
Validation plan   : 30-day holdout on top coupon partners; new-customer share tracking
KPIs              : cost per incremental affiliate customer vs blended CAC, effective commission rate,
                    new-customer share, reversal/clawback rate, revenue share of top 10% partners
  • 每一行都要说明理由。“25% 佣金,持续 12 个月 = LTV 的 13%,处于 5-15% 区间内”便于审核;单独一个百分比则不行。
  • **规范设有通过门槛。**预计每获取一名增量的联盟营销客户所需的综合成本,必须低于当前综合 CAC,且不超过计算出的利润率上限。按效率从高到低调整各项杠杆,直到同时满足这两个条件。如果仍未通过,就缩小范围,聚焦高利润率 SKU/方案;只有这样仍无法通过时,才建议不启动。
  • **验证计划不是可选项。**末次点击归因在机制上会向漏斗底部的合作伙伴支付过高佣金。留出组测试能验证规范中的增量性假设。

B2B SaaS 和 B2C 电商规范示例,以及一个反面示例,见 references/spec-and-examples.md。

常见失败模式

失败情况原因解决方法
佣金率高于贡献利润率直接照搬基准数据,而非推算得出;只有在扣除退货后才会显现亏损重新推算上限;降低佣金率或聚焦高利润率 SKU
阶梯门槛打击积极性或诱发低质流量在临界点附近设置追溯适用的阶梯;合作伙伴达到 49/50 时会推动低质注册采用边际阶梯;根据历史数据设置门槛
无上限的终身佣金超过客户利润空间在客户粘性高的产品上,将终身佣金用作招募手段设定 12 个月上限 + 续费奖金;买断现有的终身佣金安排
向优惠券/忠诚度合作伙伴支付过高佣金末次点击会将漏斗底部点击归功于优惠券/忠诚度合作伙伴,而需求其实由其他渠道创造按顺序采用:新客户限制、将佣金上限设在内容合作伙伴佣金率以下、缩短归因窗口;使用专属代码和留出组测试来验证效果
调整佣金率后合作伙伴流失未经沟通或突然切换会损害信任并影响追踪提前通知、为现有合作伙伴保留原有条件、优先分阶段调整头部合作伙伴
AOV 差异很大却采用固定百分比一笔大额订单就会让单位经济模型失衡采用固定 CPA,或按产品/方案设置分档百分比

坦诚说明:最可靠的项目数据表明,大多数联盟营销项目停滞在合作伙伴激活阶段,而非佣金率校准不准——结构推算得再完美,也无法挽救一个无人推广的项目。如果用户真正的问题在于招募或参与度,请明确指出这一点。

调用示例

  • “我们永久支付 20% 的循环佣金,财务认为成本太高——请重新设计结构。方案价格为每月 $79,利润率为 82%,平均客户留存 16 个月。”
  • “为新的 B2C 电商联盟营销项目设定佣金率。AOV 为 $65,扣除退货后的贡献利润率为 44%,而且我们希望优惠券合作伙伴的佣金率低于内容合作伙伴。”
  • “设计分级佣金方案,奖励排名前 10 的联盟营销合作伙伴,同时不超出 LTV 上限——这是去年的每个合作伙伴营收数据。”

参考资料

  • 有关两种上限计算、终身佣金与封顶佣金及递减佣金的成本比较,以及达标门槛的计算方法,请参阅 references/rate-derivation.md。
  • 有关各垂直领域的佣金率表、Cookie 窗口惯例、验证/付款期限/门槛惯例,以及已发布的计划条款(每项均附来源、日期和可靠性标记),请参阅 references/benchmarks.md。
  • 有关基于增量效果的佣金率差异、对照组测试、层级机制和迁移防护措施,请参阅 references/partner-types-and-tiers.md。
  • 有关一份 B2B SaaS 规范示例、一份 B2C 电商规范示例,以及一个未达到门槛的反例,请参阅 references/spec-and-examples.md。
  • 有关涵盖联盟佣金以外内容的完整渠道合作伙伴损益表,请参阅 mbfinotti/partnerships-skills@partner-economics。
  • 有关起草用于落实此结构的 T&C 文档,请参阅 mbfinotti/partnerships-skills@affiliate-program-terms。
  • 有关审计依照此设计进行的后续付款,请参阅 mbfinotti/partnerships-skills@affiliate-payout-audit。
  • 有关欺诈规则集,请参阅 mbfinotti/partnerships-skills@affiliate-fraud-detection——此技能仅标记会引发欺诈动机的结构。

评论

支持 Markdown