【AICon】探索RAG 技术在实际应用中遇到的挑战及应对策略!AICon精华内容已上线73%>>> 了解详情
写点什么

阿里定向广告智能投放技术体系

  • 2021-05-08
  • 本文字数:12984 字

    阅读完需:约 43 分钟

阿里定向广告智能投放技术体系

随着经济数字化地快速发展,互联网广告在赋能商家营销、帮助消费者高效了解商品和服务、以及商业平台的变现等方面扮演着越来越重要的角色。互联网广告生态中,广告主通过付费在媒体上对目标用户进行营销信息传达来完成营销过程。其中,广告主通常希望在有限的资源投入下最大化营销效果。然而流量环境、其他参竞广告形成的竞争环境的复杂性、以及广告投放策略中出价、目标人群、资源位、投放时间等变量的巨大组合复杂度,使得最优广告投放策略的计算与执行充满了挑战。通过本文,我们将从更好地帮助广告主做营销的视角出发,比较系统地介绍阿里妈妈定向广告团队基于广告主投放需求不断技术创新,建立起的一套持续演进的广告智能投放体系,具体包括预算约束下的报价策略、多约束下的报价策略、合约保量报价策略、基于长期价值的序列投放报价策略、跨渠道智能投放策略等核心技术能力的算法与实践经验。

背景介绍

今天主要分三个部分,第一部分先介绍广告业务的背景,第二部分会沿着如何帮助广告主更好地做好营销的历史脉络,讲解智能投放体系和技术的演进过程,最后会给出整个演进的总结,以及对未来的展望。

1. 广告业务背景概述


首先广告是什么,我把它抽象成了这样三个部分,在广告生态里,包括广告主,媒体(或者广告平台)和用户。广告的逻辑就是广告主在媒体上付费,通过媒体对目标用户进行营销信息传达,影响用户,让用户购买广告主的商品,形成信息和金钱的流动,也形成用户广告之间物质的流动。


作为一个广告平台来说,在中间起到了一个很重要的桥梁作用。一方面是要能够给广告主提供足够多的功能,让广告主表达诉求,然后广告主也要通过合适的方式向媒体付费。


另一方面,媒体还要基于广告主设定的策略,决定把广告投放给谁。所以媒体在中间起到桥梁的作用,要设定好广告对接机制,向广告主售卖的机制,以及把广告主的物料用怎样的投放策略投放给用户。


为什么需要这个机制?因为流量类型多种多样,售卖的时候,既可以按点击去卖,也可以按展现去卖。卖广告的时候,可以卖给品牌类广告主,或者卖给效果类广告主。另外卖流量的时候,怎么去收费呢?

其实这些问题都是需要去想清楚的,因为只有把这些事情想清楚了,这个商业模式才能够确定下来,才能够迎合当前市场的整体需求。


这里要考虑的角度是两方面,一方面就是媒体自身业务,要思考它的发展,然后去设计符合媒体自身的机制,包括商业化率,如何去介入,整个坑位的布局,出价,溢价等等。另一方面就是广告主方面机制的考虑。媒体以什么样的方式给广告主定价?广告主是手动类的出价?还是以合约的方式,让平台来去帮广告主计算出价等等。这两方面都有非常多的概念要去考虑,才能把商业模式确定下来。


除了考虑机制之外,还要去思考这个平台如何帮助广告主选择合适的广告投放策略。


场景一:CPM 计划

有的客户说我要以 50 元的 CPM 出价,在手机淘宝上首猜 1 坑投放 3 天,预算没有上限。这是一个以 PV 曝光为出价的方式购买广告,收费也是要按 PV 的方式计费。


场景二:合约计划

有的广告主要以 60 元的总价格在 1 天内购买 1000 个展现。广告主不关心单条流量的情况,只关心整体的投入和产出。在这样的设定下,平台就一定要保证广告主的投入和产出结果,这种就是合约类的计划。


场景三:序列投放计划

这是我们今年的一个创新:有的客户说要投一个广告计划,这个计划可能投放很长时间,对用户可能会产生多次的曝光和持续的影响,希望通过这种持续的影响,能够优化累计转化数。这种在广告策略上不一定追求短期的收益最大化,而是要去追求一个长期累积的收益最大化。


所以这里会迎合不同广告主的诉求,平台需要具备给出不同的广告投放策略的能力,提供一个成体系的工具,服务好广告主。

2. 广告业务迭代的历史脉络



阿里妈妈的广告体系也经过了很长时间的积累和迭代。从 2016 年开始,在售卖机制/投放方式上,从最朴素的 CPM/CPC 类的广告到衍生出来在流量粒度上能够去预估价值,并且基于预估出来价值去对流量粒度做出价调整,衍生出来 OCPM/OCPC 这样能力。为了保证广告主的结果的确定性,又有了合约保量的能力。这些 CPC/CPM/OCPC/OCPM 其实还是依托于广告主手动出价,它有运维的成本。在这个基础上我们又做了升级,让广告主只表达一个整体的投入和结果的预期,这样平台能够结合预期去自动的帮广告主在每条流量上出价,所以又有了 BCB ( Budget Constrained Bidding ),就是预算约束下自动出价和 MCB ( Multi-Constrained Bidding ) 就是多种约束下的出价。


