第四章 一级指标的口径与计算逻辑

一级指标是从北极星指标向下分解的第一步，其口径、数据源和计算周期的清晰度直接决定后续维度拆解的可信度与看板分析的准确性。本章聚焦口径定义的三大基石：口径定义、数据源、计算周期，并给出结构化的落地方法。

3.1 口径定义的三个命令

每个一级指标需回答三个问题：
① 分子/分母是谁？—— 明确包含与排除的实体。
② 什么算“发生一次”？—— 定义计数单位（用户级/事件级/订单级）。
③ 时间窗口如何切割？—— 按自然日/周/月，还是按用户注册时间对齐？

3.2 数据源的确定原则

数据源选择直接影响口径的可复现性。应遵循：

• 单一权威源：优先使用业务库主表（如 order_paid），避免多表 join 导致的延迟偏差。
• 数据血缘可追溯：记录 ETL 处理步骤，确保从原始日志到指标的变换路径透明。
• 采样 vs 全量：一级指标必须使用全量数据，不允许抽样。

3.3 计算周期的三种模式

根据业务节奏选择计算周期：

1. 固定周期（自然日、自然周、自然月）—— 适合 GMV、DAU 等宏观指标。
2. 滑动周期（过去7天/过去28天）—— 适合转化率、留存率等需要平滑波动的指标。
3. 生命周期周期（注册后第N天）—— 适合用户行为分析，如“注册后7日内支付率”。

以下 SVG 展示了一级指标口径定义、数据源、计算周期三者的关系与传递链条：

3.4 从口径到计算逻辑：SQL 示例（非主体）

以下 SQL 仅为展示口径在计算中的具体体现，实际看板应在数仓中提前清洗：

-- 计算“老用户支付转化率”（口径：过去28天至少登录1次且当天支付成功）
WITH user_pay AS (
  SELECT user_id, MIN(order_time) AS first_pay_time
  FROM order_paid
  WHERE order_status = 'paid'
  GROUP BY user_id
)
SELECT
  COUNT(DISTINCT p.user_id) AS paid_users,
  COUNT(DISTINCT a.user_id) AS active_users,
  COUNT(DISTINCT p.user_id) * 1.0 / NULLIF(COUNT(DISTINCT a.user_id), 0) AS conversion_rate
FROM user_activity a
LEFT JOIN user_pay p ON a.user_id = p.user_id
  AND DATE(p.first_pay_time) = DATE(a.activity_date)
WHERE a.activity_date = CURRENT_DATE
  AND a.days_since_last_login BETWEEN 0 AND 28;

3.5 看板中的口径文档化

每个一级指标在看板中必须附带以下信息（建议使用指标元数据表）：

• 口径定义：一句话的精确描述，含排除规则。
• 数据源表名：生产环境与数仓环境分别注明。
• 计算周期：明确是自然日/滑动日/注册日。
• 更新频率：T+1 / 小时 / 实时。
• 负责人：便于异常回溯。

例如：