A｜B测试

四、策略产品经理体验策略策略产品经理在A/B测试上线后通过将自己的测试账号在不同的实验组中切换，反复验证实现逻辑是否完全符合需求文档，并仔细体验两组实验的主观差异（如果拥有中台系统，可以通过后台实现同一用户的内容推荐顺序对比），时间允许的情况下可以写主观评估报告。

技术自测

关于结束点的选取，不同类型的产品和不同的观察指标有所不同，具体的选择方式如下：对于日活级产品（DAU/MAU大于50%的产品）：普通指标需要观察3个完整天以上（一般为4天），次日留存指标需要观察7个完整天以上（一般为8天），次周留存指标需要观察14个完整天以上（一般为15天）。对于周活级产品（DAU/MAU小于50%的产品）：此类产品用户并非每天活跃，并且具有强周期性。普通指标需要观察7个完整天以上，一般为8天，因为需要一个周期内的用户行为对比。次日留存指标需要观察10个完整天以上，一般为15天，因为需要两个周期内，两个分组的用户行为对比。次周留存指标需要14个完整以上，一般为15天，因为需要两个周期内两个分组的用户行为对比。以上数据为经验数据，主要依据是笔者经历的大多数A/B测试的次日留存指标在第7天趋于稳定，第8天、第9天、第10天和第7天的结果基本一致。其他指标的结束点时间同理，本质上是因为用户行为数据会逐渐收到固定的值。结束点时间的选择是“实验精准度”和“项目迭代速度”的折中，如果追求实验精准度，每个实验都可以开启一年之久，但这样的话在紧张的项目迭代周期中效率就会受到影响，大多数公司以单周迭代或者双周迭代的节奏开展工作。

2小时后检查数据

2. 服务端请求日志的数据量是否符合预期在实验开启后，找算法工程师一起检查一下服务端请求日志的监控，如果实验正常开启则请求数据量不为0。

八、分析实验结果在结束点以后策略产品经理需要分析实验结果，并给出如下的书面分析。分析实验数据的结果是否符合预期，以及可能的原因。一般需要参考原始实验假设，并且结合自己的主观体验报告来尝试回答这个问题。符合预期的实验，下一步优化的点是什么。不符合预期的实验，分析是假设错误还是验证错误，下一步改进点是什么。

设计实验

九、灰度上线如果实验取得了统计置信的正向收益，需要对该策略进行灰度发布，但是流程上会因是否需要发布客户端新版本而有所区别。如果需要发版，走版本审核的通用灰度流程，一般需要在小渠道放量，观察产品在不同手机型号下是否存在漏洞。如果不需要发版，关闭原试验，在A/B测试平台将该实验状态调整为“灰度发布状态”（平台需要支持该功能），调整实验组用户的占比，观察天级指标的变化情况。比如第一天放量30%，观察目标指标（比如人均停留时长）在全量用户上的变化。灰度上线的目的是观察A/B测试在全量用户上真正取得的效果，此时虽然不是严格A/B测试验证，但也是十分必要的，下文会介绍为什么正收益的A/B测试全量后效果不如原实验结果明显。

2. 假设驱动通过系统的假设、实验验证的方式来进行探索，能够持续地增加我们对于业务、模型、数据的认知。A/B测试的成功率正常是小于20%的（成熟产品A/B测试成功率更是小于10%），但基于假设驱动的实验方法，即使是失败的实验，我们也能从中提取知识，挖掘新的优化点。另外，建立系统的认知，能够使我们找到持续可迭代的改进方案，而非随机的策略优化。

六、检查点2上线24小时后观察数据变化，此时检查的重点是实验是否存在更深层次的实现漏洞。

分析实验结果

24小时候检查数据

十、回测机制在KPI考核周期之前一般需要有组织地对有收益的实验进行回测，所谓“回测”，实际上是对历史实验的重新测试。因为在实验期间有收益不代表一直存在收益（A/B测试存在局限性，可能用户群的征分布发生了改变），所以需要对考核周期内（比如说一个季度内）取得了较大收益的实验重新测试，预期是拿到同样正向的收益（数据幅度可能会有差别，这是正常的）。实验流程是前人通过不断试错总结出来的宝贵经验，有三个核心收益。

二、设计实验策略产品经理了解相关技术逻辑，设计单变量实验并撰写策略实验文档，包括但不限于实验逻辑描述，如何验证实验假设，以及预期的数据收益。

   一般来说，24小时后的数据结果往往和结束点的数据结果趋势相同，此时的检查可以提前发现数据趋势，明确不符合预期的部分（如果有问题，可以提前重新检查一遍实现方式；如果没有，则通过，不用检查）。   如果有时间，建议策略产品经理再次体验实验组和对照组的策略，此次的体验和上次的感受是不同的，因为实验开启时第一次体验实验组策略可能会有新奇感，并且重心在于测试边界用例而非用同理心来理解用户的情绪。   在检查点2重新体验实验组策略，会对用户的情绪理解得更纯粹，不仅消除了新奇感带来的误差，而且可以更加放松地置身于产品中，以普通用户的心态来使用产品，此时最容易获得用户洞察。

回测机制

1. 候选集曝光量是否符合预期如果是涉及内容候选集的实验，需要检查内容候选集曝光是否是0。如果实验没问题，该数值应该是大于0的数字。

三、技术工程师自测算法工程师完成需求，测试工程师介入测试（有时候策略产品经理需要充当测试工程师的角色），添加实验白名单，确保自己的测试账号命中实验。

产品经理体验策略

结束点

五、上线后的检查点上线后2小时观察相关数据，主要通过实时数据判断实验开启后是否存在问题，检查以下数据是否正常并记录在文档。如果存在问题，立即检查问题；如果没有问题，在下一个检查点重新确认。

提出需求

灰度上线

3. 实验开启后的过滤策略或排序策略是否生效如果是过滤策略，需要检查用户推荐日志中实验组需要过滤的内容标签是否存在。如果是排序策略，需要对用户推荐日志中的前50条结果进行随机抽样分析，检查带有响应标签的内容排序是否更靠前。策略产品经理需要验证上线产品是否符合预期并记录到实验文档中。

一、提出需求策略产品经理基于先验判断、数据分析结论或者领导要求，需要上线一个策略实验需求。

七、结束点在结束点需要终止实验，基于多天累计数据，对相应指标进行数据分析并形成数据报告。

1. 慢即是快虽然每个实验规范化的文档和对应的检验将会增加大概3小时的时间成本，但对于算法或者策略这样为期数周且持续占用流量的实验来说，是非常必要的。因为一个错误实现的实验，轻则导致数周时间无效，重则导致重要假设的错误验证。我们认真做好每个实验，会比盲目地大量做浅尝辄止的实验更加高效。实验迭代速度加快，不是通过减少实验的规范，而是通过自动化流程的建立和效率工具的开发来实现的。

3. 持续积淀对于算法策略团队而言，每一个实验即一份学习资料，积累的实验报告对公司内部的其他业务方向、新人培训等将有巨大的学习交流价值。这本用无数实验数据总结出的“实验教科书”能够放大单个实验的收益，笔者自己便是最好的例子，笔者和同事们共享实验数据库和实验结论，使所有人都能更好地理解内容推荐业务，更好地理解用户行为，实现缩小自我、产品大众、平台共享的价值观。