我们今年有一个新的工作就是叫 Multi-Channel Sequential Budget Constrained Bidding。我们可以跨各种渠道,通过序列的投放广告影响用户,然后形成预算约束下的效果最大化,所以整个发展的脉络的能力是不断升级。从优化目标上,我们也是从最早的优化通用的展现/点击,到优化成交/ROI,到优化电商系统里面用户对商品的加购/收藏/关注以及任意的后验目标,包括从短期价值到任意的长期价值的优化,所以优化目标能力也是在不断地演进的。我们这些相关重要的工作,也在国际会议上有论文的发表,包括 KDD,CIKM,ICML 等等。

3. 广告业务技术能力总结



这里把我们积累的能力做下总结。最早的时候,广告主在广告平台上朴素地按照 PV 或者点击出价。这种出价其实是一视同仁,比如所有 PV 都值 1 元,所有点击都值 0.5 元。在这个基础上,我们做了 OCPM/OCPC 的升级以后,每个 PV/点击的价值就可以去做实时地预估。做了预估以后,比如广告主认为一个点击值 0.5 元,而我们认为点击的价值更高,就可以把 0.5 元调整到比如说 0.7 元。如果这个点击价值低,可以帮广告主把 0.5 元调整到 0.3 元,所以就实现了流量粒度的价值预估和优化。进而再去升级到 BCB,对结果也能有一个提前的确定性保障。考虑到流量波动是很大的,尤其是像双十一或者 618 这样的大促,广告主对销售 KPI 和最终结果的保障性有强烈的要求,他在这一天必须把这钱花出去,拿到这么多流量。我基于对过去的流量和未来流量的规律把控,能够帮助广告主去保证它的效果,就迎合了广告主的诉求。预算约束下综合出价,就是帮广告主从手动挡升级到自动挡。多约束下自动出价,就是我们除了帮助广告主去满足预算的约束,有些广告主他不希望自己的一个 PV 或者一个点击的花费太高,所以他会提出一个点击必须在 1 元之下,一个 PV 必须在 0.1 元之下,这种其他的额外约束,在我们平台现在也是可以表达的。表达了之后,这些约束我们都会帮他满足,然后具有一个相应的自动出价的能力去把这个计划投放出去。


到了 2019 年的时候,我们也推出了合约与 RTB(real time bidding)环境的优化。这个合约就是我们要去提前保障广告主结果的确定性。但是这种合约在很多广告平台里跟 RTB 实时竞价是隔离开的。合约就是这份流量约定好就这么卖了,而实时竞价就是按实时的竞争拍卖结果卖,但这种割裂的方式显然是不符合市场经济,而是用计划经济的方式把两种模式强行分开,然后分别去做优化。最好的市场经济方式是把合约跟 RTB 直接混合起来,然后用市场自己调整的方式去得到全局的最优化。


但这个也带来很大的挑战,因为 RTB 的波动,势必对合约会产生一些不确定的影响,那么合约还能不能保证广告主的结果?并且合约和 RTB 混合起来,是不是能做到全局的收入的优化?所以这都是很有挑战的问题。


今年我们提出来序列投放优化长期价值,很多用户看广告不仅是看一次。但是很多广告平台有频控,用户只能看一次广告,再来广告曝光,就简单粗暴地不允许用户看了,用这种很生硬的方式进行频控。但根据我们的统计会发现,在电商领域有很多用户,第一次看广告,是不会去购买的,但是第二次看了广告,可能就购买了,而且可能超过 50%的购买都是发生第二次广告曝光或者第三次广告曝光。这也就出现一个问题,有的用户确实让他只看一次是合理的,因为他这次没有兴趣,以后就没兴趣。但是有的用户给他多看几次,他的心智会有加强,反而会形成一个累积的购买结果的最优。所以我们今年也推出序列投放,就是希望能够去挖掘用户的长期价值,让广告系统再去评估广告投放或者不投放的时候,不再单一的看这一次 ECPM 单次的最大化,而是要看整个长期对用户序列的运营是否能做到最优化,对序列化投放基于长期价值这个角度去优化广告的投放。


最后,我们今年也有一个很重要的产品叫 AI 智投,解决广告主的一个很大的痛点。广告主现在可以有很多的营销平台,去投品牌广告,搜索广告,还有定向广告。所有这些广告,广告主从传统的角度来看,只能把自己的广告预算按照过去的经验去分拆到这三种不同的渠道上面,然后在不同渠道内部,再做相关的人群设定、出价设定方面的优化,但是不同的渠道之间怎么做整体优化呢?这也是一个很重要的问题,所以我们从单渠道的优化走向各种各样多渠道的全局优化。整个所有的功能升级,在接下来的智能投放体系和技术里面,我会一个个给大家做一个简要的介绍。今天我们也重点介绍背后的算法核心思想,因为我们大部分的工作都是有相关论文的发表,所以对于里面一些数学的细节,大家可以去看论文。

