十个人发出一百个邀请链接不等于新增一百个用户。链接打开、注册、完成有效使用和获得奖励是四种事件。如果把它们混成一个“转化”再精确的小数也没有解释力。对独立产品我会先定义奖励触发点和反重复规则再决定是否需要优化邀请文案。本文用本地模拟事件说明口径没有真实活动数据。把人数和次数分开同一位被邀请者可以打开链接多次也可以被不同邀请者触达。统计时要明确归因政策例如首次有效邀请或最后一次有效邀请奖励政策还需要区分自邀、重复账户及异常行为。不要直接把邀请发送次数当作每人邀请人数。即便算出某个比值它也只对应特定观察窗口和人群不能直接预测长期增长。样本不足时最诚实的报告就是分子和分母。图中每一层保留独立事件奖励只从业务确认的有效使用进入。邮件或支付事件的重复交付需要幂等处理Stripe的幂等说明是一个服务端重试设计参考不能把支付API的保证直接套到整个推荐系统。去重后再统计const assert require(node:assert/strict); function uniqueActivated(events) { const ids new Set(); const users new Set(); for (const event of events) { if (ids.has(event.id)) continue; ids.add(event.id); if (event.type activated event.inviter ! event.user) users.add(event.user); } return users.size; } const events [ { id: 1, type: opened, inviter: a, user: b }, { id: 2, type: activated, inviter: a, user: b }, { id: 2, type: activated, inviter: a, user: b }, { id: 3, type: activated, inviter: a, user: a } ]; assert.equal(uniqueActivated(events), 1); assert.equal(uniqueActivated([]), 0); console.log(referrals: 2 assertions passed);保存为referrals.cjs运行node referrals.cjs。它演示事件ID和用户ID两种去重没有实现反作弊或奖励入账。真实系统还需验证ID来源、归因窗口和资格并在持久化事务中防止重复发奖。活动界面不要许诺未确认的奖励用户看到“已邀请”时应能分辨对方是否注册、是否达到条件以及奖励何时确认。若奖励仍在审核直接写待确认不要先显示到账再回收。活动结束后先复盘资格误判和支持负担再看增长。文案可以改但不能为了一个好看的系数不断移动“有效用户”的定义。