将一个App应用从1.9分提到4.5分，需要做些什么？

各类应用商店评分的重要性，不言而喻。评分低下会影响排名，二排名影响的是下载量和下载速度，最终影响商业结果。

运营过一个C端产品的人，大抵都了解在应用商店里评分的重要性。评分能影响应用在商店里的排名，以苹果商店为例，想进入某个分类的前1000名，4分是一个最基础的准线。排名进而影响的是下载量和下载速度，最终影响商业结果。商店评分的重要性，不言而喻。

前不久每日优鲜的评分翻车事件，说起来也特别好笑——更新文案中跪舔996，引起大量用户反感（或许用户大部分都是程序员），导致各路商店里每日优鲜被疯狂diss，好好的4.5分被刷成1.3。本想抖个机灵，结果一夜回到解放前。

那我们的应用是怎么了，怎么就到了1.9了？

事情得从一年前说起。

2018年7月，我们以产品演进的形式，承接了一个基于音频学习的外语学习移动产品，用户主要分布在北美，有一定的群众基础。

接手时，项目已经上线，总体功能还算可以，但效果不是很理想，主要表现为：

• 市场反应差，苹果商店里评分仅为1.9；
• 用户反馈的信息很杂乱，难以追根溯源；
• 想优化，不知从何入手。

于是有了下面一段对话：

老板，愁眉苦脸：这怎么弄啊？这评分实在太让人沮丧了！我：你想要到多少分？

老板，毫不犹豫：越高越好！

我：你先冷静一下！

评分低于2.5，大部分还是应用本身有问题，于是我们有了第一阶段：

2018年7月-2018年11月：维稳

这一阶段，我们主要解决的是bug和性能问题。

轻易能复现的bug易解，众说纷纭的性能问题难调。性能问题里，首当其冲的，就是应用崩溃。

我们用google firebase来收集数据，当时的崩溃率在6%左右，用户关于应用崩溃的抱怨也层出不穷。经过调查，我们着实发现些可以修复的事情，技术人员加紧步伐，争分夺秒地迭代了几个版本后，崩溃率和相关抱怨有了非常明显的降低。

经过技术评估、行业对比，我们做了信息拉通：

• 我们这款应用，因为是音频类的应用，它的崩溃率就是会比纯文本类的应用高一点；
• 因为我们采用的是react native的技术栈，在安卓机上的表现就是会比苹果机差一点；
• 经过我们近期4次版本线上数据的分析统计，我们认为， 安卓崩溃率在3%、苹果崩溃率在1%，是我们合理的性能指标。

在以后的迭代中，如果发现崩溃率到达警戒，则我们要尤为重视。

图例1: 安卓设备上crash free rate

三个月后，我们的评分已经悄然升到3分。

启发一：数据，相互比较，才有意义

起初，我们没有数据，不知什么样的表现才让人安心。通过一段时间的运营、迭代，有了各种比较，才正确地建立了我们的安全指标。有了这个指标做指导，我们的工作才更加有方向。

3分不是任何人想要的终点，我们在寻求下一步的改变。

2018年7月-2018年11月：求变

应用商店里的评分，大家想来也知道会有很大的随意性：

阿西吧，居然要收费？差评！

咋没有智能问答？差评！

劳资今儿心情不好，差评！

在对这些评价置之一笑的同时，我们也在尽所能地分析总结，看有什么是我们能解决的。但有一个很明显的问题困扰了我们：评论信息太少，我们难以定位。一线客服是兼职的，能提供的信息非常有限。

于是，我们增加了一个新的功能，应用内评价：

• 摇一摇，报告问题；
• 适当地弹出调查，给高分的，引导到商店去评分；给低分的，填具体信息反馈到后台。正所谓： 我们做的好，请告诉全世界，做的不好，告诉我们。

这个功能效果显著：

• 一来为用户提供了情绪的出口，让他们更加方便地吐槽、抱怨，而不用去商店里发泄；
• 二来我们能在后台统计到用户使用的机型、系统、版本、甚至是都做了什什么操作。

