AB 分析模块：自定义分析、下钻与高级分析

隐私上，人群包是最容易出事的资产：它可能包含敏感标签（未成年人、金融状况、健康状况）、可识别 ID、跨实验行为。至少要做到：

• 敏感标签分级：高敏标签不进入人群构建器，或必须审批；
• 导出审批：用户明细导出走审批流，默认脱敏、默认采样、默认限额；
• 行级权限：只有被授权的人能看到某个人群包的成员列表，而不是只有聚合人数；
• 用途绑定：人群包绑定用途（分析/投放/导出），跨用途需要重新授权；
• 留存期限：静态人群包设置过期时间，避免「两年前的名单」被反复使用。

5. 下钻：从「知道」到「知道为什么」#

下钻是分析模块最容易被低估的部分。很多平台把它实现成「加一个 group by」，结果用户点开一个维度，看到 200 个值、每个值都没有样本量、显著性颜色乱跳，最后关掉页面。真正的下钻不是「拆得更细」，而是在保持对照与统计有效性的前提下，把结论定位到一个可行动的切片。

5.1 下钻的五个层级#

DataTester 的用户详情页提供了 L5 的样本：可以按 UUID/SSID 查用户，查看基础信息、设备、画像、按时间排序的行为流，支持按 App/设备/事件/属性过滤、重要事件高亮、CSV 下载（最长 30 天）来源↗。这是一个正确的方向：从聚合到个体，但个体视图是「诊断工具」，不是「结论工具」。用户列表不能用来证明效应，只能用来解释异常、复现问题、构造假设。

5.2 交互规范：下钻不是跳页#

一个可用的下钻交互，至少要满足八条：

1. 面包屑可回退：全部用户 / 渠道=应用商店 / 城市=一线，每一级可点击，可清除。
2. 对照锁定：无论下钻到哪一层，A/B 对照关系不变；不能出现「这一层只剩实验组」。
3. 样本量常驻：每一层显示当前切片 N、基准 N、占比；N 低于阈值时灰显或折叠。
4. 统计状态常驻：CI、p、校正状态、是否探索性，跟着切片走，而不是只在顶层显示。
5. URL 可分享：当前实验、指标、人群、维度路径、时间窗、方法全部编码进 URL；分享给同事打开是同一个问题。
6. 返回不丢上下文：从用户列表返回，仍停留在原来的切片，而不是回到顶层。
7. 跨图联动可控：点击趋势图某一天、分布图某个区间，应该变成「时间/数值过滤」，而不是悄悄换指标。
8. 「解释这个数」入口：每个数字旁边有口径、样本、查询耗时、数据截止时间，而不是只有 tooltip。

建议 把下钻做成「行内展开 + 右侧抽屉」的组合：维度拆解在指标行下方展开，用户明细在右侧抽屉打开。这样既保留上下文，又不需要在页面之间来回跳。

5.3 维度层级与高基数#

维度不是一堆字符串，而是有层级、有语义的对象：

• 地理：国家 → 省 → 城市 → 区县；
• 渠道：一级渠道 → 二级渠道 → 投放计划；
• 版本：App 大版本 → 小版本 → 构建号；
• 用户：新/老 → 活跃分层 → 生命周期阶段；
• 设备：平台 → 机型 → 屏幕尺寸。

产品上要区分两种下钻：

• 层级下钻（hierarchical）：沿预定义层级逐级展开，适合地理、渠道、版本；每级自动带上父级过滤。
• 任意拆分（ad hoc）：用户任选维度组合，适合探索；必须限制维度数量与组合爆炸。

高基数维度是下钻的性能杀手。一个机型维度可能有 10 万值，一个 URL 维度可能上百万。可行的策略是：

• TopN + 其他：默认展示 Top 20，其余聚合为「其他」，并明确标注；
• 搜索 + 选择：不默认全量渲染，用户搜索后再查；
• 最小样本阈值：低于阈值（如 100 人/组）的值折叠或灰显；
• 预聚合：高频维度做 cube，低频维度走明细；
• 近似：UV 可用 HyperLogLog/Bitmap 近似，但要在 UI 标注「近似值」。

DataTester 有一条很诚实的限制：属性分组之后，不支持切换 preAA 数据、查看数据分布和箱线图 来源↗。这大概率是因为分组查询走预聚合/cube 路径，原始用户分布不在 cube 里。这就是「预聚合换性能」的真实代价：产品文档比架构图更诚实。与其假装什么都能下钻，不如在 UI 上明确「这个视图在当前粒度不可用」，并给一个替代入口。

