读数据自助服务实践指南：数据开放与洞察提效15A_B测试服务

1. A/B测试服务

1.1. 部署多个模型并将其呈现给不同的客户集
1.2. 基于客户使用的行为数据来选出更好的模型
1.3. A/B测试（也称为桶式测试、拆分测试或受控实验）是一个从产品变化、新特性或与产品增长相关的假设等方面来评估用户满意度的标准方法，并被广泛用于制定数据驱动的决策
1.4. 将A/B测试作为数据平台的一部分进行集成非常重要，可以确保在机器学习模型、业务报告和测试中应用一致的指标定义
1.5. 在线受控的A/B测试被众多公司用来制定数据驱动的决策
1.6. A/B测试是指在同一时间向不同的访问群体显示同一网页的变体，并比较哪个变体的转化率更高

• 1.6.1. 转化率高的变体就是获胜的变体
  

1.7. 成功的衡量指标对于正在测试的实验和特定假设是独有的
1.8. 运行大规模的A/B测试不仅仅是基础设施和最佳实践的问题，还需要在决策过程中嵌入强大的实验文化
1.9. 实验文化还要求全面跟踪A/B测试实验，简化多个并发实验，并与业务报告集成
1.10. 从A/B测试实验中产生可信的洞察需要坚实的统计基础、无缝集成和监控以及跨所有数据管道的各种质量检查
1.11. 痛点

• 1.11.1. 正确配置A/B测试实验并非易事，并且必须确保不存在会导致不同群体的兴趣指标在统计上存在显著差异的不平衡
  
  
  
  • 1.11.1.1. 确保用户不会接触到同时运行的不同实验的变体之间的交互也很重要
    
  
  
• 1.11.2. 大规模运行A/B测试实验需要以一种高性能和可扩展的方式生成和交付不同的配置
  
  
  
  • 1.11.2.1. 对于客户端实验，软件只是定期更新，需要在线配置才能打开和关闭产品的功能
    
  
  
• 1.11.3. 分析A/B测试实验结果是基于需要计算的指标
  
  
  
  • 1.11.3.1. 定义与以往不一致的一次性指标需要花费大量时间，从而导致不可靠的分析
    
  
  
• 1.11.4. 确保实验的可信度，以及自动优化后确保用户体验不受损害，这对于广泛的数据用户来说很困难
  

1.12. 理想情况下，自助式A/B测试服务简化了A/B测试的设计过程，隐藏了统计显著性、不平衡分配和实验交互的复杂性，并能自动化扩展以及根据不同性能来分配流量
1.13. 自动验证实验质量并优化对获胜实验的流量分配
1.14. 该服务使数据用户能够在服务的整个生命周期中配置、启动、监控和控制实验
1.15. 通过为实验设计提供信息、确定实验执行的参数，以及帮助实验负责人解释结果来减少整体洞察耗时
1.16. 开源示例

• 1.16.1. Cloudera的Gertrude
  
• 1.16.2. Etsy的Feature Flagging
  
• 1.16.3. Facebook Planout
  

1.17. A/B测试能帮助企业做出更好的决策和产品
1.18. A/B测试平台的大众化至关重要，它允许新的团队轻松上手并以低成本开始运行实验，目标是通过实验评估每个产品功能或bug修复
1.19. A/B测试正在不断发展，不仅回答影响了什么，还通过利用每个实验汇总的大量信息（在指标和维度上）回答原因
2. 路线图

2.1. 因子（或变量）

• 2.1.1. 一个可以独立变化以创建依赖响应的变量
  
• 2.1.2. 被赋值的因子称为水平
  

2.2. 实验（或变体）

• 2.2.1. 现行的系统被认为是“冠军”​，而实验是一种修改，试图优化某个目标，它被称为“挑战者”​
  
• 2.2.2. 实验的特点是会改变一个或多个因子的水平
  

2.3. 实验单元

• 2.3.1. 实验单元是可以随机分配给实验的物理实体，是进行实验或分析的实体
  
• 2.3.2. 外部因子在控制和实验之间均匀分布，故不会影响实验结果
  
• 2.3.3. 是广泛使用受控实验来评估软件新特性的关键原因
  

2.4. 样本

• 2.4.1. 接受相同实验的一组用户
  

