海外 IAP 业务群数据体系建设规划

01 · 建设结论

先把事实和口径做牢，再把判断交给系统

推荐顺序有明确依赖关系。统一口径和身份连接没有完成，后面的预测会学到错数；数据质量门没有上线，自动扩量会把一次数据故障放大成真实损失。

先做两个试点

02 · 经营问题与指标

所有数据都要落回五类决定

指标数量可以很多，但经营问题只有五层。每个看板、告警和模型都要说明它支持哪个决定，否则不进入首期范围。

两棵指标树

统一 cohort 与收入状态

• 获客默认按首次触达或安装 cohort；订阅经营可以另提供首次实际付费 cohort，但必须显示类型。
• D0、D1、D3、D7、D14、D30、D90 和首次续费追踪同一批用户。未成熟窗口显示“观察中”或预测值。
• 购买发起、实际扣款、退款后净流水、贡献利润、财务确认收入和现金结算不得混用。
• 每张指标卡必须能回到公式、分子、分母、窗口、时区、币种、归因版本、数据源、Owner 和质量状态。

03 · 数据来源与供数

技术中心交付五层能力，不交一张孤立的汇总表

业务所需数据分布在广告平台、MMP、产品、订单权益、财务、成本、技术监控和决策系统中。每个域都要保留原始记录、统一主键、事实模型、认证指标和质量证据。

数据从哪里来

表中的时效是业务目标，技术中心需在源系统盘点后确认。第三方平台存在隐私聚合、配额、迟到数据和结算延迟，不承诺所有场景都有用户级归因。

五层供数结构

首批事实模型

统一主键

身份       user_id / anonymous_id / install_id / session_id
功能       feature_id / capability_id / feature_attempt_id / task_id / result_id
交易       order_id / transaction_id / subscription_id / entitlement_id
投放       attribution_id / campaign_id / adgroup_id / ad_id / creative_id / asset_id
变更       release_id / experiment_id / entry_version / decision_id
审计       event_id / trace_id / query_id / schema_version / metric_version

原始事件统一存 UTC；报表同时保留业务本地日期。金额保留原币、标准币、汇率日期和版本。名称只用于展示，不能替代 ID 连接历史。

技术中心怎么给

04 · 统一产品埋点

研发登记功能，系统生成埋点、测试、看板和 Agent 语义

统一埋点是一套随代码生效的产品遥测协议。产品团队提出经营问题和使用数据，但不再逐版本命名事件、设计字段或人工核对埋点 Excel。

Feature Manifest 是研发入口

每个用户可主动发起、消耗资源、产生业务结果、属于付费承诺或会影响留存／退款的能力，都要在代码仓登记独立 feature_id。普通导航、装饰组件和没有机器可验证结果的页面不生成“功能完成人数”。

31 个固定事件覆盖全部产品

事件名稳定、低基数；产品、功能、版本、计划、素材、任务和错误原因放在字段中。业务代码不得自由拼 JSON 或直接把第三方 Analytics SDK 当第一方事实源。

一次功能尝试必须串成一条记录

• 用户主动重试创建新的 feature_attempt_id；系统自动重试沿用原 ID。
• 每个 attempt 最多一个权威终态。客户端和服务端冲突时，以 Manifest 指定权威端为准并触发质量告警。
• 服务端可验证的完成、支付、订阅和权益不得由客户端冒充权威。
• 禁止采集用户输入正文、生成内容正文、邮箱、手机号、支付敏感信息、密码、Token 和无约束错误文本。

从 Manifest 到发布门

05 · 产品数据 Agent

Agent 只回答认证问题，并把数字的证据一起交出来

Agent 是统一语义层的查询入口，不是可以任意扫原始事件的 SQL 机器人。它解析功能、指标、时间和维度，做权限与质量检查，再确定性编译查询。

页面不展示示例假数字。真实回答必须来自当前数据快照；没有数据时返回明确状态，而不是估算。

“立马退订”的固定算法

