Q3.11.5Sampling undercount of rare events设计研究
采样与上报丢失会系统性低估低频行为
别名: 客户端采样 · 上报丢失 · rare-event undercount
概念解释
为了省流量和存储，客户端常按用户或按事件抽 1%、10% 再上报；网络失败、进程被杀、队列溢出则造成随机或与环境相关的丢失。对高频动作，留下的仍能画出形状；对崩溃、支付失败、无障碍快捷键这类低频行为，一次没抽中或一次没发出，计数就可能从一变成零。于是稀有事件的发生率被系统性压低，看起来“几乎没人这样做”。
机制
伯努利采样对期望计数是无偏的，但对零膨胀的稀有事件，大多数窗口的观测是零，方差极大，小流量下估计贴着零。若采样单位是用户，从未被抽中的人身上发生的稀有动作永久缺席；若采样单位是事件，连续失败可能整段丢失。上报丢失往往与弱网、低端机、后台被系统回收相关，而这些环境里错误和中断更常见——丢失与目标行为正相关，低估就不是随机噪声。再对“有数据的用户”做分析，等于在已经削掉尾部之后再条件化。
怎么研究
写明采样率、采样单位、重试与本地缓存策略，以及丢失是否可观测（失败计数、队列长度）。对稀有事件停止用采样流估计发生率，改全量、提高采样，或用服务端权威日志。用捕获-再捕获或与服务端对照估计丢失率，并按网络类型和机型分层，检查丢失是否与错误相关。报告稀有率时同时给有效暴露量和零事件窗口数，避免把“没看到”写成“发生率为零”。
边界
对本来就接近全员发生的行为，轻度采样的形状误差可忽略。服务端成功落账的交易通常不依赖客户端采样，客户端丢失伤害的是过程事件而非账本。故意降采样调试日志是工程选择，前提是稀有告警另走全量通道。隐私最小化会限制能留多久的全量，但不能用采样冒充已经观察过尾部。
怎么落地
- 把崩溃、支付失败、权限拒绝、无障碍快捷键标成全量事件，禁止进百分比采样桶。
- 看板区分“采样估计”和“全量计数”；采样系列不得用于宣称某错误已经消失。
- 监控上报失败率和按机型的到达率，失败率升高时冻结稀有事件结论。
- 复盘“为什么没人用”之前先查该行为是否在采样桶里；若是，先改采集再下产品结论。