从3个角度分析吐个槽

小提示：您能找到这篇{从3个角度分析吐个槽}绝对不是偶然，我们能帮您找到潜在客户，解决您的困扰。如果您对本页介绍的从3个角度分析吐个槽内容感兴趣，有相关需求意向欢迎拨打我们的服务热线，或留言咨询，我们将第一时间联系您！

“吐个槽”是一个帮助APP等应用快速搭建反馈社区、2B的服务，涉及三个角色：用户（C端）、开发者（B端）、平台。以下行文就按照这三个维度来讨论。

用户

首先来看问题：用户反馈问题的目的是什么？是不是为了解决问题？所以如何让用户快速解决他遇到的问题才是关键点。

现在用户可以通过查看常见问题、发帖、填写反馈来尝试解决问题，如下图：

用户的操作路径清晰，那么：

• 当用户阅读常见问题后，多大个概率能解决？
• 当用户发现常见问题无用时，下一步要如何？
• 当用户反馈的问题已经存在答案，如何让用户尽快看到？

所以为了能够尽量快速解决用户问题，我们是否可以增加一点逻辑优化该流程，如下图：

• 当用户带着问题来到反馈页面，查看常见问题后点击“无用”时，应该建议用户去反馈，而不是展示“提交成功!非常感谢您的反馈, 我们将努力做到更好”。
• 当用户反馈时，随着用户输入的增加或者点击提交时，可以在已经被回复的帖子中找到相关的、有官方回复的帖子告诉用户，帮助其解决问题。

主动推荐相关已解决帖子的流程在平时反馈中也应该复用。通过以上流程的改变，增加用户尽快、自行解决问题概率。这种改变还有好的副产品：如果用户通过点击无用后再发起反馈，那么这个反馈有价值的可能性会更高。

其次，用户反馈是解决问题，所以尽量不要再制造问题，不要让用户反馈：这个反馈流程不好。反馈问题就是一个发表观点的过程，那么其交互逻辑是否可以与用户常用的发布朋友圈、发布QQ空间、发布微博类似？我们对比会发现，剔除隐私权限等设置，发布内容的交互是高度相似的，那么我们的反馈交互流程是否可以参考？

从这个点出发，选择分类是否可以滞后？

用户填写完内容后，我们直接推荐其属于哪个分类，因为这个是可以基于语义分析等算法获得；如果没有对应分类，算法进行概括一个新分类或者鼓励用户建立分类，然后再去提交，通过算法来降低反馈门槛。除流程的改变，反馈内容载体也应该改变。除了文字描述问题、图片、表情，有没有更方便用户表达、更能清晰阐述问题的内容表现形式？是有的。

• 用户是否可以用语音留言进行反馈？比如120S留言，一段留言中可以包含口音、情绪、节奏、语气等文字无法表达的内容；用户是否可以用视频反馈？
• 用户用文字叙述导致APP崩溃的流程会很复杂，但是通过几十秒的录屏来反馈，成本会大大降低。

上面谈到的用户反馈路径都是用户发现问题→寻找反馈入口→填写反馈内容→提交完成。“想到去反馈”这个动作是用户在遇到问题时，页面中不存在、用户主动思考产生，这个思路是跳跃，很多用户可能会放弃寻找和尝试，而不是想到去反馈。用户很多时候是喜欢被动的。

那这个问题我们要怎么处理哪？我们是否可以设计时间或路径规则，当用户触发时，就推荐常见问题同时提示可以反馈，比如：我们上线一个新功能，除等待数据反馈、用户主动反馈外，是否可以对使用该功能三次但未成功的用户，主动在页面上推荐反馈入口。

这就仿佛我们进入一家商店闲逛，而店员明确的发现在一个货架前徘徊许久，主动问我们是否有什么需要帮助，这也是一种降低反馈门槛的方式，也能够获得更多的高质量反馈。

以上是从降低反馈成本的角度来分析，接下来我们从让用户获得更多利益角度来看。

我理解红包就是这个目的，但是笔者认为红包效果不一定好。短期看，用户反馈后红包奖励让用户感觉被尊重、被重视、提高其参与感。

但是长期哪？用户提交反馈并获莆田小红书种草力荐佑微营得红包奖励，而第二次反馈却没有被采纳，用户会是什么心情？

