指标、实验与数据治理

数据产品不是“把数据库查询画成图”。一条可信的指标要经过事件采集、清洗、定义、聚合、展示和解释。中间任何一步含糊，图表都只是漂亮但不可复现的数字。

1. 从事件开始

埋点描述用户在系统中发生了什么。一个事件至少回答：

谁触发：匿名用户、登录用户、设备或服务。
何时发生：事件时间与服务端接收时间。
在哪里发生：页面、模块、客户端版本、地区。
发生了什么：事件名称和动作。
结果如何：成功、失败、错误码、耗时。
关联什么：会话、请求、订单或实验分组。

{
  "event": "checkout_completed",
  "userId": "u_123",
  "sessionId": "s_456",
  "occurredAt": "2026-10-31T12:00:00Z",
  "properties": {
    "orderId": "o_789",
    "amountCents": 19900,
    "currency": "CNY"
  }
}

1.1 事件命名与 schema

事件名应稳定、可搜索，并表达已经发生的事实。checkout_completed 比 click 更可分析。属性需要统一定义：

属性	推荐格式	注意
时间	ISO 8601 或统一时间戳	明确时区，区分事件时间与入库时间
金额	最小货币单位整数 + 币种	避免浮点和币种混淆
ID	字符串或明确整数范围	避免客户端精度丢失
枚举	限定值列表	新增值要考虑旧报表
设备/版本	结构化字段	方便比较发布前后

事件 schema 要版本化并校验。字段类型从数字变成字符串、含义改变或突然出现大量空值，会让后续统计失效。

1.2 客户端与服务端事件

客户端事件能捕捉界面交互，但可能丢失、重复或被篡改。服务端事件更可信，但看不到用户点击和页面行为。关键业务结果通常以服务端事件为准，客户端事件用于行为分析。

采集还要考虑用户同意、隐私、数据保留和删除请求。不能因为“分析需要”就无限收集敏感信息。

2. 指标定义

指标必须能被复述：

指标：支付成功率
人群：过去 24 小时发起支付的登录用户
分子：支付成功事件数
分母：支付尝试事件数
去重：按 payment_id
排除：测试账号、重复回调
时间：按事件时间分桶，UTC+8 展示

没有这些定义，同名指标在不同人手里会得到不同数字。

2.1 计数、比例与速率

计数：事件数量、活跃用户数。
比例：转化率、错误率、留存率。
速率：每秒请求数、每分钟订单数。
分布：p50、p95、p99、最大值。
累计值：总用户数、总交易额。

比例的分母要和问题一致。把“所有注册用户”作为活跃率分母，与“过去 7 天有登录的用户”会得到完全不同结论。

2.2 均值、中位数和分布

均值受极端值影响，中位数更稳健。收入、延迟和内容长度常常长尾明显，只看平均值会掩盖大量用户的不良体验。

标准差描述分布离散程度，但不适合所有长尾分布。必要时应看直方图、分位数和分组分布。

2.3 聚合

聚合通常遵循“拆分—计算—组合”：

SELECT country, COUNT(DISTINCT user_id) AS active_users
FROM events
WHERE event = 'app_opened'
  AND occurred_at >= now() - interval '7 days'
GROUP BY country;

分组维度越多，维度组合越稀疏。高基数标签会消耗大量存储和查询资源，应限制维度并定义默认分组。

3. 漏斗与留存

3.1 漏斗

漏斗描述完成一组有序步骤的用户比例：

浏览商品 → 加入购物车 → 开始结算 → 支付成功

每一步要定义：

是否必须按顺序。
时间窗口多长。
同一用户重复步骤算一次还是多次。
中途离开再回来是否算连续。
是否允许跨设备。

漏斗分析能定位“在哪一步流失”，但不能直接解释原因。要结合分组、错误日志、页面性能和用户反馈。

3.2 留存

留存衡量用户在一段时间后是否回来。常见定义是首次使用后的第 1、3、7、30 天仍发生关键行为。

留存曲线会受产品类型、获客渠道、季节性和版本变化影响。比较不同批次时，要使用相同时间窗口和相同行为定义，否则“留存变好”可能只是统计口径变了。

4. A/B 测试

A/B 测试把用户随机分配到至少两个组，比较某个改动对指标的影响。

4.1 随机化

随机化应基于稳定用户或设备 ID，而不是每次请求重新随机。否则同一用户会在版本之间跳变，体验和指标都受污染。

分流层要考虑：

实验之间是否互斥。
同一实验是否覆盖客户端和服务端。
新用户与老用户是否要分开。
是否跨设备保持一致。

4.2 假设、指标与样本量

实验开始前写清：

