结合用户反馈，产品经理可以更清楚地了解用户的产品使用感受，挖掘用户潜在需求，矫正产品发展方向和节奏。那么，怎么做好用户反馈收集和分析？一起来看看本文的阐述。
在平时的工作中，有一块内容是收集、整理用户对产品的反馈，并定期产出报告，也就是用户反馈的整理。它是很重要的一份工作，能够让我直接面对用户，倾听用户的声音，了解他们真正想要的是什么。因此，我希望能够结合自己的工作经验和其他人的相关文章，总结一个关于用户反馈相关的工作方法论。
开始还是老生常谈的问题。用户反馈是什么？我认为，用户反馈就是在产品的生命周期各个阶段，用户对产品的评价和诉求。
定义里有几个要素。产品、各个阶段、用户、评价和诉求。
首先是产品。这个范围非常广，大到整个产品，小到某个产品的功能模块，甚至是某个文案，某个icon的改变。这就要根据产品经理的收集目标决定了。我在工作的时候，往往会比较聚焦。
其次是各个阶段。一个产品会有多个版本，从最初的形态，到后面一步步的迭代。对于用户的反馈不能只停留在某个阶段，尤其是某个用户反馈非常好的阶段。因此对用户反馈的收集和分析是一个持续性的工作。
再次是用户。对于同一个功能，不同的用户会有不同的反馈，甚至是天差地别的反馈。对用户进行识别可以让我们对反馈有更深刻的认识。某一类反馈是普遍性问题还是某一群体在使用产品时面临的问题？某一类反馈是新用户在反馈还是资深用户在反馈？通过对用户的识别，可以使产品经理在决定反馈优先级（目标用户反馈的优先级更高）、重要程度（所有用户都在反馈的重要程度更高）和挖掘反馈背后的需求（新用户反馈的问题也许并不是用户需求本身）上更准确。我在工作中对用户的识别做的不是很好。
最后是评价和诉求。这部分很多时候可以被用户的行为数据所覆盖。比如，看一个产品用户的停留时间发现，很多用户停留的时间远小于使用产品满足需求的时间。这可能表明了用户进入之后并不知道要做什么，或不知道怎么使用。
但是这只是通过数据所作的推断，并不能真正确认到底是怎么回事。因此，在定量的同时，也需要对这种现象进行定性。用户反馈正好可以做到这一点。它能够收集到用户对产品的态度和评价。确定到底是什么原因导致了定量数据显示的现象。
对用户反馈的收集和分析有什么价值呢？
做产品就是帮用户解决问题的过程。如果洞悉用户反馈，产品经理可以清楚知道用户面对的问题是什么。同时，在用户反馈中，可以知道用户的预期边界在哪里。这为产品经理设计功能时提供的非常好的参考。用户很挑剔，它对产品“好”的定义不仅仅是解决了问题，而且能够超预期的解决用户的问题。
最后，用户反馈是反矫情的一个利器。在设计功能的时候产品经理很可能会自我陶醉，觉得自己设计的很牛X。实际上用户不一定会买账。用户反馈是一面镜子，很好的矫正产品经理对事物的理解和方案的完善方向。
分析用户反馈的目的是什么？根据用户反馈的定义可知，分析用户反馈就是为了挖掘用户潜在需求，矫正产品发展方向和节奏，衡量用户的预期。
一个完整的用户反馈流程一定是一个闭环。通常会经历用户反馈收集->处理分析->形成结论->产出方案->最终落地的过程。
用户反馈如何收集？
我在负责用户反馈工作的时候总结了一个用户反馈收集的方法。收集用户反馈要确定五点内容。目标、周期、用户、来源、具体内容。
定目标可以让用户反馈的收集有的放矢，节省成本，提高效率。定了目标之后就可以确定后面的几个点了。
用户的反馈是以自然时间进行收集（月维度、季度维度等）还是产品功能时间（上线后）进行收集？这也要确定下来。
用户是哪些用户？比如，要收集地图产品驾车导航功能的反馈，收集车主用户的反馈更有价值，也更节省资源。
来源关键的不是来源来自哪里，因为来自哪些的用户反馈都是有一定价值的。关键在于确定来源的全面性和准确性。据我了解，有些渠道的用户反馈是已经经过一道手的用户反馈。可能上游工作人员因为工作绩效的压力导致某些用户的反馈无法抵达产品经理层面。还有一些用户反馈入口可能某一类型用户看见的更多，因此，这个渠道的用户反馈可能就会放大或隐藏某些反馈。
具体内容就是我们收集时要收集哪些信息。因为某些信息的缺失可能会导致我们对问题的判断出现偏差。比如，某个问题只在IOS用户中存在，但是收集过程中，缺少了机型信息，产品经理可能就会错误的判断是所有的机型都有问题。
因此，在收集具体内容时，要注意收集三个方面的内容。分别是用户基本信息（机型、联系方式、用户id、性别、地域等）、功能信息（产品版本、功能页面等）、反馈信息（反馈时间、反馈具体内容等）。这三方面不是必须要收集的，有些辅助信息可以没有。这需要根据目的决定。
用户反馈如何分析？我总结用户分析需要有以下五个步骤。
反馈清洗。该步骤是为了去除无效反馈，去除恶意反馈。在实际工作中，有些用户会向我们打声招呼，虽然这为乏味，辛苦的工作带来了一丝丝欣慰，但我还是无情的把类似这种反馈去除（十动然拒！哈哈哈哈）。另外还有一些反馈明显是恶意的攻击。这种反馈我也会去掉。
反馈识别。这一步就是判断需求的真实性，考虑用户的诉求是否有可替代性。“不要完全听用户的，对于用户的直接诉求，需要进一步深挖其本质。”比如，有些地图用户反馈说导航结束后能不能给我推荐停车场？他的诉求是推荐停车场，但实际诉求是如何让他到达目的地后更方便快捷的停车。如果我只是简单的做一个推荐最近的或子点停车场是不能解决问题的。而应该是给用户提供一个车位充足的附近停车场list。
反馈分类。我的分类体系一共有三级。第一级可以叫做主题。是根据目的拆分出来的几个大项。比如，可以分为数据类、功能类、技术类几个大类。后续再进行更细致的拆分，第二级是主题下的某个功能点，第三级就是某个功能点的问题。这样既可以很方便的知道哪个主题问题多，还可以详细了解具体问题是什么。
其次，分类一定要标准化，这样在算占比的时候直接数据透视就可以很快的解决，省去了很多统计工作。最后，反馈分类不是一成不变的，要根据实际情况迭代优化。
优先级排序。在工作时，我采用统计占比的方式确定优先级。统计某个三级分类占总数的比例。比例高的就是优先级高的。但是这种办法存在一个问题，就是没有考虑到反馈的性质。所以这个时候我们可以根据重要紧急象限进行优先级排序。我建议先象限后占比。既能兼顾反馈的性质，又能考虑到大多数用户关注的问题。
主题分析和数据补充。通过优先级的排序可以对相关问题有个大概的掌握了。但是这样还是不够的。当用户反馈较多时，应该考虑对相关的主题着重进行分析，或者跨主题进行分析。
其次，能把自己的评价和诉求反馈的用户要不就是非常热心的，要是就是使用体验非常差的。其实产品经理能获取到的用户反馈是丢失了“沉默的大多数”的反馈，会有一定程度的失真。因此我认为如果有些问题无法通过反馈看出来，需要看用户行为日志数据作为分析补充。
上文已经探讨了用户反馈的收集和分析。分析完后就要思考如何使用。下图是我整理的一份使用流程。
对用户反馈分析完成后需要形成一份报告。这样有利于沉淀用户诉求，也有利于日后对用户反馈的追溯。报告的写法之前在评估的那篇文章中有提到过，不赘述了。
其次就是完成用户反馈的闭环工作。所谓闭环就是有相应的方案对用户反馈的问题进行解决。
在使用过程中，也要注意一些问题。
产品经理要有自己的主见。虽说用户的诉求是很重要的。但绝大多数的普通用户无法确知他们真正需要的是什么。怎么听比听或不听用户的意见更重要。产品经理要有自己的判断，这也是产品经理的价值所在。
不可太极端。既不要做一个完全不听用户声音的产品经理，也不要做一个对用户反馈言听计从的产品经理。产品经理要做的是如何做一个方便快捷满足用户需求的产品，用户反馈只是一个比较重要的参考信息，但它不是方向本身。
最后是我的一点执念。就是用户反馈的处理要提高效率，把它变成一个例行的系统化、自动化的过程。这需要构建好用户反馈分析的流程，安排专人负责这项工作，制定好工作所需的模板文件，不断迭代优化流程。
参考：
本文由 @孟老湿 原创发布于人人都是产品经理。未经许可，禁止转载
题图来自Unsplash，基于CC0协议
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。