App开发的功能实用性决策方案——开实验

penghc_xhs

已于 2024-09-16 10:49:48 修改

阅读量232

点赞数 1

分类专栏： Android 文章标签： android 产品运营个人开发 web app

于 2024-09-15 16:52:24 首次发布

原文链接：https://www.volcengine.com/docs/6287/65799

版权

Android 专栏收录该内容

8 篇文章 0 订阅

订阅专栏

App开发的功能实用性决策方案——开实验

入职过互联网开发的同学应该对实验这个词并不陌生，也手动开过实验或者给自己加过白名单以体验自己开发的功能特征。那么这期我们来介绍一下App开发绕不开的实验概念。我们可以带着以下问题来去阅读这篇文章：

什么是A/B实验？
如何设计出一个好的实验？
如何配置设计好的实验呢？
实验有客户端实验和服务端实验，两者有什么区别？
实验流量是如何分配的？流量正交又指的啥？

什么是A/B实验

现如今，大多数互联网产品野蛮生长的时代已经过去，人口红利到顶，产品策略需要从快糙猛的跑马圈地方式转向深耕细作的精细化运营方式，要精细化运营，就需要采用数据来驱动。
何为数据驱动？试想以下几种场景：

小A凭着丰富的经验直接修改了产品的线上策略，一周后发现效果不升反降，遂立马下线。
小B和小C同时上线了两个产品功能，一周后产品数据有下降，都认为是对方的问题，谁也不肯接锅。
小D上线了一个新策略，随后进入十一黄金周，用户交互有所下降，小D觉得一定是假期埋没了自己的辛苦贡献，但也辩不明白，无处申冤。
小E辛苦工作一整年，开发了365个不同的功能上线，年终写总结时却写不出到底在哪些方面究竟贡献了多少。
想必产品和开发都不希望自己落入这样的困境中吧，因此数据驱动业务增长就显得很有必要。
那么数据变化和产品动作之间到底存在什么样的因果关系呢？

因此，我们需要设计并坚持使用一套数据驱动的方法，使得业务人员可以以较小的风险对新feature进行评估，积极试错积累经验；并且我们设计的该方法有能力排除其他因素（比如同时开发的其他feature以及时间因素等）的干扰；最后，除了“好”或者“不好”，我们希望这个方法最好也能够给出定量的结果。
为了解决上述问题，控制单一变量，普遍使用的方法论是小流量随机实验，也就是我们常说的A/B实验。

到现在，我们应该可以明白什么是A/B实验了

在线上流量中取出一小部分（较低风险），完全随机地分给原策略A和新策略B（排除干扰），通过控制时间变量等，再结合一定的统计方法，得到对于两种策略相对效果的准确估计（量化结果），最终基于数据进行决策和追责。

如何设计出一个好的实验

通过对A/B实验的介绍，我们基本能知道实验的开始到结束的流程：

产品提出需求，预计收益
设计实验
A/B测试（上线）
根据数据进行分析决策
以下通过一个场景示例为大家展示如何分析、拆解一个业务问题，设定优化方向、评价指标并设计一个A/B实验来进行效果验证。

业务背景

说明
实验的来源：通过分析当前业务问题、提出潜在的解决方案，形成一个「实验idea」

背景：该产品是一个汽车类App产品，发现App登录率偏低，通过转化漏斗定位问题为触发登录率过低，影响个性化服务的机会。（如下为漏斗示意图）
在这里插入图片描述
根据上面的分析，一个比较自然的想法，就是去提升触发登录率，也就是给未登录用户增加更多的登录入口。那么就面临两个问题：

在哪里加入口？
以什么形式加入口？

针对第一个问题，需要定位目前未登录用户的主要流量去向，在这些主要的流量场加入登录入口，效果是最好的。现有未登录可使用的功能，包括但不限于：关注、点赞、进入直播间、保存发布草稿、查看浏览历史等。通过用户路径对未登录用户的行为路径进行分析发现关注、点赞、查看历史等场景流量较多，可以尝试在这些环节加入登录引导。

实验目标

说明
目标：明确「实验idea」最终想达成的业务目标是什么，根据目标来制定衡量指标
衡量指标：用于评价目标是否达成的成功标准。且需要论证是因为施加了实验策略而达成的，因此指标和策略要有明确的业务因果性
至此，就形成了完整的「实验假设」：预期通过xxx改进，可对指标A提升n%，从而为产品/用户带来xxxx价值。

