开源方案与自建
能把「开关」做好的项目很多，能把「实验」做对的很少；开源能覆盖 60-70% 的标准需求，但最后一公里仍要自建。
5.1 开源生态地图#
一句话概括 2026 年 10 月的开源实验生态：能把「开关」做好的项目很多，能把「实验」做对的项目很少，能把两者同时做成产品的只有两个半。 GrowthBook 算一个，PostHog 算一个但实验只是副产品，Flagsmith 的实验还停在 Beta——其余项目本质上都是交付层或配置层。
把实验平台拆成四层，供给的拥挤程度立刻显形：
| 能力层 | 核心问题 | 开源供给 | 代表项目 | 成熟度 |
|---|---|---|---|---|
| 交付层 | 这段代码今天对谁生效？ | 极度拥挤 | Unleash、Flipt、Flagr、Flagsmith、FeatureProbe | 高，接近商业产品 |
| 编排层 | 多个实验如何不互相污染？ | 稀疏 | GrowthBook（namespace/filters）、Superposition（100 桶互斥） | 中低，多为近似 |
| 分析层 | 组间差异是否可信？ | 极少 | GrowthBook、PostHog、Flagsmith Beta、FeatureProbe（已冻结） | 低，方法覆盖不全 |
| 治理层 | 谁批、怎么停、怎么复盘？ | 近乎空白 | 各家 Enterprise 目录里的 SSO/审批/审计 | 很低，且几乎都收费 |
统计层为什么长不出来？一是统计与指标语义强耦合：比率指标要处理分子分母协方差，留存要处理窗口，分位数连 CUPED 都不适用，这些定义藏在每家公司的数仓里。二是统计是研究成本而非 CRUD 成本：方法每两年翻一代，维护者得持续跟论文。三是买 Flag 的人和买实验结论的人不是同一拨：前者关心 P99、SDK 覆盖、容灾，后者关心偏差、功效、SRM。
按数据路径，这些项目分四类，「免费」贵在不同科目：
| 数据路径 | 代表 | 事件存在哪 | 能力天花板 | 隐性成本 |
|---|---|---|---|---|
| 自采事件 | PostHog、FeatureProbe、ABRouter | 自己的 ClickHouse / MySQL | 事件量与自建存储运维 | 存储、管道、与数仓口径割裂 |
| 仓库原生 | GrowthBook、Flagsmith（Beta） | 客户数仓 | 数仓成熟度与查询成本 | 扫描费、T+小时延迟、建模人力 |
| 只输出曝光 | Unleash、Flagr、Flipt | 客户 Kafka / 数仓 | 客户自建全部分析 | 统计层从零开始 |
| 配置 / 路由 | Superposition、AB Testing Gateway | 不涉及 | 没有实验语义 | 用错场景的返工 |
截至 2026-10-18 的快照（star 与 release 取当日 GitHub 页面）：
| 项目 | License | Star | 最近 release | 状态判断 |
|---|---|---|---|---|
| GrowthBook | MIT 核心 + enterprise/ 商业目录 |
8,506 | 5.1.0（2026-09-22） | 活跃，独立运营 |
| PostHog | MIT 核心 + ee/ 商业许可 |
40,331 | Cloud 持续发布 | 活跃，自建仅 hobby |
| Unleash | v8 起 AGPLv3，官方镜像 Apache-2.0 | 13,882 | v8.2（2026-09） | 活跃，治理最强 |
| Flagsmith | BSD-3-Clause | 6,597 | v2.286.0（2026-10-15） | 活跃，实验 Beta |
| Flipt | v2 服务端 FCL（存在争议），SDK MIT | 4,920 | v2.14.0（2026-10-15） | 活跃，GitOps 路线 |
| Flagr | Apache-2.0 | 2,610 | 1.2.4（2026-08-20） | 活跃，无商业支持 |
| FeatureProbe | Apache-2.0 | 1,638 | 2.7.0（2023-09-20） | 功能冻结，仅安全修复 |
| Superposition | Apache-2.0 | 438 | v0.118.2（2026-10-13） | 活跃，0.x API |
| ABRouter | GPL-3.0 | 46 | 无 release，2023-05 后停更 | 停更 |
| OpenFeature | Apache-2.0 | 1,273 | 规范持续演进 | CNCF Incubating |
| PlanOut | BSD 系 | 1,681 | 已归档 | 历史标本 |
这张表最容易被误读的是 star 列。PostHog 的 4 万 star 来自「产品分析 + 回放」这个更大的品类；statsig-server-core 只有 24 star，因为那只是求值内核；FeatureProbe 1,638 star，却在 2023 年 9 月后没有功能发布。star 是注意力，不是可维护性；该看最近 6 个月的 release 节奏、非依赖提交占比、是否有公司实体承担 SLA。
另一条共性是：Open Core 的付费墙位置高度一致——高级统计（CUPED、序贯、holdout、bandit）、治理（SSO/SCIM、审批、审计、多组织）、规模（席位、环境数、Flag 数）。这不是巧合，而是「免费给你能跑，收费才敢用」。理解这一点，就不会把「开源」当成「免费获得一个企业级实验平台」。
中国可用性：截至 2026-10，没有发现这些项目在中国大陆有官方云区域。问题不是「能不能装」，而是「能不能合规地长期运行」——内网镜像、ICP 备案、个人信息评估、等保缺一不可。FeatureProbe 中文文档最友好，但已冻结。
5.2 GrowthBook：开源世界里最接近「完整答案」的那一个#
GrowthBook 成立于 2020 年，官方自称「第一个 warehouse-native、开源的 Feature Flag、实验与产品分析平台」，宣称 3,000+ 家公司使用、累计处理超过 1 万亿次事件查询（About，厂商口径）。它的卖点不是统计最先进，而是数据不动：原始曝光与指标留在客户的 Snowflake/BigQuery/Databricks 里，平台只下发配置、生成 SQL、把聚合后的充分统计量拿回来算（Warehouses）。于是合规成本低、SQL 可审计、指标口径可复用；代价是分析延迟受数仓调度约束，客户必须有人会写 assignment query、fact table 和 metric。
它到底开源了什么。 仓库 LICENSE 写明：packages/back-end/src/enterprise、packages/front-end/enterprise、packages/shared/src/enterprise 三个目录走 GrowthBook Enterprise License，其余走 MIT Expat（LICENSE）。你可以 fork 核心、内部部署，但不能把 enterprise/ 当 MIT 用。付费墙的位置很关键：CUPED、Sequential、Holdout、Post-stratification、Pipeline Mode、SSO/SCIM、审批、审计、多组织全要 license（Pricing）。社区版给你的是「能跑实验」，不是「能跑可信的实验」；如果评审要求 CUPED 降方差、序贯控制 peeking、holdout 衡量长期影响，落地第一天就该按商业版做预算。
架构：轻控制面，重数仓。 官方自托管文档写明系统由 Next.js 前端、Express API、Python 统计引擎组成，打包在单个 Docker 镜像里，前端 3000、API 3100，Cookie 要求同根域（Self-Hosting）。元数据库是 MongoDB，不是 Postgres——Postgres 在这里只是「被查询的数据源」之一；官方建议三节点副本集，并明确 Cosmos DB 不能替代（Production、FAQ）。这是中文团队最容易误判的硬约束：若公司标准是「一切上 Postgres」，自托管就要多养一套 Mongo 栈，而改数据模型等于重写。统计计算在独立 Python 包 gbstats 里做，生产上可把 Jobs Server 拆出去，用 EXTERNAL_PYTHON_SERVER_URL 指向独立实例；代价是单机进程池有上限、/stats 端点本身没有内置鉴权。
分桶协议是它最值得抄的部分。 「Build Your Own SDK」规范把算法写死了：FNV-1a 32 位哈希；hashVersion=1 是 fnv32a(value + seed) % 1000 / 1000；hashVersion=2 是 fnv32a(fnv32a(seed + value) + "") % 10000 / 10000（Build Your Own SDK）。v1 存在「并行实验偏差」，v2 用双重哈希修复，官方要求所有 SDK 行为完全一致。哈希版本是必须进协议的字段，否则不同语言 SDK 会在同一批用户上算出不同结果，而这种偏差极难在报表上发现。互斥靠 namespace：把 "__" + namespace 作为 seed 对用户 ID 做哈希，每个实验在 0–1 的命名空间里占一段 range，不重叠即互斥；官方还有一句实用提醒：改 split 会让用户换组，改 coverage 不会。
统计栈：工业够用，但不是最前沿。 默认贝叶斯，可在 Organization 或 Project 级切换（Statistics Overview）。贝叶斯默认 improper 先验（方差无穷，等价于不加先验信息），开启 proper prior 后默认 N(0, 0.3)，输出 Chance to Win 与 95% credible interval；频率派是双侧 t 检验，自由度用 Welch-Satterthwaite 近似，相对 lift 的方差用 Delta Method（Statistical Details）。
CUPED 是标准回归调整：Y_adj = Ȳ - θ·X̄，θ = Cov(Y,X)/Var(X)，θ 在 control+treatment 池化后计算，默认回看 14 天。差异化在 CUPEDps = CUPED + post-stratification：用维度分层，先算层内 lift 再加权汇总，可修正层内实际分流比例与目标比例的偏差（CUPED）。序贯只支持频率派，实现是 Waudby-Smith 等（2023）的 Asymptotic Confidence Sequences，不是 mSPRT；调参量 N* 默认 5000，含义是「你通常做决策时的样本量」，越接近真实决策点，置信序列相对固定样本 CI 的膨胀越小（Sequential）。代价是序贯 CI 一致地更宽，它解决的是 peeking 导致的假阳性膨胀，不是让你更早看到显著。
最值得直接抄的是实验健康检查产品化：结果页自动跑六项——SRM（卡方，p<0.001，出现即不可信）、Multiple Exposures、Pre-exposure Bias（频率派 + Bonferroni）、Minimum Data、Variation Id Mismatch、Suspicious Uplift（Experiment Results）。它把「这个实验能不能信」做成了默认输出，而不是数据科学家的脚本。多重比较只有频率派支持，提供 Holm-Bonferroni（FWER）与 Benjamini-Hochberg（FDR），范围是「一次结果视图里的所有 Goal metrics × variations」，不包括 Secondary 和 Guardrail，adjusted p-value 只在 UI/CSV 里、API 不导出（Multiple Corrections）。Guardrail 不参与校正是有意取舍：宁可多报警，但不能用校正后的显著性去解释它。
边界与代价。 没有原生 Layers，只有 namespace/filters 和 per-experiment seed，互斥靠手工切区间，没有容量仪表盘与冲突检测；几十个实验够用，上千个会变成治理灾难。MongoDB + Agenda + 单机 Python 进程池适合「配置面高并发、分析面中等吞吐」。默认 6 小时刷新、SQL 缓存 60 分钟（Env），Event Forwarder 能把曝光入仓做到秒级，但分析仍是批处理。数仓扫描是最容易被低估的 TCO；官方 connector 覆盖 BigQuery、Snowflake、ClickHouse、Trino 等，但没有 MaxCompute、Hive、Doris、StarRocks，只能自研 adapter 或用 Trino/ClickHouse 中转。
判断：它是最好的「实验分析底座」，不是「实验平台」。分析层 85 分，编排层 60 分，治理层要付费且仍偏薄。有数仓、实验量 10–100 个/月、有 1–2 名数据同学，它是最现实的起点；DAU 千万、上千并行实验，它应做「统计与报表层」。
5.3 PostHog：把实验做成 Flag 的一个视图#
PostHog 的路径和 GrowthBook 相反：不是「把实验建在数仓上」，而是「把实验建在自己的事件管道上」。Product Analytics、Session Replay、Feature Flags、Experiments、Data Warehouse、CDP 六个模块共享同一条事件流和同一个 ClickHouse，实验与 Flag 合并计费、不单独收费（Pricing）。
实验在 PostHog 里不是一等公民。 创建实验时系统默认自动创建一个多元 flag，或挂到已有 flag 上（要求 2–20 个变体）；实验只是给这个 flag 附加「指标 + 曝光口径 + 统计配置」（Creating an Experiment）。于是 flag 可以独立存在，实验是它的分析视图；任何人在 flag 页面改比例、改发布条件，都会直接影响运行中的实验；实验的「结束」本质上是把某个变体固化到 flag 上。这与 Optimizely/Statsig 类产品有根本差异——后者有独立的实验对象、分配服务和生命周期。PostHog 用极低的接入成本，换来了治理能力的简化。
架构上，它是一家把 ClickHouse 用到极致的公司。 官方拓扑是 Django Web/API + Rust（capture、feature flags、replay）+ Kafka/WarpStream + ClickHouse 分片集群 + Aurora PostgreSQL + Redis/Valkey + S3（How PostHog Works）。事件经 Kafka 表引擎拉取、物化视图写入 Distributed 表，按 sipHash64(distinct_id) 分片（ClickHouse）。这对实验有一个重要含义：按用户 ID 分片，让「查某个用户」是单分片操作，但「按变体聚合所有用户」是全分片扫描——而实验指标天然是后者。所以它必须用充分统计量聚合、Winsorization、CUPED 回看窗口限制来压查询成本，这是工程折中，不是统计偏好。
2025-09-29，US 区域 flag 服务宕机 1 小时 48 分钟、约 78% 请求返回 504（Post-mortem）；此前官方披露旧 Django 服务 50 万请求/分钟要 300 个 pod、8,800 美元/月，Rust 重写后降到 90 个 pod、2,800 美元/月、p99 85.4ms。flag 的可用性就是实验平台的可用性。
统计：默认贝叶斯，但默认路径最容易被误读。 贝叶斯引擎把用户级数据聚合成充分统计量，用无信息先验更新正态后验，输出 chance to win 与 95% credible interval（Bayesian）。官方明确：多变体各自独立与对照比较，不做多重比较校正；5 个指标出现至少一个假阳性的概率约 23%，10 个约 40%。频率派用 Welch t-test，比率指标用 Delta Method，额外提供基于 Waudby-Smith 2023 的序贯检验（Frequentist）。CUPED 只支持 mean 指标和「有序、无数据仓库步骤」的 funnel，ratio、retention、无序 funnel 即使开启也不调整，回看窗口默认 14 天（CUPED）。笔者认为，「贝叶斯默认」更像产品体验选择：无信息先验下 chance to win 与单侧 p 值高度对应，并没有解决 peeking。
曝光是整个体系最脆弱的一环。 默认曝光事件是 $feature_flag_called，必须带 $feature_flag 和 $feature_flag_response；只有首次曝光之后的指标事件才计入，转化窗口锚定首次曝光（Exposures）。官方自己列了两个坑：Web SDK 按 identity 跨会话去重，若用户在实验上线前就查过这个 flag，事件已被缓存，上线后不会再发，老用户可能根本不算曝光；广告拦截会让 flag 请求到不了 PostHog，官方建议反向代理，称通常能提升 10–30% 采集。再加上配额耗尽时 /flags 返回 quota_limited: true、SDK 静默回退默认值（Cutting Costs），实验会「悄悄停止分流」而不是报错。这比宕机更危险。
自托管已不是企业选项。 官方定位是 MIT 下的免费 Docker Compose「hobby」部署，不支持、不做 tagged release、不发 CVE，付费功能仅 Cloud；边界是 30 万事件/月、1 千录像、30 万 flag 调用（Self-host）。2023-02 宣布停止 Helm 支持（5 月底停止常规更新）、停售自托管 license。对要求数据境内的中国公司，只剩 EU Cloud 或放弃——硬约束，不是价格问题。
成本模型要按三项一起算。 flag 请求前 100 万免费，之后分档降到 $0.00001/次；按官方价累加，1,000 万次/月约 $460，5,000 万次约 $1,460，6 亿次（假设 1,000 万 DAU、每人每天 2 次）约 $6,960（Pricing）。事件另计：1,000 万事件/月约 $324，1 亿约 $2,618。隐藏成本有三项：曝光事件本身算一条事件，一次实验曝光同时消耗 flag 额度和事件额度；Surveys 会求值项目内所有活跃 flag；本地求值按轮询计费，定义变化的轮询算 10 次请求。再加 Boost $250/月、Scale $750/月、Enterprise $2,000/月的平台包，实验其实被收了两次甚至三次。
结论：PostHog 是从 0 到 1 最快的产品，也是千人组织最不合适的平台。Approvals 只覆盖 flag 变更；SRM 从 100 次曝光起算、只警告不阻断；没有 guardrail 类型、分层/互斥、MAB。这是定位取舍，不是待补功能。
5.4 Unleash / Flagsmith / Flipt / Flagr / OpenFeature：交付层的五个样本#
这一组代表五种「把求值做对」的哲学，它们的共同短板恰好定义了自建平台的真正工作量。
Unleash：最像企业级 Flag 控制面。 13,882 star，客户案例覆盖 Lloyds Banking Group、Mercadona、Wayfair 等（厂商自述）。2026 年最重要的变化是 license：从 v8（2026-06-09）起主仓库与 npm 包从 Apache 2.0 改为 AGPLv3，官方 Docker 镜像仍是 Apache-2.0，SDK 保持宽松许可（v8.0.0 Release）。官方明确：修改源码并以网络服务形式对外提供，AGPL 要求开放修改后的源码或购买商业许可。这里有存在不同说法：部分资料仍称 Unleash 是 Apache-2.0，那是 v8 之前的版本口径；以 v8 release note 为准，但镜像与 SDK 的许可确实更宽松，法务要按「部署形态 + 是否改源码」分别判断。
架构是「API server + 多语言 SDK + 可选 Edge」：后端 SDK 拉全量配置本地求值，前端 SDK 由 Server/Edge 代求值（Overview）。分流用归一化 MurmurHash，stickiness 默认 userId、缺失回退 sessionId，groupId 默认是 Flag 名（Strategies）。隐蔽后果：同一 groupId 的多个 Flag 会相关而非独立分流，适合多开关联动，不适合正交分层。
实验支持是「有实验 Flag，没有实验结论」：开启 impression data 后 SDK 发曝光，由外部工具归因（Guide）。没有实验对象、样本量、SRM、CUPED、序贯、多重比较；「unlimited experiments」指 Flag 变体能力，不是统计实验数量。$75/seat/月，OSS 限 1 项目/2 环境/5,000 Flag，治理全在 Enterprise。它解决发布风险，不解决因果推断。
Flagsmith：五个项目里唯一把实验做进产品的。 6,597 star，BSD-3-Clause，最新 v2.286.0（2026-10-15）。2026 年最大的变化是 Experimentation（Beta）：不再只做「multivariate flag + 第三方分析工具」，而是内置仓库连接、指标定义、实验创建、贝叶斯结果页（Experimentation）。
链路是：接仓库（Cloud 可用托管仓库，也可 BYO ClickHouse/Databricks；Snowflake/BigQuery 官方写「coming soon」）→ 定义指标（Occurrence、Count、Sum、Mean 四类，区分 goal 与 guardrail）→ 选 multivariate flag、设流量与变体比例 → 跑实验（SDK 记录 exposure 与 conversion，事件默认每 10 秒批量上报，当前只支持远程求值）→ 看结果（Lift、95% credible interval、chance to beat control；曝光按 identity 去重取最早；同一 identity 出现多变体则 quarantine 排除；SRM 在至少 100 identities 后检查，阈值千分之一；每个 arm 至少 50 identities、转化指标至少 5 次转化才展示）（Analyse）。统计口径很坦诚：贝叶斯引擎，用 chance to beat control 替代 p 值；明确 frequentist engine deferred、risk/expected loss not currently planned（Statistics）。
这里有一处存在不同说法值得记录：有的资料把 Flagsmith 的实验指标概括为「转化率、计数、均值三类」，官方文档实际是四类（多了 Sum）。架构是 Django 控制面 + 无状态 Edge Proxy，Edge 跑的是 local evaluation mode 的 Python Server SDK，官方基准是 M1 MacBook Pro 上约 2,000 RPS、平均约 7ms（Edge Proxy）。关键限制是 Edge 不持久化 trait，每次请求必须带全量 traits。价格：Free 50k requests/月；Start-Up 年付 $40/月（月付 $45），1M requests；Scale-Up 年付 $250/月（月付 $300），5M+ requests，含 SAML/SSO、RBAC、change requests、audit（Pricing）。
Flipt：Git-native 的「配置即代码」派。 4,920 star，v2.14.0（2026-10-15），单 Go 二进制，默认无外部依赖，Flag 配置存在 Git 仓库，UI/API 的写操作变成 Git commit，支持 GitHub/GitLab 的 PR 流程，并提供 OFREP 与 OpenFeature provider（v2 Concepts）。分流逻辑非常透明：把 flagKey:entityID 拼接，做 CRC-32（IEEE），对 1000 取模得到 0–999 的桶，distribution 按百分比占连续区间，不持久化任何 entity/context/变体结果。优点是简单、可复现、隐私友好；缺点是 salt 设计固定——flagKey 直接参与哈希，没有独立实验 salt/层，多个 Flag 之间无法保证正交，想改分桶只能改 flagKey 或换 entityID，会破坏稳定性。它也没有 exposure 概念，Analytics 只收集 Flag Evaluation Count，可写 ClickHouse 或 Prometheus，UI 展示最多 24 小时，而且只统计经过服务端 REST/gRPC 的求值（Analytics）。
License 是这一节最需要标注存在不同说法的地方：v2 官方 licensing 页写服务端采用 Fair Core License（FCL），允许读、改、自托管、再分发，但限制「与 Flipt 商业利益竞争」的用途，FCL 在发布两年后转为开源许可，SDK 保持 MIT；而仓库 README 仍显示 GPL-3.0 徽章，第三方事实核查也按 GPL-3.0 记录（Licensing）。合理解释是 v1 服务端 GPL-3.0、v2 改 FCL，但徽章与文档不一致，法务必须按具体版本文档确认。商业版 Pro $200/月，含最多 10 个实例、SCM 集成、GPG 签名。
Flagr：极简 Go 微服务，2026 年补上了曝光。 2,610 star，Apache-2.0，仓库从 checkr/flagr 迁移到 openflagr/flagr，2026 年仍在发版（1.2.4，2026-08-20），但没有商业版/托管服务，也就没有厂商 SLA。架构按延迟预算拆成三条路径：求值走内存 EvalCache（默认 3 秒轮询 snapshot）、配置走强一致 CRUD、记录走异步 fan-out 到 Kafka/Kinesis/Pub/Sub/Datar；README 给的 benchmark 是约 2k req/s、median 327µs（README、Overview）。
分桶用 Flag ID 字符串做 salt：先 crc32.ChecksumIEEE(salt)，再 update entityID，最后 % 1000。这跟 Flipt 的「flagKey:entityID 直接 CRC32」不同：Flagr 改 flagKey 不会重新洗牌，改 flagID 会；Flipt 改 flagKey 会重新洗牌。这个差异在迁移/复制实验时是真实的坑。2026 年补上的曝光 API 很实用：客户端流程是「POST /evaluation → 渲染 → POST /api/v1/exposures」，批量上限 100，exposure 只校验 Flag/variant 存在、不重跑 segment 约束，且默认在认证白名单里，官方明确警告「开放接口可被伪造曝光」（Exposure）。但它也很坦率：「Flagr doesn't run significance tests」，join、转化率、显著性、序贯全部交给你的数仓，文档只给「first exposure + 7 天转化窗口」的 SQL 模板（Pipeline）。
OpenFeature：标准化「怎么问 Flag」，不标准化「怎么证明因果」。 CNCF Incubating（2023-12-19 晋级），核心是 Evaluation API、Provider、Hooks、Events、Tracking（Experimental）、OFREP（Specification）。官方参考求值引擎 flagd 没有 UI、没有管理控制台、没有持久化层，配置来自文件/HTTP/K8s CRD/gRPC（flagd）。它的价值有三：SDK 解耦（业务代码只依赖 OpenFeature API，底层从 Unleash 换 Flipt 不用改代码）、曝光钩子（Hooks 可在每次求值后采集 flagKey/variant/context/timestamp）、OFREP 降低 provider 数量。但 Tracking 仍是 Experimental，provider 不支持时 track 会 no-op，不能当可靠曝光通道（Tracking）。它不解决实验对象、随机化单元、分层/互斥、样本量、SRM、CUPED、显著性、治理——把 OpenFeature 当实验平台，是典型的层次错位。
把五个项目放在一起，Flag 平台做实验的五个硬缺口非常清楚：
- 统计引擎：除 Flagsmith Beta 外都不提供。工业级要有 t/比例检验、Welch、Delta Method、贝叶斯 credible interval、序贯、多重比较、CUPED、聚类稳健方差、MDE/功效，比率、聚类、多变异、连续监控各有各的坑。
- 指标语义：Unleash/Flagsmith/Flagr 的曝光字段只够定位「谁看到哪个变体」，Flipt 干脆没有 exposure；它们都缺少指标目录、OEC/guardrail 定义、比率/分位数指标、跨设备归因、实验污染处理；Unleash 的 impact metrics 是运行指标，不是业务指标。
- SRM：只有 Flagsmith 内置，且 SRM 只是症状不是根因——分流 bug、曝光丢失、重定向、机器人、实验互斥、客户端崩溃都可能触发（SRM Paper）。
- CUPED：普遍没有。它需要实验前 7–28 天用户级快照、相关协变量、按随机化单元回归、比率再叠 Delta Method、处理缺失/新用户/漂移。
- 实验治理：Flag 生命周期 ≠ 实验生命周期。change request/RBAC/Git PR 是变更治理；实验治理要注册表、分层互斥、holdout、评审、决策日志、复盘，没有一家做完整。
还有一个常被忽略的细节：分流语义。 随机化单元默认 userId，但实验可能需要 device/session/geo/cluster；触发点也不同，Unleash 在 isEnabled 时就发 impression，可能早于真正展示，Flagr 明确要求渲染后 POST；Flagsmith 按 identity 取最早曝光并 quarantine 多变体用户，Unleash 每次调用都发、要下游去重。这些不会写进功能表，却直接决定结论可不可信。
5.5 FeatureProbe / ABRouter / Superposition / 其他：三种抽象，三种教训#
这一组项目的价值不在「用」，在「读」。它们分别把实验对象、配置对象、路由规则三种抽象做到了极致，正好用来校准自研平台的数据模型。
FeatureProbe：中国团队最完整的一体化开源实验平台，但已按下暂停键。 1,638 star，Apache-2.0，中文文档优先、Gitee 镜像、微信社区，带有明显的「国内大厂内部平台开源化」印记；官方 README 称已在「一家 5000+ 开发者的公司」使用五年以上、支撑百万用户级产品（公司主体、客户名单、融资均未披露）。项目状态是这份调研里最重要的负面信号：最后一个 release 是 2023-09-20 的 2.7.0，最后一次非依赖变更停在 2024-06-05，2024-08-15 之后基本只有 dependabot；中文 README 直接写「社区活跃度不高，暂停新功能规划和发布，仅安排安全漏洞修复与社区贡献合入」（README_CN）。这不是「停止维护」，而是「功能冻结、安全修复兜底」。另一个观察：2026-10-18 实测 featureprobe.io 会 302 跳转到无关的 beautifulhotels.co，文档站仍正常，商业托管是否已停止待核实，但至少说明 SaaS 入口已不可靠。
它的架构比多数开源 flag 项目完整：React/TS 的 Admin UI、Spring Boot 的 API、Rust 的 Server（SDK 连接、规则判定、事件接收）、多语言 SDK；docker-compose.yml 显示配置库与事件库都跑在 MariaDB 上，Server 通过 FP_REFRESH_SECONDS=3 每 3 秒从 API 拉规则（Architecture）。关键词是「控制面/数据面分离、SDK 本地求值、规则最终一致」。代价是事件链路没有 Kafka、没有 ClickHouse，直接写 MySQL 再由 Analysis 查 MySQL；官方集群部署文档只建议「Admin 集群 + Server 集群 + 数据库主从」，多环境是逻辑隔离。这套架构能撑中小规模，面对 DAU 千万、每天上亿条事件时，MySQL 写入与聚合都会成为瓶颈，要上规模必须换事件链路。
分流是「顺序匹配、第一条命中即返回」，百分比推出用 0–10000 的三维数组表示权重；算法是把 FPUser 的 key 与开关 salt 拼接（salt 为空时用开关 key）、做 SHA-1、取哈希字节的后 4 位转整数、对 10000 取模（Evaluation Rules）。优点是跨语言极易复现、确定性好、无状态。真正的影响在 salt 策略：salt 默认等于开关 key，意味着改 key、复制开关、跨实验复用同一 key 都会改变分流结果，运营侧必须把 key 当不可变契约。
统计面比外界印象中强：官方定义转化/计数/平均/加和四类指标，口径很细（Metrics）——平均类会把无事件用户丢弃、不计入样本，加和类则按 0 计入。前者造成组间样本选择偏差，后者把「未曝光」与「真实零」混在一起；报表没有强制提示口径风险。
统计上团队明确选贝叶斯，给出 P(B>A)、E(loss|B)、E(uplift|B)，并称模拟显示同等效果下样本量可省约一半（博客）。但先验如何选、数值指标用什么似然、是否做多重比较、是否有序贯或 CUPED，文档都没说；「省一半」是模拟宣称，不是独立验证。它有一个可用的贝叶斯转化率比较器，还不是工业级统计引擎。
ABRouter：PHP 生态的轻量工具，GPL 是硬约束。 46 star，GPL-3.0，Laravel + React + MySQL + Redis + Consul + Traefik。事件只有 incremental（漏斗，按用户去重）与 summarizable（可求和，按日汇总）；官方「决策」文档只说等数据、看 OKR，没有显著性检验、置信区间或序贯方法（Decisions）。内部部署不对外分发时 GPL 不要求开源修改，但做成私有化 appliance 或嵌入对外销售的软件就要提供源码。最后提交 2023-05-18，定价页仍可访问（Team Cloud 1 万活跃用户内免费、超出 $19/月，Premium $99/月）——「网站在卖」不等于「产品在迭代」。
Superposition：不是实验平台，是「上下文配置引擎」。 438 star，Apache-2.0，Rust + Postgres + Redis，Juspay 开源，源自 Hyperswitch 的配置引擎，解决「配置逻辑焊死在代码里」的问题：Default Config + Dimensions + Context/Overrides，用 CSS 式的「默认值 + 更具体规则胜出」模型管理配置（Context-aware Config）。它也能做实验，但实验是配置的一种用法：一个 Experiment 有且仅有一个 CONTROL、n 个 EXPERIMENTAL，context 圈定样本，traffic percentage 是「每个 variant 分到的流量」，所以总流量 = 百分比 × variant 数（官方特别注明，容易误读）；Experiment Group 用 100 个桶做互斥：hash(identifier, group_id) % 100 得到桶号，每个桶绑定一个 (experiment_id, variant_id)，组内一个用户只会看到一个实验，组外仍可重叠（Experiment Groups）。
这套机制简单、可解释，但局限很硬：只有 100 个桶，粒度 1%，多实验分配容易碎片化；没有正交分层、holdout、sticky bucketing 的显式文档，也没有 SRM/CUPED/序贯的方法说明。它的优势在另一条轴：类型安全（JSON Schema）、审计（change_reason）、多租户（Organisation + Workspace，是这批项目里最明确的）、Casbin、OpenFeature provider。适合多租户配置 + 渐进放量 + 轻量互斥实验，不适合当纯实验分析平台。
其他项目。 微博 AB Testing Gateway 是 nginx 七层灰度路由，ngx_lua + 共享字典缓存 + Redis 策略，2018-10 后停更，今天只适合学「边缘分流 + 策略缓存」。PlanOut 是 Facebook 的实验 DSL（WWW 2014），价值在「分配逻辑、salt、namespace、日志结构化」，已归档。statsig-server-core（24 star）只是求值内核，不能代表 Statsig 整体能力。
这一组给自研平台的最大教训是：数据模型比功能清单重要。 FeatureProbe 把「进入实验组」定义为「调用分组函数」，于是同一用户可多次进入、口径要自己兜底；ABRouter 把实验做成「多分支 + 日汇总」，只能看趋势不能推断；Superposition 把实验做成「配置 override」，天然没有曝光与样本概念。三种抽象各自自洽，但只有第一种接近实验平台语义——「照着 UI 抄一遍」不等于「做出一个实验平台」。
5.6 能力对比矩阵#
把「有没有」换成「到不到」，矩阵才有选型价值。判断口径：● 官方文档可验证的完整能力；◐ 部分支持或有明显边界；○ 官方文档未见。截至 2026-10-18。
| 项目 | 实验对象 | 分层/互斥 | Holdout | 频率派 | 贝叶斯 | 序贯 | CUPED | 多重比较 | SRM | 仓库原生 |
|---|---|---|---|---|---|---|---|---|---|---|
| GrowthBook | ● Flag + 实验 | ◐ namespace/filters，无 Layer | ● Enterprise | ● | ● 默认 | ● 仅频率派 | ● | ● 仅频率派 goal | ● p<0.001 | ● |
| PostHog | ◐ Flag 的分析视图 | ○ | ● | ● | ● 默认 | ● 仅频率派 | ◐ 仅 mean/有序 funnel | ○ | ◐ 100 曝光起警告 | ◐ 自带 CH + 数仓指标 |
| Flagsmith | ● Flag 绑指标 | ○ | ○ | ○ | ● Beta | ○ | ○ | ○ | ◐ ≥100 identity | ◐ BYO CH/Databricks |
| Unleash | ◐ 变体，非对象 | ○ | ○ | ○ | ○ | ○ | ○ | ○ | ○ | ○ |
| Flipt | ○ 变体 | ○ | ○ | ○ | ○ | ○ | ○ | ○ | ○ | ○ |
| Flagr | ◐ Flag/变体 | ○ | ○ | ○ | ○ | ○ | ○ | ○ | ○ | ○ |
| FeatureProbe | ● 开关 + 实验 | ○ | ○ | ○ | ◐ 胜出概率 | ○ | ○ | ○ | ○ | ○ |
| Superposition | ◐ 配置实验 | ◐ 100 桶组内互斥 | ○ | ○ | ○ | ○ | ○ | ○ | ○ | ○ |
| ABRouter | ◐ 多分支 | ○ | ○ | ○ | ○ | ○ | ○ | ○ | ○ | ○ |
第二张表看工程与许可，它决定「能不能真的用三年」：
| 项目 | 部署复杂度 | 多租户 | 审计 | 商业支持 | 许可对二次开发 | 中国境内自建 |
|---|---|---|---|---|---|---|
| GrowthBook | 中：单镜像 + MongoDB + Proxy | ◐ Enterprise multi-org | ◐ Enterprise | Cloud/Enterprise | 核心友好，企业目录不可用 | 可行，需自建 connector |
| PostHog | 高：Django/Rust/Kafka/CH/PG/Redis | ◐ 组织/项目 | ◐ 付费 | Cloud only | 核心可，ee/ 不可 |
理论可行，官方不支持 |
| Unleash | 中：API + PG + Edge | ◐ 项目/环境 | ◐ Enterprise | Enterprise | AGPL 有网络服务义务 | 可行 |
| Flagsmith | 中：API + PG + Redis；实验加 Kafka/CH | ◐ 组织/项目/环境 | ◐ 付费 | Enterprise | 最宽松 | 可行 |
| Flipt | 低：单二进制 + Git | ○ 环境/命名空间 | ● Git 历史 | Pro/Enterprise | FCL 非竞争限制 | 可行 |
| Flagr | 低：单二进制 + DB | ○ | ◐ snapshot | 无 | 宽松 | 可行 |
| FeatureProbe | 中：5 组件 + MariaDB | ○ | ◐ 操作记录 | 无 | 宽松，但已冻结 | 最友好（中文/Gitee） |
| Superposition | 低：Rust + PG + Redis | ● Org + Workspace | ● change_reason | 社区 | 宽松 | 可行 |
| ABRouter | 中：Laravel + MySQL + Redis + Consul | ○ | ○ | 无 | GPL 传染 | 可行，但已停更 |
读这两张表，有三个结论。第一，没有一行全绿：最接近完整的 GrowthBook 分层只是 ◐、多租户要 Enterprise、数仓适配不含中国组件；PostHog 统计列齐全，但 CUPED 只覆盖 mean/有序 funnel、SRM 只警告、没有多重比较。选型不是找全能冠军，而是找「前三项需求都打 ●、其余可接受」的那个。第二，「有实验对象」和「有统计」是两件独立的事：Flagsmith 有对象、有贝叶斯但无频率派；Unleash 有变体、有曝光但无对象；FeatureProbe 有对象、有胜出概率但无 SRM/序贯/CUPED。第三，治理与 license 强相关：SSO/SCIM、RBAC、审批、审计、多组织几乎都在商业版，Apache-2.0 项目治理最弱、许可最友好。治理是 Open Core 最自然的收费点。
5.7 自建 TCO 与二次开发风险#
先固定口径，否则数字没有可比性。模型假设：36 个月、3 名工程师、人力 80 万元/人年、DAU 1,000 万、50 个实验/月（约 23 个并发、平均 3 个变体）、平均每用户每天 3 次实验曝光（约 9 亿曝光/月）、指标事件复用现有数仓、服务器按国内公有云目录价并含 3 年预留折扣、汇率 1 USD = 7.2 RMB。这是模型估算，不是供应商报价。
| 成本项（万元/3 年） | A 轻量：Flipt/Unleash + 现有 BI | B 标准：GrowthBook 自建 | C 大规模：GrowthBook + 独立 Flag 层 |
|---|---|---|---|
| 服务器/存储 | 90–130 | 130–210 | 300–450 |
| 软件授权 | 0–50 | 100–300 | 150–350 |
| 人力（3 FTE × 3 年） | 720 | 720 | 720 |
| 额外人力 | 60–100 | 0–60 | 120–200 |
| 迁移/集成 | 60–100 | 50–80 | 100–150 |
| 合规/等保 | 30–80 | 30–80 | 50–100 |
| 机会成本 | 150–350 | 100–250 | 250–450 |
| 合计（区间） | 1,110–1,530 | 1,130–1,700 | 1,690–2,420 |
| 基准值 | 1,320 | 1,390 | 2,055 |
| 现金成本（不含 3 FTE 与机会成本） | 240–460 | 310–730 | 720–1,250 |
三个反直觉的结论。第一，轻量和标准的总成本几乎一样：轻量省授权，但多花 1 名数据工程师、多花 3–6 个月补统计层，机会成本更高。第二，人力占一半：720 万元是基准线；已有 3 名平台工程师时增量现金只有 350–520 万元。只算服务器不算人，TCO 会少一半。第三，大规模方案的成本主要不在软件：ClickHouse/Kafka/多业务线治理才是大头。到千万 DAU，「买还是建」不再是 license 比较，而是「谁拥有指标口径与治理」。
与 SaaS 对照：GrowthBook Cloud（100 席位下限）约 630 万元/3 年，Unleash Enterprise + 自建统计层约 870–970 万元，B 标准自建约 1,390 万元，C 大规模约 2,055 万元——SaaS 便宜约 600–800 万元。所以自建的理由不是「省 license」，而是四个：数据不能出境、需要深度定制、实验量/席位大到 SaaS 边际成本不可接受、把能力沉淀为组织资产。四个至少占一个；实验量只有每月十几个时，自建的固定成本摊到每个实验上是荒谬的。
这里有一处存在不同说法必须标注：部分 TCO 测算把 40 美元/seat/月当作 GrowthBook Enterprise 的授权下限，但官方定价页上 40 美元是 Pro 档价格，Enterprise 明确写 Custom、需询价。本文以官方页为准，把 40 美元仅当作「授权下限锚点」，表中的授权区间要按实际报价替换。
按量计费在千万 DAU 的锚点。 用 PostHog 公开价做一个独立测算：9 亿曝光/月，若按 flag 请求计费，5,000 万以上档 $0.00001/次，约 $9,000/月；曝光事件同时算事件量，按边际价约 $0.000009，约 $8,100/月；两项合计约 $1.7 万/月，3 年约 440–500 万元，还未含平台包、数仓同步、额外环境。这个数字和 B 方案的自建现金成本（310–730 万元）已在同一量级——「SaaS 便宜」只在中小规模成立。（该测算基于公开分档价的线性外推，实际账单会因去重、采样、合同折扣而不同，属推断。）
敏感性方面，四个变量最值得盯：人力单价 60 万/100 万，TCO 约 −180 万/+180 万；实验量翻倍，数仓与存储 +30–50%、授权可能跳档；Enterprise 授权免除或翻倍，∓100～300 万；DAU 500 万/2,000 万，约 −30%/+60% 基础设施与数仓成本。
二次开发的风险，比 TCO 更容易被低估。 先看 license 这一张否决票：
| 项目 | 许可结构 | 能否 fork | 主要风险 |
|---|---|---|---|
| GrowthBook | MIT 核心 + enterprise/ 商业 |
核心可，企业功能不可 | 抄企业目录会侵权；升级冲突 |
| PostHog | MIT 核心 + ee/ 商业 |
核心可，ee/ 不可 |
自建只能用免费功能；付费功能无授权 |
| Unleash | v8 起 AGPLv3 + 商业 | 可，但有限制 | 改后通过网络提供服务需开放源码 |
| Flagsmith | BSD-3 核心 + 商业 | 可 | 最宽松；企业功能另授权 |
| Flipt | v2 FCL（争议）/ v1 GPL | 可，但非竞争限制 | 不能做对外售卖的竞品托管 |
| FeatureProbe / Superposition / Flagr | Apache-2.0 | 可 | 冻结/0.x/无支持 |
| ABRouter | GPL-3.0 | 可，但衍生作品需 GPL | 停更 + 传染性 |
Fork 的真实成本不只是改代码：你要维护长期分叉、跟进安全补丁、解决 migration 冲突、重跑 CI、维护文档和 SDK。维持一个活跃项目的 fork，每年至少 1–2 人年，3 年就是 240–480 万元，接近甚至超过一个 GrowthBook Enterprise 授权。一个 3 人团队 fork 活跃项目，通常 6–12 个月内失去同步能力，最后变成「事实上的自研」。
升级冲突也各有各的坑：GrowthBook 发布快（5.1.0，2026-09-22），MongoDB schema 与统计引擎都会变；PostHog 自建不提供版本化 release，按 master 持续发布，官方明确不保证兼容；Unleash v8 转 AGPL，老 fork 停在 v7 就拿不到新功能；Flagsmith 发版很密（v2.286.0），实验管道还在 Beta、schema 可能变；Flipt v1→v2 是 major 重写，Git 存储模型变了；FeatureProbe/ABRouter 没有功能升级，也就没有升级冲突，但有「永远不修」的风险。
统计引擎自研是最贵的坑。 一个「能用」的引擎至少要有两比例 z-test / Welch t-test、比率指标的 Delta Method、SRM 检查、序贯检验、CUPED/方差缩减、多重比较、分位数指标、聚类/分层稳健方差。MVP 6–12 人月，生产级 2–3 年；还要做 A/A 校准、模拟 false positive rate、与可信实现 backtest、处理延迟数据/口径漂移。统计引擎自研的期望成本，远高于 GrowthBook Enterprise 的授权费。 如果一定要自研，建议把统计层做成独立服务，输入是「曝光表 + 指标表」的稳定 schema，输出是估计值/置信区间/诊断；不要嵌进控制面。
迁移成本要按 6–12 人月、双跑 4–8 周预算：SDK/曝光多端接 2–3 人月、指标迁移 2–4 人月（30–100 个指标的分子分母、归因窗口、去重逻辑都要重写）、历史回填 1–2 人月、组织迁移 1–2 人月。合计占 3 年 TCO 的 10–20%；迁移期实验速度下降，这部分机会成本常被漏算。
最后是五个常见误算：只算服务器不算人；把开源版当企业版；忽略数仓扫描成本；忽略迁移（指标口径迁移往往比 SDK 更难）；忽略机会成本（平台延期 6 个月，少跑 300 个实验，比省下的 license 更贵）。
5.8 三套推荐方案#
先按顺序问四个问题：数据在不在数仓？实验量多大？有没有 1–2 个能写统计代码的人？能不能接受 6–12 个月建设期？ 数据不在数仓，先建指标层；没人能读懂 CUPED 和 SRM，买再好的引擎也会退化成「看 p 值」；不能接受建设期，就买 SaaS，不要用「开源自建」的名义做一场拖延。
方案 A：轻量——Flag 层 + 现有 BI + 轻量统计。 适合研发 <100 人、实验 <10 个/月、没有专职数据团队的组织。Flag 层选 Flipt v2（GitOps、单二进制、零 DB）或 Unleash OSS；曝光/指标复用现有埋点与数仓，用 SQL + Python 做两比例检验/Welch t-test；治理靠 Git/PR 与人工流程。成本：1 名兼职工程师 + 90–130 万元基础设施；按 3 FTE 全成本约 1,110–1,530 万元/3 年。它的价值是「两周跑起第一个实验」，不是「支撑三年」。
方案 B：标准——GrowthBook Enterprise 自建 + 数仓。 适合研发 100–1,000 人、实验 10–50 个/月、已有 ClickHouse/BigQuery/Snowflake/Databricks、有 1–2 名数据/统计同学的组织。组成是：GrowthBook 自建（先用 Open Source 做 PoC，再买 Enterprise 解锁 CUPED/序贯/holdout/多组织/SSO/审计）；GrowthBook Proxy 做 Flag 缓存，SDK 本地求值，数仓做指标与曝光；指标层建统一 metric registry；治理上实验评审、审批流、分层/互斥域、holdout。成本：3 FTE + 1,130–1,700 万元/3 年（基准 1,390 万元）；复用现有团队时增量现金 310–730 万元。
为什么不是 PostHog：自建要扛 Kafka/ClickHouse/数十个服务，且付费功能 Cloud-only；GrowthBook 把重活交给数仓，控制面轻得多。为什么不是 Unleash：Flag 层很强，但没有统计引擎，规模化后只能退化成「Flag + 手工分析」。
方案 C：大规模——GrowthBook 分析层 + 独立 Flag 层 + 薄治理层。 适合研发 >1,000 人、实验 >50 个/月、多业务线/多端、有独立数仓与平台团队的组织。分析层用 GrowthBook Enterprise（multi-org）+ 数仓，按业务线分组织；Flag 层用 Unleash Edge 或 Flipt 做高并发、低延迟、强容灾下发；治理层自研薄层（实验注册、指标 registry、审批、审计聚合、SDK 网关），不要把统计引擎重写一遍。成本：3 FTE + 2 名 SRE + 1,690–2,420 万元/3 年。关键设计是三层解耦：控制面/数据面分离；Flag 求值在 SDK/Edge，分析在数仓；曝光日志是唯一事实源。这是从「买一个产品」到「建一个能力」的分界线。
三套方案共享同一套底座，这部分比选型更重要。最小曝光契约建议至少十个字段：
| 字段 | 说明 | 必填 |
|---|---|---|
event_id |
全局唯一，幂等去重 | 是 |
experiment_id |
实验注册表 ID，不是 flag_key | 是 |
flag_key / flag_version |
Flag 标识与配置快照版本 | 是 |
variant |
变体 key，含 control | 是 |
assignment_key |
随机化单元（user_id/device_id/session_id） | 是 |
assignment_unit |
user/device/session/geo/cluster | 是 |
exposure_time |
客户端/服务端曝光时间，带时区 | 是 |
context |
国家、端、版本、新老用户等 | 否 |
surface |
页面/组件/实验位 | 否 |
ingest_time |
服务端接收时间 | 是 |
五条设计原则：experiment_id 与 flag_key 必须分离（一个实验可能复用多个 Flag）；flag_version 必须带（否则中途改配置，前后曝光无法区分）；曝光在渲染后发（前端组件 mount/IntersectionObserver，服务端「响应返回且未降级」）；去重键用 (experiment_id, assignment_key) 取最早曝光；SRM 作为发布门禁（异常直接标记「不可决策」，下钻到端/版本/国家/新老用户/实验位）。这五条不依赖选哪家产品，但决定三年后结论能不能被审计。
落地节奏按「90 天闭环、180 天规模化、12 个月智能化」推进：第 1–2 周定 Flag 选型与 OpenFeature 适配；第 3–6 周建曝光管道与事实表；第 7–10 周上 SRM + 基础检验 + guardrail；第 11–13 周接 CUPED/比率指标，跑 3–5 个真实实验复盘。半年内补分层/互斥、holdout、多重比较、指标 registry；一年内再谈序贯、HTE、自动决策建议。不要一上来做「全自动 MAB」：MAB 会改变分流概率，导致经典的固定比例检验失效。
最后是一张「不要选」清单：不要用 PostHog 自建扛 1,000 万 DAU；不要把 FeatureProbe 作为新项目底座；不要选 ABRouter；不要把 OpenFeature 当实验平台（Tracking 仍是 Experimental，track 可能 no-op）；不要 fork GrowthBook 把 MongoDB 改成 Postgres（Mongoose model 遍布后端）；不要用 star 数做选型；不要为了省 license 而自建（标准自建比 Cloud 贵约 600–800 万元）。
一句话收束这一章：开源给了你「不必从零写求值」的起点，但没有给你「不必从零建统计与治理」的捷径。 真正的分水岭不是选 GrowthBook 还是 Unleash，而是你是否愿意把「曝光契约、指标语义、实验治理」当成三件独立的一等公民来建设——这三件事，没有任何一个开源项目能替你完成。
本章主要来源：GrowthBook 定价、GrowthBook 自托管、GrowthBook 统计总览、GrowthBook CUPED、GrowthBook 序贯、GrowthBook SDK 规范、PostHog 定价、PostHog 曝光、PostHog 贝叶斯、PostHog 自托管、PostHog ClickHouse 架构、PostHog flag 故障复盘、Unleash v8 release、Unleash A/B 指南、Unleash 定价、Flagsmith 实验分析、Flagsmith 统计口径、Flagsmith Edge Proxy、Flipt v2 概念、Flipt 许可、Flagr 曝光、Flagr 数据管道、OpenFeature 规范、OpenFeature Tracking、FeatureProbe 指标口径、FeatureProbe 项目状态、Superposition 实验组、ABRouter 决策文档、CUPED 论文（WSDM 2013）、SRM 论文（KDD 2019）。