同一用户 24 小时下了 3 单 漏斗第二步把转化算成 300%

SELECT COUNT(DISTINCT user_id) FROM event WHERE step = 'pay_success' AND dt = '2026-03-01';
SELECT user_id, COUNT(*) c FROM event WHERE step='pay_success' GROUP BY user_id HAVING c > 1;

下单漏斗第二步显示转化率 300%，实际下单用户 1,200，步骤事件 3,600 次，运营以为埋点坏了。先别急着动参数，把报错原文和时间点记下来，顺序反了容易白折腾。

原因不复杂，漏斗按事件次数算，没有按用户去重，同一用户重复下单被算了三次。分母用的是去重用户数，分子用的是事件数，两边粒度不同。步骤之间也没有限制先后顺序。

「漏斗重复计算」改完先别急着全量，挑一台机器放半天，真有问题这段时间就能看出来。改完隔一天再看一次，当场正常不代表能稳住。

测试环境和线上的差别，往往就在版本号和那几行被忽略的配置上。线上出问题先对时间点，跟发布、备份、任务执行的时刻排一排，能省掉一半功夫。

处理上按这个顺序：漏斗每步按用户去重 同一用户只算一次；分子分母统一到用户粒度；加时间窗口 只算首次进入后 7 天内；用一批已知重复下单的账号回算验证。

改完只确认一件事：漏斗第二步回到 100% 以内，重复下单用户只计一次。