从上述结果报告中可以看到：大概涉及到了10多个功能子块儿，主要包含：今年度歌曲、今年度歌单TOP10、今年度四季喜爱歌曲、今年度喜爱歌手、今年度各曲风统计占比、今年度收听最小众歌曲、今年度听歌关键词…这些功能是从 今年该用户收听的歌曲中，按照歌曲结构化数据本身，如曲风、是否小众、歌手、发表日期，歌词内容等维度进行统计分析的。

而 地域曲风“同频共振”功能则需要事先 按地区，统计不同地区的曲风占比，再与用户曲风做对比，找到“契合点”。以及听歌品味相似用户推荐，则需要综合考虑每个用户的听歌特征，可能涉及一个或多个特征（如听歌曲风、喜爱歌手、英文歌/中文歌标签等）。再如今年新探索曲风功能，需要与去年的曲风进行对比，则考虑的是 “时间维度”（本周期与上个周期）。

下述脑图，是报告中涉及到的数据统计分析部分的功能框架图：

此外，网易云音乐报告还涉及到一些非统计类的功能需求，如封面生成与保存到相册、分享，以及切换到每个数据统计分析页面的交互功能等。

在上述功能框架中，除了相似听歌品味研判功能涉及到一套相对复杂的AI研判算法以及听歌关键词涉及到的热词挖掘算法外，其余均为比较基本的数据统计、分析、排序需求，PM规定好输入、输出，研发同学开发相应的接口即可。

在这些简单的统计、分析需求确认过程中，会涉及到一些细节问题，比如春天最喜爱歌曲，其时间粒度是？从1月1日到4月30日？认为是春天？再比如，如何定义小众？听歌人数<一定值？还是歌曲累计播放次数<次？还是？再比如用户今年度发表的精彩评论，若有的情况下，展示评论数据的哪些字段？（评论时间、该评论涉及的曲目、评论文本、获赞次数，以及当评论文本过长时，前后端怎么处理，缺省用“…”还是直接截断？这些都是需要PM和研发在技术方案设计前对齐好的）。

下述脑图，为笔者梳理的网易云音乐App的核心数据框架（由于笔者不是网易云音乐App的PM，按照我的经验理解，猜测其部分主要核心数据有下面这些，仅供参考）：

上述《网易云音乐年度听歌报告》报告中用到的数据，主要是“普通/黑胶用户基础数据”和“歌曲结构化”、“用户社交”两大部分数据。其余的数据，是否可以构建出其它数据统计分析功能？答案是肯定的，但是是否有必要放在报告中，就需要产品经理深入思考了，用户的时间就那么多，放太多功能，报告浏览时间势必会加长，而且一些功能，用户平时不经常使用的，也没必要做分析。

艺人资料数据，是网易云音乐App，艺人资料页所展示的，包括艺人名称、性别、最近演出动态、官方获奖情况等。按我的经验，一般这种艺人基础资料，应该都是找外部团队整理或者直接从外部采购的公开数据，应该不是网易云团队自行整理的（如果猜的不对，那以实际为准，哈哈）。

确认好数据分析报告每一块要输出给用户的信息后，就完了吗？当然没完。

第一，报告的最终呈现形态是什么？各个模块间的排版布局是什么样的？

当输入数据缺乏某些字段时，怎么处理？这都需要PM来思考清楚、确认清楚。比如用户是普通用户，而非黑胶用户，则“今年度黑胶VIP歌曲”收听统计次数模块，不必输出；再如用户今年从未使用过评论功能，评论分析模块，是否还需要展示？我觉得这里可以展示一下，输出内容文案like this：

“今年的你，没有发表过任何评论，是一枚妥妥的倾听者呢”。输出的目的是：可以告诉用户“你今年没有发表过任何评论，明年可以体验体验我们的这个功能”。

第二，报告制作和查看支持的端？——移动端？是否支持web网页操作和查看？PAD端？大屏端？

这也是需要产品经理所明确的。显然，网易云音乐报告，优先支持移动端是最合理的，能够满足98%以上的用户需求，而PC端web网页制作，首先这种需求场景很少，可以通过转至移动端进行操作，而且其前端框架和移动端不同，还需要设计另外一套UI方案。因此，仅考虑移动端制作音乐报告是合理的。

1. 数据大屏示例