智能投放体系和技术

1. OCPC/OCPM

① 广告主需求

广告主说:“我已经习惯了 CPC,在此基础上,能帮我做点别的吗?”      

在这个基础上,我们可以做 Optimized Cost Per Click ( OCPC )。


② 优化方案



第一,广告主对 CPC 出价,是所有点击一视同仁的,但不同的点击其实价值是不一样的,按统一的出价其实很不合理。


第二,广告主有时候有多维度的优化诉求,不单单只想拿更多点击,可能还有点击之后的转化价值,比如说购买/加粉,这些诉求广告主也是希望优化的。


那么基于这两点,OCPC 就可以在广告拍卖机制下借助系统的能力进一步优化客户价值。那么它是怎么做到的?我们看在 GSP 拍卖机制里面,传统的广告排序依赖的分数叫 ecpm,那么它的在 CPC 广告里面它的计算公式是 ecpm=org_bid(广告主的原始出价)*pctr(这条流量的点击率),然后就会按照这个做排序。


在激励兼容的机制里面,广告主的原始出价是基于一段时间一个流量的平均价值基础出价的。广告主可能上午 10 点开了这个计划,他认为从上午 10 点到晚上 10 点这 12 个小时每个点击的平均价值就是 0.9 元,所以他就出了一个 0.9 元。这是基于一段时间的流量的平均的评估,显然是有缺陷的。在平均的意义上,广告主的出价跟流量价值确实达成一致了,但是在单条流量上,对广告主的价值有可能是有差异的。比如广告主如果关注的是点击之后的转化价值,那么有的点击背后是能够形成高转化的,有的点击背后是不能形成高转化的,因此不同的点击背后价值就不一样,相应的出价也应该不一样的。造成缺陷的一个主要原因是广告主不能对单条流量去评估价值,因为他不能钻到我们的系统里面来观察每一个流量的价值,靠人肉是做不到这一点的。所以改进的办法就是我们要对广告主原始出价做一个调整,把它变成一个叫做 optimized_bid,那么 optimized_bid 就是在广告主的原始出价 org_bid 的基础上去乘一个因子,这个因子是 pValue/baseValue。分子 pValue 就是在单条流量上,我们利用系统里面的机器学习模型,能够实时地去感知流量用户的信息和广告的信息,然后利用这两个信息去给出单条流量的价值。它放在分子这个位置,说明 pValue 如果高,流量价值就高,可以往上调一点价格。如果 pvalue 低,那么这条流量价值低,可以往低调一点价格。pValue 是需要有一个锚定点的,锚定点就底下的 baseValue,baseValue 是基于历史的数据去评估广告主表达的流量的平均价值,比如它过去所有这些流量的平均的转化率是多少,或者平均的关注率是多少。这里 pValue 和 baseValue 是一个点击后的价值,这个客户是需要通过在平台上去表达的。比如说他是想去优化转化,或者想去优化收藏,或者想优化关注。有了这样的一个基于 pvalue 和 basevalue 对 org_bid 的调价,在我们新的 ECPM 排序机制下,就可以用 optimized_bid 的去做排序。


③ 效果评估

在这个情况下,广告主和平台是双赢的。对广告主来说,相同预算下,价值回报上涨,ROI 提升了。因为他以前买这个东西都是一视同仁的,现在可以选里面最好的东西去买,除此之外也给广告主提供了多维度的价值优化,比如优化转化,或者优化关注。


对于平台来说,广告主 ROI 提升了以后,他肯定觉得在这个地方投资回报率高,应该投入更多的预算,然后获得更多的回报。那么广告主意愿的加强,也会对平台带来收入的增长。所以整个 OCPC/OCPM 也是很类似的一个思想,它的核心理念就是这样。

2. BCB(Budget Constrained Bidding )

① 广告主需求

广告主手动出价之后,我们怎么帮助广告主把手动的出价的价值精细化到流量的力度?

有的广告主说自己还要去评估平均价值,运维成本很高,而且广告主经常有很多商品,要开很多计划,计划里面又有非常多的定向人群,或者是买词,那么每个人群或者词上都要去调价,操作成本就非常高。

所以广告主能不能就花这么多钱,然后帮他达成一个最优化的目标?比如“我每天可以花 1000 元,能帮我买到尽量多的粉丝吗?”。广告主不想去关心具体怎么出价,让平台去帮助他去自动出价。


② 优化方案

针对这个需求,我们推出了相应的产品叫 Budget Constrained Bidding,就是在预算约束下自动地出价。这里我们给出一个生动的例子,让大家看一下它是一个什么样的概念。



