移动App A/B测试中的5种常见错误

2020 年 4 月 05 日

移动App A/B测试中的5种常见错误

A/B 测试是一个需要不断学习的技能。而任何技能都需要通过不断的磨练才能越来越好。本文列举了 5 个 A/B 测试在移动 App 中常见的错误,希望产品经理和 Growth 的同学阅读完本篇文章后,可以在以后的 A/B 测试中避免同样的错误。


1. 直接复制其他公司的 A/B 测试经验


场景描述:看到同行业另一家公司的产品正在做 A/B 测试,他们的新版本看起来不错,我们也 Copy 他们新版本的产品形式直接上线吧。


不同的公司,甚至同领域的不同公司所做的 A/B 测试的经验一般不能直接复制。这里面最经典的是人人网与 Facebook 的案例。Facebook 曾经在一个 VP 的带领下做过一个首页的产品大改版,因为产品改动巨大所以这个版本一直在做小流量的 A/B 测试(虽然是小范围测试,但是 Facebook 总体用户量巨大,所以有百万级别的用户看到过这个新版主页),并没有推送给所有用户。但是人人网并没有学习 Facebook 的 A/B 测试经验,而是在看到 Facebook 这个新版本之后直接决定 Copy 过来。结果 Facebook 的这个主页大改版其实非常不成功,最后并没有推送到所有用户,然而人人网却直接上线了这个版本,对他们用户体验的伤害其实是无法估量的。






这里面最关键的问题是,不同公司的用户群体的行为其实是很不一样的,因为产品的场景、用户群不一样,这就决定了每一个 App 都应该围绕自己的用户群体和使用场景去做 A/B 测试,而不是照搬同行的经验。


2. 不够全面、准确的优化指标


场景描述:我更改了购买按钮,并跟踪了该按钮的点击次数。经过 4 周的 A/B 测试,该按钮的点击量提升了。但是,点击该按钮和完成购买之间还有 3 个步骤。这个按钮的改变是真的提升了转化率,还是仅仅鼓励了更多的用户点击购买按钮,而没有真正完成任何购买?


另一方面,如何知道您是否已跟踪了足够多的指标?我们一般也不会想跟踪整个应用中的每一个指标:如果你看到太多的指标,很可能会出现其中一些指标会显示试验版本比原始版本好,另外一些指标会显示试验版本比原始版本差,这个时候就很难判断到底新版本好还是原始版本好了。


避免这类错误的关键是先问自己一些问题:


  • 你将如何判定一个A / B测试是成功的(或失败的)?

  • 为了保证A / B测试成功,你 必须 跟踪哪些指标?是一个就够了,还是要同时关注多个指标?是否需要基于多个指标做组合形成一个复合指标?

  • 选择指标后,请自行检查:“如果所有这些指标都显示新版本相比原始版本具有正向的、统计显著的结果,那么你是否有足够的信心将此新版本推送给所有用户?”


这些问题可以帮助我们避免上面提到的情况,因为很多时候仅仅关注按钮点击的指标是不够的。


3. 未规划好参与试验的用户规模


