登录
首页从0到2亿,网易云音乐如何依靠数据治理实现用户增长?
从0到2亿,网易云音乐如何依靠数据治理实现用户增长?
2016-09-19
收藏

在前不久举办的CDAS2016中国数据分析师行业峰会·互联网大数据分论坛,网易商业智能部门总监沈琦分享了网易云音乐如何依靠数据治理,实现从0到2亿用户的增长。下文根据嘉宾演讲实录整理。

大家下午好。非常幸运今天下午能到这里给大家分享。


我现在是网易商业智能部的负责人。我们商业智能部构成还是比较复杂的,下面有两个部分,一个是杭州研究院下面的,是负责云音乐、易信、云阅读,还有博客部门的产品;还有一个是考拉的电商的商业智能部,也在我这边负责。考拉下面已经有40多人的团队了。我们把杭州研究院的商业智能部叫做本部,就是傅志华老师说的大数据中心技术团队的概念。另外还有很多数据分析师分布在各个事业部里面。

我今天讲的是云音乐中的数据治理。


这是一个云音乐的播放界面,在2013年的时候出来的,感觉挺酷的,是我们老板主抓的一个项目。我们看几个数据,现在的用户大概是超2亿了,每天日活超千万、行为日志接近100亿,正品的高品质音乐歌曲超1000万首。我们的歌单大多是自己创建的,平台也会进一些歌单,大概已经有上亿个歌单了,累积评论2亿条,曲库使用率是80%。我们的推荐做的不错,能够把一些小众的歌曲推荐出来。


我们会对云音乐的所有数据进行分析。这是搜索跟播放历史两条线的数据。横轴可以理解为会员等级,也就是会员的忠诚度。我们可以看到新用户一开始使用搜索的频率非常高,但是越到后面搜索频率越来越低了。播放历史也是比较高的,但是随着用户等级的升高,对云音乐产品越来越熟悉之后,会发生一些变化。

这个变化会反映了什么问题?新用户到云音乐来第一时间是希望从这里找到他想找的歌曲,找到以后,他有自己的歌曲爱好,然后听他喜欢的。


这个是每日歌曲推荐,带有一些个性化信息。我们可以看到,随着用户等级的提高,他的使用频率越来越高。一开始自己想听什么听什么,我们会根据他的喜好推荐,这个功能使用频率越来越高,后面趋于稳定。


从个性化推荐也是可以看到这样一个趋势。一开始用户可能在做一些尝试,我们也做一些猜想。最后当等级很高的时候,他用的特别多。但这不一定说他真的感兴趣听,有可能已经对我们云音乐形成依赖了,或者放在那里刷等级。具体原因还要分析。

我们之前的版面是这样的,左边是个性化推荐、私人电台、每日歌曲,包括热门推荐。这个热门推荐一开始是非个性化的,是我们自己编辑的比较好的歌单,新歌放在下面。通过刚才的分析,我们发现用户对个人化的需求越来越强烈,希望听到不一样的歌。所以我们把每日歌曲做了处理,所有的歌单也都是个性化的,最新的音乐也是跟用户相关的。做这么一个改版,我们的歌单推荐使用率翻了一番,私人FM播放率提升了30%,最新音乐进入率提升35%。

再举一个例子。关于分享音乐,我们在策划阶段准备了方案一跟方案二,有什么区别呢?方案一的折中方案强化了下载按钮。更激进的方案下载按钮也是强化了,但是把黑胶放在这里可以点,点了以后可以直接下载。我们去测效果好不好,做了一些简单的分析,也发现了一些问题。

突出下载按钮以后,整体点击率提升60%左右,拉新提升明显。激进方案下载按钮点击效果最好,说明黑胶的样式吸引力最高,但下载转化效果不好,且有种欺骗用户的感觉,考虑修改。

删除打开按钮,对老用户影响很大,老用户无法进入。前面打开评论按钮,一开始版本里面是有的。从一开始的版本里面我们可以得到一些数据,这两个点击还是比较高的。所以经过讨论以后,我们的产品经理又得到了一个综合性方案。

因为要保留老板要求的黑胶,方案大概是这样的:我们现在的打开按钮,考虑到老用户,老用户评论分享也看到了,不要求下载,新用户下载。点击黑胶不是下载了,而是以评论形式展开,用户可以评论。我们在整个音乐的发展过程中是做了大量的类似事情。

另外一个例子是很早的,应该是2013年6、7月份的例子。当时一个下载按钮,其实埋的比较深。我们通过一些用户模式的分析认为,只要用户达到下载按钮的存留就很高。当时这么一个按钮的改变,就整个流程提高了百分之十几个点。网易云音乐在2013年到2016年三年之间,通过大量的数据分析支撑用户从0到两个亿多。

刚才一些都是分析上的案例。我们说从数据治理上来讲需要做哪些事情。从这张图上的爱因斯坦,我们可以看到强大的大脑,健壮的体魄,生命力挺强。


大数据也是类似的。我们可以分成骨骼层,也是最重要的基础设施,硬件的存储和计算能力,它需要大存储、高性能的计算,以及对数据的实时传输。


第二层称为血液层,即数据本身,我们对数据进行建模,对元数据进行管理,去分析和把控每一个业务,深入的分析才能推动业务的发展。不能做技术就是做技术,做业务的做业务,最终不能产生所谓的价值,这对任何的管理者来说是很头疼的问题。

这是很常见的数据治理流程,


首先采集数据,传输到我们的存储里面,然后对数据进行处理、计算、建模,统计、分析、挖掘,最后做一个可视化的展示,然后根据用户的反馈改进这个流程。

