惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

阮一峰的网络日志
阮一峰的网络日志
The GitHub Blog
The GitHub Blog
酷 壳 – CoolShell
酷 壳 – CoolShell
雷峰网
雷峰网
U
Unit 42
Y
Y Combinator Blog
I
InfoQ
P
Proofpoint News Feed
Engineering at Meta
Engineering at Meta
量子位
Microsoft Security Blog
Microsoft Security Blog
B
Blog
The Cloudflare Blog
F
Fortinet All Blogs
Google DeepMind News
Google DeepMind News
MyScale Blog
MyScale Blog
C
Check Point Blog
S
SegmentFault 最新的问题
爱范儿
爱范儿
博客园 - 叶小钗
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
Hugging Face - Blog
Hugging Face - Blog
罗磊的独立博客
T
Tailwind CSS Blog

人人都是产品经理

为什么你的产品找不到差异化?90%的失败都卡在第一步上(下) – 人人都是产品经理, 3年从30万到1300万用户、获2200万美元融资,这个AI教育产品用“抽卡”破解了获客难题 – 人人都是产品经理, 园区招商系统怎么做才能真正帮到去化?我加了这一个功能,推广链接转发400次阅读过万 – 人人都是产品经理, AI大事件:OpenAI发完网络安全模型又搞药物研发,小鹏汽车要抓”DeepSeek时刻” – 人人都是产品经理, 电商不是卖货,是一场更残酷的产品经理实战 – 人人都是产品经理, 没想到,活动营销又回来了! – 人人都是产品经理, 为何All-in海外KOC:一场关于AI时代窗口期的豪赌 – 人人都是产品经理, 重新理解企业的内部协作 – 人人都是产品经理, 苹果的 AI 战略到底是什么? – 人人都是产品经理, 医疗智能体·第2讲——合规护城河:等保、PIPL与HIPAA的架构实战 – 人人都是产品经理, 向量知识库五步法:从“答非所问”到“精准回复” – 人人都是产品经理, 鸿蒙PC三方库构建总指挥HPKBUILD(sha)库为例 – 人人都是产品经理, 何时该用LLM?AI产品经理的LLM设计指南 – 人人都是产品经理, 医疗信息领域的需求方、决策方、准入方以及关注点(二) – 人人都是产品经理, 即梦涨价:一场被误读的「傲慢」 – 人人都是产品经理, 面试AI PM必答题:Hermes和OpenClaw的区别,如何讲清楚业务价值 – 人人都是产品经理, AI的下一张船票:世界模型——AI产品经理必须理解的技术拐点 – 人人都是产品经理, 小红书做GEO,怎么让AI信你?记住这 3 个重要信息 – 人人都是产品经理, 5 家印度 AI 初创公司,看看印度 AI 再做什么 – 人人都是产品经理, AI项目跨团队协作:产品技术业务如何不打架 – 人人都是产品经理, Agentic Workflow(智能体工作流):让AI从”答案生成器”变成”数字员工” – 人人都是产品经理, lycium_plusplus 项目全景解读:OpenHarmony 三方库构建的“大管家” – 人人都是产品经理, 从爆单救火到前置履约:两套预采策略,把生鲜大促履约效率拉满 – 人人都是产品经理, 什么时候该补货?我用一轮数据做了一个决定 – 人人都是产品经理, 从“机械兜底”到“动态分流”:AI客服重复进线治理的4大底层逻辑 – 人人都是产品经理, 抖音拼效率,红书拼洞察 – 人人都是产品经理, 全民狂欢与退潮——为什么龙虾这波热潮冷却得如此之快? – 人人都是产品经理, Stripe押注!MPP重塑全球支付 – 人人都是产品经理, 小红书GEO:AI引用你的内容,不是因为你对,而是因为你看起来可信 – 人人都是产品经理, 前百度副总裁押注办公Agent,日韩付费爆发,Manus迎来强劲对手 – 人人都是产品经理,
不适合做AB实验的场景下,如何做出有品质的产品决策?
骆齐 · 2023-04-20 · via 人人都是产品经理

虽然AB实验是一种很直接、公正又简单的产品验证方式,但在现实中无法做A/B Test的情况又蛮常见,这种情况下该如何做出合理的产品决策呢?本文作者整理了一些AB实验之外的产品验证方法或流程,希望能给你带来一些帮助。

