referral-abuse-guardrails

推荐滥用防护规则

制定防止终端客户钻客户推荐好友计划空子的防护规则，并将其整理为规则规范：包含阈值、验证关卡、奖励暂缓政策、分级处置机制和监控信号。这项技能保护现有奖励结构——绝不会重新设计奖励结构。

目前没有经过批准的标准涵盖消费者推荐滥用问题。只借鉴以下四项，仅作思维模型，绝不作为合规声明：

• GIVT/SIVT 的形式（广告测量标准）：低成本的确定性层级，加上成本较高的佐证层级。
• OWASP OAT-019 Account Creation：仅涉及自动化的部分。
• 信任与安全领域的分级处置原则：用于处置部分，遵循适度、一致、透明。
• Sybil 攻击的结论，作为战略框架：如果没有中心化身份机构，就无法彻底检测出虚假身份，因此每项防护规则本质上都是施加给滥用者的成本。

目标是让滥用行为无利可图，而不是抓住所有滥用者。

基本原则

• 严格用于防御。对每种滥用模式的描述仅限于防御者识别和拦截所需的深度：说明计划数据中的可观察迹象，绝不提供规避技巧、工具或逐步利用方法。
• 为每个数值阈值标注来源：已发布的计划条款、学术研究结果、供应商经验法则，或用户根据自身数据推导出的基准。绝不能将供应商的经验启发式说成行业常数。
• 警惕两个流传的数字：“推荐欺诈占所有电商欺诈的 21%”属于循环引用（供应商互相引用），而“误拒交易造成 4430 亿美元损失，欺诈造成 480 亿美元损失”这一说法精确到无法核实。应说明其原理——误报的成本高于欺诈，因为误报会导致客户终身价值流失——绝不要引用这些数字。
• 区分真正的滥用者和激进的优惠猎手。前者适用分级处置机制；后者应通过调整规则来应对，而且通常值得留住。
• 在推荐发生之前未在计划条款中公布的规则，不得用于处置该推荐。每项规则都必须与其公布方式一并设计。

访谈

设计任何内容之前先提问。每条消息只问一个问题；尽可能采用选择题；已回答的问题无需重复提问。

• 当前生效的计划机制和奖励结构是什么：奖励发放给单方还是双方、每方奖励的类型和价值、奖励触发条件是什么？
• 是 B2B、B2C，还是两者都有？
• 用户账户和身份模型是什么：仅通过电子邮件注册？需要手机号？在达成合格事件之前是否已保存支付工具？
• 目前具备哪些验证能力（电子邮件确认、SMS、拦截一次性域名、设备信号、账单 Webhook）？
• 实际可以查询哪些数据：推荐事件、注册元数据、支付记录、退款/拒付记录、按群组划分的留存情况？
• 目前发现过哪些滥用行为，是如何发现的？
• 面临风险的奖励金额是多少：单笔奖励，以及整个计划每月的奖励总额？
• 底层购买的退款或拒付期限有多长？
• 对摩擦和损失的容忍度如何——宁可多付一些奖励给钻空子的人，还是宁可损失一些真实推荐？
• 目前是否已公布计划条款？条款对上限、资格和拒发奖励有哪些规定？
• 防护规则必须在什么日期前上线——重新发布、董事会审查，还是正在失血的事件处理？
• 你想针对已出现的滥用行为进行一次性修复，还是建立一套能够随计划扩展而持续生效的控制措施？
• 工作量上限是多少：本周期可投入的工程时间、审核人员数量，以及合格事件是否可以更改？

最后三个问题决定工作流第 4 步中的控制措施排序，因此设计任何内容之前都要先问——到了第 4 步，读者已经选定了路径。

工作流

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

2. 确认范围边界：奖励结构（奖励对象、类型、金额、触发条件）是既定条件。如果这正是问题所在，请明确指出，并转至 mbfinotti/partnerships-skills@referral-incentive-design（参见 Reference）。

3. 根据 references/abuse-patterns.md 梳理项目的滥用风险面：奖励价值、身份模型和合格事件实际会暴露哪些滥用模式。

