A/B相信大家都或多或少做过，但是A/B测试你又了解多少呢？A/B只是一种消遣吗？什么是科学的A/B实验。下面阿里前端技术达人就结合最近的一些学习，系统通俗的讲一下A/BTesting，希望对大家有所帮助。什么是A/B测试？A/B有很多定义。一般来说，A/B是一个工具，把A和B两个版本分开，统计数据，然后看哪个版本的数据更好，对产品目标更有帮助。这里我想从A/B本身的意义来说说它的定义。以我们的业务迭代为例，我们会定义产品的业务数据指标（这些指标通常可以直接和间接地反映我们的业务目标），然后我们会在业务迭代中不断做出假设，期望改变这些假设提高相应的经营指标。这里A/B是衡量我们提出的业务改进假设是否有效的一种方法，是一种统计意义上的假设验证方法。我觉得这个定义的好处是A/B不仅仅是一个工具，更多的是和业务发展结合的迭代思想，A/B背后其实有科学的统计依据。还将更加关注每个业务假设是否确实有效。用户增长最忌讳的就是一味套用其他业务线的增长方式，而忽略了自己业务的分析和推导过程。我们需要测试以了解是否一切正确。产品在什么阶段适合做A/BTesting？对于一个初创项目来说，产品刚刚孵化出来，这个时候不适合做A/B测试，因为我们这个时候的目标比较明确，就是快速形成一个“原型”产品的大框架，“产品诞生”，所以基本上不会有太多的细节。而当产品发展到一定阶段，模型已经相对稳定，相对处于快速迭代阶段，更适合使用A/BTesting来帮助业务发展。A/BTesting的步骤在讲A/BTesting的步骤之前，我想说的是，A/BTesting实验并不是说你做了一个实验得到了之后就不需要再做A/B了结果。它更像是一个持续优化和理解产品和用户的过程。所以这里说的A/BTesting的步骤并不是指我们在平台上如何配置A/B实验，而是更广泛的步骤，如何通过A/BTesting来优化产品。一般来说，业界一般将A/BTesting分为8个步骤。这是我在学习期间看到的8阶段A/B划分。我们可以看到我们技术同学最关心的A/B实验的创建其实只是第4和第5步。在此之前，我们还有很多工作要做，那么要科学地做A/B，我们??每一步应该怎么做呢？让我们来看看。1、搭建产品漏斗这一步，我们在工作中经常被忽略。我觉得，不管是做业务的还是学技术的，了解我们的产品链接和用户漏斗，了解用户是从哪里来的，都是很有必要的。我们希望用户走到哪里，我们就可以为增长做好准备。例如，在用户拉入过程中，其漏斗大致可以是：2、确定产品链接的核心指标。明确了产品漏斗之后，我们需要明确产品环节中要观察哪些核心指标。如果您的注意力只集中在一个页面上，那么您可能需要更仔细地查看当前页面的用户指标；如果您关注的产品链接比较长，您应该关注整个链接上各个节点之间的指标。以上面的“新用户拉动”为例，我们可能需要关注每个节点的用户数（PV/UV），以及每一层的转化率（例如：点击/曝光）等等。确定指标后，我们需要将这些指标纳入长期观察。3.观察指标，提出优化假设。那么我们产品同学就可以根据指标分析当前的业务情况，然后结合需要优化的数据指标，提出相应的业务假设。从这里，您将掌握进入市场的统计知识。这里我们说的假设其实包括两种：原假设，也称为原假设和零假设（NullHypothesis），代表我们希望通过实验结果推翻的假设。备择假设（AlternativeHypothesis）表示我们要通过实验结果来验证的假设。可以看出原假设是悲观的。为什么我必须这样划分它？老实说，一开始我很困惑。这里我们首先提出这两个概念（原假设，备择假设），它们的作用将在接下来的几个步骤中看到。假设我们的场景是优化页面按钮的点击率，而我们预期的做法是增加按钮的尺寸。那么零假设的表达就是：增加按钮的尺寸，按钮的点击率不会改变。备择假设的表述是：增加按钮的尺寸，按钮的点击率会受到??影响（我认为影响包括改进和减少，但在大多数解释中，这个假设只会写改进，我理解我们通常不假设为了数据减少，这个可以讨论）。另外，需要注意的是，在假设检验中，原假设和备择假设只有一个为真。确认假设后，我们继续进行实验设计。4.设计A/B实验方案在实验设计中，我们需要明确一些信息：我们需要说明实验的目标是什么，包括上面提到的假设。在实验分组方面，我们需要考虑如何划分分组，是否有A/A控制，应该为实验切多少流量？另外，在投放方面，我们的实验应该针对谁？它应该放在特定区域吗？还是放在特定的一端？此外，在A/B实验中，最好一次更改一个“变量”（尽管受时间的限制，您也可以同时进行多个变量，例如Obama的经典A/BB版海报），更有利于后续的数据分析和明确的结论。5.开展A/B实验这一步是我们最熟悉的阶段。一般的项目需求审查从这里开始。开发同学会使用RuntimeSDK编写UI逻辑、bucket逻辑等，这里不再赘述。细节。6、运行实验开发完成后，我们准备上线。这时候我们需要设置实验运行的配置，例如：我们主要需要设置：指标的样本量（反过来，样本量也决定了实验的运行时间）。实验的显着性水平（α）和统计功效（1-β）业界一般设定为5%，β设定为10%~20%。为什么要设置显着性水平(α)和统计功效(1-β)？这是因为所有的实验在概率和统计上都存在误差，误差会导致我们做出错误的判断。这里常见的误判包括：第一类错误（弃真错误）：原假设为真时拒绝原假设；I类错误的概率记为α（alpha），对应的值就是显着性水平。II型错误（false-takingerror）：原假设为假时未能拒绝原假设。II类错误的概率记录为β（Beta），倒数（1-β）对应统计功效值。说的再通俗一点，用上面的例子：第一类错误是指增加按钮的尺寸，按钮的点击率实际上并没有改变，但是因为错误，我们认为有改变。第二种错误是当增加按钮的尺寸时实际上会导致按钮点击率发生变化，但由于错误，我们认为没有变化。如果觉得这里很曲折，可以多感受几次。完成这些设置并发布代码后，我们就可以发布实验了。7、实验数据分析我们之前说过：A/BTesting的统计本质就是做假设检验。当然，在我们开始假设检验之前，我们需要验证我们的数据本身是正确的。那么我们就要根据实验数据看：实验的显着性是否符合要求？实验结论是否证实了假设对数据的改进？实验是否导致漏斗中的其他数据恶化？关于实验的意义，这里我们也将使用z-test计算p值来进行验证。p值表示我们观察到实验样本是由随机过程生成的可能性有多大。p值越小，我们越有信心原假设无效。如果p值小于显着性水平(α)，我们可以认为原假设不成立。8.实验结论最后，我们根据本实验的分析结果总结实验结论。比如：在这个实验中，我们通过做xx专门提升了xx指标，并没有影响到其他指标。通过本实验的结论，我们推导出在xx场景下，适合使用xx方法来提升xx指标。当然，如果没有达到预期的目标，我们就不得不调整策略，提出进一步的优化假设。这8个步骤，有时我们也把它缩短为一个5步循环：一般来说，同样的事情就完成了。我们在做电商业务的A/B测试时会面临哪些挑战？说了这么多，我们来看看目前电商业务中的A/B测试。我们面临什么样的挑战？个人认为主要挑战在于：A/B测试直观感觉成本高，业务有接受门槛。电商都讲究跑得快。我也和很多同学谈过这个问题。其实大家觉得接受A/B测试并不是这么买账的。原因很直观，就是成本高，发展快。开发了两个（n）个版本，推迟了发布时间。但讲道理，既要追求“跑得快”，又要“走对的方向”。我相信我们之前已经说了很多。我们可以看到结合A/BTesting做业务是一个比较科学的过程。通过A/BTesting，我们将更加关注业务流程中的假设验证、数据推导和验证。同时，与“一班车功能”相比，/B推出还可以降低迭代带来的业务风险。甚至结合A/B，你可以发现业务中的问题，更好地了解你的用户行为。另外，通过A/B，可以获得可以沉淀和概括的业务成长经验。另外，A/B不是一次性的事情，而是一个长期迭代的过程。大家应该抱着“持续优化”的心态去做A/B，而不是“一次性完成”。从A/B“平台”的角度来看，我们有很多问题需要解决来帮助商家解决这些挑战：解决A/B成本高的问题（这里我们从几个角度来解决）：1.平台运营效率（是否简单易用），平台工具是否通俗易懂（A/B中这么多统计概念的理解成本是否可以被我们平台端平滑）。2、发展更加规范。我们需要在开发sdk上规范业务的自定义A/B开发，提供开发。3、开发效率提升：从工程化的角度，我们可以通过代码脚手架、代码生成等方式来提升效率。在平台功能上，我们可以提供UIEditor等工具，将一些“静态配置”的部分开放给运营和产品，让他们为A/B实验做改动，减少开发者自身的投入。4.A/B能力需要集成到其他流程、平台和系统中。以后运营使用其他平台时，你不会觉得A/B配置是一个单独的部分。当然，这里的解决方案也需要我们仔细思考。将A/B能力集成到其他平台的成本还是很高的。.我想这些也是我们需要逐步解决的问题。