5.4 用户级下钻：能看到人，但不能带走人#

从聚合到用户，是分析模块最敏感的一步。产品上要默认「三不」：

• 不默认展示全量：先给样本（如 100 条），需要更多再申请；
• 不默认展示原始 ID：脱敏为 u_8f3a•••，需要原始 ID 走审批；
• 不默认允许导出：导出是独立权限，带水印、限额、审计。

DataTester 的报告支持下载进组用户 ID（上限 500 万）来源↗，用户详情支持行为流 CSV 下载（最长 30 天）来源↗。这些能力对分析很重要，但必须与权限、审计、脱敏一起设计。否则「下钻」会变成「拖库」。

5.5 查询实现：预聚合、即席与混合#

下钻的性能取决于三个选择：

一个务实的做法是「三级查询」：

1. L1 缓存/预计算：固定报表、核心指标、常用切片，命中直接返回；
2. L2 同步即席：单指标 + 单维度 + 有限时间窗，走 ClickHouse/Doris，目标 P95 < 2 秒；
3. L3 异步任务：多指标 × 多维度 × 长窗口、用户明细导出，进队列，给进度与取消。

腾讯微信的公开论文给了一个极端的工程样本：Spark 例行预计算 + ClickHouse 即席下钻，BSI 运算经 JNI 调 SIMD；预计算负责 scorecard 与 CUPED，即席负责下钻 来源↗。这不是每个团队都能复制的，但它说明了一个原则：预计算与即席不是二选一，而是按查询模式分工。

缓存 key 必须包含所有影响结果的版本：hash(experiment_version, metric_version, cohort_version, dim_set, time_range, granularity, filter_hash, engine_version)。少一项，就会出现「改了定义但报表没变」的幽灵。

5.6 性能预算：下钻的速度决定分析的深度#

这些数字不是拍脑袋：超过 2 秒，用户就会失去「连续探索」的感觉，退回「先想好问题再查」的模式；而分析的价值恰恰来自连续追问。性能预算应该写进 PRD，和功能一起验收。

5.7 六个下钻反模式#

1. 把子群当结论：在 20 个切片里挑一个显著的，写成「对某人群有效」。→ 必须标探索性 + FDR。
2. 下钻后对照组消失：某切片只剩实验组，仍然显示「提升」。→ 必须显示两组 N，缺一组就禁用结论。
3. 维度值洪水：一次渲染 500 个机型，用户找不到重点。→ TopN + 搜索 + 最小样本。
4. 口径漂移：下钻时换了指标定义/时间窗，用户不知道。→ 上下文条常驻 + 版本号。
5. 缓存串租户：A 租户的查询结果被 B 租户命中。→ 缓存 key 带 tenant_id + 权限校验。
6. 导出泄露：用户列表导出包含敏感字段/全量 ID。→ 脱敏、审批、水印、审计。

6. 高级分析：默认严谨，逐项解释#

高级分析的功能清单很容易做：CUPED、Uplift、序贯、贝叶斯、DiD、合成控制，每个名字都能变成一个菜单项。难的是另一件事：当用户点下这个菜单项时，平台是否替他承担了假设检查、多重比较、失败解释和决策责任。

6.1 产品化的四层接口#

6.2 方法菜单：每个方法回答什么问题#

这张表最重要的不是「支持多少方法」，而是「什么时候不该用」。一个方法如果只能在满足假设时使用，产品就必须在入口处做检查，而不是在结果页写一行免责声明。

6.3 CUPED：默认开，但要说清代价#

CUPED 的逻辑很简单：用实验前的协变量 X 解释实验期的 Y，把「本来就会不同」的部分减掉：

Y_adj = Y − θ · (X − X̄)
θ = Cov(Y, X) / Var(X)
方差缩减 ≈ ρ²

产品上最容易犯的错，是只给一个「CUPED 已开启」的开关，不给用户看：

• 用了哪段 pre 期？pre 期是否被上一个实验污染？
• 协变量与当前指标的相关性是多少？实际方差缩减了多少？
• 新用户没有 pre 数据，是否被排除？排除后样本量变化多少？
• 分位数/比率指标是否直接套用了均值 CUPED？

