数据策略案例

简介: 抖音、快手策略推荐分析

什么是推荐策略

推荐策略是通过用户属性和用户行为,找到每个用户的兴趣偏好,从而达到个性化推荐的目的。如果你尝试在抖音和快手上看一些短视频,会发现,看的越多,推荐的短视频就越符合我们的兴趣,即,抖音、快手的推荐策略通过用户历史的观看行为,为用户推荐其喜欢的视频。本文将以抖音、快手为例,介绍数据分析在推荐策略上的运用。也就是我们说的策略分析。


在此之前,我们需要先揭开推荐系统的面纱,了解它的内部数据流,在此基础上探索数据分析和推荐可能的合作方式。以下是我基于对推荐系统的认知,整合了对抖音快手的业务理解,画出的推荐系统架构。

image.png


用户请求服务后,一般系统先判断用户属性,在相应的召回层中捞出一批视频,召回层打捞的视频量级通常会大一些,视 App 请求量级和计算资源而定,可能为万也可能为千级别。这些视频进入粗排层,粗排层会制定一些规则,快速对召回层的视频进行排序,选取一部分视频进入精排层。进入精排层的视频可能就只剩百级别的数量了。精排层对视频排序的准确性要求更高,通过视频精排,选取排名前几的视频返回给用户,就是我们在 App 上看到的视频。用户继续请求服务,推荐系统再次给用户返回推荐的视频内容,如此反复。


用户请求服务

用户请求服务,在抖音的场景里,可以理解为打开 App、下拉刷新页面、向上滑动视频看下一个视频等,这些都是一次用户请求。Server(服务端)收到请求后,进入推荐流,通常情况下,Server 会判断用户属性,返回不同的召回源。不同类型的用户,召回层的视频池(也叫候选池)很可能是不同的,比如,对新用户是否不出广告。当然,这种属于比较成熟的推荐系统,很多中小型平台的 Server 收到请求后,直接进入召回层,在后续的粗排层再将用户属性作为一个 Label(推荐特征),来干预视频排序。


召回层

召回层,简单来说,就是从全量视频池中召回(打捞)尽可能多匹配用户兴趣的视频。像抖音、快手日活级别的产品,每天用户上传的作品量上百万,甚至上千万。服务器资源不允许计算用户对所有视频的感兴趣程度,用户更不可能给推荐系统太多时间去计算(之前流行说法是,互联网用户最多 3s 耐心,现在更短)。所以,需要在召回层,通过一些召回规则,每种规则下召回(打捞)一定量级的视频。这里可以简单理解,基于某一种规则筛选的视频为一种召回源。所以召回源的视频总和构成了召回层。


召回源的来源通常有多种,比如对站内已经有热度的视频作为一个召回源,把它们推荐给更多用户,打造站内、甚至全网爆款,这种在抖音上比较常见;比如运营构建“长尾优质”召回源,通过筛选优质内容,给予流量倾斜,扶持 KOL、同时保证站内内容的多样性,这种在快手可能更常见。那么,在召回层,数据分析师也可以提供一批视频作为召回源,以达到某种目的。根据站内用户请求量和计算资源,召回层捞回的视频可能为万级别、千级别,也不排除仅为百级别。


粗排层对召回层提供的视频,快速排出用户兴趣低的视频,捞出百级别量级的视频进入精排层。可能你会疑惑,粗排层的 Ranking(排序)算法应该是推荐主导,数据分析师又能如何参与进来呢,后面我们会举例说明。


粗排和精排

精排层对视频排序的准确性要求更高,排序结果直接影响到呈现给用户的视频内容,也是很重要的一环。与粗排层一样,数据分析师可以给予 Ranking 算法的建议。


至此,我们花了大量的篇幅来介绍推荐系统,我们的分析也是基于推荐流上的优化。相信敏锐的数据分析师,可能已经能发掘我们在策略分析上可以做哪些事情了。


可以与推荐进行的合作

召回层合作:增加召回源

我们知道,推荐系统的准确性是建立在有大量用户行为数据的基础上的,但是对于新用户,他们的行为是缺失的,我们能拿到的新用户属性也是少之又少的,除了用户机型、地域、安装渠道等,其他信息基本为零。这就导致新用户的推荐特征稀疏,针对新用户的个性化推荐,很难取得较好的效果。这种情况,我们可以针对新用户建立单独的召回源,通过分析之前的新增用户在哪些视频上的观看表现较好,把这些视频作为一个召回源,以帮助提升新用户的视频观看时长,从而达到提升新用户留存的目的(我们知道,通过 AARRR 模型,此时用户处于“激活”阶段,下一步重要的转化阶段就是要实现用户留存)。


召回层合作:优化现有召回源

