为何Firebase的churn预测记录时间晚于用户实际流失时间？

核心逻辑遗漏点 #

• Firebase预测导出到BigQuery的prediction_time字段为预测结果计算完成写入表的时间，并非预测的基准行为截止时间。预测是基于用户截至basisTime（表内对应字段）的历史行为，预测未来指定窗口（默认流失预测为7天）的流失概率，prediction_time通常比basisTime晚1-2天，若用户在basisTime之后、预测结果落地之前发生卸载，就会出现卸载事件时间早于prediction_time的情况，属于正常现象。
• 当前查询的对比逻辑存在缺陷：
  1. 你为每个用户取了首次预测概率>0.2的日期，和用户全量历史中最后一次卸载的日期做匹配，完全没有对应预测的有效窗口。流失预测仅对生成后对应窗口内的行为有效，跨时间匹配自然会出现大量时间逻辑矛盾的记录。
  2. 若用户存在卸载后重装、再次卸载的情况，取MAX(卸载日期)会完全匹配不到早期的预测记录，进一步放大时间偏差。
• 少量异常上报的app_remove事件存在时间戳偏移：移动端离线状态下发生的卸载事件，会在后续联网时上报，部分极端场景下会出现事件时间戳记录错误，可过滤掉上报时间和事件时间差超过7天的异常数据。

现有查询的优化建议 #

你需要为每一条符合阈值的预测记录，匹配对应预测窗口内的卸载事件，而非按用户全局聚合后匹配，参考修正逻辑如下：

SELECT
  -- 预测基准时间（不是落地时间prediction_time）
  CAST(u.basisTime AS DATE) AS prediction_basis_day,
  u.user_id,
  p.probability AS churn_prediction_prob,
  -- 匹配预测窗口内的卸载日期
  MIN(CAST(TIMESTAMP_MICROS(a.event_timestamp) AS DATE)) AS churn_in_window_day
FROM
  `Predictions_table` AS u,
  UNNEST(u.predictions) AS p
LEFT JOIN `Analytics_table` a
  ON u.user_id = a.user_id
  AND a.event_name = 'app_remove'
  -- 卸载发生在预测基准时间之后的7天窗口内（和Firebase默认预测窗口对齐）
  AND TIMESTAMP_MICROS(a.event_timestamp) BETWEEN u.basisTime AND TIMESTAMP_ADD(u.basisTime, INTERVAL 7 DAY)
WHERE
  p.id = 'churn'
  AND p.probability > 0.2
  AND NOT (u.user_id IS NULL OR u.user_id = '')
GROUP BY
  prediction_basis_day,
  u.user_id,
  churn_prediction_prob

内容的提问来源于stack exchange，提问作者Mohammad Eskandari