建议 结果页并列显示「原始」与「CUPED」两套数字，并给出方差缩减比例；当 CUPED 改变结论方向时，强制提示「结论对协变量调整敏感」，而不是只展示调整后的漂亮区间。Eppo 的文档把 CUPED 的假设、协变量选择与实现讲得比较清楚 来源↗，可以作为产品文案的参考。

6.4 Uplift / CATE：从「找人群」到「验证人群」#

Uplift 的产品价值不在模型，而在交付：一群人、一个方向、一个可执行的名单。DataTester 的敏感人群洞察把这件事做成了完整工作流 来源↗：

• 任务粒度是「一个指标、一个实验组、一个对照组」；
• 挖掘方向分正向/负向；
• 输出 TOP 敏感人群、特征重要性、TOP 3 特征的二维交叉子群；
• 支持下载人群明细（treatment、uid、ite、bins、业务 ID）。

但它也暴露了 Uplift 的典型风险：

• 推荐入组人数 > 2 万、维度 > 4 个，否则模型不稳定；
• 子群是「TOP 特征交叉」选出来的，存在选择偏倚；
• 公开文档没有说明子群 p 值是否做多重比较校正，产品上应按「未校正」处理；
• ITE 是模型预测，不是个体真实因果效应；
• 下载名单用于全量投放前，应该做 holdout 验证。

建议 产品上把 Uplift 放进「探索」层，把验证放进一个新的 confirmatory 实验：用 Uplift 选出人群 → 设计一个只看这批人的 A/B → 用 holdout 验证增量 → 再决定是否全量。这个闭环比「模型 AUC 很高」更有说服力。

6.5 序贯与贝叶斯：让「随时看」不再等于「假阳性」#

实验平台最常见的用户行为是「每天打开报告看一眼」。在固定样本频率派框架下，这会让一类错误膨胀；序贯检验/always-valid 就是为这个场景设计的。产品上要区分两件事：

• 监控：每天看趋势、护栏、SRM，不宣布胜负；
• 决策：达到预定义样本/时间后，用固定样本或序贯的正式区间做结论。

如果平台支持「随时可停」，就必须同时支持：

• alpha spending 或 confidence sequence；
• 预定义看点与参数锁定；
• 早停时的效应量高估提示；
• 多指标/多版本的额外校正。

贝叶斯则是另一条路：给决策者「获胜概率/期望损失」，而不是 p 值。它的产品难点在先验：没有历史数据却拍一个强先验，比不做贝叶斯更危险。Eppo 对贝叶斯与频率派方法的对比写得比较克制 来源↗，可以作为术语与文案的参考。

6.6 多重比较：先定义家族，再谈显著性#

多重比较不是「把 p 值乘一个数」那么简单。产品必须先帮用户定义「家族」：

• 一个实验里的所有变体 × 所有指标，是一个家族；
• 一个指标下的所有维度切片，是另一个家族；
• 护栏指标应该单独一个家族，用更严的 FWER；
• 子群应该先做交互检验，而不是逐格检验。

常见方法：

• Bonferroni：α/m，保守但简单；
• Holm：逐步法，比 Bonferroni 有更高功效；
• BH：控制 FDR，适合探索性指标多、但可以接受少量假阳性的场景。

建议 默认策略：主指标 preferential α，次要指标 BH，护栏 Holm，子群先交互。界面同时显示 raw p 与 adjusted p，默认按 adjusted 排序；当 adjusted 跨 0 而 raw 显著时，文案必须写「校正后不显著」，不能写「有趋势」。

6.7 为什么「自定义人群 + 高级方法」最容易产生假阳性#

三个乘数叠在一起：

1. 人群定义的自由度：年龄、城市、活跃度、价格敏感、生命周期……可以切出无数个子群；
2. 指标的自由度：5 个指标 × 4 个人群 = 20 次检验，至少一次假阳性的概率约 64%；
3. 方法的自由度：CUPED 开/关、贝叶斯先验、序贯看点、异常值处理，每一种都能改变结论。

更麻烦的是事后定义：先看结果，再圈一个「高价值、低活跃、近 30 天没下单」的人群，等于把选择藏进了分析。校正只能覆盖登记过的检验，覆盖不了用户脑子里那条还没说出口的假设。

LLM 会把这条乘法器再放大一次：让模型扫描所有切片、挑出「最值得讲」的三个，再写一段原因，等于把数据挖掘自动化。每一句听起来合理的解释，背后都可能是一个未登记的检验。

6.8 方法选择决策表#

