2024年1月，上海一家工具类应用的数据组和增长组对同一周的DAU吵了起来：数据组说DAU是412万，增长组说是387万，差25万。查了3天，发现是“活跃”定义不同。数据组把“启动即活跃”算进去，增长组要求“启动且停留超过3秒”。两个口径都合理，但放在同一张周报里就是事故。最后统一成“启动且停留超过3秒”，周报重发，历史数据回溯重算花了11个小时。
统计口径要写清楚4个要素：时间窗口、去重维度、过滤条件、计算方式。举例：DAU=当日0-24点内，设备ID去重，排除停留小于3秒的启动，按自然日切分。少写一个要素，数字就能差出5%-8%。某次做留存率，一边用“注册后第7天当天活跃”，一边用“注册后第7天及以后7天内活跃”，同一批用户算出21%和34%，差了13个百分点。
概率抽样也有坑。做用户满意度调研，团队在APP内弹窗随机抽10万人，回收1.2万份，满意度4.3分。但弹窗只对“近7天活跃用户”展示，沉默用户根本没机会被抽到。结论写成“用户满意度4.3”就是以偏概全。改成短信+弹窗双渠道，沉默用户回收3200份，满意度3.6分，整体修正为4.0分。偏差0.3分，在决策上就是从“可以涨价”变成“再等等”。
数据统计里最常见的错误是辛普森悖论。某次改版，iOS端点击率从5.1%升到5.6%，安卓端从4.8%升到5.2%，两端都涨，但整体点击率从5.0%降到4.9%。原因是iOS用户占比从60%降到45%，而iOS点击率本来就高于安卓，结构变化把整体拉低了。看整体数字会误判改版失败，分端看才知道都成功了。
对账流程建议固定成4步：1）双方各自写出指标定义文档，不超过200字；2）用同一份原始数据各算一遍，看差异出在哪一步；3）差异超过1%必须定位到具体SQL或过滤条件；4）统一口径后写进指标字典，版本号加1。某团队按这个流程跑了半年，指标争议从每月3-4次降到每季度1次。
成本也要算。每次口径变更，历史数据重算、报表刷新、下游模型重训，一次约消耗12人时。一年改5次口径就是60人时，够做一个小功能了。所以口径要在需求评审时定死，上线后至少稳定3个月再动。
还有一个细节：时区。做海外业务时，UTC时间和本地时间混用，DAU能差出一天的量。某次报表把美国用户按UTC切分，晚上8点的活跃被算到第二天，日活曲线出现规律性凹陷。改成按用户本地时区切分后曲线平滑了。时区、夏令时、跨年，这三个时间点每年都要单独检查一次。
