用户反馈分析实例：新浪新闻客户端

编辑导语：当用户产生疑问，或者遇到其他问题时，可能就会通过用户反馈系统将自己的问题反映给平台方，之后再由平台方进行处理。然而用户反馈中可能存在着大量无意义的内容，如何才能知晓哪些用户反馈是有效的？又应该如何对其进行处理？本文作者结合实际案例对该问题进行了总结，一起来看一下。

一、引言

在新浪新闻，我接触到的第一项工作就是月度用户反馈的分析。

新浪新闻具有一套成熟度较高的客服系统来分发和处理大批量的用户反馈，所以用研的主要工作侧重于对反馈内容进行聚类分析，探索有价值的体验优化方向。接下来，我想分享在新浪新闻的用户反馈分析工作当中的工作思路、实际经验和一些想法，希望和大家进行讨论。

二、哪些用户反馈更重要？

在不同的团队架构中，处理用户反馈的岗位可能有所不同（也许是客服、运营或者产品）。

很多接触过用户反馈的朋友可能都或多或少发现——在大量无意义、无原因、重复性的反馈内容里，到有价值的内容似乎并不是一件容易的事情——所以，我们首先要做的就是对海量的反馈内容进行拆分和合理聚类，这也就引出了第一个问题：有哪些类型的用户反馈？其中哪些是重要的？

1. 功能类反馈

在新浪新闻的用户反馈处理系统中，经常看到用户提出这样或者那样的功能需求，“为什么不能调节行间距？”“为什么评论不能发动图？”——面对这一类问题，我通常会结合业务现状去思考：

1. 用户实际的需求是什么？
2. 我们现在是否已具备相关功能能够满足用户的需求？
3. 如果已有相关功能，用户为何不使用？
4. 如果没有相关功能，是否需要添加？

2. 内容类反馈

新浪新闻作为内容流产品，来自用户的内容类反馈也是非常常见的，其中，内容质量问题和推荐算法问题是最主要的2个组成部分。

这两种类型的问题优化都是中长期，甚至持续不间断迭代进行的，有可能用户提出的问题，对应业务侧已经优化完就等上线了，这就需要用研深入扎根业务，才能做到不浪费资源，动态分析。

3. 运营/活动类反馈

在我的经验中，短期的运营活动会产生大量用户反馈（通常占全量80%左右）——询问活动流程和规则的，吐槽页面卡顿或者BUG的，查询活动收益和奖品兑换结果的，不一而足。

分析这一类反馈是性价比较低的，不仅因为发现的问题往往因为时间周期的关系来不及修复/优化，且这次的经验下次也未必能够复用，故通常关注一下高频关键词，排查一下重大问题，对客服话术进行优化，即可解决主要问题。

当然，如果时间非常充足，也可以不考虑这些。

4. 账号/评论类反馈

这一类问题通常来自于因评论命中某些管理规范而被限制账号权限的用户，通常只需要客服按手册进行回复即可，但也有例外，如登录异常的反馈量明显上升，我们也需要搞清楚其中发生了什么，才能够判断接下来是否需要、如何采取措施。

5. BUG类反馈

诸如“图片变黑白”“页面无内容”这一类BUG问题处理起来是最为简单的，在用研接手之前，客服部门一般都已对BUG进行复现核实，将问题报告给对应的业务负责人，极少会出现用研从反馈中发现未知BUG的情况，一般只需要关注问题趋势和跟进处理进度即可。

6. 其它类型反馈

有相当数量的用户（较常见的是在应用商店评分里）并不会对产品问题进行具体的描述，而只是单纯地抒发个人情绪感受，这一类反馈通常不具有太多分析意义，故在此按下不表。

三、客户端内用户反馈处理流程

1. 数据清洗

在拿到当月的用户反馈原始数据之后，通常按照以下步骤完成数据清洗：

1. 对不同来源的数据进行合并，统一格式；
2. 删除无效数据；
3. 对同场景的多条反馈信息进行内容按类型进行合并/拆分（这一步比较漫长）。

2. 分类汇总