比如我们的目标是在广告主有六美元的预算约束下,要尽可能去获得足够多的点击。底下横坐标轴是时间,就是广告计划,比如今天凌晨 0 点开始投放了,到今天 24 点结束,那么在这 24 个小时里面,一共有这么多蓝点流量让广告主去竞争。这些蓝点代表的流量的市场成交价都不一样,有的是 1 美元,有的是 2 美元,有的是 3 美元。对于广告主来说,为了获得更多的点击,即想要更多的蓝点儿,他应该怎么去出价呢?广告引擎里面的“小机器人”,根据自己的算法,就会沿着时间,对于每一条流量会做判断这个蓝点要还是不要。


  • 小机器人看到第 1 条流量的成交价格是 1 美元,觉得这是一个很高的性价比。因为 1 美元就可以拿到一个点击,所以它就会把它拿下,之后预算就从六美元变成了五美元。



  • 然后接下来他又遇到第 2 个流量,这个点击要花 3 美元,性价比就非常低,决定不要这个流量了,那么红色就不竞得。


  • 再接下来它又看到一个 2 美元的点击,觉得性价比还不错,所以这个也拿下。


 

  • 然后我们的预算就进一步减小,现在只剩 3 美元的预算了。然后又有一个低成本的流量,拿下。

 


  • 然后第 5 个蓝点的价格很高,不要。


  • 然后,第 6 个蓝点又拿下。



  • 最后一个不要。


这个时候今天所有的流量也就结束了,预算也花光了。

从结果来看,我们这个算法把所有 1 美元和 2 美元的点击全部都拿到了,3 美元点击都扔掉了。从一个点击上的成本来看,它把性价比最好的流量全都拿到手里面了。所以这就是 budget-constrained-bidding 的概念,具体它的算法是怎么去设计的呢?


首先我们要形式化这个问题,在给定预算 b 的前提下,要尽量拿到最多的价值。比如,这里要拿到最多的点击,那么在竞价广告里就变成了系统要对每条流量出一个报价,让最终的目标函数最大。底下的 maximize 的 bi是对每条流量上的出价 ( i 指的是零到 24 小时所有的流量 )。这里的“1”是一个示性函数,ci是这条流量的市场成本 ( 即市场成交价 )。如果 bi出价大于市场成交价,那么这条流量就竞得了,这个示性函数就取值为 1。如果出价小于市场成交价,就没有竞得,示性函数就是 0。旁边 vi是这条流量的价值。如果 i 定义的是 PV 粒度的流量的话,这是一个 CPM 广告的建模方式,这里每一个示性函数取 1,就说明曝光 PV 拿下了。vi就可以理解为曝光的价值,比如说 vi如果是点击价值,那么用户点击了,vi就是 1,如果没点击,vi就是 0。底下的约束也是一样的。对于所有流量来说,每一条竞得的流量对应的 ci是市场成交的价格,所有流量市场成交价格加起来,不能超过总的预算。所以这个就是预算约束下的价值最大化的建模。如果我们把这个示性函数当做一个变量,比如说把它当做 x ( x 可以取 0 或 1 ),它其实就是一个线性的优化问题。


在优化问题方面,张伟楠老师的参考文献里面从连续空间做了分析,最后得出这个问题的最优出价公式 bi*=vi*。他的分析办法,是把它看作一个原问题,然后用拉格朗日的办法把它转换成一个对偶问题,然后对对偶问题去做分析,得到最优的出价,就等于单条流量上的价值除以一个固定的参数λ*。大家要注意这个地方的λ*,就是 0 点到 24 点的 24 个小时里,对所有的流量λ*都是一个固定的值,然后 vi就是每一条流量的价值。所以它的直观的含义就是:对于任何一个流量来了,流量的价值高,我出价就高,价值低,出价就低,出价跟价值完全是正比例的线性关系。线性关系的系数就是 1/λ*,λ*可以通过历史数据,对线性问题直接去求解。这个求解也是非常容易的,直接能得到一个最优λ*,但是实际情况其实会更复杂一些。我们可以从下图看出,在实际广告投放的时候,在一天的 24 小时里面,首先,流量的波动是很大的。其次,我们可以看出不同小时的出价波动也很大。我们再看红线跟蓝线,天与天级别之间它的差异也很大。所以根据历史数据,虽然利用规划类的软件就能把λ*解出来,但它不一定在明天还能够适用。所以λ*求解既要结合过去的数据,也要结合当天实时的数据,这个解法一般可以用反馈控制的方式去解,也可以用一些强化学习的方式去解。


λ*的含义是什么?其实它是一个性价比的阈值。我们看到 bi*是出价,如果按照广告的二价计费,小于 bi*的最后市场成交的流量都会被拿下。我们可以看到λ*=vi/ci,vi是流量的价值,ci是流量的成交价成本,vi/ci其实就是性价比。那么处于λ*这个性价比之下的这些流量 ( 每一个蓝点都是一个流量 ) 都会被竞得,因为这些流量的最后的 ci一定是小于 bi的。那么处于λ*之上的就一定会被扔掉,因为他们的 ci是大于 bi的。所以按照 bi*=vi*的公式去出价,最后的结果就相当于把全天流量里面性价比最高的这部分流量都给竞得了,然后性价比低的流量就全部扔掉了。不管是你用反馈控制,比如大家熟悉的 PID 的算法或者强化学习控制,它背后核心就是在找λ*,要在所有波动的环境里面去把最好的λ*能够稳定地找到。