2.5. 总体评价标准（OEC）

• 2.5.1. OEC指的是实验要达到的指标、目标或目的
  
• 2.5.2. 是一种用来比较不同实验的反馈指标
  
• 2.5.3. 当实验运行时，记录用户与系统的交互，并计算指标
  

2.6. 实验是一个设计、执行和分析的迭代循环
2.7. 实验分析是在实验的整个生命周期中进行的，包括生成假设、设计实验、执行实验和实验后的决策过程

• 2.7.1. 生成假设
  
  
  
  • 2.7.1.1. 该过程从收集数据开始，以确定需要改进的方面
    
  • 2.7.1.2. 历史实验的结果为新的假设提供了信息，帮助估计新假设对总体评价标准的影响，并帮助确定现有想法的优先级
    
  
  
• 2.7.2. 设计特征和应用特征
  
  
  
  • 2.7.2.1. 对网站或移动应用程序体验上的元素进行所需的更改，并验证更改的正确性
    
  
  
• 2.7.3. 设计实验
  
  
  
  • 2.7.3.1. 应该使用什么样的随机化方案进行受众人群分配
    
  • 2.7.3.2. 实验运行的持续时间是多少
    
  • 2.7.3.3. 分配的流量占比是多少
    
  • 2.7.3.4. 分配的流量占比是多少
    
  
  
• 2.7.4. 执行实验
  
  
  
  • 2.7.4.1. 实验开始，用户被分配到受控或变体实验中
    
  • 2.7.4.2. 他们每一次经历的交互都会被度量、计算和比较，以确定每个体验的表现
    
  • 2.7.4.3. 实验是否对用户造成了不可接受的伤害
    
  • 2.7.4.4. 是否存在导致实验结果不可信的数据质量问题
    
  
  
• 2.7.5. 分析实验
  
  
  
  • 2.7.5.1. 目的是分析对照组和实验组之间的差异，并确定是否存在统计学上的显著差异
    
  • 2.7.5.2. 监控应该在整个实验过程中持续进行，检查各种问题
    
  • 2.7.5.3. 分析需要确定实验数据是否可信，并理解为什么实验组比对照组好或差
    
  • 2.7.5.4. 下一步可以是上线或不上线的建议，也可以测试一个新的假设
    
  
  

3. 最小化A/B测试耗时

3.1. 包括设计实验、大规模执行（包括指标分析）和优化实验所需的时间
3.2. 标准

• 3.2.1. 一个成功的标准是防止错误的实验规模达到统计显著性，浪费发布周期时间
  
• 3.2.2. 另一个标准是检测危害，并提醒实验负责人用户的体验不佳，从而防止直接发布后损失收入和流失用户
  
• 3.2.3. 最后一个标准是检测与其他可能导致错误结论的实验的交互
  

3.3. 实验设计

• 3.3.1. 包括受众选择，并依赖于特征设计。这是通过使用目标定位或流量过滤器来实现的
  
• 3.3.2. 设计需要考虑单因素测试与多因素测试—测试与单因素值相对应的实验，测试与多因素值相对应的实验，并比较两种测试
  
• 3.3.3. 需要确保实验的持续时间内样本量的统计显著性
  
• 3.3.4. 实验的持续时间是根据历史流量推断出来的
  

3.4. 大规模执行

• 3.4.1. 包括在客户端（如移动应用程序）或服务器端（如网站）大规模运行实验
  
• 3.4.2. 为了扩大实验规模，需要提供一种简单的方法来定义和验证新指标，并让新指标被广泛的数据用户使用
  
• 3.4.3. 挑战
  
  
  
  • 3.4.3.1. 用户可以在未登录或未注册的情况下浏览，因此关联用户操作很困难
    
  • 3.4.3.2. 用户还可以切换设备（在Web和移动设备之间）​，这使得关联更加复杂
    
  • 3.4.3.3. 确保用于实验的指标与业务仪表盘一致也很重要
    
  • 3.4.3.4. 要计算成千上万的报表，处理TB级的数据，这是一项重大挑战
    
  
  
• 3.4.4. 缓存多个实验中通用的计算对降低数据大小和性能很有帮助
  

3.5. 实验优化

