数据与广告系列七:广告与推荐系统技术架构

广告与推荐系统技术架构。

数据与广告系列七:广告与推荐系统技术架构

作者|黄崇远(题图:pixabay.com,CCO协议) 

01 

接上篇文章《数据与广告系列六:一图读懂在线广告产品交互关系》,上篇逻辑里核心是从产品逻辑的角度,来阐述整体广告生态中不同的产品以及平台的角色。而这篇,我们则从偏技术以及数据逻辑来了解整体的在线广告系统的技术架构以及数据流向来做分析。

在做正式的分析之前,我们先把《计算广告》中涉及的技术架构图来一张(重新绘制就没有必要了,手拍一张,凑合着看先,后面有数据虫巢这边按逻辑理解的再绘图):

数据与广告系列七:广告与推荐系统技术架构

从整体的角度来看,其实相对还是比较完善的了,基本把整个广告技术逻辑,以及各个部分的角色阐述清晰了,但从个人的角度来看,更期望的是更偏技术的逻辑,甚至是数据流转的逻辑来理解这么个整个技术体系。

所以,我们围绕具体一些的技术选型方案以及数据流转的动向来理解整个在线广告的技术架构逻辑可能会更容易理解一些。

02

在看我们重新理解绘制的“在线广告技术架构图”之前,我们来看一张数据虫巢这边之前做推荐系统的时候绘制的推荐系统架构逻辑图:

数据与广告系列七:广告与推荐系统技术架构

之前我们就一直有提到过,推荐系统和广告系统有着天然的一些联系,关于业务逻辑这块,我们可以参考第二篇《数据与广告系列二:计算广告和推荐系统》。这里我们回到技术维度,我们从推荐的技术架构来推演广告的技术架构,以及类似的数据流转逻辑。

回到上图,推荐的核心几个逻辑步骤是:

1.做推荐候选的召回处理

2.做推荐候选的排序逻辑

3.进行推荐的策略规则干预逻辑

4.进行推荐的服务化输出

其中召回部分有很多推荐相对专用的召回算法或者召回逻辑,这是一个候选初筛的逻辑,关于工程实现部分的差异,当然,大部分都是离线模式下的召回,也有强依赖于工程数据流转的实时召回逻辑。这部分应对的是广告的候选初筛,当然逻辑会有些不一样,并且可能实时性要求更强一些,所以在算法复杂度上会弱一些,但对于标签体系的要求会高很多。

在排序部分,实际上就是根据特征做点击预估的计算,追求的点击转化率。这个维度跟广告相似度是非常之高的,只不过广告对于点击预估的要求会更高,毕竟涉及的都是真金白银,所以在点击预估这边投入的技术成本会多很多,不管是对于特征的处理,或者对于算法的复杂度都会有所提升,核心目标就是点击预估率要高。

规则引擎逻辑部分,其实说白了就是各种人工因素的干预部分,这部分跟广告部分几乎较少关联,因为推荐是介于用户体验和广告中间态的一种逻辑,所以必然要考虑一些人为的因素。

而服务化的部分,其实跟广告的最终服务化差异性不大,承担并发压力,各种实验标志的传递输出等等。

还有一部分非常核心的就是推荐的实验平台,核心承担目标是推荐的效果优化,类似广告逻辑里也有类似的优化核心承担的逻辑模块,包括数据BI分析逻辑和策略优化逻辑。差异点较大的是,广告的BI数据逻辑部分是需要开放给广告主的,不单纯需要内部使用,还需要封装成对外的数据查看逻辑,而推荐则基本都是自用辅助实验平台。

这是核心主逻辑的技术逻辑结构差异部分,更多的逻辑我们结合着数据虫巢重新理解的“在线广告技术架构图”来阐述,毕竟我们的主体是广告。

03

我们来看一下具体的技术逻辑架构图:

数据与广告系列七:广告与推荐系统技术架构

先来看一下在线广告的主逻辑部分(深橙色部分):

1.广告检索

2.点击预估部分

3.广告排序部分

4.广告输出的服务化

针对于广告检索,其实就是广告的召回部分,做广告资源的候选召回,这里的广告检索召回,很多时候对于实时性要求会高一些,有别于推荐的各种离线推荐召回算法,这里更多依赖于auc三源(a广告,u用户,c投放环境)的标签,直接通过标签匹配来做快速检索,所以很多时候这里会大规模使用倒排索引相关的技术,如果是开源的解决方案推荐的就是ElasticSearch等检索引擎。

在点击预估部分,追求的是单次广告输出的转化率,由于在最终排序的逻辑里,点击转化率起到了非常核心的影响作用(没有转化保证,其他的因素都可以忽略),所以这里不管对于CTR模型输出的算法要求也好,对于特征的处理要求也好都非常严格,并且大部分时候为了保证CTR的准确率,都要求对于实时性的特征流转要求很严格,要求能够快速拿到实时的特征做特征输入。