我们团队的吴迪老师在 2018 年的时候发表过一篇论文,用强化学习解决前面提到的整个流量波动的问题。强化学习建模里,消费者的流量不断请求广告引擎,构建了不确定的交互环境。模型包括 Agent ( 智能体 ),就是我们的广告算法。模型的状态指的是广告计划 ( 比如当前的一些预算,或者历史的平均 CTR/CVR,以及包括剩余没有花费的预算等等 )。智能体的 action,对λ去做调整。DQN 可以设计成两个输出端子,一个端子是对λ上调一个αt,另一个端子对λ下调一个αt。当然你也可以把它设成 A2C、A3C 等等,设计成一个连续函数的 action 输出。


总而言之,action 这边调λ,然后整个建模我们是用一个 model free 的方式去做,一个 time step 可以认定为 15 分钟,那么一个 time step 里面所累积的所有的回报的 value,比如所有的点击量或者所有的购买量,当做 reward。


在这样的一个强化学习的设定下,我们搭建了一个离线的训练平台。在离线训练平台下,我们可以把过去的日志做一个回放,依托强化学习的建模,用 DQN 或者 A3C 等模型去训练。在线的时候,就把训练好的模型部署上去。


实际做的时候会发现一个问题,这种预算约束下,让一个强化学习的智能体去探索的时候,有可能出价高一点,就能在某个 time step 拿到非常大的价值。因为这个也是显而易见的,你出价高,拿的流量多,当然价值就多。但是因为是有预算约束的,强化学习算法可能会比较短视,在短期内它可能没有触达预算的上限,就拼命地去拿流量,觉得现在的 reward 很高就很好。但是算法跑到中间的时候发现预算花光了,后面的流量都拿不到了,这样的话这个算法就相当于是探索出来一个次优的路径。但是强化学习的整个序列探索,想让它自己去不断探索,探索出前面省吃俭用,到了后面刚刚好,又能最后把钱正好花光的算法或者路径,这其实是非常难的,所以在 reward 的设计上就要去巧妙地构思。


我们组的同事也提出了一个方法,实践中既能保证效果,而在理论上也是非常棒的。把它的每一步获得的 reward 都跟整个序列获得的整体的 reward 做了一个关联,这里面 RT 它不再是一个 time step 15 分钟的结果,它是把整个序列的 reward 都能够反映到里边,但是它反映过来以后还给出了一个理论的证明,叫 reward shaping。在 shape 以后的 reward 情况下,我们得到最优策略跟原始严格的强化学习建模定义的最优策略,是严格一致的,所以这个 reward 极大的加速了这个问题的收敛。


③ 效果评估


我们可以看到这张曲线图,底下红线就是按照最原始的 reward 去训练,训练了很多 time step,它的 reward 一直处于很低的,收敛得非常慢。但是如果加了我们的 reward-shaping 之后,它 reward 就上升得非常快,收敛得非常好。然后左边这张图,我们用基于强化学习捕捉流量变动,出价变动,天级别之间变动的方法,叫做 DRLB(Deep RL Bidding),加粗的线也比其他传统的方法要好。这些传统的方法包括 FLB(fix linear bidding),用过去的历史日志,得出过去认为的最优的λ0,放进来,然后还有一些启发式的规则的,比如 BSLB 等等。用强化学习去做能得到一个非常好的效果。

3. MCB

① 广告主需求

刚才提到的是预算约束下的情况。广告主除了希望预算约束,还希望点击成本也不要太高。比如说:“我每天可以花 2000 元,能帮我买到尽量多的成交吗? P.S.根据经验我希望点击成本不超过 1.5 元”。


② 优化方案



在这个问题里面,我们的建模和刚才类似,目标函数还是要最大化整个流量的 value,约束里面第一项还是预算的约束。


第二项就是某种成本下的约束。这里的分子是所有流量的最后成交价格累积起来,相当于是总的投入(即总的消耗),分母的 wi就是某种单位。比如说这个里面是 PCTR,分子是总消耗,分母是总点击量,得到的就是一个平均的点击成本。广告主希望平均一个点击,成本不能超过 1 元钱,这个约束就会让平均点击成本不会超过 cw。该问题也用对偶的办法,可以分析出来它的最优的出价形式如下:



我们团队的杨迅同学,在 KDD 发表了一篇论文给出了这个对偶公式的推导,大家可以去参考。公式的第一项乘以 vi的,关注的是这条流量的价值。第二项是 wi*Cw,关注的是这条流量出价对于平均成本的影响。所以这里面的拉格朗日的对偶的变量 p*、q*,它就起到了去权衡这两个项目的作用。p*、q*一旦求得以后,那么就在一天里面都是固定不变的,它的解法也可以包括两种。一种是基于强化学习的解法,跟刚才我们提到的很类似,可以把一些 reward shaping 的思路借鉴进来,只不过在这个里面要把第二个约束也考虑进来。可以在 reward 里面把底下平均成本的约束 PCW 也加进来,如果最后违反了平均点击成本,就给一个惩罚,如果没有违反,就不给惩罚。通过这种对 reword 的干预,实现多约束的情况下的强化学习求解。还有一种方式就是基于反馈控制的办法。