我主要讲这两个方面,一是数据采集,二是是数据建模

为什么这两方面特别重要?数据采集涉及到一个概念叫数据质量。我们做数据的时候,最头疼的问题就是数据质量问题。


左边这种情况我估计每个企业都会发生,数据都是这么不规则。我是2011年开始做数据,当时就我一个人,做的时候发现数据太乱了,乱到我真的无法忍受。你要做分析也好,挖掘也好,都没法进行。因为数据都是不整合的,不仅是传统企业,互联网企业也一样。

数据采集现在外界也非常关注,也有一些流行的工具,以前都是移动通过代码埋点的方式做的。这两年以可视化埋点还有无埋点的方式进行,现在国内很多公司都提供了这种方法。但它只是提供了一个通用的平台,通用的分析、采集工具。云音乐这种每天百亿条的数据,很多基本情况都是无法满足的。所以我们需要看这几种方法的一些使用场景,还有它能解决的问题,或者一些局限。


首先代码埋点。你可以按照你的逻辑埋进去,但是它比较复杂,每个点都要去规范化、命名、分类。第二类是可视化埋点,它可以把网页或者APP的那一页扒下来,客户在某一个点下载我就埋个点。但是它只能做一些比较简单的逻辑性的埋点动作。还有无埋点,无埋点的概念,其实是全埋点。它是通过技术把树型结构扒下来,带来的问题是数据的超负荷发送,任何一个点击都会传输到数据服务端。无埋点有一个非常大的优势,你不需要做这个事情的时候,产品经理说我想看这个数据,无埋点可以回溯,你只要统计出来就可以了。

我们内部采用的方式是代码埋点,如果是一些创业型的公司没有能力解决的话,可以用别人提供的工具解决。我们主要做几个事,一个是规范,一个是实施。

规范就是命名跟分类,云音乐大概埋了800多个点,我们对每个点进行了比较好的分类,统一命名。

在实施阶段涉及人的问题,谁来实施。代码埋点肯定是产品的开发工程师,但是谁去整理这个规范。我听说脸书有工程师整理这个规范,分析师按照这个分析就可以了。我们一开始让分析师确立一个规范,让开发工程师去埋,我们自己也开发了很多工具,可以通过一个平台看这个点有没有被埋进去,逻辑对不对,做一个简单的校验就可以上线了。

第二个问题是数据建模的问题。数据过来了,我们也传输了,也放在集群上。我们怎么去把它整理成我们分析要用的数据。这个整理不是说技术人员随便去整理,而是按照一个技术规范,因为它是跟业务结合的。

大概的流程是这样的,一类叫交易类的,还有行为类的。不管是服务端采集的还是客户端采集的,放数据仓库里面,形成两条线,一条叫维度表,它主要从业务数据里面抽出,包括音乐的一些元数据信息,比如说这首歌谁唱的,哪个专集的,什么时间发行的。另一个是事实表。结合一些业务数据库,形成我们非常细密度的一个数据表结构。其实中间这一层很技术化的,最主要的是后面,它要针对不同的数据分析逻辑,用这两张表构建它的数据分析的模型。


这个要注意两点,维度表的构建需要深度业务,尽可能保证维度的完整,减少多余的join操作。事实表是各种行为统计表,关键是做好数据建模工作。

我给大家稍微演示一下怎么建模。

这是一个数据模型,可以说是大家认可的模型,还是不错的。


基本上是一切产品日志都符合事件模型的。who、when、where、how、what,谁在什么时间,什么地点,对什么歌曲进行了操作。这个模型还是比较通用的。


我们的原始日志会涉及到deviceid、userid、ip、apver,终端系统的一些操作日志,action,最后会有很多的附加属性。

这是云音乐最底层的规范化的数据日志,


我们可以看到这几个,who是有的,where是有的,when是有的。通过原始日志我们没有办法去做存储,然后做快速的分析。这就需要对日志进行细分,前面三个不变,我们把刚才说的一些机型的信息,客户端的信息放在client info里面,包括用户行为的上下文环境,歌曲被播放的时长、数量的概念。在前面的基础上做ETL的过程。这是在以天为单位,做一次低层次的抽象。

有个细节需要注意,我们把刚才这个表结构中第一次和最后一次操作某个歌曲的时间拿出来。因为这个是业务中经常查的,他会经常说我这个在什么时候第一次发生的,然后让分析师查一下。如果我们底层没有构建模型,查的时候全扫描了,是非常耗时的。

这是比较低层次的抽象。其实我们会对业务场景进行更多的抽象,这是更上层的可以分析的模型。who也有,主要做这一块,这时候有几个点要特别关注:天、一周、两周、28天、四周、月,这些概念是分析中经常用到的。你们分析的时候肯定不会关心技术怎么存数据,拿数据,认为这很简单。但其实技术很痛苦,他说这个东西拿不出来,其实是数据模型没有建好。这是比较重要的模型上的一些。


在模型上的宽表问题上做几个建议。不具有统计意义的字段不要放到宽表。比如歌词,量很大,但这个东西没有统计意义。宽表是存起来经常被访问和扫描的,不要放经常变化的维度。宽表可能是一年的宽表,如果经常变的话,每更新一次都要一天了。太大字段也不要放进去,宽表受不了这么大字段的扫描。

数据挖掘建模感兴趣的同学,CDA开设数据挖掘课程,四大专题,皆为大牛,R语言近期开课,预报从速:



数据分析咨询请扫描二维码

上一篇
下一篇
客服在线
立即咨询