使用功能标志进行实验

实验和 A/B 测试不仅仅可以通过特性标志(Feature Flags)来实现。你也可以在不同的分支中开发容器,并使用Kubernetes在生产环境中运行不同版本;然而,这会增加Git的复杂性,并且扩展性较差。而且你也无法获取用户的上下文,因此收集数据以验证或反驳你的假设要困难得多。大多数特性标志的解决方案都内置了实验支持,因此这通常是最快的入门方式。

为了进行实验,你需要定义一个假设,进行实验,然后从结果中学习。实验可以按照以下步骤进行定义(见图10.4):

  • 假设:我们认为{客户群体}希望{产品/功能},因为{价值主张}。

  • 实验:为了验证或反驳上述假设,团队将进行实验。

  • 学习:通过以下度量标准,实验将证明假设是否正确。

image 2024 12 27 14 54 01 226
Figure 1. 图10.4 – 使用特性标志进行实验

让我们来看一个例子。通过查看应用程序的使用数据,你发现新用户注册对话框的第一页的页面浏览量远高于完成注册流程的人数,只有约20%的用户完成了注册。假设是,注册对话框过于复杂,当对话框简化时,完成注册的用户数量会大幅增加。

为了进行实验,你在应用程序中增加了两个新度量:started-registration(每次用户点击注册链接时增加),和finished-registrations(每次用户成功注册时增加)。这两个度量使得计算aborted-registrations(中断注册)变得容易。

你在接下来的几周收集数据,并确认中断注册率在这些周平均为80%。然后,你的团队创建了一个新的、更简单的对话框,使用了一个`new-register-dialog`特性标志。它移除了所有不必要的必填字段,例如地址和支付信息,并将代码发布到生产环境。因为数据最终会在结账时验证,所以简化后的注册流程仍然有效,尽管这可能会在结账时带来一些可用性问题。

在生产环境中,你为50%的新用户开启了该标志,并比较了两组的中断注册率。看到旧对话框的用户,中断注册率大约保持在70%到80%之间,而看到新对话框的用户中断注册率仅为55%。

尽管结果尚不完美,你开始增加新的度量,以找出用户在对话框的哪个部分遇到困难。这导致了下一个假设(见图10.5):

image 2024 12 27 14 54 18 792
Figure 2. 图10.5 – 使用特性标志进行实验

为了使用特性标志进行实验,你需要数据。只有具备正确的度量标准,并能够将这些度量映射到具有特定标志开启或关闭的用户群体,你才能真正进行基于证据的开发。

在第19章《使用GitHub进行实验和A/B测试》中,我们将更加深入地探讨如何使用GitHub进行实验和A/B测试。