6.9 LLM 在分析模块里的可信边界#

LLM 在实验分析里能做三层，可信度依次下降：

• 叙述层：把已经算好的结果翻译成业务语言。安全，前提是数字只能来自结果对象。
• 诊断层：提示 SRM、MDE 不足、cohort 未成熟、样本低于门槛。较安全，因为规则可审计。
• 归因层：解释「为什么涨」。不安全。实验识别的是效应，不是机制；机制要靠埋点、日志、访谈和后续实验去验证。

产品规则可以写得很硬：

1. 数字白名单：只允许引用结果对象里的字段；每个数字带 cell 链接；没有计算就写「未计算」，不许估。
2. 拒绝条件：SRM 未过、样本低于门槛、CI 跨 0、校正后不显著时，不允许生成「获胜原因」。
3. 归因措辞：只能写「可能机制（待验证）」，并列出还需要什么证据；不能写「因为 X 所以 Y」。
4. LLM 提议的切片就是新的检验：必须登记、校正，或放到 holdout 上验证；否则就是自动化 data dredging。
5. 评估与审计：用历史实验的已知结论做回归测试；记录模型、提示、上下文、版本；上线决策必须有人签字。

字节在 AICon 2024/2025 的公开演讲里提到，用 LLM 做实验分析提效、实验咨询与分析智能体 来源↗ 来源↗。这是方向，不是交付证据。对产品团队的含义是：LLM 应该先做「叙述 + 诊断」，不要把「归因」当成默认能力；否则它会用最流畅的语言，放大最脆弱的统计结论。

7. 页面设计：一张分析页的解剖#

分析页不是「数据展示页」，而是「决策证据页」。四类用户不是四种并列视图，而是同一条证据链上的四个检查点：

7.1 首屏：只回答「要不要动」#

首屏的权重顺序是：结论 > 护栏 > 核心指标 > 证据入口 > 诊断。图表回答「怎么变」，首屏要回答「做不做」。DataTester 把结论放在实验概览区，并用颜色标显著方向 来源↗；但「建议」应该由实验 owner 写，系统只给证据。这个分工很重要：平台不能替组织做决策，但必须让决策所需的信息在 5 秒内可见。

7.2 关键组件：每个组件都在回答一个反驳#

DataTester 有一个值得警惕的细节：PV、UV、SUM、去重数这类指标不支持置信水平计算 来源↗。它们可以出现在表里，但必须标「不可检验」，否则用户会把「没有 CI」当成「没有差异」。

7.3 信任设计：让数字可被质疑#

• 口径卡，而不是 tooltip：指标配置里本来就有「指标描述」字段，要求写清含义、计算逻辑、用途 来源↗。报告页应把它升级为可引用的定义卡：分母、时间窗、归因、排除规则、版本、owner。
• 样本量拆三层：进组、曝光、有效样本。只给一个 N，SRM 无法判断。DataTester 的进组数当天实时、次日起 T-1、以 0 点为界 来源↗。
• SRM 与护栏：DataTester 公开报告文档没有 SRM 状态（证据缺口）。GrowthBook 在结果页直接插入 SRM 与多重曝光警告，SRM p<0.001，并写明「不应相信结果」来源↗。建议做成硬 gate：异常时置顶诊断、隐藏效应、只留样本与排查入口。
• 探索性标记：差异分析用 Monte Carlo 给「获胜概率」来源↗，敏感人群是 Uplift 挖掘 来源↗；这些是探索，不是确认。UI 要标「探索性、未校正、需独立复现」。
• 多重比较提示：页面显示「本页 24 指标 × 6 切片」；提供 BH/Holm 或 adjusted p。GrowthBook 的校正家族是 goals × variations × dimensions，维度切片单独校正 来源↗。
• 变更历史：漏斗任何修改都会更新所有使用它的实验报告，且不缓存 来源↗——这是典型的静默变更。建议版本化 + 「报告已重算」横幅 + 变更 diff。
• 评论与批注：公开文档未见（证据缺口）。建议锚定到指标/切片，@owner、resolve、写 decision log；评审用不可变快照，而不是实时页。

7.4 空态、加载态与错误态#

分析页的失败，大多不是「算错」，而是「用户不知道发生了什么」。三种状态要写清楚：

7.5 可访问性与响应式#