图例2：应用内评价及后台系统

通过这些数据，我们得到很多有用的信息，比如：

• 我们一直没有做iwatch的适配，我们发现反馈来源里暂时没有iwatch，那么iwatch的适配就暂时被放在低优先级，不急于处理。
• 有人反馈说，音频播放的按钮不灵敏。我们试了试，没能复现这个原因。设想可能是个别问题，比如他网络不好，或是手机问题；后来有更多用户来反应同样的问题，那么这个问题便不容小觑，优先级大大提升，我们必须马上做测试、检测、系统优化。

到了2019年1月份，我们的评分已经渐渐上升到3.8分，着实令人欣慰。

启发二：数据，能帮助我们厘清优先级，正确分配资源。

我们预算有限，团队规模不允许我们做大而全的事情。

其实，任何一个项目的预算都有限，如何把钱花在刀刃上，可能是每个项目都要考虑的问题。我们无法在短时间里做到十全十美，数据可以帮我们度量事务的重要性，在迭代增量中，争取最大的商业价值。 四两拔千斤 ，说的可能就是这意思。

2019年1月-2019年3月：演进

系统稳定了，功能也增强了，是时候谈谈产品该如何演进了吧。

我曾做过很多设想，比如做一个类似英语流利说那种语音智能打分？让用户自己创造内容？初步做了个估算，哪一项都得个一年半载的。

这个时候，我们也有了更多更稳定的数据来源：

• 系统运维数据：firebase的崩溃统计；
• 用户行为数据：firebase的事件埋点；
• 用户反馈数据：苹果／谷歌商店的评论及评分、应用内评价；
• 商业统计数据：苹果／谷歌后控制中心。

通过对这些数据的分析和比较，我会得到和之前认知不太一样的结果——比如说，我常听说商业级产品会有相对集中的用户行为，因为他们有相同的文化、流程等，而用户级产品没有。真的没有吗？

这款产品在20年前卖的是CD，用户就喜欢在开车的时候听点外语，美国地广人稀，无网又是常态，那么这种场景就是这款app的重要用户使用习惯，通过事件点击数据，我们也能得到一致结论。

图例3：音频的使用的周期性，波峰出现在工作日，波谷出现在周末，每个周期出现的规律大体相同，可以推断用户大多数会在通勤时使用该应用。

那么， 蓝牙、下载、车载配置 ，就是用户最最需要的特性，而在最初的设计中，这部分功能是缺失的，导致相当一部分用户在反馈这个问题。如今，现在便是产品演进的最好时机。

小步快速地演进了上述功能后，在今年3月初，我们的app已经升到了4.5分，得到了用户更高的满意度。用户满意了，又怎样呢？下图是苹果商店里销量的走势图。

老板再也不是愁眉苦脸的样子了，他们现在更热衷于讨论产品如何进一步优化升级。4.5分不是一个终点，无论在用户量扩大、还是产品体验上，我们还有很长的路要走。

启发三：数据，能帮我们纠正认知偏差，回归客观事实。

我以前做项目交付，对产品总是存在一些假想，认为应该是这样这样。

如今明白，基于验证的结果，才更为可信。

基于验证的学习策略，是精益创业思想的核心理念之一。基于此理念，Eric Ries定义了“度量——学习——构建”的验证式学习循环。

如何验证，数据是最为恰当的手段之一：有针对性地埋点，对产品进行数据度量，通过定性定量分析，学习数据带来的结果，去伪存真，形成客观认知，进而构建新一轮的迭代增量——以此来践行产品演进，或许再适合不过。

作者：刘瀛州，ThoughtWorks咨询师，个人公众号：圆周江湖。

本文由 @刘瀛州 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自Unsplash，基于CC0协议

作者暂无likerid, 赞赏暂由本网站代持，当作者有likerid后会全部转账给作者（我们会尽力而为）。


Support author:
Author's Filecoin address:
Or you can use Likecoin to support author: