如何搭建数据驱动产品开发的实验环境

作为产品负责人，经常会面临选择A方案还是B方案的问题。或者，应该实施哪个版本的屏幕才能获得更好的效果？做出此类决定可能具有挑战性，尤其是当您在时间紧迫且资源有限的情况下。此外，此类决定是基于个人判断或模仿竞争对手的方法做出的，这可能会导致次优结果。

好消息是，人们可以通过设置一个需要相对较少工作量的简单实验环境来避免此类陷阱。在本文中，我们将介绍如何实现这一目标。

目录

• 为什么搭建实验环境很重要。
• 神话
• 设置你的实验环境
  • 定义未来实验的目标
  • 设计实验环境的架构
  • 分析和解释结果
  • 扩大首选方案。
• 结论。

为什么设置实验环境很重要？

设置实验环境很重要，原因有二：

• 首先，它可以让您确保在实施新功能后，您可以根据数据驱动的方法选择最佳选项。

  
  

• 其次，它允许您通过将“现状”与假设的“未来”选项进行比较并进行“假设”分析来不断改进产品的现有功能。

神话

在我们继续使用该方法之前，让我们揭穿一些通常误导产品所有者的神话：

我需要大量资源来设置一个允许进行实验和 A/B 测试的复杂环境

错误：所描述的方法占用的软件工程师资源不到一周。

我需要完善的数据收集流程和详细的事件跟踪

错误：您可以依赖现有的数据库来存储有关产品主要实体生命周期的信息。例如，如果您是送货服务，则为订单状态。

我需要一个专门的分析师团队每天处理我的请求

错误：一旦了解了实验的方法和指标，您就可以使用简单的SQL 查询定期自行拉取数据。

方法

要设置您的实验环境，建议遵循以下步骤：

1. 定义未来实验的目标、了解选项并选择指标

在联系您的产品设计师之前，定义要在实验中衡量的目标和指标。对于经典的“选项 A 或选项 B”问题，通常很简单，您希望通过实施更改来实现什么。例如，您可能正在处理漏斗的特定部分。

为了便于说明，我们假设您在一家快递公司工作，目前专注于订单创建表单。您希望解决提供送货地址然后选择送货方式的用户比例相对较低的问题。另外，假设您有两个新版本的旅程：

1. 当前版本：一个屏幕需要输入地址并根据提供的地址用图钉显示地图。下一个屏幕允许根据提供的地址选择送货方式。

   
   

2. 新版本：单屏需要在那里输入地址并选择运输方式。

目标是确定哪个选项会导致更多用户提供地址并选择送货方式。指标相当简单：提供地址并选择送货方式的用户百分比。

事实上，有两种方法可以衡量此类数据：

1. 基于后端设计已经可用的数据。例如，考虑一个包含订单生命周期信息的数据库。您的订单可能具有以下状态或状态：

   
   

   1. 已创建草稿

   2. 尝试寻找送货方式

   3. 找到送货选项/找不到送货选项

      
      

2. 事件跟踪——这不是开箱即用的东西，因此需要额外的努力来实现。但是，事件跟踪将为您启用更精细的分析，例如，设备类型和浏览器名称可以作为事件的参数传递。

在本文接下来的部分中，我们将重点关注第一种方法，即现有数据架构，没有事件跟踪。

2. 设计你的实验环境的架构

实验流程中应完成 2 个主要步骤：

• 使用选定的参数创建实验
• 定义用户旅程的一个阶段，当用户应该被分配到任一组时，并确保显示相关的 UI 作为结果

创建一个实验：

这个想法是想出一个轻量级的A/B 测试框架，它应该尽可能简单，并且应该允许您使用以下参数创建实验：

• 实验编号
• 最大样本
• 每组人数及姓名
• 落入每组的概率

能够配置这些参数允许您设置样本限制并随机选择实验的候选者，直到达到所需的样本量。

客户端和服务器都需要为此进行更改：服务器应跟踪每个实验的候选人数量，而后端将决定当前用户是否应该参与实验。后端将根据当前样本大小和固定概率来决定经过身份验证的用户是否应该参与实验。此外，后端应维护属于给定实验一部分的用户集合，以便为用户提供一致的体验并正确计算实验结果。

这就是实验配置端点的样子：

POST /api/your-service/experiment-create

