你需要一个能够监控你应用质量状态的工具，请外包花的钱，必须对质量有所要求，比如Crash率低于多少，个别Crash对用户的影响有多大，都是要去关注的。不是开发说一句“这个错误影响小”你就可以忽略的。开发不是喜欢“用数据说话”吗？你就让他看数据呗！
上周我在逛知乎的时候，看到了下面这个问题《作为产品经理 如何对应用的质量状况进行监控》，问题描述如下：
我是一个移动应用的产品经理 目前负责一个有几百万用户的应用 最近上线了一个新版的产品之后 在用户群里面收到一些用户的反馈 表示使用过程中容易卡 有的甚至闪退 我将这个问题反馈给我们开发同学之后 他说这只是个别情况 不需要理会 目前他正在提离职 一个月后就走 我觉得他有点心不在工作上了 一切需求都是在敷衍 我需要怎样才能知道开发说的是不是真的呢 突然意识到自己对应用的质量有点失控了。
这个问题把我拉回了之前一段痛苦的经历：产品规划做好了，发布时间也定好了，但是移动开发工程师一直还没有招到，因为战略原因，必须在定好的时间发布这一款应用，实在找不到人了，只好去找外包开发同学。给我们做应用的这位同学也是兼职做外包的，有自己的本职工作，非常忙，在这样的背景下，我和他的拉锯战就这么开始了。
那个时候，每次拿到包，我都会去内测用户群里面让大家体验，然后收集用户反馈，整理后发给这位开发同学，经常会遇到一些无名的crash，我这边无法重现，于是开发同学就不去解决了。但是每次更新包拿给用户体验后，都会发现总有几个用户的机型会重现这个错误，这个crash的一直未修复，已经引起了他们的不满。
但是开发同学说：那只是个例，影响不大。我竟然不知道该怎么反驳他。
这几个用户使用的机型是现在市面上流行的机型，而直觉告诉我，这绝不是个例。
1、几个你需要关注的与质量相关的指标
Crash次数：在选定的某段时间内，应用程序报错的次数；单纯只看这个数字没办法看出什么问题，这个错误次数要跟错误覆盖人数、活跃用户数、用户留存率等指标进行重叠查看。
Crash覆盖人数：指的是在选定的某段时间内，应用程序报错的设备数，这个指标就很能说明问题哦，如果这个指标很大，就说明你的应用的质量问题已经影响很广泛了，用户这个时候可能已经准备卸载你的应用并且上社交网络叼你了。
微信扫码上方二维码，可领取2025年最新互联网创业项目！
项目收款截图
