5亿用户的墨迹天气如何用A/B测试实现分享率18%提升 | 最佳实践

“嗯,这次安卓平台的分享图标变得和iOS平台的一样了,我觉得挺好的,提升了不少逼格,现在每次打开APP看天气或者新闻时,都有种莫名点击右上角去分享的冲动哈。”

 

“整体布局变得更流畅了,看新闻或者看具体预报可以同时在首屏完成,现在我很少开其他新闻类APP,有时候看天气时候顺便就在这里里看看新闻了,挺方便的。”

 

以上是墨迹天气在前阵子发布6.0版本更新后,安卓平台的产品经理 Moke 做回访时收到的用户反馈。

%e9%bb%98%e8%ae%a4%e6%a0%87%e9%a2%98-%e8%ae%be%e8%ae%a1%e5%88%9b%e5%bb%ba%e4%ba%8e%e5%88%9b%e5%ae%a2%e8%b4%b4-4

作为目前国内提供最专业、最稳定的天气查询服务的生活类应用,墨迹天气始终将用户体验作为产品迭代中的首要考量,经历了几次改版之后,产品中逐渐添加了更多促进用户互动以及与生活息息相关的服务内容,进而不仅仅再是一个简单的天气查询工具,成为了用户生活中的一部分。

 

这次6.0的版本更新花费了他们的大量心血,它包含了很多新增的服务栏目以及优化体验的细节,为了追求极致的用户的体验,他们在上个季度,几乎把所有运营和研发资源都放在完善这个版本的工作上了。

 

“这次版本迭代后的用户反馈基本符合我们之前的预期,在全面完成这个版本的数据分析后,我们应该可以发现更多可以优化和提升的元素,到时候我们还是照例根据已经定好的流程去做评估,之后会约数据团队的同事讨论哪些优化元素可以通过A/B测试去验证。” 似乎对于产品的负责人来说,这个版本的所取得成功在发版之前就已经可以确认。”

至于为何他们可以这么自信,还要追溯到当初他们和A/B测试的那段姻缘。

 

“在你的用户量级积累到日活千万级别的程度时,在产品迭代的时候就需要非常小心了,因为一个微小的改动,往往会带来巨大的用户影响,那个时候,用户反馈也不能完全做参考,很有可能一个提升这部分用户的改动,却带来了另一部分用户群体的流失。”

 

“在这个阶段,A/B测试的引入是非常有必要的,除非你想闭着眼睛撞大运。我们之前和国外的 Optimizely 以及 VWO 都有有过深度沟通,但是他们的价格太贵了,也没有本地化的服务。我们也尝试过自建一套系统,但是在尝试了一段时间之后就放弃了,因为涉及到统计算法的话,需要考虑的问题实在是太多了,在搭建过程中会有很多额外的成本;国内要能有做AB测试的第三方服务商,我们一定会尝试。”
这是我们做用户回访时,来自墨迹管理团队的反馈。

 

和吆喝科技一样,墨迹天气一直都是数据驱动决策优化的追随和实践者,无数据,不增长。作为 AppAdhoc 早期种子用户之一,墨迹天气的管理层在接触 AppAdhoc 之前就对A/B测试有了一些了解;他们当时一直在寻找第三方的服务商,在了解 AppAdhoc 公开招募种子用户后,就第一时间注册试用了。

 

和所有首次接触A/B测试的用户一样,墨迹的产品以及研发团队在最开始并不太了解A/B测试具体是什么,更不用提它对产品增长有怎样的含义了;但是管理团队当时最担心的并不是这些问题,而是他们的技术团队是否可以顺利创建第一个A/B测试并完成代码层面的集成工作。
“当初的担心看来都是多余的,你们的CSM团队在最开始就介入了,他们专业的服务完全打消了我们的顾虑,从前期的理论知识培训、业务对接,再到SDK集成,试验落地,整个试验周期中,他们几乎整天都在和我们的产品和技术团队一起协作,这大大减少了我们在前期的学习和试错成本。”

 

在完成了一些简单的试验后,墨迹的产品团队逐渐看到了A/B测试的价值;通过 CSM 团队的培训以及案例分享,他们也学习到了很多宝贵的实践经验;在这之后,他们开始尝试将大家之前争论的产品元素做成试验假设,让数据去验证谁的想法是被用户认可的。

 

在当时,他们印象最深的就是一个关于安卓应用分享图标的试验。在这个试验中,他们发现了一个非常有意思的现象:如果将安卓版的分享的图标换成苹果风格的话,分享率会比其他版本提高近18%!

灰度发布

