Q3.11.3Non-retrospective event capture设计研究
缺失埋点无法追溯补齐
别名: 无法回溯埋点 · 补埋无效 · no retroactive logging
概念解释
客户端和服务器只在事件被触发的那一刻发出记录。当时没有声明的事件，历史会话里就不存在对应行。事后补埋只能从补上的版本开始积累，不能让上个月的用户“重新点一次”。用相邻事件拼出来的替代指标，是另一件事情的测量，不是把缺失事件找回来。时间对日志单向流动。
机制
日志是前向写入的流。磁盘上没有负时间的插入点：用户的手机不会保存一份未发送的“应用筛选”候补。服务端若当时没记请求体里的某个字段，原始包通常也已按保留策略丢掉。从页面浏览、点击坐标或截图去反推“是否比较了两件商品”，改变了构念：比较是一种认知动作，浏览是另一种痕迹。替代可以应急，但置信区间和偏差方向都属于新指标，不能接在旧趋势后面假装连续。
怎么研究
对每个关键问题标注最早可回答的日期，即对应事件全量到达生产的日期。需要历史深度的研究，先查该日期之前有没有可接受的代理，并写明代理与目标事件的定义差。补埋后做一段新旧并行，估计代理偏差，而不是直接把新事件接到旧序列上。若决策窗口已经落在不可见的过去，改用访谈、支持记录或新的前瞻采集，并缩小主张的时间范围。
边界
服务端仍保存原始请求、或客户端本地有未采样的调试日志时，有限的字段有可能从仓库回放——这是原始材料还在，不是“凭空补事件”。合规删除和过期策略会关掉这条后路。前端完全控制的交互若从未出过网，任何后端都救不了。实时系统可以在短缓冲里补发，但缓冲长度以秒或分钟计，帮不了季度复盘。
怎么落地
- 把“这个数字从哪一天才存在”写在看板脚注里；日期之前的格子留空，不用灰色估计填满。
- 评审会问“如果下周才想到这个问题，历史是否已经永久不可见”；答案为是，则把埋点提前到功能发布，而不是发布后再说。
- 需要补历史时，单独命名代理指标，禁止与新事件同名。
- 对监管或对账类问题，发布当天就必须有事件，因为事后补的数据在审计上不算当时证据。