2023年6月，一个工具类App对外宣称日活120万，投资人尽调时发现真实日活只有76万。差距来自口径：后台统计的是启动次数去重设备数，包含推送唤起、后台唤醒、第三方SDK拉起。修正过程走了4步：1）剔除无用户操作的唤醒，日活降到98万；2）剔除3秒内退出的异常启动，降到89万；3）按自然日0点到24点切分，跨天会话只算一次，降到81万；4）去掉测试设备和内部员工账号约5万台，最终76万。
平均数最容易骗人。某功能使用时长，平均值显示18分钟，看起来不错。但把数据按分位数切开：中位数只有4分钟，90分位是62分钟。也就是说10%的重度用户撑起了整体均值，剩下90%的人用完就走。产品经理照着18分钟去设计深度功能，上线后使用率不到8%。看分布永远比看均值更接近真相。
对比两个渠道的次日留存。渠道A投放1万人，次日留存42%；渠道B投放5000人，次日留存46%。表面看B更好。算一下标准误：A的留存率标准误约√(0.42×0.58/10000)≈0.49%，B约√(0.46×0.54/5000)≈0.70%。两个95%置信区间分别是41.0%-43.0%和44.6%-47.4%，其实并不重叠，B确实更好。但如果B只有500人，标准误升到2.2%，区间41.6%-50.4%，和A大量重叠，就不能下结论了。
时间窗口选错会得出相反结论。某活动7月1日上线，运营看1-3日数据，转化率比平时高35%，大喜。把窗口拉到7月1-14日，整体转化率只高4%，因为前3天是老用户集中回访，属于存量释放。正确做法是对比活动前后各14天的同期均值，同时剔除周末效应。周五和周日的下单率能差20个百分点，不做日期对齐很容易把波动当成效果。
统计口径要写进文档并锁定版本。某公司两个团队同时汇报月活，一个报2300万一个报1900万，开会吵了40分钟。查下来差异是：一个包含小程序入口，一个不包含；一个按设备去重，一个按账号去重；一个统计自然月，一个统计滚动30天。三个维度组合出8种口径。后来统一为账号去重、自然月、含小程序，并在数据集市里做成唯一指标，争议才消失。
漏斗分析常见错误是把步骤顺序搞反。某注册流程5步：打开落地页、点击注册、填手机号、收验证码、设密码。整体转化率2.8%。逐级看：落地页到点击注册58%，点击到填手机号71%，填手机号到收验证码89%，验证码到设密码只有9%。问题出在最后一步，验证码到达率低。若只看整体2.8%会误以为是拉新问题，实际是短信通道在晚高峰拥堵，19点到21点到达率从96%掉到61%。