试验里包含了目前线上版本的图标,另外还选了三个样式进行测试,试验版本通过改变分享图标提高用户在端内的分享率。从最后的分享数据比例看,方案 3 是获胜方案,更容易获得用户的点击。比控制组方案 1 提高了 近18%的分享率。

 

墨迹目前是千万级别的日活,这个提高带来的,可不仅仅是分享率这个数据的增长。

 

“看来安卓用户对苹果风格的分享图标也有着独特的情怀啊。”墨迹的产品团队在看到这个增长后,很是兴奋。

 

然而,在产品和技术团队专注测试的同时,管理层也看到了新的问题:由于没有固定流程和长期的试验规划,每次试验感觉都不是沿着一个规划好的方向去进行的,试验完成后虽然拿到了用户认可的版本,但还是觉得缺了点儿什么。

 

如何将A/B测试完整融入到产品迭代流程中呢?

为了可以尽快帮助墨迹将A/B测试融入整个产品迭代的流程, AppAdhoc 的 CSM 团队在深入了解各个部门的分工后,给出了自己的建议。
在之前的分享活动中,各个部门都对A/B测试有了一定的了解,而且流程中的角色,也是按照各自的分工去定义的,所以这个流程很快就落地执行了。现在,每次发版之后,各个业务线的产品经理都会在数据分析时和数据增长团队的同事进行讨论,看看哪些环节适合通过A/B测试去验证;确定之后,研发团队根据产品排好的周期,按照标准的文档去做代码集成。如果有同学想了解之前的试验数据,公司的内部网络也有详细的历史数据和试验方案提供参考。

 

“A/B测试最大的价值,就是每次发版时候不用再提心吊胆了。因为在发版前,用户已经告诉我们答案了。”

——墨迹数据增长团队负责人 Charles

 

这就是为何他们可以这么自信。

 

其实我们回过头来看,任何重视用户体验和精细化运营的产品团队都可以复制这个模式。

 

我们先来回顾一下流程中角色:

 

A/B测试的管理方:如果你有像墨迹天气那样独立的数据驱动团队,那他们是承担这个角色的不二人选;没有也没关系,产品经理或者运营也可以承担这个角色,它在整个测试过程中主要负责试验计划管理、数据解读、协调内部资源等。

 

A/B测试需求方:一般由产品经理担任这个角色;产品经理在定期的数据分析和需求评估时,都应该可以发现一些产品提升空间,如果在其中某个产品元素的讨论上大家各执己见,那么就可以通过A/B测试去进行验证。

 

代码集成方:既然是和 SDK 和代码相关的工作,交给研发团队就没错了。

 

试验调试与技术支持:AppAdhoc CSM 团队会帮助你解决在测试过程中出现的任何问题。
了解完各自分工后,我们可以结合下图理解每个角色在整个流程中所负责的工作:

A/B测试需求方(产品团队)在做数据分析或者需求评估时,确认产品优化方向以及产品改进建议。

 

CSM团队提供专业性建议,帮助A/B测试需求方确立哪些因素可以通过A/B测试去优化和验证。

 

试验方案确认后,A/B测试的管理方根据产品排期,确立A/B测试项目实施计划与相关日程。协调技术团队进行A/B测试方案的研发和SDK集成,以及包含测试代码应用的发版工作。

 

A/B测试的管理方按照计划管理试验进度、在试验过程中与CSM团队保持有效沟通,在试验后期进行数据解读;之后将产品迭代的可行性建议回复给A/B测试需求方,作为正式版本迭代前的最终参考。

 

将通过A/B测试验证的版本,直接在AppAdhoc A/B测试平台推送给所有用户,如果有单独的发版计划,也可以把它放到后续大版本迭代的更新计划中。

 

把这个流程结合产品迭代循环利用起来,你的产品,也可以这么自信。

 

本文作者:吆喝科技客户成功专家傅礼阳。

 

吆喝科技:国内唯一同时支持前端(Web/H5、iOS、Android)及后端(Node.js、PHP、Java 等) A/B 测试服务的专业 SaaS 平台。支持线上灰度发布、多维度数据统计分析、科学的流量分配系统、一键发布新版本无需应用市场审核、定向测试。

用数据帮助用户优化产品,提升转化、留存和你想要的一切。 AppAdhoc 用数据验证最佳方案,提高产品设计、研发、运营和营销效率,降低产品决策风险。

8370 Views
即刻实践文章理论 A/B测试 灰度发布 产品优化 免费申请
Please wait...

订阅我们

对于每位订阅读者,每两周,吆喝科技会为您发送4篇精选文章,可能是最新的A/B测试实践,也会是你所期待的增长干货。