4. 参照 references/guardrail-mechanics.md，梳理控制措施阶梯。六种控制措施争夺相同的时间：

   • 事件：合格事件设计。
   • 上限：预算上限、频率限制、冷却期。
   • 冻结期：奖励冻结期。
   • 资格条件：带记忆的规则。
   • 验证：门槛。
   • 审核：人工审核。

   供应商博客把这个顺序完全颠倒了——先讲检测工具，最后才讲项目设计。请对它们排序：

   • 效率：事件 > 上限 == 冻结期 > 资格条件 > 验证 > 审核
   • 价值：事件 > 资格条件 > 冻结期 > 验证 > 上限 > 审核
   • 工作量：审核 > 验证 > 事件 > 资格条件 > 上限 == 冻结期
   • 合规成本：验证 > 资格条件 > 事件 == 上限 == 冻结期 > 审核

   上限和冻结期并列，因为二者都是写入条款的支付侧数值，只需一次配置更改即可上线，不会阻碍任何合规用户，而且各自能限制另一方无法限制的损失——上限限制数量，冻结期限制撤销风险。事件、上限和冻结期在合规成本方面并列，因为它们都不涉及身份数据，也不需要审批。审核在这个维度上排位最低，因为纳入人工环节会_降低_风险：有些监管制度禁止完全自动化的拒绝。

   这里的工作量是综合指标——对合规用户造成的摩擦、构建时间和可逆性。重新设计事件触发条件需要数周的产品和计费工作，但验证的排位仍高于它：前者是一次性工程成本，而验证会持续给每位合规用户增加成本。事件设计在效率方面领先，原因也相同。

   默认做法：第一轮始终加入上限、冻结期和已公布的资格条件。只要当前合格事件是简单注册或无需付费的操作，就应升级为事件重设计——如果事件可以免费造假，后续措施就无法发挥作用。

   这种顺序会把验证门槛和人工审核压到末位。它们对于上限和冻结期无法应对的两种滥用——自动化账号批量注册、B2B 空壳实体——都很有价值，但在效率排序中每轮都落后。当逐项审核成本低于奖励金额（B2B 默认情况），或确认事件是自动化而非投机性滥用时，应提高它们的优先级。

   根据访谈答案重新排序，并在规范中指出哪个答案改变了哪项控制措施：

   • 如果上线期限紧迫，应优先加入上限、冻结期和资格条件（配置工作，几天即可完成），并将事件重设计安排到下一个周期——不可省略。
   • 如果要求措施长期有效，应优先考虑事件设计和带记忆的资格条件，它们无需持续投入成本也能发挥作用。
   • 如果工作量上限很低，应直接从规范中删除人工审核和较高阶的验证措施，而不是把它们排在末位；记录删除了哪些措施以及原因。

   再根据你对该项目已有的了解重新排序：

   • 如果在合格事件发生前已收集支付工具信息，应大幅提高验证的优先级——最强的门槛已经提前付费完成。
   • 如果已有信任与安全团队，人工审核的工作量会大幅降低。
   • 受监管项目已经在进行身份核查，因此其最高阶措施的边际成本为零。

   将排序视为默认方案，而非硬性规定：它会随具体情况和执行方而变化。

5. 明确区分 B2B 和 B2C。上限、冻结期和带记忆的资格条件对两者的作用完全相同——请明确说明。B2B 的不同之处在于：

   • 推荐方与被推荐方之间的域名重合检查：这是关键检查，因为仅检查工作邮箱并不可靠，空壳公司也有真实域名。
   • 付款前人工审核：在 B2B 中投资回报为正，在 B2C 中则不然。
   • 默认将奖励记入公司账户：向个别员工付款，首先会涉及采购或礼品政策问题，其次才是欺诈问题。

6. 从 references/detection-signals.md 选择监控信号，其中列出了各个维度的完整排序。

   • 效率：payment-reuse == cohort-quality > velocity > email-similarity > graph > fingerprint

   两项领先信号并列，因为它们都已存在于账单数据中，不会因浏览器或设备变化而失效，而且各自恰好能捕捉到另一项遗漏的情况。Cookie 和 IP 关联不纳入排序，也不是被降级处理：它们的价值已经跌至谷底，因此为其排序会造成虚假的精确感。图信号是这一排序最弱的一环；请参阅参考资料，了解何种条件会提升其优先级。