经过我们的分析,我们发现 p*和 q*,对于预算约束和平均点击成本的约束的影响,是可以解耦控制的,即可以分别控制 p*和 q*从而分别去影响预算和平均成本,在理论上证明是可行的,然后就可以独立地去搭两个 PID 做控制。


除了帮助广告主满足多约束,优化某个目标(优化,就是你不能保证结果)。那么还有一类投放策略,既能满足广告主的预算约束,还能保证最后给多少曝光或者多少点击,就是合约保量。


比如广告主说:“我要以 60 元总价格在 1 天内购买手机淘宝首猜 1 坑 1000 个展现。我们可以事先签订合同,但完不成要给我赔偿!我很好奇你们是怎么分配流量的?”


对于整个平台来说,我们希望把合约保量的计划跟 RTB 的计划能够混合起来,让他们统一在市场经济下,去竞争做优化。


那么这个问题是怎么定义的?我们这里优化的目标包含三项,第一项 RGC就是合约保量的目标,第二项 QGC就是合约保量拿到流量的平均质量,第三项 RRTB是市场实时竞价下的收益,我们希望把这三项加起来联合去做优化。


这里 RGC是合约保量的收益是怎么定义的?下面我们给出式子:



c 是保量的单位花费,d 是要保多少量的需求。所以 cj*dj按道理说就是你保量能够达到的总收入的上限。但是你如果保不住量怎么办,那么这里 pj就是缺量的惩罚,你要赔广告主多少钱呢?yj就是你最后的缺量,所以 pj*yj是最后如果没有保数量,缺了这么多量,要赔给广告主的钱,所以 RGC就是合约这一块的总收入。QGC这里的λj是一个权衡因子,是固定常数,用来权衡合约保量的流量质量的重要程度。这里的 xij就是第 i 条流量对于第 j 个保量计划,要不要去竞得这条流量的示性函数。Qij这里说的就是这条流量价值,比如这条流量的 PCVR ( 转化率 ),那么 QGC在这里是为了优化平台收入时不能让合约保量的这部分流量质量太差,不然广告主它每次一买合约,发现最后合约的效果跟 RTB 效果差异非常大,合约的质量永远很差,未来他就不会愿意去买合约产品了。虽然你能保证确定性,但你买的都是很垃圾的流量,这是非常不合理的。所以 QGC的功能就是要保障合约这部分的流量质量。RRTB的 bi2就是最后 RTB 的二价,这个二价就是我们通常所理解的 RTB 最后竞得带来的平台收入。


这个问题如果展开,其实也是一个线性的优化问题,用对偶分析,会发现对第 i 条流量,第 j 个合约计划的最优出价就等于λj*qij +αj*,αj*就是要求的最优对偶变量。根据前面的思想,我们也可以去给出一套强化学习的解决方案,或者大家也可以去尝试用一些解耦的 PID 的控制方案。


③ 效果评估



这张图是我们用了一套强化学习的方法,能够比传统的一些固定的α*的出价有更好的效果。这个里面 PID 可能要注意必须站在一个全局的视角去做反馈控制。因为这个时候涉及到的是很多个智能体在一起配合,所以这里到底应该牺牲谁,应该保障谁?其实这个并不是一个严格的单增单减的关系,在这种情况下,你一定要有一个全局的调整,才能保证你最后得到α*真的是面向全局最优的。

4. MSBCB

① 广告主需求

如果广告主问:”有的用户需要多次曝光才会购买,预算有限下我应该如何投放?”


② 优化方案


如图所示,有的用户可能第一次访问平台它被曝光了,那么他这个时候才稍微对这个商品有一些心智,那么再去看广告的时候,他就感兴趣了,可能就加到购物车里面了,那么第三次看这广告的时候,他最后就决定购买了。


对于这种情况下,我们应该怎么去优化广告投放呢?这里面也给出了一个建模的方案。



这里定义了 VC和 VG两个概念。某一个固定的广告,对于某一个用户 i,有一套运营用户的策略π( πi是指如果广告跟这个用户在这一周内比如能接触 5 次,这 5 次里应该选哪几次去投放,哪几次不要去投放 ),投放以后最后整个序列的整体预期回报就是 VG。那么整个序列最后期望要投入的广告的消耗是 VC。所以 VG是期望的长期的价值 Long Term value,VC是长期的成本 Long Term cost,都依赖于这个广告对这个用户运营的策略πi。优化目标也是显而易见,类似于前面的 budget constraint bidding,他的变量有两方面。


第一,要去选哪些用户 ( 即 x) ?


第二,对于选定的这个人,我要用怎样的策略πi去运营用户的序列?