• 键盘：指标表用 grid 模式，roving tabindex，方向键移动，Enter 展开，Esc 关闭 来源↗。DataTester 的交互是 hover 出解读、点击出统计卡 来源↗；hover-only 必须补 focus/click 等价物。
• 色彩不是唯一编码：DataTester 用绿/红/黑编码显著性 来源↗，WCAG 1.4.1 要求颜色不能是唯一手段 来源↗。加箭头、图标、文字，灰度打印仍可辨。
• 对比与焦点：文本 4.5:1、UI 3:1、焦点可见；触控目标至少 24×24（WCAG 2.2）。
• 表格小屏降级：≥1280 全列；768–1279 隐藏绝对差/MDE，保留相对差 + CI；<768 一行一卡（指标名、效应、CI、状态），点开底部抽屉；首列 sticky，横向滚动给阴影提示。
• 图表替代：提供「表格视图」与文字摘要；异步完成用 aria-live 播报，不要只靠 toast。
• 移动端：只保留「结论 + 核心指标 + 护栏 + 审批」；下钻与高级分析引导到桌面，而不是硬塞进小屏。

7.6 六条可用性验收标准#

1. 5 秒结论：80% 目标用户不滚动即可说出「上/不上/证据不足 + 主指标方向 + 是否过护栏」。
2. 三重编码：任一显著性标记在灰度与色盲模拟下仍可区分；颜色、图标、文字同时存在。
3. 键盘闭环：从实验列表到展开统计卡 ≤ 6 次 Tab/方向键；无 hover-only 信息；焦点始终可见。
4. 口径可追溯：任一数字 2 次点击内看到定义、分母、时间窗、版本、最后更新；口径变更后出现「已重算」提示。
5. 状态可解释：查询 > 2 秒有阶段进度与取消；失败保留上次结果并给原因与重试；空态给下一步入口。
6. 切片不静默：任何筛选/分组后同时显示 N 与基准 N；探索性结果带「未校正」标记；页面显示「指标数 × 切片数」。

8. 技术实现：语义层、查询与统计#

分析模块的工程难点不是「把 SQL 跑快」，而是让同一个业务问题，在实验组与对照组、今天与上周、整体与下钻之间，被编译成同一套可复现的查询。

8.1 逻辑架构：六个平面#

这六层的失败模式各不相同：元数据错会串组，指标错会口径漂移，人群错会人口漂移，维度错会把「当前属性」当成「进组时属性」，缓存错会串租户，治理缺失会让错数无法追溯。架构图的价值不是好看，而是让每一层都有明确的 owner 与可观测指标。

8.2 指标 DSL：七个槽位#

一个实验指标 DSL 至少要有七个槽位：事件、聚合算子、分母、过滤、时间窗、归因窗口、去重键。

{
  "metric_id": "gmv_per_entrant_7d",
  "version": 4,
  "entity": "user_id",
  "numerator": {
    "agg": "sum",
    "event": "pay_success",
    "property": "amount",
    "filter": [{ "property": "currency", "op": "=", "value": "CNY" }],
    "dedup": { "key": "order_id" }
  },
  "denominator": { "type": "entrants" },
  "window": { "anchor": "exposure", "length": "7d" },
  "attribution": { "event_time": "server_received_at" },
  "owner": "growth-data",
  "certified": true,
  "stat_support": ["delta_method", "bootstrap"]
}

DataTester 把前三个槽位产品化成了 14 种「计算方式」来源↗。拆开看，14 种其实是 3 个原子（count / sum / distinct）× 4 个分母（AU、UV、PV、SUM(DAU)）× 时间语义。分母才是灵魂：同样是「支付转化」，UV/AU 问的是「进组的人里有多少人付过」，PV/UV 问的是「付过的人平均付几次」，两者不能互相解释。

置信度支持矩阵是 DSL 的一部分，不是 UI 的补丁。DataTester 明确列出，总量（PV）、总人数（UV）、求和（SUM）、按属性去重四类单指标不能计算置信度；组合指标也只对特定分子/分母类型开放 来源↗。推断：这不是产品偷懒，而是统计引擎的真实接口——方差必须从「每个用户一个值」的样本里估计，纯总量没有用户级分布。所以编译器必须先把任何指标降成「每人一行 (num, den)」，再由统计层聚合。

8.3 查询编译：从请求到充分统计量#

一个分析请求是一个五元组：experiment × metrics × cohort × dimensions × time。编译器做七件事：