虽然AB实验是一种很直接、公正又简单的产品验证方式,能够协助 PM 们通过数据进行决策,但在现实中其实「无法做 A/B Test」的情况又蛮常见,在这些情况下我们该怎么依然有凭有据的做出合理产品决策呢?

我整理了一些AB实验以外的产品验证方法或流程,希望能帮助大家通过数据决策。

01 哪些状况不适合AB实验?遇到这些状况该怎么办?

除了公司没资源没有实验架构、老板不给时间这些原因以外,这四种情况也不太适合做AB实验,以下随场景附上推荐的解决方案:

状况一:流量太低

当产品每天只有千位甚至百位活跃用户,A/B Test 分组下去一组只剩几百甚至几十人,这样的情况通常不适合做那种改一点按钮颜色、改一点文字翻译的小步快跑 A/B Test,因为如同大家所知,样本太少时并不容易达成统计上的显著。

推荐方法:定性研究为根基的「大步跑」

一个 A/B Test 若样本数多、产品改动的影响大、时间跑得长,就越容易达成统计上显著。所以其实低流量也不是什么问题,只是那些线上样本计算机会跟你说「你的实验只要跑 5487 天就会有显著结果哦!」。

现实中我们当然不可能乖乖等 5487 天,通常都希望在几周内可以看到结果,才好做下一步的产品规划,所以这个时候我们可以尽量把产品改动的规模扩大做大,放弃小步快跑来个大步跑,若带来的影响够大,自然也会更容易达成统计上的显著。你可以试试这样做:

  • Step 1:为了降低大改带来的风险,执行扎实彻底的用户研究。
  • Step 2:规划大改动(例如整页信息架构调整,前后流程调整等等)。
  • Step 3:改动上线后通过其他反馈工具来做验证,例如使用 NPS 工具,在产品内嵌入简单的问卷表单,与客服协作获得反馈等。还是可以试着跑跑看 A/B Test,如果效果不错影响面够大也是可以获得统计上显著的。
  • Step 4:若还是想得到量化信息,可以考虑在未来产品流量提升之后,进行 Blackout Experiment 来观测。所谓 Blackout,就是将某个已上线的改动或功能在实验中暂时关掉,看看这些改动或功能是否真的有影响。

除了这种「扎实版大步跑」以外也有一些其他方法手段,我会在下一大段落中一并分享其他在低流量产品身上也能使用的产品实验设计方法,有兴趣的朋友可以滑动到底下阅读。

状况二:ToB 产品

当你的产品用户非一般消费者、而是天天要用你的产品工作的「专业使用者」或企业,比如说用 POS 系统点餐的餐厅店员、用饭店管理工具后台确认订房付款状况的饭店柜台等等,他们已经习惯按钮颜色、位置、功能,需要一致的体验,可能也经不起你三天一小改五天一大改、无法预期的产品实验。

推荐方法:利用 Beta program 进行快速回馈与沟通

可以试着和几个关键用户讨论看看他们是否愿意加入「新功能抢先用的」 Beta program,以他们为主要用户研究对象、访谈、规划与开发产品,开发后的新功能与改动再先利用 Beta program 上线,以获取早期回馈。

等到这些功能与改动比较成熟稳定,再开始对其他用户做中大型规模的 A/B Test 来做最后的验证。这样的话就可以降低对用户的干扰程度,也较好对 Beta program 用户们做预期管理。

状况三:新产品

新产品除了跟流量低的产品有相同问题以外,相较于成熟产品,MVP 和理想的商业模式通常差比较远,产品本身体验和用户真正的需求落差也可能更大,在这个时候若还坚持每次只改动一个变量、慢慢用 A/B Test 当成唯一验证手段,或许也不是最有效率的方式。

推荐方法:定性研究与规律用户测试为王

在新产品的阶段,基本上和状况一的低流量一样,需要更多市场研究、用户研究、竞品研究等信息来提供洞见,以及通过反馈工具与客服状况来了解上线后的效果。

尤其在 MVP 开发阶段,由于产品根本还没上线也毫无 A/B Test 的可能性,建议安排规律的(每个月或甚至每周)User Testing,利用手边的原型去获得早期回馈再来做产品调整,就不用等到上线之后才崩溃的发现都做得不对。

另外以早期产品来说,除了易用性与功能,也建议要持续验证整个产品的商业模式,打好基础,同时收集能够应用在未来产品路途上的信息。

