浅析RTB和RTA（三）

接着上一篇文章《浅析RTB和RTA（二）》，今天我们开启这个系列的第三篇也是最后一篇。

RTA（RealTime API）实例

根据前面的介绍，我们会发现RTA真正发挥作用的阶段其实是检索阶段：查询对该用户有潜在付费意愿的广告账户列表，Account[n]。

我们来看一个具体的例子：

选定策略：根据用户价值ltv进行决策，对于某个广告账户而言都有一个期望的ltv门限值，当用户ltv<账户ltv门限值时，认为该账户没有获得该用户的曝光权的意向，也就是不会被加入后续的付费意愿广告账户列表Account[n]。

思路迭代过程

（1）最开始时，要决策是否加入Account[n]，最暴力的方法莫过于当有用户发起广告请求时，立刻去数据库查询用户的信息，统计用户的历史行为，根据一定公式（比如对历史行为：点击、激活、充值等打分并且加权求和）计算出用户价值，然后和广告账户的门限值做对比，筛选出Account[n]。这样的方法简单且容易实现，但是用户量大时会带来大量的数据库查询和用户价值计算的资源消耗，而且并发量过高时难以承受。

（2）为了解决上述多查询和计算量大的问题，首先我们可以考虑加入缓存，减少查询的压力，但是计算量大的问题依然存在，这时候为了减轻计算压力，我们可以考虑由广告主离线筛选出一些人群包，我们定时将人群包写入缓存中，当用户请求来的时候直接去查缓存，找到的就说明是用户价值达标的，将广告账户加入Account[n]。

（3）上述的方案解决了查询和计算的问题，但随之而来的问题是，我们是定时用新的人群包覆盖旧的人群包，但如果在新旧交替之间，用户的行为数据会有一个时间差，缺少实时性，为了解决实时性，我们可以将定时筛选人群包的任务交给广告平台来做，在线任务是接收用户请求，离线任务是根据用户的数据来筛选人群包，并且写入缓存，这样用户请求来的时候，直接查缓存就知道要不要将广告账户加入Account[n]。

（4）这时候大家觉得，实时性和高可用性都解决了，应该可以使用了吧？然而并不是的，处于业务需求，有些数据广告主是不能或者不愿意透露给广告平台的，比如银行想要投放一批广告，要先提出低征信或者无征信的用户，但是征信在法律上属于隐私，是不能透露的。又或者淘宝想要定点向购买能力高的用户投放一批广告，购买能力这个数据属于商业机密，淘宝不愿意透露。在这种情况下，只能将RTA的过程下沉到广告主的DSP（需求侧平台）平台来完成，也就是广告主自己根据自己的数据离线训练并写好缓存，当有用户请求到达ADX，ADX直接转发给DSP，DSP后接RTA模块，此处不同广告主可以根据自己的需求，选择不同的策略接口来筛选自己的广告账户，最后只需要返回参与竞价的广告账户和出价即可，后续的工作交由RTB来进行。

所以RTA主要的特性有以下三个：

（1）实时性

（2）数据安全性

（3）策略多样性

这也是Realtime API的名称由来。

本文结合一个具体例子引出了RTA的三个特性，实时性、数据安全性以及策略多样性。如果你喜欢我的文章或者我的公众号，记得分享、点赞、顺便点个在看再走哦！

欢迎大家关注计算广告那些事儿，除了原创文章之外，也会不定期和大家分享业内大牛的文章哈！