7. 根据 references/enforcement-and-compliance.md 设计执行阶梯：列出公开的阶梯级别、为每项拒绝提供具体原因说明，并设置可用的申诉渠道——先构建原因说明和申诉渠道，再开发检测器。将法律限制作为设计约束，并将实际法律问题交由法律顾问处理。

8. 核实每条规则都已公开发布：任何未列入当前条款的规则，在发布前均不可执行；条款起草事宜请交由 mbfinotti/partnerships-skills@affiliate-program-terms 处理。

9. 如果可以查询该计划的事件数据，请根据用户自身的合法推荐分布推导频率和标记阈值（例如，每周推荐数的 p95-p99）；否则，应将其标注为示例默认值，并在首个审查周期内替换为推导出的基线。

10. 按照 Output Shape（下文）逐节输出防护规范，供用户逐节确认；内容应以 references/worked-examples.md 中相匹配的实例为依据。

11. 附上 Pass Threshold（下文）中的校准计划，并持续迭代，直至满足要求。

12. 如果你的运行环境支持持久化记忆，请记住已确定的阈值、等待时长和执行阶梯，以便后续调优时从这些设置开始，而不必重新询问。

Output Shape

每项合作均须交付此产物。每条阈值说明都必须带有来源标签；每条规则说明都必须指出可能触发该规则的合法行为。

REFERRAL GUARDRAIL SPEC - <program>, <date>
Qualifying event : reward trigger + why it is costly to fake + reversibility note
Caps             : per-referrer (period + lifetime), per-referee, program budget ceiling.
                   Take the values from the existing reward design where one exists and
                   record them as given; this spec enforces caps, it does not size them
Velocity         : referrals/claims per referrer per window + cooldown after a burst
Hold policy      : hold length = refund/chargeback window (+ processing), pending-state display
Eligibility      : new-customer definition, self/household exclusion, cross-referrer cooldown,
                   B2B domain-overlap rule
Verification     : gates by friction rung, escalation condition per rung, what is never gated
Monitoring       : signals watched, expected flag baseline, cohort-quality dashboard
Enforcement      : published ladder rungs, reason strings, appeal path + response SLA
Terms status     : where each rule is published; unpublished rule = not yet enforceable
Calibration      : holdout cell design, review cadence, leakage/friction computation

通过门槛

评估规范时，必须同时考量泄漏和摩擦，不能只看命中率或精确率目标。任何地方都没有公布专门针对推荐的假阳性基准；切勿用行业数据替代用户自己的留出组数据。

• 使用相同的计量单位计算两者：泄漏 =（支付的无效奖励）×（奖励成本）；摩擦 =（错误扣留的奖励）×（奖励成本 + 支持成本 + P（流失）× LTV）。摩擦项包含 LTV 乘数，而泄漏项没有，因此错误率 1:1 的权衡几乎永远不会达到盈亏平衡——拿不准时，就放宽规则。
• 使用留出组进行校准：在较宽松的规则下运行一个小规模实验组，并按以下三个条件与严格规则进行比较。只有三个条件全部满足，规范才算通过：
  1. 总价值，而非每次注册价值：严格规则组按每 1,000 名触达的推荐人计算的 90 天队列价值，至少与留出组持平。此条件至关重要，绝不能用每次注册的平均价值替代。
     • 收紧规则会减少边际注册量，因此规则越严格，每次注册的价值就越高或持平。
     • 最严格的配置最容易满足每次注册价值门槛，而且无论规则收紧到何种程度，都不会因此未达标；而过度收紧正是本节要识别的问题。
  2. 质量：被推荐用户群在留存率、退款率和 90 天收入方面均优于自然获客用户。
  3. 扣除上述公式的成本后：严格规则节省的泄漏成本超过其造成的摩擦成本，且两者均按相同的触达基数计算。
• 如果即使采用合理的防护措施，被推荐用户群的表现仍不如自然获客用户，那么该计划买来的是注册量，而非客户——问题出在奖励结构，应转交给 mbfinotti/partnerships-skills@referral-incentive-design，而不是进一步收紧规则。
• 持续调整阈值，直到三个条件全部满足；如果目前还没有可用于校准的数据，请在交付内容中说明，并将留出组安排为上线后的首个评审关卡。

常见失效模式

