2022年9月，某工具类App的运营周报上日活写着120万，技术侧监控显示只有87万。差异来自口径：运营用的是“当日启动去重设备数”，技术用的是“当日有任意接口请求的去重用户数”，两者相差33万，主要是后台保活和推送唤起的启动。
四种常见日活口径，按数值从大到小排：1）启动口径，App冷启动或热启动即算，数值最大，通常比真实活跃高10%到20%；2）前台口径，App在前台停留超过1秒才算；3）接口口径，当日至少一次业务接口请求，能过滤掉纯推送唤起；4）核心行为口径，比如完成一次搜索或播放，数值最小，一般只有启动口径的55%到70%。对外汇报用哪个，要写清楚，否则跨部门对数永远对不上。
一次典型事故：2021年11月，某社区把日活统计从启动口径改成前台口径，数值从210万掉到156万，运营以为产品出问题，紧急排查了6小时。实际是口径切换没提前通知。事后定的规矩是：口径变更必须提前一周在数据字典里标注版本号，新旧口径并行跑30天，差值超过8%要出说明。
统计里的另一个坑是去重维度。按设备去重和按账号去重，在换机频繁的群体里能差出15%。某电商2023年春节活动，按设备算参与率是23%，按账号算只有19%，因为不少用户用两台手机登录同一账号。活动预算按23%做的，实际核销超了预算的12%。
对比两种埋点方案：前端埋点在按钮点击时上报，优点是及时，缺点是网络差时丢报，实测丢报率3%到8%；后端埋点在服务端收到请求时记日志，优点是不丢，缺点是无法区分用户是否真的看到了界面。稳妥做法是核心转化用后端埋点，曝光类用前端埋点加补报，两端对账差异超过2%就查。
概率抽样在用户调研里也常出错。某团队从日活用户里随机抽2000人发问卷，回收率18%，只有360份。这360人的平均使用时长比全量高22分钟，因为重度用户更愿意填问卷。修正办法是按使用时长分层抽样，每层按真实占比分配名额，再做加权，加权后偏差从22分钟降到4分钟。
数据统计的三条硬规则：1）任何比率都要同时给出分子、分母和去重口径；2）跨周期比较前先确认统计时段是否等长，2月比1月少2到3天是常态；3）异常波动先查埋点版本和口径变更记录，再查业务，经验上六成“数据异常”是统计问题，不是业务问题。