它其实整个把频控这件事情包括进来了,那么约束就是我要选哪些用户,以及我对用户的运营策略下,整个序列的所有的成本要小于等于预算。那么最后既要优化选哪些用户,又要优化对不同的用户之间用怎样的策略去优化它,这肯定是一个约束下的优化,又是一个序列决策的问题,它的解的组合空间非常大,求解起来也非常难。我们实际是怎么求解呢?我们把它分成两层求解。


第一,选用户

假设已经找到了对用户最好的运营策略πi,我们应该怎么挑用户?跟前面方式也是很类似的,依托性价比最优去选就好了。所谓性价比就是用户的长期的价值/用户的长期的成本,然后对用户从高到低去选择就可以。在实际情况中,因为流量粒度很细,所以这种背包的贪心算法基本是可以取得 99%比率接近最优解的。


第二,运营用户

当你知道怎么去选用户之后,对一个用户你应该用什么样的策略πi去运营它呢?

我们刚才看到选用户的时候,选性价比最优的用户。直观的一个想法是把每一个用户的性价比运营到最大化是不是最优解呢?这里我们给出了一个结论,不是最优解!


为什么呢?我们给了一个示意图,这个示意图你可以看作是个大背包,背包里每一个长方形代表一个用户。每一个长方形的高度,就是整个序列下来的总消耗,它的面积就是整个序列的总回报。那么底下横轴就是面积/长方形的高度,得到的性价比。背包已经按性价比从高到低,把用户一个个叠罗汉的方式摞起来了,整个高度累加起来就是它的预算。整个按性价比优选的话,虚线之上的就相当于被挤到背包之外的,外面的性价比较低的用户就不要了,而虚线以下的性价比高,都已经装进来了。


这个时候我们来看最下面的蓝色长方形,已经是把用户运营到了性价比最高的状态。如果对它的运营策略πi做一些调整,让性价比下降一些,底部蓝色长方形的高度(即期望的成本)上涨一些,头部低性价比的用户就会被挤出去一些。二者一加一减的高度虽然相等,但是我们挤出去的是低性价比变化量,获得了更高的性价比增量。通过牺牲最下面长方形用户的性价比,从最极致的状态稍微下调一点,整个背包的容量就增加了。


我们也有一系列理论推导,最后能给出一个严格的理论证明。对用户运营的时候,用户运营的长期的 return 目标函数,要按照:



去运营,那么最后就能得到整个背包的最大。而且我们两阶段的优化既要去挑用户,又要去对单个用户去做运营,这个来回迭代的算法,我们也严格证明了这个算法能够收敛到全局唯一的最优解。


我们的这个工作被 ICML2020 会议接收,感兴趣的朋友可以去参考我们的论文。


③ 效果评估


左图中,当考虑到用户跟一个商品反复交互有这种序列效应的时候,表示长期价值效果的红色的线是显著高于表示短期价值效果的蓝色的线。从右图可以看出,红色的线(代表目标函数策略)的确是比蓝色的线(按照"性价比最大化"的思路运营用户)也要高出一截。我们也跟传统的 Constrained 的一些方法去做了对比,在线上我们也取得了 10%的 ROI 和 GMV 的增长。


5. CCSA

① 广告主需求

上面介绍的很多都是在局部的一个渠道去投放。广告主预算如何在搜索、推荐和品牌广告渠道最优分配呢?


② 优化方案

当广告主面对不同的渠道的时候,怎么能够在整体上去做最优化?这个问题的建模可以看作 i 从 1 到 N,广告平台有 N 种投放渠道,每个渠道都可以投入预算 xi,你可以获得渠道最后给你的回报 fi。那么目标就是在所有渠道的预算 xi加起来小于等于总预算的情况下去最大化整体的渠道回报之和。广告主面对各种复杂的广告平台操作,还要再去联合优化,这种操作是很难实现、很难评估的。


所以我们可以把它集中到一个非常简化的、操作便利的单一的操作接口上,广告主只要去通过 minimal 的操作接口,就可以去设定投入,然后 minimal 的操作接口就可以控制所有的渠道去实现整个渠道的最优化。从整体视角来看,最终广告主投入比如 1000 元的一点点边际的预算,在各个渠道里带来的增量的边际回报是相等的,这个状态就是最优的了。



但实际去做的时候,因为各个渠道是很粗的粒度,你是很难去控制到各个渠道里面的一些具体的操作的,至少在系统的复杂性上会带来很大的难度。所以我们目前阶段性的方案是中心的 minimal 的平台对各个渠道通过下发预算分配或者利润要求等粗粒度的控制策略,然后去影响各个子渠道的投放策略,各个子渠道就可以去用 BCB/MCB 或者序列投放等等去优化它们的策略,然后通过这种方式实现了一个大一统的优化,各个渠道之间的这种系统的耦合上也是比较低的。


③ 效果评估

这里给大家做一个宣传,阿里妈妈今年推出了 AI 智投的投放产品,这比客户自己去各个渠道去分预算投广告,投放的效率能够提升 50%,这是一个很大的提升!

总结与展望