1. 取实验版本与 variant 映射；
2. 展开指标为 (numerator, denominator, filter, window)；
3. 下推人群（join 快照或 bitmap）；
4. 解析维度（字典表或 argMax 取时点值）；
5. 生成用户级 CTE；
6. 生成聚合查询；
7. 交给统计层。

编译后的伪 SQL 大致如下。注意三个细节：variant 只做列不做表、分母恒为 1 且用 LEFT JOIN、结果返回二阶矩而不是一个数。

WITH ent AS (
  SELECT user_id, variant, min(exposure_time) AS t0
  FROM exposure
  WHERE exp_id = 'exp_1024' AND exp_version = 7
    AND dt BETWEEN '2026-09-01' AND '2026-09-30'
    AND user_id IN (
      SELECT uid FROM cohort_snapshot
      WHERE cohort_id = 'c_88' AND cohort_version = 20261018
    )
  GROUP BY user_id, variant
),
per_user AS (
  SELECT e.user_id, e.variant, d.country,
         sumIf(p.amount, p.event = 'pay_success'
               AND p.event_time >= e.t0
               AND p.event_time <  e.t0 + INTERVAL 7 DAY) AS num,
         toUInt8(1) AS den
  FROM ent e
  LEFT JOIN events p
    ON p.user_id = e.user_id
   AND p.dt BETWEEN '2026-09-01' AND '2026-10-07'
  LEFT JOIN dim_user d ON d.user_id = e.user_id
  GROUP BY e.user_id, e.variant, d.country
)
SELECT variant, country,
       sum(num) AS num_sum,
       sum(den) AS den_sum,
       count() AS n,
       sum(num * num) AS yy,
       sum(den * den) AS xx,
       sum(num * den) AS xy
FROM per_user
GROUP BY variant, country;

最后三列是「二阶矩」，它们让统计层不必回表就能算方差与协方差。这是语义层与统计层之间最重要的接口契约：查询结果不是「一个数」，而是一组充分统计量。

保证两组同口径，靠四条硬规则：

• variant 只做列不做表；
• 分母固定为进组人数且每人计 1；
• 归因窗口锚定各自的进组时间 t0；
• 所有过滤条件同时作用于分子与分母。

DataTester 的漏斗给了正面样本：漏斗不要求单独配置曝光，但计算时会把曝光事件当作第一步之前的过滤事件，且曝光自带实验版本 VID 来源↗。组的定义与指标同源，避免了 assignment 表 join 的丢失与串组。

8.4 存储选型：三种负载，不可能一个引擎全吃#

预聚合有三件套：Bitmap 做 UV（交并差快，但高基数会膨胀，且回答不了「这些人是谁」）；BSI 做金额求和与分位数（需 bucket 编码，精度换空间）；物化视图做固定维度组合（查询改写依赖优化器）。一条容易犯的错：不要把比率的比值存进 cube，只存分子和分母，查询时再除；否则跨天、跨维度合并时权重就错了。

维度组合是 2^N，全预聚合必然爆炸。现实做法是「高频维度做 cube + 任意维度现算明细」。DataTester 有一条很诚实的限制：属性分组之后，不支持切换 preAA 数据、查看数据分布和箱线图 来源↗。推断：分组查询走的是预聚合/cube 路径，原始用户分布不在 cube 里，所以分布类视图只能关闭。这就是「预聚合换性能」的真实代价。

8.5 API 与数据模型#

一个最小可用的分析 API 可以只有六个端点：

核心表至少要有：

8.6 性能、成本与可观测性#

按复杂度分四级：

• L1 已预计算的固定报表：缓存命中，亚秒；
• L2 单指标单维度：秒级，同步；
• L3 多指标多维度/长窗口：十秒到分钟，异步任务；
• L4 自定义 SQL 与导出：队列 + 配额 + 审批。

只有 L1/L2 值得优化，L3/L4 应该「排队并告知」，而不是让所有人一起拖垮集群。

缓存 key 必须包含所有影响结果的版本：hash(experiment_version, metric_version, cohort_version, dim_set, time_range, granularity, filter_hash, engine_version)。少一项就会出现「改了定义但报表没变」的幽灵。

可观测性要回答的不是「查询慢不慢」，而是「数字为什么变了」。至少四类信号：

• 查询日志：query_id、SQL 指纹、扫描行数、缓存命中、租户；
• 慢查询：按模板聚合，而不是按单条 SQL；
• 口径异常：分母为 0、UV 大于进组人数、比率大于 1、某维度值单日突增；
• 结果 diff：同 query 重跑、新旧指标版本、实时与离线对账。

