
从上述结果报告中可以看到:大概涉及到了10多个功能子块儿,主要包含:今年度歌曲、今年度歌单TOP10、今年度四季喜爱歌曲、今年度喜爱歌手、今年度各曲风统计占比、今年度收听最小众歌曲、今年度听歌关键词…这些功能是从 今年该用户收听的歌曲中,按照歌曲结构化数据本身,如曲风、是否小众、歌手、发表日期,歌词内容等维度进行统计分析的。
而 地域曲风“同频共振”功能则需要事先 按地区,统计不同地区的曲风占比,再与用户曲风做对比,找到“契合点”。以及听歌品味相似用户推荐,则需要综合考虑每个用户的听歌特征,可能涉及一个或多个特征(如听歌曲风、喜爱歌手、英文歌/中文歌标签等)。再如今年新探索曲风功能,需要与去年的曲风进行对比,则考虑的是 “时间维度”(本周期与上个周期)。
下述脑图,是报告中涉及到的数据统计分析部分的功能框架图:

此外,网易云音乐报告还涉及到一些非统计类的功能需求,如封面生成与保存到相册、分享,以及切换到每个数据统计分析页面的交互功能等。
在上述功能框架中,除了相似听歌品味研判功能涉及到一套相对复杂的AI研判算法以及听歌关键词涉及到的热词挖掘算法外,其余均为比较基本的数据统计、分析、排序需求,PM规定好输入、输出,研发同学开发相应的接口即可。
在这些简单的统计、分析需求确认过程中,会涉及到一些细节问题,比如春天最喜爱歌曲,其时间粒度是?从1月1日到4月30日?认为是春天?再比如,如何定义小众?听歌人数<一定值?还是歌曲累计播放次数<次?还是?再比如用户今年度发表的精彩评论,若有的情况下,展示评论数据的哪些字段?(评论时间、该评论涉及的曲目、评论文本、获赞次数,以及当评论文本过长时,前后端怎么处理,缺省用“…”还是直接截断?这些都是需要PM和研发在技术方案设计前对齐好的)。
二、产出上述报告所必需的基础数据有哪些下述脑图,为笔者梳理的网易云音乐App的核心数据框架(由于笔者不是网易云音乐App的PM,按照我的经验理解,猜测其部分主要核心数据有下面这些,仅供参考):

上述《网易云音乐年度听歌报告》报告中用到的数据,主要是“普通/黑胶用户基础数据”和“歌曲结构化”、“用户社交”两大部分数据。其余的数据,是否可以构建出其它数据统计分析功能?答案是肯定的,但是是否有必要放在报告中,就需要产品经理深入思考了,用户的时间就那么多,放太多功能,报告浏览时间势必会加长,而且一些功能,用户平时不经常使用的,也没必要做分析。
艺人资料数据,是网易云音乐App,艺人资料页所展示的,包括艺人名称、性别、最近演出动态、官方获奖情况等。按我的经验,一般这种艺人基础资料,应该都是找外部团队整理或者直接从外部采购的公开数据,应该不是网易云团队自行整理的(如果猜的不对,那以实际为准,哈哈)。
三、数据分析报告模板框架制定及应用案例确认好数据分析报告每一块要输出给用户的信息后,就完了吗?当然没完。
第一,报告的最终呈现形态是什么?各个模块间的排版布局是什么样的?
当输入数据缺乏某些字段时,怎么处理?这都需要PM来思考清楚、确认清楚。比如用户是普通用户,而非黑胶用户,则“今年度黑胶VIP歌曲”收听统计次数模块,不必输出;再如用户今年从未使用过评论功能,评论分析模块,是否还需要展示?我觉得这里可以展示一下,输出内容文案like this:
“今年的你,没有发表过任何评论,是一枚妥妥的倾听者呢”。输出的目的是:可以告诉用户“你今年没有发表过任何评论,明年可以体验体验我们的这个功能”。
第二,报告制作和查看支持的端?——移动端?是否支持web网页操作和查看?PAD端?大屏端?
这也是需要产品经理所明确的。显然,网易云音乐报告,优先支持移动端是最合理的,能够满足98%以上的用户需求,而PC端web网页制作,首先这种需求场景很少,可以通过转至移动端进行操作,而且其前端框架和移动端不同,还需要设计另外一套UI方案。因此,仅考虑移动端制作音乐报告是合理的。
四、其它数据统计分析报告案例1. 数据大屏示例