• 3.5.1. 包括监控实验和优化实验人群分配。实验启动后，对日志进行持续分析，确保实验达到统计显著性，对客户体验没有负面影响，没有交叉实验干扰
  
• 3.5.2. 优化的另一个方面是自动增加运行良好的实验的客户流量
  
• 3.5.3. 为了跟踪实验，可以使用丰富的仪表日志来生成自助服务分析并对实验进行故障排除
  
• 3.5.4. 指标需要时间来积累数据才能达到稳定状态
  
  
  
  • 3.5.4.1. 二级指标（如注册次数、登录次数等）和操作指标（如可用性、页面性能等）也会被跟踪关注，以确认实验是否会继续下去
    
  
  

4. 实现模式

4.1. 实验规范模式

• 4.1.1. 自动处理与实验设计相关的随机化和实验交互
  
• 4.1.2. 侧重于使实验设计成为关键，使实验负责人能够在整个生命周期中配置、启动、监控和控制实验
  
• 4.1.3. 该规范涉及受众选择、实验规模和持续时间、与其他实验的交互以及随机化设计
  
• 4.1.4. 当用户被随机分到不同的实验中时，存在不平衡的可能性，这可能导致实验群体之间出现统计显著性差异
  
  
  
  • 4.1.4.1. 这种随机失衡的影响与实验组的影响分开是非常重要的
    
  • 4.1.4.2. 流行方法是重新随机化
    

    4.1.4.2.1. 如果检测到随机不平衡，则重新开始实验，对哈希种子进行重新随机化
    

    
    
  
  
• 4.1.5. 检测随机不平衡的方法
  
  
  
  • 4.1.5.1. 使用A/A实验（即实验组和对照组相同）​，先运行几天作为运行实际实验前的完整性检查
    
  • 4.1.5.2. 使用为实验选择的哈希种子随机化模拟历史数据
    

    4.1.5.2.1. 在现实世界中，许多回顾性A/A分析是并行进行的，以生成最均衡的种子
    

    
    
  
  
• 4.1.6. 在实验交互的上下文中，用户有可能同时被分配到多个实验中
  

4.2. 指标定义模式

• 4.2.1. 简化了评估实验的指标分析，减少了实验负责人提取与实验相关的洞察所需的时间
  
• 4.2.2. 简化了分析实验所需的指标的定义
  
• 4.2.3. 这种模式没有实现一次性和不一致的指标，而是提供了一个DSL来定义指标和维度
  
  
  
  • 4.2.3.1. DSL作为一个内部表示，可以被编译成SQL和其他大数据编程语言
    
  • 4.2.3.2. 使用独立于语言的DSL可以确保跨不同后端数据处理机制的互操作性
    
  • 4.2.3.3. 目标是使添加新指标的过程变得轻量级，并为广大用户提供自助服务
    
  
  
• 4.2.4. LinkedIn的Unified Metrics Platform
  

4.3. 自动化实验优化

• 4.3.1. 跟踪实验的健康状况，并自动优化实验变体之间的流量分配
  
• 4.3.2. 旨在自动优化用户之间的变体分配，并确保实验趋势正确，既符合统计显著性，又不会对客户体验产生负面影响
  
• 4.3.3. 三个构建块：用户遥测数据的聚合和分析、实验指标的质量检查以及自动优化技术
  
• 4.3.4. 为了跟踪实验的健康状况，以合格的实验、实验组和用户要访问的页面等形式跟踪遥测数据，这些数据与用户真正经历的实验和实验的应用程序日志相关
  
• 4.3.5. 遥测数据通常从客户端和服务器端收集
  
  
  
  • 4.3.5.1. 人们倾向于从服务器端收集，因为它更容易更新、更完整、延迟更少
    
  
  
• 4.3.6. 验证机制是A/A实验，如果没有处理效应，则p值预期会均匀分布
  
• 4.3.7. 多臂强盗
  
  
  
  • 4.3.7.1. 目标是首先探索哪些实验变体性能良好，然后积极给获胜变体增加分配用户数量来平衡开发与探索
    
  
  
• 4.3.8. ε-贪婪算法、汤普森采样、贝叶斯推理
  

来源：程序园用户自行投稿发布，如果侵权，请联系站长删除
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！