LT 预测(用户生命周期预测)
预估用户平均存活天数与留存曲线下面积,为 LTV 计算提供核心衰减参数。LT 不准,则 LTV 必偏。
LT 预测是 ThinkingAI 行业 Skill 库中的一项用户存活时长预估能力,帮助增长与运营团队基于留存率数据预测用户平均活跃天数(LT)——这是 LTV 计算的核心衰减参数,LT 不准则 LTV 必偏。这正是 ThinkingAI「10 年行业经验沉淀为开箱即用 Skill」的体现。
login、注册属性 #reg_timeae-analysis 拉取 1 月 31 个注册队列的分日留存scipy 积分求留存曲线下面积,生成 LT 与预测表算完了。先说结论:55 天的老口径高估了 30%,拟合出来的 LT 是 42.3 天——按 0.6 元/天的 ARPU 折算,LTV 应为 25.4 元而不是老口径的 33 元,投放回本对不上的根源就在这。
一、有效队列与置信度
1 月注册跨 31 天,不同注册日的留存数据长度不一,直接平均会被短队列污染。先按有效队列数分层:
| 留存天数节点 | 有效队列数 | 置信度 | 处理 |
|---|---|---|---|
| D15 | 17 个 | 高 | 全量参与拟合 |
| D25 | 7 个 | 尚可 | 参与拟合 |
| D31 | 1 个 | 低(<5 个) | 标注剔除,不参与拟合 |
二、拟合曲线与外推
衰减形态是幂函数(衰减速度在放缓),属于健康形态——如果拟合出指数衰减(流失加速),问题就不只是口径了。你们的 LT 问题出在起点估算,不在曲线本身。
三、参数与预测
| 项目 | 数值 | 说明 |
|---|---|---|
| LT(截断 365 天) | 42.3 天 | 拟合曲线积分求面积 |
| 拟合函数 | r(n) = 0.46·n^(-0.295) | 幂函数,三者中 R² 最高 |
| R² | 0.91 | 对数 0.87 / 指数 0.79 |
| 安全预测窗口 | D90 | 有效数据至 D25,超窗需滚动校准 |
| 预测留存 | D30 16.9% / D60 13.7% / D90 12.2% | 与图表预测段一致 |
行业痛点
LTV 的计算公式是 LT × ARPU,其中 LT(用户生命周期天数)是留存曲线下面积。多数团队用倍数法估算 LT(如 D7 留存×倍数),但倍数法本质上靠人猜衰减速率,偏差极大——某团队用 3 倍法估算 LT 为 21 天,实际拟合后仅 14 天,LTV 估算偏高 50% 导致回本判断完全错误。更精准的做法是对留存曲线做函数拟合后积分求面积,但需要数学功底且单次手动执行耗时 30 分钟以上。时间段聚合场景(如"整个 1 月份新增用户")更复杂——不同注册日的队列产生不同长度的留存数据,加权计算易出错,手工计算一次平均需 1-2 小时。
核心价值
- 支持三种曲线拟合(幂、对数、指数),自动选 R² 最高的输出,积分求面积得到 LT
- 时间段聚合场景自动计算有效队列数,有效队列 < 5 的数据点标注"低置信度"不参与拟合
- 数据不足时可借用成熟批次的衰减率辅助预测,并标注借用来源和版本一致性
- 输出包含 LT 估算值、拟合函数参数、R² 评分、安全预测窗口和免责声明
- 提供加权留存 SQL 兜底方案,确保无 MCP 接口时也能执行
适用场景
新批次买量后,需要预估用户平均存活天数以配合 LTV 计算
整月或整季度新增用户的加权 LT 估算,不同注册队列留存长度不一致
留存曲线衰减形态判断——幂函数衰减(健康)还是指数衰减(流失加速)
对比不同渠道或版本的 LT 差异,辅助投放和产品决策
已有 LTV 预测结果但 LT 参数不确定,需要独立校准
实战案例
常见疑问
LT 和 LTV 有什么区别?
LT 是用户存活天数(留存曲线下面积),LTV 是用户生命周期价值(LT × ARPU);LT 是 LTV 的核心输入参数,LT 不准则 LTV 必偏。
只有 7 天数据能做 LT 预测吗?
可以但偏差较大,安全预测窗口仅 7-10 天;建议借用成熟批次衰减率辅助,或持续滚动校准。
时间段聚合怎么处理不同队列长度?
Skill 自动计算每个留存天数对应的有效队列数,有效队列 < 5 的数据点标注低置信度并排除出拟合,确保加权计算可靠性。
相关 Skills 推荐
用「LT 预测(用户生命周期预测)」武装你的 Agent
预约演示,看看它如何在你的业务场景中落地