在特征部分,又是一个巨大的工程体系,涉及到实时和离线特征如何计算,特征如何进行快速维度扩增,而扩增之后的十万级百万级甚至是千万级维度的特征如何存储,以及如何解决稀疏高效存储计算的问题等。

在最终的排序部分,这部分跟推荐的差异性最大,需要综合考虑上一步骤里的点击预估转化率,还要考虑商业因素(Money),以及对于平台方来说要赚长远的钱(不是一次性的消耗),所以结合上个逻辑计算的CTR评分,结合用户的竞价(具体竞价逻辑参考第四篇《数据与广告系列四:搜索广告来源和竞价策略》),以及广告主的质量评估(优质可持续投入的广告主,更受广告平台的欢迎),最终加权计算一个排序出来,通过排序来决定有效广告位资源的归属问题。

特别需要提出来的是,在广告主评分计算逻辑里,针对于有投放记录的广告主来说,评分相对容易,毕竟之前有各种投放记录,甚至包括投入的预算等等,通过一个相对合理的预估是能够评估出来广告主的有效长期价值的,对于新的广告主来说可能更多需要依赖于人工运营/标签化,以及外部舆情的一些手段来做辅助判断。当然,从整体逻辑看以及结合前面文章的逻辑,我们可以预估的出来整个的质量评分还是偏向于辅助作用的,更多依赖的是点击预估和出价。

在服务化这层不多说,多出来的是与竞价逻辑结合起来的预算管理模块,一般在竞价逻辑里实际上每次出价都是需要约束好预算的。

04

上面这些是主逻辑部分,而整个在线广告技术逻辑架构里比推荐逻辑相对还是复杂一些的,除此之外,还有几个非常重要的部分。

先来看数据流向逻辑,广告部分对于数据的实时性要求更高,不单纯是实时特征部分的专门性要求,哪怕在数据BI维度上,实时性要求也非常高,除此之外由于Money结算涉及到多方结算,不同于推荐的单一主体平台,所以在数据风控上有很高的要求,比如进行点击异常数据的判别等。

外部的另外一部分就是整个广告逻辑的优化策略部分,针对于召回的策略,点击预估的算法,排序的策略,竞价的策略,甚至是与数据关系不大的创业自动生成策略等,都可以与推荐一样做各种精细化的流量分发控制,再结合数据回流来做调整和优化。

还有一部分就是非常核心的新客发现逻辑,即依赖于一方数据(广告主数据),二方数据(广告平台累积数据)以及三方数据(购买的第三方数据)集成做的投放种子人群,通过种子人群计算种子人群的各种标签画像,结合以有的用户资源池做人群的扩散计算。

而针对于Look-Alike人群的扩散,其实方式方法也非常之多,比如单纯计算人群的相似关系,看似很简单,但规模一旦很大的情况下,计算相似关系也需要面对很多的挑战,比如数据的处理,相似关系计算的代价等等。当然,也有很多应对的方式,比如做人群聚群再进行相似关系计算,标签的相似关系召回。以及,在当前移动互联网如此“横行”的时代里,通过社交关系做的扩散非常之有效,有兴趣的可以去了解一下腾讯的人群扩散的相关资料。

除了我们从技术架构图上可以看到的一些信息流通道,实时离线的计算,仓库的应用等等,针对于大规模使用的标签相关的问题解决也需要关注,比如标签如何做大规模的存储和计算,以及相对麻烦的标签维护扩充和维护等。

04

综上,我们对于整体在线广告的技术逻辑架构,以及围绕技术架构的数据流转都应该有了个认知,当然细究每个部分都有非常多的东西值得研究,比如单纯标签,能做的事就很多。标签维度的设计,标签的计算存储,维护更新,都可以成为一个研究的课题。还包括诸如重头部分CTR如何做的更好,召回排序模型的优化,服务化的并发承压和效率等。

在后续的一段时间里,这个系列一定会继续补充,并且甚至是做一些细节程度的分析和深入,但短时间内这个系列可能先告一段落,大概几个月后会做新的衍生补充。当然,如果有时间的话,也可能会补充一篇关于广告数据分析维度的东西,看时间了。

而这篇文章本来也应该是一周前发的,由于个人离开了待了三年的坑,跑去度假了,所以耽搁了些许,下周要入新坑了,所以短时间内不一定有时间来写这么偏严肃性的文章了(严肃性的文章真的很费脑),而且发现了一个非常之悲剧的事就是,一旦涉及偏严肃性质的文章,阅读量就嗖嗖下降,哈哈。

打完收工,下个坑绿厂,而且刚好真的是广告方向,或许有缘我们会相见,或者我们下篇文章见。

本文为专栏文章,来自:数据虫巢,内容观点不代表本站立场,如若转载请联系专栏作者,本文链接:https://www.afenxi.com/73918.html 。

(1)
上一篇 2019-05-18 23:13
下一篇 2019-05-25 17:43

相关文章

关注我们
关注我们
分享本页
返回顶部