按照反馈类型给每条信息编码，得利与新浪新闻用户反馈系统的完善性，到手的数据中绝大部分是自带类型编码的，但编码信息是用户自主提交的，准确度并不足够高，因此用研还是会全部浏览一遍，逐一进行匹配修正。

3. 数据可视化

在完成编码之后，我们首先会对每种类型的反馈数量进行计数统计，给出数据透视表，然后和过往数据进行纵向比较，了解问题变化的趋势。除了和上月反馈数量进行对比之外，还会绘制半年趋势的折线图，如果发现某种类型的问题有连续变化的趋势或者出现较大的拐点，则意味着需要给予额外关注。

此外，我会对具有一定规模的二级问题进行渗透度分析，给出四象限图（X=反馈量，Y=影响规模），对进入一二三象限的问题进行重点讨论（PS. 值得一提的是，到现在为止并没有出现过象限I问题）。

4. 需求分析

通过上述工作，我们已经可以得到来自当月用户反馈的用户痛点问题清单，但这些问题并不是需要全部、立刻拿小鞭子抽着产品经理去讨说法的，在此之前，我会先进行一轮需求分析：

1. 这个问题是如何产生的？会对哪些用户产生何种程度的影响？
2. 这个问题是短期还是中长期问题？
3. 是否有较为明确的优化方向
4. 根据重要和紧急程度，依次找对应的业务负责人沟通问题现状，讨论解决方案
5. 获得结论，包括是否处理、处理方案、优先级、排期等。

5. 归档与追踪

建立往期问题档案清单，把每个月的重点用户体验问题进行归档。我每次会把它作为附录放到报告的末尾，在完成月度反馈分析工作的时候，顺手跟踪一下往期优化中的项目的最新进展，这样可以很好地了解到自己的工作成果落地的情况，跟产品/运营/开发等不同岗位的同事多沟通有助于深入学习和了解业务。

如果业务侧认为你提出的问题很有价值，也许还能诞生出一个更具有针对性的专项研究，一举多得。

四、小结与思考

1. 各职能线精益协作对用户反馈分析的促进作用

完成用户反馈分析工作的过程当中，用研会持续与客服、产品、运营，交互乃至研发等不同岗位的小伙伴进行沟通。客服要对数量庞大且内容各异的用户反馈信息进行第一手处理，很多BUG类问题在分析之初先找客服聊一轮，往往就能够了解到问题的发生原因、处理方案/结果、业务对接人是谁等等。

而业务侧也会帮助用研深入了解业务现状，分析相关数据，积极讨论体验点是否转化为需求，以及跟进需求最终落地。

可以说，用研能够借助用户反馈来挖掘用户需求，实现优化用户体验，很大程度上得益于各职能线之间的精益协作。

2. 负反馈的局限性

一直以来，我们围绕用户提出的负反馈进行纵向深入的监测和分析工作，为最大化降低用户的负面体验付出了许多努力，也收获了很多关于体验提升的策略落地成果。尽管用户反馈的价值已被论证，但我们还是应该注意到，如果只分析来自客户端内客服系统的负反馈，也具有明显的局限性：

• 被动 ：我们在评估时只能被动接收有反馈意愿的用户提出的问题，也很难有机会后续沟通联系，往往无法明确问题细节。
• 滞后 ：由于采用月度评估，相对与客服系统的即时性，用研对反馈问题做出反应的时间较为滞后。
• 幸存者偏差 ：正常使用产品的用户不会提负反馈，负反馈用户对产品甚至品牌存在负面偏见，对产品更加“挑剔”，无法代表全部用户的想法。
• 维度单一 ：只分析负反馈，不关注正反馈。

在许多产品中，对于产品/服务的 体验度量 的尝试大都集中在解决用户的“负反馈”维度，然而这种维度相对单一的聚焦方式，无法客观、真实反映用户对产品/服务的完整体验。

在用户研究的层面上，我们认为可以从一个更为积极的角度出发，探索用户对新浪新闻更为立体的体验评价，形成一套可量化、可持续，且（和负反馈分析方法相较）更为立体和主动的用户体验度量衡——这将是我们后续工作的目标。

 

本文由 @新浪MDC 原创发布于人人都是产品经理，未经许可，禁止转载

题图来自Unsplash，基于 CC0 协议