目标：在不影响未登录用户使用体验的前提下，提升登录率，更好地为服务用户
衡量指标：登录率
实验假设：通过在每个入口尝试不同的引导方式，可对指标「登录率」提升n%，从而好的服务用户。

实验设计

根据当前线上主流的登录引导由弱到强有：非阻断式弹窗/蒙层引导、半屏/全屏面板引导、全屏面板强制登录。针对不同入口，可以实验不同的登录引导方式。进一步设计出不同的实验策略

实验模式	客户端编程实验
实验受众	全体用户，不做任何过滤
流量大小	根据影响范围+触发登陆用户数进行评估
实验时长	14天及以上
实验时长	14天及以上
对照组：线上样式	全屏面板强制登录
实验组：新样式	半屏面板引导，增加引导说明
评估思路	「登录率」是成功指标： - 显著上涨则说明方案有效果，可以直接上线 - 显著下降则说明方案有负向影响，需要进一步拆解数据来分析原因 - 无显著变化则说明没有明显作用，可以通过拆解用户分层、商品品类的数据来分析是什么原因导致的，如果发现有显著变化的敏感人群或敏感品类可以进一步施加策略做实验

如何配置设计好的实验呢

好了，现在我们已经知道实验如何设计了，那怎么样配置实验平台让实验合理化呢？

实验开在哪

这里所说的“开在哪儿”，指的是如何选择正确的实验层。
何谓“实验层”呢？“实验层”技术是为了让多个实验能够并行不相互干扰，且都获得足够的流量而研发的流量分层技术。
设想一下，假如我现在有4个实验要进行，每一个实验要取用30%的流量才能够得出可信的实验结果。此时为了同时运行这4个实验就需要4*30%=120%的流量，这意味着 100% 的流量不够同时分配给这4个实验。那么此时我只能选择给实验排序，让几个实验先后完成。但这会造成实验效率低下。试想一下，许多大型互联网公司每年有上万个实验要进行，如果只能排队挨号，实验恐怕可以排到4202年。
那么有没有办法可以解决这个问题呢？
有，就是使用实验层技术，把总体流量“复制”无数遍，形成无数个流量层，让总体流量可以被无数次复用，从而提高实验效率。各层之间的流量是正交的，你可以简单理解为：在流量层选择正确的前提下，流量经过科学的分配，可以保证各实验的结果不会受到其他层实验的干扰。
在这里插入图片描述
在选择实验层的时候，我们要遵循的规则是：业务冲突，在系统层面体现为参数冲突。进行实验时需要规避业务冲突。

说明
如何鉴定一个实验A是否与其他实验冲突？一般由业务含义来判定。

例如，点赞按钮，实验A设计为红色，实验B设计为蜡烛；实验A与实验B涉及到对同一个「物理对象」的修改（操作），同时修改会引起冲突或者问题，即对一个具体用户的按钮，它到底是什么颜色。
规避的方法主要为，将冲突的实验选择在同一个流量层进行实验。
这类实验在推全时，也需要考虑冲突的问题；不能单独推全。
如果不存在业务冲突，那么一般建议直接独立进行实验即可，不用考虑其他实验的运行。在 DataTester 上，直接新建实验将被单独分配一个新的流量层，这个流量层与其他实验正交。

实验开多久

基于一些统计学原理，实验开设得过长或过短都不利于实验结果的可信度。通常实验时长要与产品的“数据特征周期”一致。如何理解呢？比如某旅游攻略类app产品，用户在周一到周五的活跃度较低，在周末活跃度较高，以一个自然周为周期，不断循环。那么这一旅游攻略类产品在做A/B实验时，通常应该将时长设置为一周。

谁进入实验

实验中，我们要对进入实验的流量大小做出设置。通常在实验的初始阶段，我们倾向于先分配较少的流量（如1%）进入实验。如果初期实验结果一切正常，那么可以进一步加大流量；假如实验数据出现巨大的异常，那么可以随时将实验终止。小流量可以最低程度减少实验异常对用户体验的影响。
除了对流量大小进行设置之外，我们还可以添加限制条件，对进入实验的用户进行过滤，比如只看“安卓用户”、只看“北京地区用户”等等。这部分过滤条件通常需要由实验发起者和分析师共同确认。

关注的指标

确定哪些指标是我们所关注的。再来看看前文中我们做出的假设：将购买页面主色调从蓝色改为红色能够将用户购买率提升3%。在这一实验中，“用户购买率”必定是我们的关注的指标，并且是我们的“ 目标指标 ”。除此之外，我们还应该关注一些产品常关注的重要数据指标，用以观察实验中的新策略是否会对其他重要指标产生负面影响。

