对于 APP 来说，一个好的评分无疑会在商城内有一个更高的排名，那么该怎么去提升自己的 APP 商城排名呢？下面就和大家来聊聊吧。

评分能影响应用在商店里的排名，排名进而影响的是下载量和下载速度，最终影响商业结果。重要性不言而喻。

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

前不久每日优鲜的评分翻车事件，说起来也特别好笑——更新 WordPress 文案中跪舔 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 分。

启发一：资料，相互比较，才有意义

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

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

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

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

阿西吧，居然要收费? 差评!

咋没有智慧问答? 差评!

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

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

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

摇一摇，报告问题;

适当地弹出调查，给高分的，引导到商店去评分; 给低分的，填具体资讯反馈到后台。正所谓：我们做的好，请告诉全世界，做的不好，告诉我们。

这个功能效果显著：

一来为用户提供了情绪的出口，让他们更加方便地吐槽、抱怨，而不用去商店里发泄;

二来我们能在后台统计到用户使用的机型、系统、版本、甚至是都做了什什么操作。

通过这些资料，我们得到很多有用的资讯，比如：

我们一直没有做 iwatch 的适配，我们发现反馈来源里暂时没有 iwatch，那么 iwatch 的适配就暂时被放在低优先顺序，不急于处理。

有人反馈说，音讯播放的按钮不灵敏。我们试了试，没能复现这个原因。设想可能是个别问题，比如他网络不好，或是手机问题; 后来有更 WooCommerce 多商户来反应同样的问题，那么这个问题便不容小觑，优先顺序大大提升，我们必须马上做测试、检测、系统优化。

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

启发二：资料，能帮助我们厘清优先顺序，正确分配资源。

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

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

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

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

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

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

系统运维资料：firebase 的崩溃统计;

用户行为资料：firebase 的事件埋点;

用户反馈资料：苹果/谷歌商店的评论及评分、应用内评价;

商业统计资料：苹果/谷歌后控制中心。

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

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

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

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

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

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

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

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

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

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

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