使用GrowthBook和Flagger进行有效的A/B测试

GitHub 本身并不提供 A|B 测试工具，但市面上有许多工具可供选择。问题在于，这些工具的范围完全不同。有些工具更像是网页体验工具，适用于使用内容管理系统（CMS）来构建网站或通过可视化编辑器创建和测试 A|B 测试变体（例如 Optimizely – 见 https://www.optimizely.com/）。有些则更多集中在营销、着陆页和活动管理方面，比如 HubSpot（https://www.hubspot.com/）。这些工具很棒，但可能不是工程团队的最佳选择。

一个更好的解决方案是使用特性标志工具，如 LaunchDarkly、VWO 或 Unleash。第 10 章《特性标志与特性生命周期》中已经介绍了这些工具，因此这里就不再赘述。如果你正在使用这些特性标志解决方案，那么它们是进行 A|B 测试的首选解决方案。

本章将重点介绍两个开源项目：GrowthBook 和 Flagger，它们都非常关注实验，但方法完全不同。

GrowthBook

GrowthBook（https://github.com/growthbook/growthbook）是一个具有免费和开源核心的解决方案，也提供 SaaS 和企业版计划。它提供了 React、JavaScript、PHP、Ruby、Python、Go 和 Kotlin 的 SDK。

GrowthBook 的设计完全容器化。如果你想尝试它，只需克隆该仓库并运行以下命令：

docker-compose up -d

启动后，你可以通过 http://localhost:3000 访问 GrowthBook。

在 GitHub Codespaces 中运行 GrowthBook

如果你想在 GitHub Codespaces 中尝试 GrowthBook，首先需要配置 docker-compose.yml 文件，使用正确的 DNS 名称，因为 GrowthBook 使用 localhost 连接其 MongoDB。设置 APP_ORIGIN 环境变量为本地端口 3000 地址，API_HOST 为本地端口 3001 地址，并确保端口 3001 可见。

连接后，你可以使用它来提供特性标志或构建实验。要构建实验，必须将数据源连接到 GrowthBook，例如 BigQuery、Snowflake、Redshift 或 Google Analytics 等。它提供了预定义的数据模式，你也可以构建自己的数据模式。接着，你可以根据数据源创建度量标准。度量标准可以是以下几种：

  • 二项型（Binomial）：简单的是或否转化（例如，帐户已创建）。

  • 计数型（Count）：每个用户的多个转化（例如，页面访问次数）。

  • 时长型（Duration）：某个操作的平均时间（例如，停留时间）。

  • 收入型（Revenue）：平均收入增减（例如，每用户收入）。

image 2024 12 27 18 21 14 231
Figure 1. 图19.7 – GrowthBook 中实验的结果

你可以向实验中添加或删除度量标准，也可以将实验导出为 Jupyter notebook。

GrowthBook 还提供了 Google Chrome 扩展 GrowthBook DevTools，适用于 JavaScript 和 React SDK，允许你在浏览器中直接与特性标志进行交互。可视化编辑器目前处于 Beta 版本。

GrowthBook 是一个直接的工具，也基于特性标志，类似于第 10 章中介绍的解决方案。

Flagger

一种完全不同的方法是使用 Flagger（https://flagger.app/）。它是一个用于 Kubernetes 的交付操作器，可以与服务网格 Istio 配合使用。Flagger 更常用于 Kubernetes 集群中的金丝雀发布，但它也可以根据 HTTP 匹配条件路由流量。

例如，你可以为所有用户创建一个实验，使用一个持续 20 分钟的 insider cookie，配置如下：

analysis:
  # 调度间隔（默认 60s）
  interval: 1m
  # 总迭代次数
  iterations: 20
  # 在回滚之前，最大失败的指标检查次数
  threshold: 2
  # 金丝雀匹配条件
  match:
    - headers:
        cookie:
          regex: "^(.*?;)?(type=insider)(;.*)?$"

你可以将 Flagger 与 Prometheus、Datadog、Dynatrace 等指标平台结合使用。我在这里不再展开详细内容，更多信息请参见 Flagger 文档（https://docs.flagger.app/）。Stefan Prodan 也有一篇很好的教程：使用 Flux v2、Flagger 和 Istio 的 GitOps 配方（见 https://github.com/stefanprodan/gitops-istio）。

使用 Flagger 和 Istio 的解决方案提供了很大的灵活性，但也相对复杂，不适合初学者。如果你已经在 Kubernetes 和 Istio 上运行并进行金丝雀发布，那么 Flagger 可能是一个强大的框架。

如你所见，市面上有很多解决方案可以帮助你运行实验和 A|B 测试。从内容管理系统（CMS）和活动管理工具到 Kubernetes 操作器，提供的解决方案有许多种，且方法各异。最适合你的解决方案取决于许多因素——主要是你现有的工具链、定价和支持。我认为，重点应放在流程和数据分析上。提供两个版本的应用程序不应是挑战——真正的挑战可能在于如何理解你的数据。