就如让司机评价自己的驾驶技术，大部分司机认为自己的驾驶技术位于人群头部，但这明显不合理，所以人们往往都是高估自己的能力，当第一次被采纳，之后没被采纳或者没有红包时，这里面的失落和沮丧可能带来更多的负面情绪，甚至增加对这个APP整理评价下降的可能性。

如果我们还是想回馈用户，是否可以考虑奖金池？也就是说反馈的好坏只决定是否能进入奖金池，而进入奖金池后，能分得多少，就要看个人运气，运气是一个随机事件。

所以是否可以入池是一回事，入池后能否得到钱是另外一回事；而因为运气的存在，用户的得失心会被运气这个因素所影响，那么对APP整体的评价波动会小很多，同时因为是随机性的奖励，游戏感、趣味性、参与感都会有所提升。

在增加红包奖励的同时，虚拟荣誉奖励也是好的方案，比如：

• 我们可以在发版时告知用户：您当时提的***需求已在***版本上线；
• 可以在启动动画中加入一个感谢的画面；
• 可以在release note中写上用户ID；
• 可以有个反馈明星墙。

综上，用户反馈是为了解决问题，所以反馈要快速相应、流程简洁、有点奖励。

二、开发者

说完用户，我们再来看看开发者。开发者希望通过反馈来干嘛？是否是希望通过反馈来持续优化APP、满足用户需求、实现商业价值？

假设你是一个小区的水果摊摊主，

• 有一个经常来你这里买水果的小区用户A，还有一个仅仅是今天碰巧路过该小区来你这买水果的用户B，他们两个的意见，哪个更加重要？
• 两个人都是小区的住户，也都按照相同的频率来你这里买水果，一个人建议你要囤一吨苹果，另一个建议你应该供应一些其他品种的苹果，增加大家挑选空间，哪个更加重要？
• 一个小区用户每次来买苹果都反馈想吃偏酸的苹果，这个问题一年反馈365次，今天元旦，又和你反馈了一次；另一种情况是小区内的用户中有一部分人，每人仅反馈一次想吃偏酸的苹果；两个问题孰轻孰重？

这三个问题的答案是否清晰？那么在反馈平台上，一个反馈问题至少可以分两个层次来看：

• 第一层，哪类用户反馈的问题，重度用户、新用户、低频用户等；
• 第二层，反馈问题是否是已存在、同质化的问题，或者很情绪化而无实质的问题，如果是，反馈内容的价值会降权，否则需要提高权重。

而我们要优先处理哪些反馈问题哪？应该是总价值V最大的问题，即

V（总）= V （用户价值）* V（问题价值）

所以后台要让开发者能够发现V（总）更大的反馈是哪些，可以查看V（总）更大反馈的变化趋势是是什么，可以编辑定义什么是V（总）更大的反馈。这需要将反馈问题与用户数据关联，然后由开发者定义关键用户，由用户的反馈内容及开发者的反馈内容来定义问题价值。

基于以上的分析，我们看B端的后台，如下截图所示：

当前这些数据其中包含不准确和噪声，所以我们看到如下图可以提一些问题：

• 发帖下降，是否是V（用户价值）较高的反馈减少？
• 发帖下降，是否是反馈V（问题价值）较高的减少？
• 发帖下降，同时需要考虑是否是因为DAU下降？
• 回帖下降，是否是因为有些问题水分太多不值得回复？

为解决以上问题，需要用户数据与反馈数据的互通，那么如果APP开发者用了腾讯移动分析是否可以支持？这样通过用户数据加持来确定V（用户价值），通过用户数据及反馈内容分析来确定V（问题价值）。这样我们可以从反馈量变化的大趋势中发现更加关心的小趋势的变化，以便来分析现在做的如何、未来怎么做。

接下来再思考如下问题：

• 由不同渠道来的用户，在APP内的行为模式、价值贡献是一致的吗？
• 在不同版本间来对比，由于版本功能差异，是否会导致用户行为变化？
• 针对同一个功能模块，每次优化都能一定能产生正向效果吗？

基于以上示例，再看后台折线图，通过支持选择版本、用户类型、反馈类型、渠道，能更准确展现反馈问题趋势。比如：

