由一个问题引发的回忆
我是一个移动应用的产品经理 目前负责一个有几百万用户的应用 最近上线了一个新版的产品之后 在用户群里面收到一些用户的反馈 表示使用过程中容易卡 有的甚至闪退 我将这个问题反馈给我们开发同学之后 他说这只是个别情况 不需要理会 目前他正在提离职 一个月后就走 我觉得他有点心不在工作上了 一切需求都是在敷衍 我需要怎样才能知道开发说的是不是真的呢 突然意识到自己对应用的质量有点失控了。
这个问题把我拉回了之前一段痛苦的经历：产品规划做好了，发布时间也定好了，但是移动开发工程师一直还没有招到，因为战略原因，必须在定好的时间发布这一款应用，实在找不到人了，只好去找外包开发同学。给我们做应用的这位同学也是兼职做外包的，有自己的本职工作，非常忙，在这样的背景下，我和他的拉锯战就这么开始了。
那个时候，每次拿到包，我都会去内测用户群里面让大家体验，然后收集用户反馈，整理后发给这位开发同学，经常会遇到一些无名的crash，我这边无法重现，于是开发同学就不去解决了。但是每次更新包拿给用户体验后，都会发现总有几个用户的机型会重现这个错误，这个crash的一直未修复，已经引起了他们的不满。
我竟然不知道该怎么反驳他。
Crash覆盖人数：指的是在选定的某段时间内，应用程序报错的设备数，这个指标就很能说明问题哦，如果这个指标很大，就说明你的应用的质量问题已经影响很广泛了，用户这个时候可能已经准备卸载你的应用并且上社交网络叼你了。
每次启动的Crash次数：在选定的某段时间内，你的应用平均每启动一次会出现多少次错误，计算方法：Crash次数 / 启动次数。这个字数越小越好。
接下来以腾讯云分析的报表作为例子来解读这些指标。
可以看一下下面的这个图，从这个数字可以看到这个应用昨天错误次数有208，错误覆盖人数/设备是84，还好每次启动错误的次数仅有0.0686。但是我们看一下错误覆盖活跃用户占比，达到了1%，也就是每100个经常使用我们应用的用户（活跃用户）里面，有1个人就会发生错误。活跃用户是我们需要重点去维护的群体，有一句话叫做“好事不出门，坏事传千里”，一个应用用得好，用户可能不会在社交网络上去发声，但是如果一个应用给用户带来了不好的体验，那么他会有很大几率去社交网络上去发泄。
如何判断错误是个例还是普遍存在
于是我在那个诡异的crash上进行了标注（需要注意），然后又在公司内部跟同事找来了错误频发的那几个机型，然后把内测群的那几个用户都细细询问了发生错误时的具体操作。接着设置了一个告警，然后，安装上我的应用，连续在10台手机上按照用户描述的步骤进行操作。很快，QQ弹窗、微信推送、邮件push的提示声同时响起，我的嘴角不由地浮起了一个微笑：我是对的！！！（有没有觉得我好贱啊好贱啊哈哈哈）
（1.备注错误）
A:在关键的环节埋点统计，不管是我方还是对方，都要对双方进行统计。统计的项主要有：app在活动期间的增长量、活跃量、活动页面的pv、uv，建议尽量使用第三方的统计工具、抽奖工具，是避免彼此作弊的一个比较好的方法。当然，这个统计平台的数据必须是双方都可以看到的，需要允许设置“仅查看”。（我用的是下图这个工具，关注人仅有查看权限)
Q：感觉现在很多平台带量能力都一般（竞争激烈），楼主有没有尝试过线下渠道的曝光拉量？效果如何？
A：线下渠道其实效果不是很好。不过如果你参加的那个线下活动，有搭配一些媒体资源，会把这个活动给沉淀下来，并且给予连续的报道，那么这样的线下活动是值得去参与的，比如36氪的开放日。
Q：我们一直在尝试微信内容分享拉量，内容质量好的话，传播效果挺明显的，不过一定要跳出微信用浏览器下载这一步消耗非常大，有没有什么办法可以规避或者提升用户的动力？
Q：交流群骚扰信秘太多，效果不太好，有没有一些定期的圈子活动？感觉线下认识的人更靠谱，关系也好维系
A：交流群可以设置屏蔽关键词，当有群聊提及这个你关注的词的时候，就会提示你，你就不会错过消息（还是要善用工具啊亲爱的）。其实最好维护的还是线上，至少你不用请吃饭、不用喝咖啡、不用到特定的时空去会面、维护。线上的，几句亲爱的，几句你的产品真棒，就很容易拉来话题，形成小圈子。
去年今日运营文章
- 2023: 学习的最新揭秘(0)
- 2023: 真正厉害的职场人都善于向上管理(0)
- 2023: 老板问我，完全没有用户历史行为记录，怎么做推荐？(0)
- 2023: 老板问我，什么是基于内容的推荐？(0)
- 2023: 2023年做小红书必备的10个模型(0)
原创文章，作者：爱运营，如若转载，请注明出处：https://www.iyunying.org/social/app/2377.html