场景描述:我想测试按钮文案更改对结帐流程中最后一步的影响。我的用户中有不到 1%的人看到了此步骤,但我认为将此步骤的转化率从 80%提高到 85%将大大提高我的收入。我有 3 个按钮文案的想法想进行 A/B 测试,所以我可以通过 Testin 的 A/B 测试平台(http://www.http://www.testin.cn/product/ab)运行一个有 3 个版本的 A/B 测试试验,以提高


这里的错误是,没有获取足够的用户来执行想要的 A/B 测试。一般来说,我们需要至少 1000 个用户来获得统计显著的试验结果。这似乎不那么高,但如果只有 1%的用户看到支付流程的最后一步,意味着你需要有 10 万个该 App 的用户参与到 A/B 测试试验中来才行。10 万个用户对有些 App 来说很容易,但如果你的应用程序只有 25000 个用户,你需要 4 个月才能达到统计效果显着的试验结果。简而言之,你必须保证做 A/B 测试的那个页面至少有 1000 个用户会访问才可以。


4. 过早停止 A / B 测试


场景描述:我的一个 A/B 测试试验运行了 3 天,看到了统计显著的结果,这是一个成功的 A/B 测试,于是我发布获胜的版本给所有用户。


过早地停止 A / B 测试是一个不明智的选择。如果你的测试只运行了一个较短的时间(例如仅 3 天),那么参与试验的用户几乎都是你的高频用户。如果你的高频用户喜欢这项变更,你很可能在最初几天看到正面的结果。但是如果测试运行一个月,你看的数据会包含一个更全面的用户群的视图,因为除去高频用户外,其他可能每个月只用两三次的用户行为也会慢慢展现出来,这时候的数据的结论可能跟你前 3 天看到的完全相反。


当 Airbnb 测试他们的价格滑块的变化时就经历过类似的情况。






在 Airbnb 这个 A/B 测试中[1],他们尝试将搜索页面的价格过滤器的最大值从 300 美金提高到了 1000 美金。从试验数据来看,在试验进行到第 7 天的时候,该试验的统计数据显示新版本能将房屋预定的量提升 4%(蓝色曲线),且它的 p-value 已经小于 0.05(红色曲线),属于统计显著的效果。如果他们在那一天结束这个试验并将新版本发布给所有用户的话,他们会期望得到房屋预订量的提升;但是,好在他们当时将这个试验继续运行了 36 天的时间,以检验该变动是否真正会取得统计显著的提升。最后的结果显示,这个改版相比原版本的提升几乎为 0,而且其 p-value 值也变成了 0.4(统计不显著)。


那么我们该如何判断一个试验究竟该运行多长时间呢?一个好的经验法则是先思考你的 App 中一个典型的用户周期是多长时间,然后将你的测试运行两个用户周期。对于许多 App 来说,一个用户周期就是一个星期。但对于某些特殊应用(例如银行应用),这可能是一个月。如果你的测试运行至少 2 个用户周期,这就增加了同时捕获高频用户和一般用户的点击行为的机会。


5. 认为所有用户的行为都是一样的


场景描述:某电商 App 的商品详情页进行了改版后的 A/B 测试,发现新版本页面停留时间、加入购物车次数比原始版本都下降了,说明新版本是失败的,不应该上线。


A/B 测试通常捕获到的是用户共性的行为数据。大多数用户喜欢版本 A,但可能有一部分用户喜欢版本 B。用户选择 B 版本也有可能是随机的行为,但肯定有一个共同的特征,导致那些用户喜欢版本 B。因此找出并分析用户喜欢版本 B 的原因并在以后的试验中运用也是非常重要的。业内有句话叫“再牛的产品经理也跑不赢一半的 A/B 测试”,正是因为用户群体的不确定性导致产品经理需要使用 A/B 测试来验证自己的想法。这就是为什么需要在 A/B 测试中做用户定向试验的原因。


在 Testin 的 A/B 测试平台中,产品经理可以基于用户的设备特征(例如手机机型、操作系统版本号、手机语言等)和用户的自定义标签(例如性别、年龄、新老用户、会员等级等)进行分群,每一个 A/B 测试试验都可以选定特定的用户群进行试验。在之前的电商商品详情页的案例中,产品经理在第一次 A/B 测试之后,提出了一个假设:我们平台上老用户比较多,新用户只占 40%,如果我只给新用户做版本对比的 A/B 测试,试验结果会不会不一样呢?果然,在只对新用户进行 A/B 测试之后,他们发现新用户的行为喜好与老用户确实存在差别,为他们将来产品改版和个性化产品页面积累了很宝贵的经验。


2020 年 4 月 05 日 16:53105

评论

发布
暂无评论
发现更多内容

多省市出台关于区块链人才引进的计划

CECBC区块链专委会

新基建 区块链技术

区块链+收藏品,全球三种典型应用路径的差异化

CECBC区块链专委会

区块链 应用价值

机器学习算法之——卷积神经网络(CNN)原理讲解

迈微AI研发社

学习 算法 卷积神经网络 CNN

List 和 Map 的排序

方明

Java

机器学习算法之——K最近邻(k-Nearest Neighbor,KNN)分类算法原理讲解

迈微AI研发社

学习 算法 KNN K聚类

JDK1.8新特性(七):默认方法,真香,开动!接口?我要升级!!

xcbeyond

接口 新特性 JDK1.8 默认方法

Kafka处理请求的全流程解析

yes的练级攻略

kafka 后端 面试题 消息队列 源码解析

troubleshoot之:用control+break解决线程死锁问题

程序那些事

Java JVM 死锁

真正的勇士,会跨过六道裂谷,奔向云与AI的彼端

脑极体

从数据中台到AI中台,企业到底要建什么中台?

脑极体

区块链跃升各国创新战略

CECBC区块链专委会

新基建 国家战略 区块链标准

2.1.2 类加载器的工作原理与自定义加载器 -《SSM深入解析与项目实战》

谙忆

如何设计实现一个证书加密签名工具包

三尾鱼

Go: 互斥锁和饥饿

陈思敏捷

go golang mutex

# spring boot自定义线程池进行异步调用

方明

Java

服务器与普通电脑的区别?

德胜网络-阳

基于 grpc,protobuf搭建 server/client模型通信

是老郭啊

2.2.1 类反射 -《SSM深入解析与项目实战》

谙忆

如何理解Java8 的函数式编程

Rayjun

Java 函数式编程

原来你是这样的B+树

Java技术宝典

B+树

ARTS Week8

丽子

HTTPS证书过期导致的故障

焦振清

运维 https SRE 服务故障 证书过期

重学JavaScript02——类型

张理查rootv

如何对 ElasticSearch 集群进行压力测试

Bestony

elasticsearch ELK Elastic Stack

数据库的乐观锁和悲观锁并非真实的锁

架构师修行之路

数据库 架构 乐观锁 悲观锁 分布式锁

LeetCode题解:24. 两两交换链表中的节点,递归,JavaScript,详细注释

Lee Chen

LeetCode 前端进阶训练营

ARTS-week-2

saddamwilson

ARTS 打卡计划

重学JavaScript03——执行

张理查rootv

知路,然后智行远;懂行,所以万业兴

脑极体

LeetCode题解:21. 合并两个有序链表,利用数组排序,JavaScript,详细注释

Lee Chen

LeetCode 前端进阶训练营

DevOps 技术栈

柴锋

Linux DevOps 运维 敏捷 Shell

移动App A/B测试中的5种常见错误-InfoQ