1. 选出查询期内达到指定完成规则的成功记录，并按登录 user_id 去重；匿名用户单列。
2. 只保留功能完成时订阅有效且自动续费开启的用户，形成退订率分母。
3. 按渠道确认的业务生效时间，查找完成后同一用户、同一产品、同一 subscription_id 的第一个 subscription_cancel_requested。
4. 用户多次完成时，取消事件连接取消前最近一次合格成功；每个用户在一个窗口最多计一次。
5. 分别计算 10 分钟、1 小时和 24 小时。没有走完整观察窗的用户只标记“观察中”。
6. 到期、退款、拒付、撤销、支付失败和重新开启续费分别报告，不能并入退订。

首批 13 个认证指标

默认解释和停止条件

权限和隐私先过上线门

留存与删除数字是技术设计基线，不替代公司制度。策略未获批准时，Agent 只能在试点沙箱运行。

06 · 看板、漏斗与告警

五张工作台共用认证指标，任何结论都能下钻

看板负责持续观察，Agent 负责按问题取数，告警负责在偏离时接管。三者使用同一指标版本和数据水位，不允许分别维护公式。

单个计划与单点素材的完整漏斗

曝光／自然触达 → 点击／商店访问 → 安装／Web 到达 → 首次打开／会话
→ 核心任务开始 → 首次成功 → 结果接受／导出 → 付费墙到达
→ 试用开始 → 实际扣款 → 第二次使用 → 首次续费 → 后续续费／退款／流失

分析维度固定为：产品 → 国家 → 平台／OS → 渠道 → 广告账户 → Campaign → Ad Group／Ad Set → Ad → 素材 → 入口版本 → 实验 → App／Web 版本 → 套餐／SKU → Cohort。

所有比率同时展示分子、分母和样本。素材需与同 Campaign、国家、受众、版位和入口的同期基线比较，不能只按总 ROAS 排名。

四类告警和统一接管方式

07 · 预测与智能收放量

先影子运行，再给建议；先人工审批，再有限自动化

预测解决未成熟 cohort 的回收判断，但模型不能覆盖原始事实。每个历史预测都要保留当时的数据快照、特征、模型和规则版本，成熟后再用真实结果复盘。

第一版预测范围

模型上线门

• 按时间切分训练、验证和回测；与简单同类 cohort 基线比较。
• 置信区间需要覆盖真实成熟结果，误差能按产品、国家、渠道、订阅周期解释。
• 冷启动使用业务基线或相似 cohort，并扩大不确定区间，不伪造精度。
• 数据质量变差、模型漂移或产品机制改变时，自动退回规则与人工判断。
• 用预测支持的动作还要与“不执行”对照，验证是否产生增量。

五种建议与执行护栏

• 一次只改变预算、出价、国家、受众、素材或入口中的一个主要变量。
• 每次动作有限额、冷静期、审批等级、平台响应、失败回滚和效果窗口。
• 数据延迟、归因断链、支付异常、版本事故或履约容量不足时自动冻结。
• 高风险内容、隐私、商店和合规决定不交给自动化。

08 · 技术交付与路线

20 周完成从合同到人工审批执行，自动化另设验收

每个阶段都要有可以回读的业务结果。页面上线、接口返回 200 或看板有图表都不算验收；需要从源记录、事实表、指标、Agent／看板一路对账。

技术中心启动周要交的材料

每张表和接口都要有合同

• 权威源、业务 Owner、技术 Owner、异常联系人、业务含义、粒度、主键和唯一性。
• 字段、枚举、必填、单位、时区、币种、事件时间、处理时间和源更新时间。
• 增量方式、SLA、迟到数据、退款回补、历史重算、删除、幂等、重试、死信与重放。
• 历史覆盖、Schema 兼容、变更通知、对账对象、差异容忍、原因码、权限、脱敏、留存和审计。
• 对应的 Feature Manifest、事件 Schema、完成规则、认证指标版本和消费方。

首批建议验收线

这些是启动讨论目标。完成现状盘点后可以调整，但必须保留版本、审批理由和对指标／模型的影响。

组织边界

可下载的机器合同

下列文件已经内嵌在本 HTML 中，可以直接下载后放入技术中心版本库。它们是设计合同，不是生产 SDK。