第2章 核心指标定义与口径对齐：DAU/MAU、留存率、转化率、LTV的口径统一

产品迭代依赖数据驱动，而数据驱动的基础是指标口径统一。同一指标在不同团队、不同产品阶段可能有完全不同的计算方式，导致数据“对不上”、结论“打架”。本章从定义、口径、拆解、看板、异常、动作、复盘七个层面，系统对齐 DAU/MAU、留存率、转化率、LTV 四大核心指标。

2.1 指标定义与业务含义

2.2 数据口径对齐规则

口径对齐是跨团队协作的“宪法”。以下三个维度必须逐项书面约定，并在数据字典中版本化管理。

▸ 时间窗口对齐

• 自然日/自然月：按 00:00:00–23:59:59（UTC+8）切割，不跨时区漂移。
• 滚动窗口：如“过去 7 天活跃”按当前时刻向前滑动 7×24h，适用于实时看板。
• 对齐基准：公司内统一使用“自然日+UTC+8”作为主口径，滚动窗口仅用于实时监控。

▸ 用户识别对齐

• 设备 ID vs 用户 ID vs 账号：未登录场景靠 device_id，登录后合并为 user_id，最终以 user_id 为唯一标识。
• 去重规则：同一 user_id 一日内多端登录只计 1 次 DAU；多设备场景优先保留主设备。

▸ 事件定义对齐

每个核心指标对应的事件必须在埋点规范中明确“事件名+触发时机+属性”。以下为口径定义配置示例：

{
  "dau": {
    "name": "日活跃用户",
    "time_window": "自然日 00:00:00-23:59:59 UTC+8",
    "user_key": "user_id",
    "event_list": ["app_launch", "page_view", "core_action"],
    "dedup": "user_id per day"
  },
  "retention_d1": {
    "name": "次日留存率",
    "time_window": "注册日+1 自然日",
    "user_key": "user_id",
    "numerator": "第1日回访 UV",
    "denominator": "注册当日新增 UV",
    "event_condition": "至少发生1次 app_launch"
  },
  "conversion_core": {
    "name": "核心转化率（注册→首购）",
    "time_window": "自然周",
    "user_key": "user_id",
    "funnel": ["register", "first_purchase"],
    "step_condition": "同一 user_id 在 7 日内完成两个事件"
  },
  "ltv_180": {
    "name": "180 天 LTV",
    "time_window": "注册后 180 个自然日",
    "user_key": "user_id",
    "aggregation": "sum(payment_amount) / 注册用户数",
    "currency": "CNY"
  }
}

2.3 维度拆解方法

统一口径后，需要从多个维度拆解指标，才能定位迭代方向。常用拆解维度包括：

• 渠道维度：自然量 vs 付费渠道 vs 社交裂变 — 用于评估获客质量
• 版本维度：上一版本 vs 当前版本 vs 灰度版本 — 用于评估功能效果
• 用户分层：新增用户 vs 活跃用户 vs 沉默用户 — 用于针对性运营
• 地域/时段：一级城市 vs 下沉市场；工作日 vs 周末 — 用于资源调配

2.4 看板结构设计

基于四大核心指标的统一看板建议采用“三层结构”：

1. 概览层：DAU/MAU 趋势、整体留存曲线、核心转化漏斗、LTV 累计曲线 — 面向决策者，每日更新。
2. 明细层：按渠道/版本/用户分层拆解的上述指标 — 面向产品/运营，可下钻到单用户粒度。
3. 异常层：指标突变告警、口径变更日志、数据质量监控 — 面向数据团队，实时刷新。

2.5 异常解释与排查

当核心指标出现异常波动时，按以下流程快速定位：

• 第一步：排除口径变更。检查当日是否有埋点改动、事件名调整、用户去重规则修改。
• 第二步：排除数据延迟/丢失。核对数据管道监控，确认无断流或重复计数。
• 第三步：维度下钻。按渠道→版本→地域→用户分层逐层下钻，定位异常群体。
• 第四步：关联事件分析。查看该群体在异常时段的行为事件序列，寻找诱因。

2.6 业务动作驱动

指标口径对齐之后，数据才能直接指导决策：

2.7 复盘分析框架

每次迭代完成后，使用统一口径复盘四大指标的变化，形成“假设→实验→验证→标准化”的闭环：

1. 回顾口径基线：确认迭代前后口径未变更，或变更已记录在案。
2. 对比实验组 vs 对照组：DAU/MAU 是否正向迁移？留存曲线是否上移？转化漏斗是否收窄？LTV 是否提升？
3. 归因贡献度：用多维拆解判断提升来自哪个渠道/版本/用户群，避免“平均主义”误判。
4. 更新口径文档：若引入新的事件或用户分类标准，同步更新口径字典并知会全团队。