实验配置参数

配置参数实际上是一串代码，这串代码决定了进入实验的用户，其体验到的产品会有什么不同。仍旧用前文中的假设做例子，如果我假设“将购买页面主色调从蓝色改为红色能够提升用户购买率”，那么在实验中，我的下发的配置参数flag就应该让实验组用户的购买页面色调呈现为红色。这些参数的具体代码需要与产品的研发进行确认。

前期测试

在经过上述的步骤，我们的实验就已经基本设置好了。但在我们并不应急于开启实验，还应当对实验进行前期测试。
测试时，我们会将“测试用户”添加白名单之中，并在测试用户的手机/电脑上中观察实验配置是否能够正常生效（如购买页面的颜色改变是否可以正常显示）、客户端/网页是否会崩溃、实验数据能否正确上报等。

实验的基本概念

AB实验、实验组、对照组

相关概念	概念介绍
AB实验	A/B实验的基本思想就是在线上流量中取出一小部分（较低风险），完全随机地分给原策略A和新策略B（排除干扰），再结合一定的统计方法，得到对于两种策略相对效果的准确估计（量化结果）。这一套基于小样本的实验方法即为A/B实验，亦被称为“对照实验”或“小流量随机实验”，同时满足了低风险，抗干扰和量化结果的要求，因此不论在互联网产品研发还是科学研究中，都被广泛使用。
实验组、对照组	实验组和对照组是一组相对的概念，A/B实验通常是为了验证一个新策略的效果。假设在实验中，所抽取的用户被随机地分配到A组和B组中，A组用户在产品中体验到新策略，B组用户在实验中体验的仍旧是旧策略。在这一实验过程中，A组便为实验组，B组则为对照组。

客户端实验、服务端实验

对比说明	客户端实验	服务端实验
实验描述	指通过客户端获取实验分组信息并控制配置生效的实验。	指通过服务端获取实验分组信息并控制配置生效或下发的实验。
特点及场景	特点：APP唤起时，AB相关配置即需生效场景：要求启动就要曝光的场景，比如我们要针对APP的开屏页面进行A/B实验，用户刚刚打开APP，客户端就需要向用户展现开屏界面了。这种情况下客户端可能来不及向服务端请求配置参数。	特点：命中和曝光的逻辑在服务端处理，不要求唤起APP时就使实验配置生效。客户端有充分时间向服务端发起请求，获得实验配置后再向用户展示策略。场景1：推荐策略、纯服务端配置实验，通常uid分流，不要求唤起APP时就使实验配置生效。场景2：部分功能只能由服务端来控制，比如内容分发算法（如用户打开今日头条以后在feed流中会看见什么内容）、由服务端逻辑控制的产品功能（如推送）等。

实验流量、流量分配

互联网行业的A/B实验中，流量通常用于描述产品所拥有的总体用户数量。
开A/B实验时，一般都会小流量测试，当看到某个实验组效果后，再大流量测试，最终再全量上线。

实验流量分层：互斥实验、流量正交

互斥实验

互斥实验，指的是互斥组中的所有实验都不会共享用户，开在同一流量层的多个实验中，流量只能命中其中一个，即同层实验的流量之间是相互排斥的。如果一个用户/设备命中了实验A，就不会命中该互斥组中的其他实验。
基本原则：内容相同或相关、可能会彼此影响的实验，建议将实验加入到同一个互斥组中。举例，您要同时做按钮颜色和按钮形状的实验，就需要将两个实验加入到一个互斥组。

正交实验

互斥组=互斥层=实验层
每个独立实验为一层，一份流量穿越每层实验时，都会随机打散再重组，保证每层流量数量相同。
如何理解流量正交？

举个例子。假设我现在有2个实验。实验A（实验组标记为A1，对照组标记为A2）分布于实验层1，取用该层100%的流量；实验B（实验组标记为B1，对照组标记为B2）分布于实验层2，也取用该层100%的流量。（要注意，实验层1和实验层2实际上是同一批用户，实验层2只是复用了实验层1的流量）
如果把A1组的流量分成2半，一份放进B1组，一份放进B2组；再把A2组的流量也分成2半，一份放进B1组，一份放进B2组。那么两个实验对于流量的调用就会如下图所示。此时实验A和实验B之间，就形成了流量“正交”。