产品|用户反馈分析实例：新浪新闻客户端( 二 )

6. 其它类型反馈有相当数量的用户（较常见的是在应用商店评分里）并不会对产品问题进行具体的描述，而只是单纯地抒发个人情绪感受，这一类反馈通常不具有太多分析意义，故在此按下不表。
三、客户端内用户反馈处理流程
文章插图
1. 数据清洗在拿到当月的用户反馈原始数据之后，通常按照以下步骤完成数据清洗：

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

2. 分类汇总按照反馈类型给每条信息编码，得利与新浪新闻用户反馈系统的完善性，到手的数据中绝大部分是自带类型编码的，但编码信息是用户自主提交的，准确度并不足够高，因此用研还是会全部浏览一遍，逐一进行匹配修正。
3. 数据可视化在完成编码之后，我们首先会对每种类型的反馈数量进行计数统计，给出数据透视表，然后和过往数据进行纵向比较，了解问题变化的趋势。除了和上月反馈数量进行对比之外，还会绘制半年趋势的折线图，如果发现某种类型的问题有连续变化的趋势或者出现较大的拐点，则意味着需要给予额外关注。
此外，我会对具有一定规模的二级问题进行渗透度分析，给出四象限图（X=反馈量，Y=影响规模），对进入一二三象限的问题进行重点讨论（PS. 值得一提的是，到现在为止并没有出现过象限I问题）。
4. 需求分析通过上述工作，我们已经可以得到来自当月用户反馈的用户痛点问题清单，但这些问题并不是需要全部、立刻拿小鞭子抽着产品经理去讨说法的，在此之前，我会先进行一轮需求分析：

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

5. 归档与追踪建立往期问题档案清单，把每个月的重点用户体验问题进行归档。我每次会把它作为附录放到报告的末尾，在完成月度反馈分析工作的时候，顺手跟踪一下往期优化中的项目的最新进展，这样可以很好地了解到自己的工作成果落地的情况，跟产品/运营/开发等不同岗位的同事多沟通有助于深入学习和了解业务。
如果业务侧认为你提出的问题很有价值，也许还能诞生出一个更具有针对性的专项研究，一举多得。
四、小结与思考1. 各职能线精益协作对用户反馈分析的促进作用完成用户反馈分析工作的过程当中，用研会持续与客服、产品、运营，交互乃至研发等不同岗位的小伙伴进行沟通。客服要对数量庞大且内容各异的用户反馈信息进行第一手处理，很多BUG类问题在分析之初先找客服聊一轮，往往就能够了解到问题的发生原因、处理方案/结果、业务对接人是谁等等。
而业务侧也会帮助用研深入了解业务现状，分析相关数据，积极讨论体验点是否转化为需求，以及跟进需求最终落地。
可以说，用研能够借助用户反馈来挖掘用户需求，实现优化用户体验，很大程度上得益于各职能线之间的精益协作。
2. 负反馈的局限性一直以来，我们围绕用户提出的负反馈进行纵向深入的监测和分析工作，为最大化降低用户的负面体验付出了许多努力，也收获了很多关于体验提升的策略落地成果。尽管用户反馈的价值已被论证，但我们还是应该注意到，如果只分析来自客户端内客服系统的负反馈，也具有明显的局限性：