某工具类应用在2023年3月的周报里写「7日留存41%」，环比涨6个点，团队准备加大投放。复核时发现统计口径混了：分母用了当日新增设备数，分子却用了7天后仍有活跃的账号数，一个用户两台设备就被算了两次。修正后7日留存实际33%，环比只涨1个点。
第一个坑是设备与账号混算。该应用月活约80万，设备数92万，差值12万来自双端登录。正确做法是先按账号去重，再关联设备。步骤：①取注册表按user_id去重；②活跃表按user_id+日期聚合；③留存表以注册日为起点做左连接。常见错误是直接对原始日志做count distinct，日志里同一行为可能上报两次。
第二个坑是自然日与滚动24小时混淆。产品定义「次日留存」为注册后第2个自然日活跃，但数据同学用了注册后24小时内活跃，导致晚间注册用户被低估。对比测试：按自然日算次日留存38.2%，按滚动24小时算41.5%，差3.3个百分点。金额上，这影响投放预算判断约每月15万元的分配。
第三个坑是分母口径漂移。1月新增12.4万，2月新增9.8万，3月新增14.1万。若用「当月新增」做分母，留存率受新增量波动影响大；改用「月初存量+当月新增」的队列口径更稳。队列表按注册周分组，每组跟踪8周，共32个队列，每队列样本量不低于5000才出报表。
概率层面要区分点估计和置信区间。33%的7日留存，样本量14.1万，95%置信区间约±0.25个百分点。但若只看某个渠道的2万新增，区间拉宽到±0.7个百分点。两个渠道留存差1.2个百分点时，先算区间是否重叠，再决定是否调整渠道预算，避免把噪声当信号。
修正后的统计看板加了4道校验：①账号设备一对一映射表每日更新；②自然日定义写进指标字典，版本号v2.1；③队列样本量低于5000标灰；④留存率同时展示点估计和区间。上线后月度复盘会议时间从3小时压到1.5小时，争议减少。
一个具体案例：某渠道A投放单价28元，7日留存35%；渠道B单价22元，7日留存31%。粗看B更划算，但把7日留存换算成7日内活跃天数，A人均4.1天、B人均3.2天，再结合每次活跃的广告展示收入0.9元，A的7日回收是28.9元、B是25.1元。加上留存区间后，A的回收区间26到32元，B是23到27元，决策改为A为主、B为辅。
数据统计的常识是：口径先于计算，队列先于汇总，区间先于结论。这三条写进团队规范，每次报表发布前由第二人复核，复核项共11条，平均耗时20分钟，比事后返工省得多。
