企微老客推荐异常防刷

解决什么问题

企业微信的老客推荐活动里，奖励往往与“成交”挂钩：老客分享专属入口，新客通过会话或订单完成核销，双方都拿到好处。问题在于，这套链路的参与方并不只有真人。同一批设备批量注册、同一笔支付反复使用、退款后又退回领奖名额、甚至根本没有发生真实成交的“核销”，都会稀释真正老客推荐的价值。

但防刷的难点不在于“抓坏人”，而在于不误伤正常推荐。阈值太松，羊毛党把预算吃干净；阈值太紧，真实的老带新会被拦掉，成交率和客诉一起出问题。更麻烦的是，很多团队把风控当成一次性的运营活动，没有把判断依据、处理级别和申诉流程固化下来，出了问题只能临时拍脑袋。

这个技能如何工作

它只做一件事：把防刷规则设计成一份异常检查清单，而不是替你去拦截、处罚或改规则。

• 前置输入：客户标签、推荐关系、核销记录、历史异常、设备支付信息、退款记录。缺哪一项，先输出补证据清单，而不是硬着头皮往下走。
• 硬约束：不读取通讯录 且 需明确有效新客。任何方案都不允许用“我们先拉个通讯录比对一下”这种兑现不了的承诺绕过这条线。
• 信号建模：识别同设备、同支付、短时集中、重复退款和虚假核销这几类异常信号，并为每个信号给定判断阈值和处理级别（放行 / 延迟 / 复核 / 拒绝）。
• 申诉与核验：每个风险信号都要写清复核证据、通知方式和申诉规则，避免“系统判了就没得说”。最终交付前，用专属入口、会话和订单记录交叉核验，并以 有效推荐成交率 作为复查指标。

需要说清楚：阈值不能凭空写。清单里每个阈值都要能对应到具体的数据口径或业务依据，否则宁可标记为“待确认”。

适用边界与注意点

• 它不替代全盘策略、真实平台操作，也不替你做合同或合规审批。
• 涉及预算、价格、库存、时间、平台规则、会员或客户数据时，必须标明来源和日期，并把已确认事实、分析判断、待确认事项分开。
• 质量检查里有一条很关键：风险信号不直接定罪。识别出来的是“可疑”，不是“判定”，处罚权始终在业务方手里。
• 当专属入口、会话和订单记录无法对应到关键判断时，或有效推荐成交率缺乏清楚计算口径时，输出应该是“暂不可交付”，而不是用空泛建议填满模板。
• 不承诺流量、转化率、收入、排名或活动效果；不读取密码、Token、私钥及与任务无关的个人信息；涉及真实发送、付费、退款或生产变更时，必须先取得明确授权。