增加召回源是一种方式,但是实际中使用的并不多,主要是因为新增召回源后,还需要持续更新召回源的算法,维护成本较高。同时也会增加 Reco(推荐)的管理成本(召回层有大量的召回源,也是需要管理的)。所以,我们更多的是通过分析现有召回源的视频表现,将它们作为优化、甚至是下线某些召回源的依据。以短视频为例,评价视频表现的指标有完播率、平均播放时长、视频的点赞率、评论率、转发率等。其中,完播率是指视频被看完的比例;平均播放时长是视频被多次观看的平均时长;视频点赞率是指视频播放时,被点赞的比例。如果某些召回源的少数指标表现较差,我们可以帮助优化召回源的筛选规则,提高该召回源的视频质量;如果某个召回源的多个指标都表现较差,也可以建议 Reco下线召回源。另外,我们也可以整体分析所有召回源的流量分布,如果流量分布极度不均衡,可能会造成平台内容过于单一,长远看对用户留存可能有损,Reco 也是需要优化的(相信大部分用户是不愿意在一个泛娱乐的平台上,看到过于单一的内容)。


粗排层和精排层的 Ranking(排序)优化

在上一部分我们提到,评价视频表现优劣的指标是多维的,完播率、点赞率、评论率等,而不同指标的权重有大有小,如何确定指标的权重呢?我们假设目前视频点赞率的平均水平为 7% 左右、评论率为 2% 左右、分享率 1% 左右。那么我们可以合理推断,用户一次分享的价值高于一次点赞(分享率 1% < 点赞率 7%)。或者说,用户分享行为是用户给予推荐系统更强的一个正反馈,“我可能喜欢这个视频”,那么,Ranking 算法中,分享率这个指标可能需要被提权,从而让好的视频被筛选出来,推给更多用户。


当然,实际中,业务场景可能更复杂。因为商业化因素的考虑,所以需要出广告;因为要保持站内内容的多样性、维持健康的生态,所以需要对长尾内容进行流量扶持;因为要给予中小生产者涨粉的通道,所以需要给予他们冷启流量等等。这些地方,数据分析师都可以发挥作用。


以广告的 Adload 为例来说。广告的 Adload,是指用户消费的视频流(含广告)中广告的数量占比。Adload 越高,平台的商业化收入越高,但是对用户的体验伤害也越大。部分用户甚至不再活跃,长期看是不可持续的。而 Adload 越小,虽然用户体验会变好,但是平台收入也少了,就不能持续运营下去。所以广告的 Adload 应该限定在一个合理的范围内。这个合理范围需要通过 A/B 实验,分析不同 Adload 带来的商业变现,及相应的日活损失。以此计算出既能保证平台持续运营的最小商业化变现要求的范围。同时,尽量使得单次广告展现导致的日活损失值最小。(单次广告如何达到最高的变现效率是另一个问题,此处不展开讨论。)


另外,还可以更精细化的管理用户的 Adload——不同用户对广告的忍耐度是不同的。我们以用户生命周期来说,对于稳定期的用户,他们对平台的黏性最高,对广告 Adload 的容忍度也相对更高;相反,对于衰退期的用户,他们本身的流失风险就很高,此时如果再向他们推荐广告,很可能会加速他们在平台上的流失。所以,合理的做法是,针对不同的用户,加载不同的广告 Adload。在此过程中,数据分析师承担了用户分群的职责,通过合理定义用户所在的生命周期,帮助平台最小限度的减少流失用户、最大限度的实现商业化变现。

目录
相关文章
|
SQL 数据安全/隐私保护
通用数据级别权限的框架设计与实现(3)-数据列表的权限过滤
查看上篇文章通用数据级别权限的框架设计与实现(2)-数据权限的准备工作,我们开始数据列表的权限过滤. 原理:我们在做过滤列表时,根据用户权限自动注入到相关SQL中,实现相关过滤,如果拥有全部权限,则不生成相关SQL片段 首先我们来分析一下数据列表的SQL 能看到所有数据的SQL SELECT role.
1119 0
|
5天前
DataphinV4.0来啦 | 自定义全局角色 ,实时研发全场景覆盖
DataphinV4.0来啦 | 自定义全局角色 ,实时研发全场景覆盖
11 0
|
9月前
|
存储 druid 关系型数据库
MySQL数据库优化的方法和策略
MySQL数据库优化的方法和策略
|
分布式计算 搜索推荐 数据挖掘
数据自定义分析|学习笔记
快速学习数据自定义分析
68 0
数据自定义分析|学习笔记
|
算法 数据挖掘 开发者
关联模式评估| 学习笔记
快速学习关联模式评估。
149 0
关联模式评估| 学习笔记
|
安全 Java 开发者
案例之资源服务中加入校验用户所需对象|学习笔记
快速学习案例之资源服务中加入校验用户所需对象
62 0
案例之资源服务中加入校验用户所需对象|学习笔记
|
NoSQL Redis 开发者
数据删除策略|学习笔记
快速学习数据删除策略
122 0
数据删除策略|学习笔记
|
算法
数据策略分析
数据策略如何驱动业务增长
675 0
数据策略分析
|
数据库 开发者 Python
综合案例8-删除书籍 | 学习笔记
快速学习综合案例8-删除书籍
|
开发者 Python
综合案例3-增加模型数据 | 学习笔记
快速学习综合案例3-增加模型数据
102 0