点击上方"蓝字"
发现更多精彩!
信息流产品的内容分发方式包括:推荐、投放、push、订阅等,其中的"推荐"是最为主流/熟知的分发方式。但在实际的信息流产品中,通常是多种分发方式同时并存,共同打造内容生态,共同提升用户体验。
要证明世上没有鬼是很难的,但如果要证明有,却很简单,举例说明即可。同理,要证明为什么需要xxx,只需要说明:没有xxx,不行即可。
因此,“为什么要投放”,可转化为:“推荐系统在内容分发场景中有什么不足”,以此来进行具体分析。
推荐系统的一个最大遗留问题是马太效应”。一套虚拟系统,就是现实社会的一个映射,因此,在现实社会中存在的问题,在推荐系统同样存在,如上图所示:
这和20%的人掌握了全世界80%以上财富的现象、及原因,本质是一样的。推荐系统,本质也是市场经济体系:供应方(B侧作者),消费方(C侧用户),市场(推荐平台)。
因此,当该体系(推荐系统)出现“马太效应”这种合理、但并非合适的现象时,作为该体系中的每一方,当然都有逃脱不了的干系。
人,食五谷杂粮者,非要练就金刚不坏之身,确实是有些难为了。我当然知道,我应该看些有思想/有深度的文章/视频,但如果你天天给我推荐大长腿+大胸妹妹,我能不看吗??
我看下也就算了,推荐系统还非要认为是我自己想看的,然后继续给我推更长的腿+更大的胸,于是乎,我只能沦陷在此“温柔乡”了。可我知道,这并非我所愿...
有需求,就杀害:对于作者而言,写诗歌/散文,情怀固然重要,但在现实/钱面前,情怀不过是扯淡。
既然,消费内容的80%+,都是短/贫/快的无脑娱乐化图文/视频,那么对于真正的优质账号作者自然是致命的:没有生存的环境/土壤,只能是肥的拖瘦,瘦的拖死(要么逃,要么死)。从而使得内容池的2/8分化趋势进一步加剧,当然也会加剧消费情况的2/8趋势...
那么上述的“马太效应”,应该由这场交易的中间方(推荐平台)来背锅吗?当然不能!推荐平台,恰恰只不过是做了它本来该做的事,而已。
既然,推荐系统已经做了它该做的事情,为何结果却并不理想呢?下面从两方面分析:推荐系统是什么? 推荐系统有什么问题?
上图,是一个基本&通用的推荐系统架构。
推荐系统诞生的初衷,是为了解决海量用户 vs 海量内容的信息过载问题,注重规模效应。本质是以人(消费者)找内容,并且侧重为其中的人服务。也即是说,看似公平的中间人,实际是被消费者牵着在走,而忽略了内容生产方。注重开发利用,而忽略生态环境建设。
两个关键点:
总结:
在市场经济体系中,市场当然是至关重要,但市场本身是有缺陷的(贪婪/唯利),因此人为的宏观调控也是必须的。
同样,在信息流分发体系中,推荐当然是至关重要,但推荐本身是有缺陷的(伪喜欢/唯消费者),因此人工干预也是必须的。
你隔壁运营组同学的需求:
总之,运营需要一个可以人工干预的内容分发渠道,来满足他们的各种日常需求。
对于内容生产方的号主,同样有类似上面运营同学的需求。只不过,号主运营的是自己的多篇内容,而运营同学运营的是多个号主的内容。比如:
以内容找人,粗略等于一个内容发起的Push动作(推荐的人找内容,近似用户发起的Pull动作)。
Push分发,在一个产品的初期是很重要的一种分发方式,是拉新的基本手段,比如你常讨厌的红点推送。但由于Push操作过于强/硬,影响体验,容易导致用户反弹,因此,不适合长期/大规模发力。
订阅分发,如同共产主义,是美好、而不可达到,但可以无限逼近的?如果:
但,目前确实还没到来...
相对于我们耳熟能详的推荐系统,投放系统似乎更为陌生?其实,并不然。可以通过下图直观感受下投放的含义:
投放的字面意思:把某物品投掷出去, 并放置于某处。
三方:商家(外卖) -> 快递小哥 -> 前台妹子(消费者)其中,连接中介是快递小哥,连接的是商家和消费者
三方:作者(小视频) -> 投放系统 -> 前台妹子(消费者)其中,连接中介是投放系统,连接的是文章背后的作者和消费者
一个关键点:不管是射箭的妹子,还是骑手小哥,还是传书飞鸽,他们的起点/出发点都是物品侧。
在互联网领域,最早的、最常见的就是广告投放了。电梯、公交、地铁、移动App...,无处不在,无孔不入,所以我们无时无刻不是消费者,无时无刻不是在被消费。
广告投放的本质,是将平台流量,售卖 给有广告需求的商家。当然,在具体实施时,是一个反向过程:将商家的广告,投放给平台流量(消费者)。
所以,在这场活动中,投放平台方,服务的是商家(广告主),而C侧用户只是可以售卖交易的流量而已。
信息流投放,本质上和广告投放是一致的。只是投放的物品有所区别而已,信息流投放的物品,包括图文、视频、广告等多种形态。
在具体实施过程中,也是以内容找人,和推荐系统的以人找内容相反。投放强调的是:从 B侧->C侧的过程,和推荐系统以C侧需求为出发点相反。更加关注底层的内容生态健康,而非一切为C侧消费者服务。
当然,在产品/业务的发展初期,处于快速跑马圈地阶段,我们往往忽略(应该是来不及关注?)生态的健康问题。但,随着产品/业务逐步发展壮大时,曾经重要但不紧急的生态问题,就会变得重要而急迫了,因为这通常会关系到产品的生死存亡。比如随着市场经济迅猛发展的阿里粑粑,一不小心就可能被宏观调控了。
这也是为什么在信息流产品的生命周期里,一开始就必须要一套强大的推荐系统,而投放系统通常在中期阶段才出现的一大原因。
到此,终于将为什么,是什么,这两个基本的&&重要的背景问题讲完了。名正,则言顺,因此接下来的不过是具体实施细节,也就变得相对简单了。
如前所述,投放是连接B侧作者,和C侧用户的中介。因此,一套广义/完整的投放系统,至少/主要包括以下3部分:
下文,将按照需求/物品流向,即DSP -> TFX -> SSP的顺序,对各子模块的设计和实现进行具体分析。
DSP主要包括需求(投放任务)的接入和管理两部分,是整个投放系统的入口和触发点。
投放需求的来源通常是多方面的,比如:
在技术实现层面,由于需求来源很多,包括运营系统、创作者中心、C侧客户端等,因此在投放任务(需求)接入时,需要注意通用性方面的考虑,便于灵活快速的接入多端/多场景的各类投放需求。
投放需求(或投放任务,下同)的管理模块,和常规类CMS系统等,并无太大差异,主要就是增/删/查/改等操作(好吧,应该是我自己太肤浅了!)。
除CURD常规操作外,DSP的一个特殊模块是任务熔断。
投放,是一次交易活动的具体执行过程,那么这个执行过程到什么时候结束呢?这里涉及到的就是熔断策略问题,例如:
简单的说,熔断的基本原则就是,要求在规定的时间内,保质,保量 的完成B侧下发的投放任务。
当然,保质、保量,本身就是一对矛盾体,因此,这里是一个平衡问题。在实际进行中,如何提升投放效果,保证投放完成率,同时兼顾三方利益,一直是我们追求的优化目标。道阻且长,吾欣然往之。
连接B侧和C侧的投放中介,也就是狭义上所说的投放系统, 是整个投放体系的关键部分,也是一次投放交易的决策和兑现机构。一次投放任务的下发-执行的主要流程如下:
投放中介,可分为对接B侧的离线,和对接C侧的在线,两个子系统。以下将对两部分进行具体分析。
离线子系统,是直接和需求方平台(DSP)对接的,为DSP提供投放任务的排期决策服务。如前所述,投放系统通常需要接入来自运营/号主等多方的各类投放任务。如此多的投放任务(50w级),如何保质保量的完成,这不仅是在线兑现的模块的问题,还必须依赖离线的排期决策。
任务排期,即在投放任务的生成阶段,对该任务进行排期。简单说:相当于货(流量)仓调度员,当有人来谈生意(下发投放任务)时,需要根据自己手上的货物,进行实时的评估,然后决定要不要/能不能承接这一单生意,并为后面的兑现环节做好必要的准备!!。
排期的主要作用/目的:
任务排期的几个关键步骤依次如下:
回顾一下,你带女朋友去超市买雪糕的场景即可:
你:老板,有东北大板的雪糕卖吗?
老板:噢,我看下....有,你要几根嘛?
你:给我妹子一根就好了
老板:来....
一些具体的排期策略:
投放任务:一个短视频要在48小时内,投放10w的曝光量
当然,具体的排期策略,在不同的产品/业务场景,或者同一产品的各阶段,都会有很多差异,这里只是列举一些基本/常用的策略,以供参考。策略,永远在优化的路上...
库存管理是排期策略得以实施的底层支撑。库存管理,类似一个忠诚&勤劳的仓库管理员。需要对流量库存的已使用、剩余、时间分布、定向分布等了如指掌。为上层的排期决策,提供细致准确的数据信息支持。
流量库存的数据,需要从在线服务进行抽样/采集,从而得到各个业务场景的具体流量分布情况。
在线子系统,即投放任务的真正执行/兑现机构。在C端用户请求进入时,根据任务的定向条件,或者lookalike智能扩散等,召回与用户匹配的任务,曝光给该用户,即兑现一次该任务的曝光流量。
在早期,由于投放任务量较少(1w条以下),所以一种简单粗暴且高效的方案是,在线过滤匹配即可。当用户请求进入时,循环遍历投放任务列表,把任务的定向条件与用户画像进行匹配,由于任务量很少,耗时通常在50ms以下,完全满足需求。
当任务量不断增加,则需要建立召回索引,提高在线检索性能。
定向召回的基本流程和架构,与常规的推荐召回是一致的,包括数据源接入、数据预处理、离线索引构建、在线检索等4个主要部分。架构图如下:
值得注意的是,在具体实现上,传统的倒排索引方式,无法直接满足定向召回的需求。其根本原因在于,推荐与投放是有本质区别的:
例1(错误示范):按推荐的传统倒排索引进行召回
例2(正确示范):按改良后的定向索引进行召回
改良的关键点在于,补齐/显示化所有需要匹配的定向维度,以解决召回结果被放大的问题:
经过补齐后,在检索时,就会检查到任务要求的所有定向维度,从而得到正确的召回结果。
当然,补充操作会带来一些额外代价:
这些额外代价,也可以通过继续优化去缓解,比如增加二级索引等,来解决在线检索的性能消耗问题( 具体细节,后有专文介绍 )。
凡是我们知道的问题,都不是问题;问题是那些,我不知道有问题的问题。
定向投放,只能解决明确知道目标用户群体的情况。而很多时候,运营/号主,并不知道他们该把这边文章投放给什么样的用户群体。对于这种情况,就需要一种更加智能的投放方式了,比如基于lookalike的人群扩散方式。
在智能投放(自动化人群圈定)场景下, 即根据已有的少量种子用户,通过算法模型来计算其他用户 与 种子用户的相似程度,从而得到一个与种子用户群体相似的,更大的用户群体。
在投放时,即可将该“相似的,更大的用户群体”作为投放任务的目标人群,进行投放,从而解决定向条件未知的问题。
在具体实现中,这里也涉及很多方面,比如:
整个投放系统,供应/售卖的是C侧用户带来的流量。流量,即资产。因此,供应方平台解决的就是,如何通用灵活的接入C侧流量的问题,尤其在类似一些多端多场景的情况。
当然,如果要建设一套通用/开放的信息流投放平台,自然就需要接入更多的流量场景,并且要灵活快速的支持各场景的随时下线和新增上线等需求。
供应方平台涉及的相关技术点,主要是常见后台接入层的系列挑战,如: 一些需要考虑的基本问题:
由于这些挑战点,与投放本身关系不大,因此就不再具体展开讨论。
到此,对一套投放系统所涉及的最主要模块进行了逐一的分析。当然,还有很多子模块,如连接离线与在线的任务分发模块,负责播放控制的Pacing调控模块,以及投放效果管理平台(TMP) 等等,这些遗留部分,后续争取找机会分享补齐(如果你相信的话)。
在此给出一张一般/通用的投放系统的完整架构图,以供参考:
沿着,为什么要投放,投放是什么,怎么做投放,这样的路线,对一般意义上的 && 通用的信息流投放系统,进行了深入浅出的 && 较为完整的 讨论(自认为如此?)。
一套完整的投放系统,所涉及的点确实很多,包括:B侧/平台/C侧, 管理端/后台/算法/客户端等诸多参与方。本文,仅根据个人在业务实践中的理解,斗胆分享一些浅薄的所思所想,以供参考。部分术语并非十分严格/准确,部分思路也未必正确,欢迎各位随时交流讨论 / 批评指正。
由于篇幅 / 时间所限( 其实还是懒),文中抛出了诸多悬而未决的问题点。仅 "具体细节,后有专文介绍" 这种骗人鬼话,就出现了5+次,在此,有必要对看到3+次的你,表示感谢和歉意。
最后:
感谢团队里一起建设投放系统的小伙伴;
欢迎各信息流的相关团队/同学,进行更加深入的讨论和协同共建等
作者alieyu(腾讯VTeam技术团队高级工程师)公众号↑↑↑
腾讯VTeam技术团队公众号↑↑↑
你的每个赞和在看,我都喜欢!