要验证的假设。
主指标和护栏指标。
最小可检测效应。
显著性水平和统计功效。
预计样本量与实验时长。
失败或异常时的停止规则。

样本量不足时，看到差异可能只是随机波动；频繁偷看并随时停止，会提高假阳性。可以按序贯检验等方法设计，但不能把普通 A/B 当成随时可停的小游戏。

4.3 置信区间和 p 值

p 值表示“在原假设成立时，观察到当前或更极端结果的概率”，不等于“新版本更好的概率”。置信区间表达了效应量的范围，通常比只看是否显著更有信息。

业务还要判断效应大小。统计显著但转化率只提高 0.01%，可能不值得增加复杂度和维护成本。

4.4 常见陷阱

多重比较：同时看很多指标，总会碰巧出现显著。
新奇效应：用户对任何变化都短暂更活跃。
选择偏差：分组不随机或只分析完成者。
样本比例失衡（SRM）：实际分流比例与预期差异过大，说明实验机制有问题。
干扰效应：一个组的用户行为影响另一个组，例如共享库存和社交网络。
指标漂移：实验期间同时发布其他功能或发生外部事件。

5. 数据可视化

图表不是装饰，而是信息编码。先确定问题，再选图形：

问题	适合图形
比较类别	条形图
看趋势	折线图
看分布	直方图、箱线图、散点图
看构成	堆叠条形图；饼图只适合少量部分
看关系	散点图
看转化步骤	漏斗图
看时间区间	面积图或带置信区间的折线图

5.1 可读性原则

坐标轴不要随意截断，尤其是条形图。
单位、时间范围和样本量写在图上。
颜色要有含义，并考虑色盲用户。
同一仪表盘使用一致的尺度与时间窗口。
不要用 3D 透视扭曲比例。
图表标题写结论或问题，不只写“数据图”。
缺失数据要明确显示，不能用 0 代替。

5.2 仪表盘

好的仪表盘先服务决策，再展示数据。区分：

实时运行状态。
日/周趋势。
长期业务健康。
探索分析。

重要指标要能下钻到定义、分组和数据来源。否则图表只能引起争论。

6. 数据仓库分层

常见分层是 ODS → DWD → DWS → ADS：

层	作用
ODS	接近源系统的原始数据
DWD	清洗、统一、明细事实
DWS	按主题和粒度汇总
ADS	面向报表和产品的应用数据

分层不是强制标准，核心是让原始数据、清洗逻辑和业务口径有明确位置。不要在报表 SQL 中直接复制大量源系统细节，否则定义无法复用。

6.1 事实表与维度表

事实表记录可度量的业务事件，如订单、点击、支付，通常包含维度键和时间。
维度表描述“谁、什么、哪里”，如用户、商品、地区和渠道。

粒度必须明确：一行代表一个订单、订单商品还是一个用户日汇总？粒度混用会造成重复计数。

7. 数据治理

7.1 质量维度

维度	问题
完整性	必需字段是否缺失
准确性	是否与真实业务一致
一致性	不同系统定义是否相同
唯一性	是否出现重复实体
及时性	数据何时可用，延迟多大
有效性	枚举、范围、格式是否合法

数据质量要有监控、校验和负责人。只有出错后人工查表，不算治理。

7.2 数据血缘

血缘描述数据从哪来、经过哪些任务、流向哪些报表。出现异常时，可以回答：

哪个源系统字段变了。
哪个清洗任务失败。
哪些下游指标受影响。
修复后需要重跑什么。

没有血缘，修改一个字段可能让多个部门第二天才发现报表全错。

7.3 元数据与权限

元数据包括表结构、字段含义、负责人、更新频率、敏感级别和生命周期。数据权限要按角色、数据集和行/列级别设计，审计访问记录，离职和项目结束时及时回收。

8. 数据分析的基本顺序

把业务问题改写成可计算问题。
明确人群、时间窗口、指标和排除规则。
检查数据质量与样本量。
做整体与分组分析。
用图形和统计方法验证。
区分相关与因果，设计实验。
记录结论、限制和可复现查询。

检查清单

事件名称、属性、时间和去重规则是否统一。
指标是否有可复述的分子、分母、人群和时间窗口。
是否查看分布和分位数，而不只看平均值。
漏斗与留存定义是否一致，是否处理跨天和重复步骤。
A/B 测试是否随机、是否预设样本量和停止规则。
是否检查分流比例、多重比较和新奇效应。
图表坐标、单位、样本量和缺失值是否明确。
仓库分层和事实表粒度是否清楚。
是否有数据质量监控、血缘、负责人和访问审计。
结论是否附查询、版本和局限，能否被复现。