最后,总结下阿里妈妈广告系统的迭代历史,我们经历了从粗放式价值评估,到精细的单条流量价值预估和优化升级,以及从单一到多维的目标的优化,从不确定到对广告主有合约保量确定的结果保障,以及从广告主自己手动调出价到广告主只要设定预算,我们就自动帮它运维的这种升级,以及从单一的预算的约束,到包括各种成本约束(比如曝光成本,点击成本约束)的控制能力,从短期的价值优化到长期的价值优化,以及从单个渠道的优化到全局所有渠道的整体优化。


面向未来,我们会继续深挖客户的痛点,从数据智能,机制设计,算法升级和产品迭代方面进行全方位的体系和技术升级。


分享嘉宾:

靳骏奇 博士

阿里巴巴 | 算法专家

靳骏奇博士来自阿里巴巴集团精准定向广告团队,主要研究机器学习、机制设计在互联网广告与推荐系统中的应用。靳骏奇 2007-2016 在清华大学学习,获得控制科学与工程学士、博士学位,以及清华经管学院经济学第二学士学位。他在 IEEE TPAMI,ICML,KDD,IJCAI,AAMAS 上发表多篇学术论文。


本文转载自:DataFunTalk(ID:dataFunTalk)

原文链接:阿里定向广告智能投放技术体系

公众号推荐:

2024 年 1 月,InfoQ 研究中心重磅发布《大语言模型综合能力测评报告 2024》,揭示了 10 个大模型在语义理解、文学创作、知识问答等领域的卓越表现。ChatGPT-4、文心一言等领先模型在编程、逻辑推理等方面展现出惊人的进步,预示着大模型将在 2024 年迎来更广泛的应用和创新。关注公众号「AI 前线」,回复「大模型报告」免费获取电子版研究报告。

AI 前线公众号
2021-05-08 08:005218

评论

发布
暂无评论
发现更多内容

Java中抽象

爱好编程进阶

Java 程序员 后端开发

2021秋招必刷题:Redis+Mybatis

爱好编程进阶

Java 程序员 后端开发

25 网站应用攻击与防御

爱好编程进阶

Java 程序员 后端开发

60KX17薪的面试题是什么样的,需要具备什么技术?首发

爱好编程进阶

Java 程序员 后端开发

Java JVM知识汇总

爱好编程进阶

Java 程序员 后端开发

01-Linux 系统简介

爱好编程进阶

程序员 后端开发

线程简介

急需上岸的小谢

5月月更

apache,httpd服务启动报错解决方法【linux用日志排错方法

爱好编程进阶

Java 程序员 后端开发

java SpringMVC Filter登录拦截器

爱好编程进阶

Java 程序员 后端开发

brew使用记录

爱好编程进阶

Java 程序员 后端开发

IDEA整合jeesite4

爱好编程进阶

程序员 后端开发

Java Swing大神必经之路7:Swing 的任务线程与 EDT 事件分发队列模型

爱好编程进阶

程序员 后端开发

JavaWeb期末复习

爱好编程进阶

Java 程序员 后端开发

2021腾讯最新面经总结:面试题库+实战笔记

爱好编程进阶

Java 程序员 后端开发

30天消化MyBatis源码解析笔记,吊打面试官,offer接到手软

爱好编程进阶

Java 程序员 后端开发

AI 顶会 NeurIPS 收录:淘系技术自研3D AI 算法

爱好编程进阶

Java 程序员 后端开发

Caddy VS Nginx,谁领风骚

码农大熊

api 网关 盘古开发框架 Caddy

异构资源交付效率提升50%,这家头部券商是如何做到的?

BoCloud博云

证券 案例 云管理平台

如何使用Tomcat实现WebSocket即时通讯服务服务端

华为云开发者联盟

html5 spring tomcat 浏览器 websocket

appiun滑动的简单封装

爱好编程进阶

Java 程序员 后端开发

Day163

爱好编程进阶

Java 程序员 后端开发

HashMap

爱好编程进阶

Java 程序员 后端开发

8年开发架构师浅析SpringBoot的JVM的内存占用与Docker-spring

爱好编程进阶

Java 程序员 后端开发

npm install过程中遇到typings deprecated的warning该怎么处理

华为云开发者联盟

typescript 前端 npm typings.json

Java~异常Exception和异常习题“用户登录

爱好编程进阶

Java 程序员 后端开发

为什么企业一定要拥有知识管理的能力

小炮

企业知识管理

java中调用js代码

爱好编程进阶

Java 程序员 后端开发

12-Redis持久化

爱好编程进阶

Java 程序员 后端开发

95% 的算法都是基于这 6 种算法思想

爱好编程进阶

Java 程序员 后端开发

java三大特性之多态的认识,以及多态的实际应用(一

爱好编程进阶

Java 程序员 后端开发

Java全栈开发---Java ERP系统开发:商业ERP(五

爱好编程进阶

程序员 后端开发

阿里定向广告智能投放技术体系_AI&大模型_DataFunTalk_InfoQ精选文章