• 我们对一个功能做AB test，除了对比渠道间数据外，也要对比渠道间的反馈变化；从数据反馈两条线来分析改版对整个APP的影响；
• 如果我们发现一个渠道的用户留存率相对高、反馈率相对高，那么我们是否可以认为这个渠道的用户是真爱粉，我们有新的想法可以先给他们尝鲜；
• 如果我们发现一个渠道的用户留存率在反馈数量上升而下降，那么这个渠道我们更加应该投放的是经过验证的稳定版本。

我们再看个“管理员回帖数”这个数据，如果判断其回帖是对用户有价值的？我们是否应该让发帖人可以对管理员的回答做评分，或者至少选择有用/没有，而不是仅仅靠回帖数量来分析这个问题。

同时，因为我们记录用户认为很有用的回答，而用户的问题也在我们的数据库中，我们就可以针对一些反馈给出推荐回答，此时管理员回答的效率将增加，因为可以从编写答案、复制粘贴答案变成选择答案。对于“常见问题” 和“ 反馈分类”，随着反馈数量上升，系统推荐筛选常见问题、推荐分类方案，管理员只需负责简单维护即可。

反馈列表中可以考虑增加一个指派给谁的功能，方便某位管理员遇到无法解决问题时提醒某同时关注，用户也能因此尽快得到反馈；同时我们考虑问题追踪机制，一个用户的反馈很可能就是一个需求的开始，那么反馈如何和已有的需求池建立连接，然后再通过需求管理将版本发布后告知用户与反馈系统的微信通知相关联？

这样就行程一个对C端提高参与感，对B端提高反馈价值效率的简单闭环，呼应用户分析部分的release note荣誉部分内容。

综上，开发者需要找到V（总）高的反馈，也要能通过反馈判断之前的工作结果和之后的工作方向。

三、平台

从这张图可以看出，平台就像一条必经之路，连接着两端，所以平台上的信息是最多的，因为他是一个枢纽。

那么从这个角度出发，我们可以尝试一下几点：

（1）反馈数据与应用排行榜结合

如果我们想去安装某类应用，该分类存在一个排行榜，是否会影响我们的决定？

我想答案是肯定的。那么当一个应用让用户感到不爽时，用APP本身的反馈来提供意见是不是算作影响榜单的一个因素？

所以我们可以试想下，使用“腾讯吐个槽”的APP，用户在吐槽平台的反馈可以作为一个参数来影响应用在应用宝中排行，比如我们以关键用户吐槽比率为一个指标，将该指标加入现有的排行榜的算法中，对不使用“腾讯吐个槽”服务，那么这个因素可以考虑不添加。

（2）反馈数据与行业结合

排行是一个应用分类的缩影，也是一个行业的缩影，所以可以做“共享反馈白皮书”，比如说这段时间用户对视频应用吐槽最多的是什么哪个模块、什么问题、占整体比率等，而我们自己APP又是什么情况，这是一个他山之石可以攻玉的参考，也是对用户需求方向变化的参考。

（3）从软件反馈服务，到服务大众生活

反馈是一个问答的过程，也是一个交流过程，而这个过程中随着数据收集的越来越抖音企业号与个人抖音号有多，那么问题有哪些、该用什么内容回答、那种回答更加有效等就很容易判断，现在语义分析和语音合成技术都相对成熟，可以将平台的数据进行扩展应用，比如做电话客服来解决、线上自动客服等。

写在最后

最后，尝试回答刚开始写这个文章时的一个疑问：为什么吐槽反馈的内容要建立一个贴吧社区哪？在写这篇文章的过程中，我想到一个类比。

传统的反馈功能就像是我们在某些机构大门口看到的意见箱，我们都潜意识的知道它无用；而现在的贴吧社区像什么哪？像是一个许愿树，我们不确定自己的愿望是否会被实现，但是我们会感觉一些温暖，愿意把我们的期许写上去。

一些不成熟的小建议，供参考，以上。

#专栏作家#

代成龙，专栏作家，智能硬件创业公司产品狗，从视频巨头公司到玩智能硬件的公司，继续产品设计工作。

本文于。，。

题图来自 Pixabay，基于 CC0 协议