状况四:难以测量的体验或易用性提升

在大部分情况下,提升易用性、增加便利性还是可以被测量的,但我之前曾遇过一个我真的不知如何测量的状况:我们想改善照片编辑 App 的操作手势,我和设计师在长按、双点击、一长一短点击这种常见手势该搭配什么对应功能之间纠结,长按该把照片往底部推?还是编辑照片?还是拉到最上层?这个其实我到现在还没想到可以跑 A/B Test 的方法(有想法的朋友欢迎跟我分享),因为这件事的验证牵涉到用户手势意图,是数据很难告诉我们的信息。

推荐方法:大样本定性研究

一般的用户研究会测试五位用户左右,因为根据研究计算,只要测试五位用户就可以看出行为模式、涵盖大部分的痛点。这里我所谓的大样本是指比平常用户研究数量还多两三倍的d研究,之前的经验是我们从咖啡厅、路上、办公室等地对 10–20 位用户做了易用性测试,确实记录每个动作、手势、使用流程与背后的动机和意图,再画成表格比较优缺点。

在做这件事情的时候一定要很小心,确保:

  1. 受测者涵盖你的目标用户区隔
  2. 询问的方式不带引导性
  3. 详细记录比较用户的意图以获得最公正的信息。

02 六招低流量产品也适用的产品实验设计方法

如果你的产品整体其实有些流量,但你只负责一部分的产品或注重某个国家或区域,这里提供六个步骤帮助你设计一个「测得出结果」的 A/B Test:

1. 找流量

哪里有流量就往哪里实验!可以合并不同的用户区隔增加样本数,或者选择在产品流量较大的页面做实验。(以电商为例,可以尽量在流量较多的如落地页、搜索结果页验证你的产品假设,避开那些结算流程的末端)

2. 将统计功效(Statistical Power)纳入优先级的考量

在排优先级时,选择样本数多、Base conversion 低、预估影响力大这些「能够被 A/B Test 验证的」功能。可以利用线上的统计样本计算机,先设定自己「最多可以接受实验跑多久」的目标再反过来计算需要的样本数。记得在做这件事情之前,要先向伙伴说明为何实验很重要、为何统计显著很重要等等,让团队都可以理解排序背后的意义。

3. 以创造更大效益为目标扩大改动规模

停止那些改一点按钮颜色、改一点文字翻译的小步快跑 A/B Test,以创造更大效益为目标,花时间去研究怎么开发中大型但有意义的改动。但同样的这个做法风险也比较高,记得搭配扎实的事前准备与研究来使用。

4. 把时间和资源移到开发前的研究与早期验证

既然数据还无法提供证据,那就用定性研究与反馈来了解用户行为与动机,这些洞见同时也可以成为产品长大后很好的实验素材。

5. 延长实验时间

如果可以接受,也可以将实验时间设定比较长,一样可以用上面提过的样本计算机得出合理 Runtime。但记得跑多久这件事一定要在实验开跑前就规划好,一旦确定,就算提早看到成效也不要把实验提早结束,也不要为了看到结果就无限延长,因为那都很有可能是错误的结果。

6. 重新思考目标指标

如果 A/B Test 中的主指标一直不见效,有可能是因为指标本身很难撼动,可以试着找找其他较容易观察成效的先行指标。但这件事情跟方法五一样,也最好在实验前就先规划好,不然如果只是到处翻找显著改善的数据指标,一样很有可能是错误的。

03 结语

其实在不能做 A/B Test 的情况下,许多的替代方案都是结合定性研究、反馈收集来获得决策需要的「证据」。

一个有品质的产品决策,最重要的就是有清晰的脉络与有说服力的原因来告诉你的团队、你的主管和你的用户「为什么」这是个正确的决定,而这些原因都必须要被某种公正证据支撑着。PM 或设计师所要做的,其实也就是因应不同状况、找到对的工具、收集足够的信息来做合理决策。

就说这么多。

专栏作家

骆齐,公众号:骆齐,人人都是产品经理专栏作家。分享产品思维、商业思维、职场之道、个人成长相关内容。拉开人生差距的是你的认知深度。用文字酿一杯红酒,和你共饮,回味悠长。

本文原创发布于人人都是产品经理,未经许可,禁止转载

题图来自 Unsplash,基于CC0协议

该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。