解读

面试官问“渠道级实时LTV预测看板”，核心想验证三件事：

1. 能否把抽象的LTV拆成可落地的渠道口径（不同渠道用户贡献的钱怎么算、算到哪天为止）；
2. 能否用国内主流数据工具把“预测”做成“实时”（不是T+1跑数，而是小时级甚至分钟级刷新）；
3. 能否把预测结果变成运营可读的“看板”（一眼看出哪个渠道今天亏、哪个渠道明天要爆雷）。
   回答必须体现“数据+业务”双视角：既讲埋点、模型、调度，也讲怎么让运营同学愿意每天打开看板做预算调整。

知识点

1. LTV定义与渠道归因
   • 国内默认用**“7日回收+预测后续”**打法：先算已发生的7日GMV/广告金，再用概率模型预测后续。
   • 渠道归因按**“最后一次点击”+“设备号匹配”，iOS用ASA+SKAN 4.0**，安卓用OAID+渠道包+UTM。
2. 实时数据链路
   • 埋点：客户端埋点→Kafka→Flink实时ETL→ClickHouse/Doris宽表。
   • 订单：业务库Binlog→Maxwell/Canal→Kafka→Flink→Redis缓存最新成交。
3. LTV预测模型
   • 已发生部分：窗口函数实时聚合。
   • 未发生部分：
     – 新客冷启动：XGBoost/LightGBM用“渠道+媒体+素材+人群包”特征做7→30→180天分层预测；
     – 老客滚动：Gamma-Gamma+BG/NBD概率模型，每日凌晨Airflow调参刷新。
4. 看板实现
   • 指标：渠道级实时LTV0、LTV7、预测LTV30、预测ROI、回收周期。
   • 工具：Superset/Metabase直连ClickHouse，Redis缓存1分钟级结果，飞书/企业微信订阅机器人推送异常。
5. 运营闭环
   • 阈值：预测ROI<1的渠道自动暂停投放；
   • 预警：分位数箱型图监控，低于P10的渠道标红并@渠道经理。

答案

分五步落地，每一步都给出国内可直接套用的技术栈与业务规则。

第一步：统一口径

1. 收入口径：用不含退款、不含优惠券成本的实付GMV；
2. 成本口径：用渠道当天实际消耗+平台技术服务费；
3. 归因窗口：iOS7天点击窗，安卓7天点击+1天展示窗；
4. 口径文档写进飞书多维表格，财务、投放、运营三方签字冻结，防止事后扯皮。

第二步：实时数据层

1. 埋点：客户端用神策/GrowingIO埋点SDK，事件名固定为pay_success带order_id、channel、campaign、ad_id、cost；
2. 流式计算：
   • 用户行为流：Flink 1.16消费Kafka，Watermark 5秒，双流Join订单流；
   • 订单流：MySQLBinlog→Kafka，FlinkLookup Join补全优惠券金额；
3. 存储：
   • 明细写ClickHouse分区表，按**(channel, stat_date, hour)**分片；
   • 聚合结果写Redis Hash，Key格式ltv_channel_{channel}_h{hour}，TTL 48小时，供看板秒级查询。

第三步：LTV预测模型

1. 特征工程：
   • 实时特征：当日CTR、CVR、CPM、激活率、首单率、复购率；
   • 离线特征：过去30天留存率、客单价、退款率、品类偏好；
2. 模型训练：
   • 新客模型：每天0点Airflow调度，用LightGBM回归log(LTV30)，损失函数Tweedie；
   • 老客模型：每周日Spark MLlib跑BG/NBD+Gamma-Gamma，输出E[CLV]；
3. 模型上线：
   • 把LightGBM的PMML推入Flink UDF，实时打分写入Redis；
   • 老客部分批跑结果写MySQL，Flink异步I/O关联补齐。

第四步：看板搭建

1. 指标层：
   • 已发生：LTV0、LTV1、LTV7；
   • 预测：pLTV30、pLTV180、pROI= pLTV30/消耗；
   • 辅助：回收周期=消耗/日均实付GMV；
2. 可视化：
   • Superset直连ClickHouse，图表用双轴图（柱状=消耗，折线=pROI）；
   • 渠道筛选器+素材下钻，支持联动；
3. 实时性：
   • Redis缓存1分钟过期，看板自动刷新30秒；
   • 大促期间把Flink checkpoint降到30秒，延迟控制在1分半内。

第五步：运营闭环

1. 预警：
   • pROI<1且消耗>5000元的渠道，飞书机器人**@渠道经理+财务**；
   • 连续3小时激活成本>目标1.5倍，自动暂停该广告组（通过巨量引擎OpenAPI）；
2. 复盘：
   • 每周一AB实验对比“模型预测 vs 真实LTV30”，**MAPE>15%**触发模型重训；
   • 把误差写入飞书OKR系统，作为数据组季度考核。

用以上五步法，可在4周内上线MVP：第1周冻结口径，第2周打通实时数据，第3周模型+看板，第4周运营闭环与预警。上线后，渠道预算浪费可下降12%-18%，大促峰值决策时间从6小时缩短到10分钟。

拓展思考

1. iOS隐私政策升级后，SKAN 4.0的回传窗口拉长到35天，如何把** coarse转化值映射到收入，再用贝叶斯层级模型**校正渠道级LTV，是下一阶段重点。
2. 当渠道数量>2000条/日，Flink实时Join会背压，可考虑把预测任务拆成“微批”（5分钟窗口），用Spark Structured Streaming轻量替代，牺牲2分钟延迟换稳定性。
3. 若公司同时有小程序、App、H5三端，需先做UnionID+OAID+手机号的统一ID-mapping，否则LTV会被重复计算或漏算。
4. 真正让投放同学“敢”按预测数据调预算，需要把预测置信区间一起透出，并在看板上给出**“建议调降比例”**，否则只看单点值没人敢动。