建议 把编译后 SQL 的哈希作为「口径指纹」写进结果表，报表页可展示。这样任何数字都能回答「它是用哪版定义、哪版人群算的」。权限上，指标的可见性与行的可见性要分开；共享缓存和导出文件是最容易被忽略的越权泄漏点。

8.7 三个阶段：MVP、规模化、智能化#

MVP 的目标不是快，而是「每个数字都能手工复算」。此时最重要的交付物是 DSL 和一张指标契约表，而不是引擎。智能化的底线是：自然语言只能生成 DSL，不能直写 SQL——否则前面所有的版本、权限、口径指纹全部失效。

9. PRD：P0/P1/P2 与验收#

9.1 范围与不做什么#

做：一个实验分析工作台，支持结论、指标、人群、下钻、高级分析五个面；支持自定义指标、人群圈选、筛选模板、维度下钻、CUPED/序贯/多重比较；提供 API 与审计。

不做（至少第一年）：不做通用 BI；不做全量 SQL 编辑器；不做自动投放；不做跨实验的因果网络；不做无审批的用户明细导出。

9.2 需求优先级#

9.3 验收标准#

1. 可复现：任取一个结论，输入六个版本号，能在 1 次重跑中复现同一数字（误差在浮点范围内）。
2. 可解释：任一数字 2 次点击内看到指标定义、分母、时间窗、版本、owner、数据截止。
3. 可拦截：SRM 异常时，效应数字被隐藏，只保留诊断与样本；护栏恶化时，结论卡强制降级。
4. 可探索：维度下钻 P95 < 2.5 秒；用户样本 P95 < 3 秒；超过 30 秒自动转异步。
5. 可校正：页面显示「本次分析 N 次检验」；adjusted p 与 raw p 并列；探索性结果带标记。
6. 可协作：分享链接打开是同一实验、指标、人群、维度路径、时间窗、方法；评论可 @owner。
7. 可审计：谁在什么时间、用什么理由、导出了多少行、包含哪些字段，全部可查。
8. 可访问：键盘可完成「进报告 → 切指标 → 展开证据 → 下钻 → 返回」；颜色不是唯一编码。

9.4 成功指标#

9.5 落地节奏#

• 0–90 天：P0 契约 + 结论卡 + 指标表 + 人群构建器 + SRM/护栏；先接 1 个业务线、20 个核心指标。
• 90–180 天：下钻 + 模板 + CUPED/序贯/多重比较 + Cohort/漏斗；接 3 个业务线。
• 180–365 天：差异分析 + Uplift + 决策记录 + API；建立指标认证与 owner 制度。
• 365 天以后：组合视图、自动下钻、LLM 叙述/诊断；把「分析质量」纳入平台 KPI。

9.6 风险与缓解#

10. 反模式与决策清单#

10.1 十二个反模式#

10.2 自建 vs 采购：分析模块的决策清单#

10.3 问供应商的十个问题#

1. 你们的指标定义是否版本化？被实验引用后还能改口径吗？
2. 人群是在分流前还是分流后生效？能否分别配置？
3. 子群分析是否默认做多重比较？用的什么方法？家族怎么定义？
4. SRM 是自动检测还是手工配置？异常时会不会隐藏效应？
5. CUPED 用哪段 pre 期？新用户怎么处理？分位数指标支持吗？
6. 序贯检验支持中途查看吗？alpha spending 参数能否锁定？
7. 下钻的 P95 是多少？高基数维度怎么处理？缓存 key 包含哪些版本？
8. 用户明细导出有哪些权限、脱敏、审计与限额？
9. 指标口径变更后，历史报告会不会重算？如何通知？
10. 是否提供 API/DSL，让我把分析嵌进自己的 workflow？

10.4 一句话收束#

分析模块的终局，不是「什么都能查」，而是「查到的每个数都能被解释、被复现、被质疑，并且最终能变成一个更好的决策」。Libra/DataTester 值得学的，不是某一个图表，而是它把统计假设、数据口径、能力边界三件事同时放进了界面；代价是重、慢、学习曲线陡，收益是同一个结论能被 PM、DS、运营用同一种语言复述。

如果只能记住一句话：先建契约，再建画布；先保因果，再谈智能。

11. 参考来源#