缺陷	后果	修正方法
防护措施过严，导致合法推荐也无法进行	项目陷入停滞；摩擦成本超过节省的损失	应用损失／摩擦公式；逐步放宽限制，直到每 1,000 名看到推荐信息的推荐者所带来的群体价值恢复。每次注册的平均价值上升而注册量下降，正是这一缺陷的特征，绝不能据此认为不存在该缺陷
设置上限，却不检查速度	滥用者在一个周末内就达到终身上限，却未被发现	每个上限都应配套设置每个时间窗口的速度限制和突发冷却期
忽视设备和支付工具的重复使用	漏掉了成本低且可确定识别的自我推荐	优先检查支付工具的重复使用；这是目前掌握的最强信号
悄无声息地拒绝奖励	损害信任、增加支持负担，并在多个监管制度下引发法律风险	在构建检测器之前，先准备具体的原因说明和已公布的申诉渠道
追溯性地收紧规则	无法对过去的推荐执行新规则；引起监管机构关注	先公布规则，再开始执行；已获得的奖励应按旧规则处理
暂缓期短于退款期限	被推荐者在奖励发放后退款；奖励无法追回	按产品线将暂缓期设为退款／拒付期限加上处理时间
将热情的倡导者视为作弊团伙	头号推荐者被封禁；这是最糟糕的口碑传播	除图结构特征外，还应要求有其他佐证：奖励分成、退款、群体表现骤降
人工审核成本超过奖励价值	无论准确率如何，每次审核都是净损失	仅对价值高于审核成本的奖励进行审核；B2B 默认审核，B2C 例外
对低价值消费者奖励要求完整 KYC	注册流失造成的损失远超所防止的欺诈	验证支付工具即可；KYC 适用于受监管的项目

关键绩效指标（KPI）

• 跟踪：
  • 无效奖励率（损失）
  • 申诉获支持后错误扣留奖励的比率（摩擦）
  • 推荐用户与自然用户群体在留存率、退款率和 90 天收入方面的差异
  • 标记率与预期多账号操作基准的差异
  • 从暂扣到发放的时间
  • 预算上限消耗情况
  • 关于奖励被拒的支持工单
• 将损失和摩擦以货币计量，使用相同单位并列报告——单看一个数字总会造成误导。
• 出现以下情况时，升级处理规范本身：
  • 申诉获支持率上升（规则过于严苛）
  • 群体质量下降，而标记率保持平稳（团伙操作未被发现）
  • 符合条件的事件退款率上升（事件门槛过低）

调用示例

• “我们的餐盒订阅服务给双方各 $25，有人刚用 40 多个加号寻址的电子邮件账号刷了奖励。重新上线前，先写好防护规则。”
• “我们下个月要在健身应用中推出‘推荐好友，双方各得 10’——设计好上限、暂扣政策和验证关卡，确保上线第一天就不会被钻空子。”
• “我们的 B2B SaaS 每有一个被推荐的工作区转为付费，就发放 $500 账户额度；财务怀疑有代理机构在推荐自己的空壳账户。制定防滥用规则和审核流程。”

参考资料

• 梳理滥用风险面时，阅读 references/abuse-patterns.md——其中包含消费者奖励滥用分类，列出每种模式的可观察特征以及已记录的事件。
• 设置上限、暂扣、资格规则和验证关卡时，阅读 references/guardrail-mechanics.md——其中包含附有来源依据的已发布数值、摩擦阶梯和 B2B 专项内容。
• 选择监控信号时，阅读 references/detection-signals.md——其中包含信号强度评级、正在失效的信号以及校准基准。
• 编写执法阶梯、原因说明、申诉流程和法律设计限制时，阅读 references/enforcement-and-compliance.md。
• 设计交付内容时，阅读 references/worked-examples.md——其中包含一份已填写的 B2C 规范、一份已填写的 B2B 规范，以及一个反面示例。
• 有关奖励结构（奖励对象、类型、金额、发放触发条件、层级），请参阅 mbfinotti/partnerships-skills@referral-incentive-design——此技能用于保护该结构，不会重新设计它。
• 有关专业联盟流量和佣金欺诈，请参阅 mbfinotti/partnerships-skills@affiliate-fraud-detection。
• 仅当该计划也设有专业联盟层级时，才参阅 mbfinotti/partnerships-skills@affiliate-program-terms，以了解消费者推荐好友条款的措辞。