要求：

 { experiment_id: "f380739f-62f3-4316-8acf-93ed5744cb9e", maximum_sample_size: 250, groups: { { group_name: "old_journey", probability_of_falling_in: 0.5 }, { group_name: "new_journey", probability_of_falling_in: 0.5 },}

回复：

{

200,

experiment_id: "f380739f-62f3-4316-8acf-93ed5744cb9e"

}

决定何时以及如何将用户分配到实验组：

您将需要一个单独的端点，负责将特定用户分配给实验和相应的组。我们称它为experiment-enrollments 。

在设计整个环境时，您应该清楚地了解应该在用户旅程的哪个阶段调用experiment-enrollments端点。此外，可能并非所有用户都应参与实验。这就是为什么将用户身份验证令牌也提供给端点也是有用的。

在我们的例子中，如果我们只想关注第一次下订单的新用户，user-auth 将允许我们确定它是什么类型的用户以及是否应该在实验中注册。此外，确保在调用端点后所有必要的信息都可用，并考虑您的旅程和生命周期的细节。

experiment-enrollments端点如下所述。它可以在旅程的特定阶段（例如，在登陆需要送货地址的屏幕之前）针对特定类型的用户（例如，仅尚未提供地址的新用户）调用，并将计算当前用户是否应该参与是否在给定的实验中：

POST /api/your-service/experiment-enrollments ，需要用户授权令牌

要求：

\ {

experiment_id: "f380739f-62f3-4316-8acf-93ed5744cb9e"

}

回复：

 {200, enrolled: true/false, group_name: group_1,}

为了说明理论数据流的样子，假设在送货公司中有相同的订单创建流示例。您正在订单创建屏幕的 2 个选项之间进行选择。

下图中提到了以下端点，即：

• /创建订单草稿（第 3 步）

• /find-shipping-method（第 16 步）

• /提交订单（第20步）

  
  

提供用于支持说明性示例，不是实验环境的必要部分

此外，下面提供了数据库的说明性和简化架构。

主要有3个表：

1. Experiments set - 它包含您之前创建的所有实验。每次调用/experiment-create端点时，数据库都会更新。

   
   

2. Experiments database - 它包含与特定用户的每次注册相关的所有记录。每次调用experiment-enrollments端点时，数据库都会更新

   
   

3. Order lifecycle database ——提供它是为了支持如何存储实验相关数据的示例。关键是此表（或与您的产品细节相对应的任何类似表）将允许您查看条目（例如订单创建）对于您注册的某个实验组中的特定用户是否成功已经设置。在我们的示例中，我们可以依赖于选择的运输方式状态，该状态允许得出用户成功提供运输详细信息然后选择建议的运输方式之一的结论。

   
   

   
   

设计和实施方法概述

优点：

1. 结果样本是异质的
2. 样本量是预先知道的
3. 可以根据固定的采样概率快速计算结果

缺点：

1. 需要更改前端和后端
2. 计算结果将依赖于多个数据库，其中一些数据库最初设计时并非用于分析目的。

任务和指示性估计：

• []未定义[后端]创建模型并公开获取计数器端点：~2个故事点
• []未定义[后端]公开增量计数器端点：~2个故事点
• []未定义[后端]公开端点以获取和递增计数器：~1个故事点
• []未定义[前端]调用计数器端点在注册流程之间切换：~3个故事点

一旦你设计了你的后端，与你的前端团队就接收信息的最佳方式以及在流程的哪个阶段进行调整保持一致。

请记住并减轻主要依赖性：

• 确保您的团队提前在合同上保持一致，以便前端部分可以与后端并行实施。
• 尽量避免在整个后端完成之前阻止您的前端
• 无论实验环境如何，无论如何都应该实现所有 UI 选项

3. 分析和解释结果

一旦您的实验运行了足够长的时间，分析和解释结果以得出有意义的结论就很重要了。

定义您需要计算对您之前决定关注的指标的影响的字段列表。

从上面的说明性示例中，数据源将是 2 个表：

• Experiments database ：

  • 输入：您要查找结果的实验 ID

  • 输出：作为特定实验参与者的所有用户 ID 的列表，每个用户被分配到的组以及用户被分配时的时间戳

    
    

• Order lifecycle database
  • 输入：实验范围内的用户列表和他们注册实验时的时间戳
  • 输出：与这些用户关联并在用户注册实验后处理的所有订单的最终状态

根据此数据，您可以计算每个实验组成功创建订单的百分比。

在分析结果时，重要的是不要只看原始数字。您还需要寻找统计显着性，以确保您在测试组之间观察到的任何差异不仅仅是由于随机机会造成的。我不会过分关注这部分，因为我已经看到很多与此主题相关的文章以及其他在线资源。无论如何，这里不需要过多的知识：在我看来，能够应用Z-Test或 T-Test来检查两组之间差异的显着性就足够了。

然而，一旦您确定您的结果具有统计显着性，您就可以开始得出关于您的产品的哪个选项表现更好的结论。

4.扩大首选方案

在您成功运行实验并对最佳选择获得足够的信心后，下一步就是在您的产品中扩大您的更改。可以有几种方法：

• 最简单的方法是调整您的实验配置，使100% 的用户都属于表现出更好结果的组。以后需要预留一些时间来清理代码，让这部分UI的显示独立于实验环境

  
  

• 不太直接的一种是您的产品是否可在多个平台上使用。在假设网络流的实验结果适用于移动应用程序流时要格外小心（反之亦然）。有时安全总比后悔好，以类似的方式在另一个平台上运行一个单独的实验。

总结

拥有自己的实验环境对于任何产品经理来说都是一个非常方便的工具。无论您当前的产品处于哪个成熟阶段，创建实验环境都不应该花费太多时间。支付相当低的一次性成本以使其正常运行将很快向您展示投资回报。

最后，这里有一些提示可以确保实验结果有意义：

• 首先，通过实施您正在考虑的更改，了解哪些指标会受到影响（如果有的话）。
• 在开始实验之前明确定义您的目标和指标
• 让您的实验尽可能简单，一次只关注一个关键变化
• 在考虑将您的实验结果外推到其他平台或其他类似服务时要小心
  

通过遵循这些最佳实践，您可以建立一个有效的实验环境，帮助您做出数据驱动的决策并随着时间的推移提高转化率。