本页优先使用官方文档、论文与工程博客；厂商营销材料只用于确认产品存在，不作为能力证据。标注「推断」「建议」的内容是我们的产品判断，不代表任何厂商的官方设计。

11.1 一手产品文档#

• BytePlus DataTester, Experimental Report Overview：链接↗
• BytePlus DataTester, How to Interpret the Experiment Report：链接↗
• BytePlus DataTester, Metrics Analysis: Event Metrics & Retention Metrics：链接↗
• BytePlus DataTester, Create Event Metric：链接↗
• BytePlus DataTester, Create Warehouse Metric：链接↗
• BytePlus DataTester, User Cohorts：链接↗
• BytePlus DataTester, User Details：链接↗
• BytePlus DataTester, Report Page Custom Filter Template：链接↗
• BytePlus DataTester, Advanced Analysis: Difference Analysis and Group Comparison：链接↗
• BytePlus DataTester, Advanced Analysis: Cohort Analysis：链接↗
• BytePlus DataTester, Metric Analysis: Funnel Metric Analysis：链接↗
• BytePlus DataTester, Report Interpretation: Customer Group Experiment：链接↗
• BytePlus DataTester, Sensitive Population Insights：链接↗
• BytePlus DataTester, SQL Custom Query：链接↗

11.2 统计、方法与工程#

• Eppo, CUPED：链接↗

• Eppo, Analysis Methods：链接↗

• Eppo, Sample Ratio Mismatch：链接↗

• Eppo, Multiple Testing：链接↗

• Eppo, Certified Metrics：链接↗

• GrowthBook, Sequential Testing：链接↗

• GrowthBook, Multiple Corrections：链接↗

• GrowthBook, Experiment Results：链接↗

• Statsig, CUPED：链接↗

• Wager & Athey, Estimation and Inference of Heterogeneous Treatment Effects using Random Forests：链接↗

• Deng et al., Applying the Delta Method in Metric Analytics（KDD 2018）：链接↗

• Netflix, It's About Time: Practical Considerations for Measuring Long-Term Treatment Effects：链接↗

• Instacart, Geo-based A/B Testing and Difference-in-Difference Analysis：链接↗

• ByteDance, DQ Estimator for Two-sided Markets：链接↗

• 腾讯微信实验平台, VLDB 2024 论文：链接↗

• Statsig, Interpreting Results / Custom Queries：链接↗

• Statsig, Differential Impact Detection：链接↗

• Eppo, Segments：链接↗

• Eppo, Copy SQL：链接↗

• Eppo, Property Analysis：链接↗

• GrowthBook, Dimensions：链接↗

• GrowthBook, Metrics：链接↗

• Amplitude, Advanced Metric Use Cases：链接↗

• Amplitude, Sequential Testing：链接↗

• Optimizely, Experiment Results Page：链接↗

• VWO, Campaign Report Components：链接↗

• AB Tasty, Data Explorer：链接↗

• Convert, Experiment Report：链接↗

• PostHog, Experiments / CUPED：链接↗

11.3 中国平台公开材料#

• 字节跳动 AICon 2025 演讲者简介（Libra/DataTester）：链接↗
• 《AI 时代实验平台演进之路》InfoQ 报道：链接↗
• 字节 AICon 2024《LLM 在 A/B 实验平台的应用探索》：链接↗
• 字节 CUPED/ITR 内部实践报道（IT168，2024-10）：链接↗
• 淘天通天塔 Fluss 实践（阿里云开发者社区，2025-07）：链接↗
• 美团 BETA 分析引擎（2024-09）：链接↗
• 美团可信实验白皮书（2025-05）：链接↗
• B 站北极星与 ClickHouse RBM：链接↗
• 知乎 AB2.0 从 ClickHouse 预计算迁 Doris 的公开分享：链接↗

11.4 交互、可访问性与设计#

• W3C, ARIA Authoring Practices: Grid Pattern：链接↗
• W3C, WCAG 2.2: Use of Color：链接↗
• W3C, WCAG 2.2: Reflow：链接↗
• Nielsen Norman Group, Progressive Disclosure：链接↗

11.5 引擎与存储#

• ClickHouse, Incremental Materialized Views：链接↗
• ClickHouse, Bitmap Functions：链接↗
• Apache Doris, Materialized View Overview：链接↗
• StarRocks, Asynchronous Materialized Views：链接↗
• BigQuery, Materialized Views：链接↗
• Snowflake, Materialized Views：链接↗
• Apache Druid, Design：链接↗