计费系统&超投控制

背景

在整个广告系统中, 计费是处在和钱最相关的环节:检索端把结果展现给用户,如果用户感兴趣,并且产生点击之后,这些点击就需要通过计费系统进行流转,对广告主的费用进行扣费。

因为计费系统和钱完全相关,所以任何问题都是钱的问题,而钱的问题在广告系统里边都是最受到重视的所以在各个广告平台当中,都会有专人对计费系统进行升级,维护和监控。
想象一下出了问题之后,要么是广告平台的钱受到损失,要么是广告主的钱受到损失,计费系统如果有问题,要么广告主直接跳出来找你,要么就公司收入受损失,所以一般做计费系统的同学的压力都是比较大的。
例如在大厂(比如腾讯,阿里巴巴,字节),如果一天的广告收入是一亿,在高峰时段,出了故障半小时就损失大几百万,而且有一些事故的收入是回补不回来的,这个收入是回补不回来的这个还是挺恐怖的。

下面就给大家介绍一下积分系统的实现逻辑。

图:计费系统系统位置

在用户看到检索端呈现的结果之后,如果用户感兴趣,就会发生接下来的点击和转化,此时,这些信息就流转到计费系统去进行计费。

计费数据链路


图: 计费数据链路图

广告计费平台涉及以下内容:资金管理,实时计费,投放控制,日终结算等和钱相关的工作,重要性非常高。

上图中的几个组件功能如下:

  1. 资金管理平台, 主要是对用户的账户资金进行管理,包括交易,结算,充值等。
  2. BP,主要对投放进行管理, 包括投放计划/单元的设置,投放预算的设置。
  3. 计费平台,为本文的核心部分,主要和广告投放引擎,资金管理平台进行协同进行计费,同时进行投放的控制和结算。

计费系统的挑战很多,主要体现在以下几方面:

  • 实效性非常高, 否则会造成较多超投,或者少投,相当于是资损。
  • 涉及金额较大, 广告平台涉及到的所有的钱都会通过该系统链路
  • 线上‘钱’的链路的最后一环, 需要对上游系统错误进行容错,最大程度避免钱的损失。

超投控制方案

超投: 超过广告主余额,计划预算的投放流量是不能找广告主收钱的,该种情况就是超投。 超投不可避免,但可以尽量降低超投或者少投,这就是一种开源节流

为什么超投不能避免?
原因很简单,以CPC为例(CPA等其他模式会更加严重,因为转化路径和转化延迟更为严重),广告平台的展现,到用户的点击是有时间差的,如果广告展现的时候还有预算,但用户点击时预算花完,该点击就不能向广告主收费,就会出现超投。

另外系统的数据链路本身也会有延迟。 所以超投不可避免。

图:计划撞线

如何降低超投?
控制超投的思路, 就只有一个, 就是在预期计划可能超投的情况下, 进行投放的减速

具体来说,就是**降速在消耗接近预算/余额前,进行降速,以期望在预算为0时,正好停止投放。 思路就类似于预算/余额接近0的时候开始刹车。

在具体实施的时候,可以使用以下方法进行刹车控制:

  1. 根据预算/余额直接进行计算是否开始踩刹车。参见图:刹车控制超投
  2. 根据剩余点击数,根据预算/余额,以及最近的N条点击的花费,计算出剩余的点击数进行控制
  3. 根据剩余预算/余额/点击分段进行控制, 这是更精细化的方式,越接近刹车终点,速率越慢。
  4. 缓升控制, 该方法不仅考虑预算控制的刹车的方法,还需要考虑计划投放启动的速率,主要是避免有些预算较少的单元,因为一开始投放较多, 直接就控制不住超投。参见图:缓升控制超投。


图:刹车控制超投


图:缓升控制超投

计费收益优化

排序

为了实现平台的收益最大化, 以及统计口径的统一, 在计费日志遍历的过程中,需要对排序逻辑进行优化, 排序优化分为以下4个阶段:

  1. 按日志的自然顺序计费,该计费的方式优点比较直接, 就是计费逻辑比较简单,同时能够保证计费结果的一致性;但缺点也很明显: 该方式对平台不利,很容易出现较多的超投。
  2. 引入贪心算法, 即大价格在前,该方式对于自然顺序有一定优化。
  3. 引入改价策略,即排序的时候进行计费日志改价,这样就能够保证最后一条日志能够计费。
  4. 引入排序稳定性改价, 多次重跑,保证结果一致。

最后,大量招人,算法,工程,数据P6~P9,具体岗位参见: 招聘信息

基于blink DataStream的实时数据配置平台

背景

随着移动互联网的普及, 以及各种超级APP的出现, 每个公司都对数据收集以及充分挖掘数据的价值非常看重,并几乎不计成本地投入。 在每个公司, 无论是实时的BI报表统计分析, 通过实时数据的异常监控, 还是根据用户的实时反馈进行算法效果模型预估,在各个公司都有非常多的应用,并对公司业务效果的保障有着巨大的影响和贡献。

当然, 随着近些年各种开源软件,平台的出现, 特别是以hadoop为起点的开源组件,使得各公司都能够基于这些组件,以及各大厂的云计算快速搭建自己的大数据平台,包括实时数据处理系统。

这里八卦下自己的看法, 个人觉得这些年百度相比于阿里,百度的技术其实是在退步的(虽然我在百度工作了很多年,百度是我的老东家), 我觉得一个主要的原因就是百度的系统太封闭。这在早些年, 在开源社区还不活跃, 大家都需要自己封闭造轮子的时代,这个时代就比拼各个公司自己的技术能力,彼时以工程师为主导的文化, 的确让百度技术领先阿里一大截。 记得10年前,我们都特看不起阿里的技术,就觉得阿里没有技术, 就业务好。 甚至业界还没提云计算的时候, 我们在百度内部, 大家的开发机就已经是以虚拟账号的方式分配资源了。相当于内部已经开始某种意义上上云了。
但后来随着开源社区的兴起, 百度这样连STL都自己重新写一套的模式就慢慢跟不上节奏了: 开源社区结合了各路神仙的才智,对各种大数据组件进行打磨,这也是开放带来的牛逼之处。

通过近两年对老东家百度出来的同学的面试深深由此感觉, 百度甚至内部跑数据还在自己写各种MR,感觉跟我2013年还在百度的时候没啥区别。。。。

扯了那么多,就是想说各种中间件的大数据处理组件,还是需要开放生态,才能有竞争力。国家都需要开放,更别说公司技术。

此处就为大家介绍我们团队为了降低实时数据计算的成本, 构建的‘基于Blink DataStream的实时数据配置平台’,从思路上介绍我们是如何满足各种纷繁多样的基于LBS的实时数据计算需求的。希望对大家有借鉴作用。

同时打个广告: 团队长期招p6~p9数据,工程,算法; 业务发展快。 感兴趣的同学可直接关注以下公众号获取岗位信息:

解决问题

移动互联网目前已经发展到近乎巅峰状态,各个大厂都有自己主打的超级APP,头条各种基于内容的kill time app,腾讯, 阿里淘宝,包括高德都是DAU过亿的超级应用。 这些应用也时刻在产生海量的用户数据。 很多场景都需要对这些数据进行实时处理, 包括:

  1. 用户行为反馈后,进行BI实时报表计算&分析&财务结算
  2. 系统监控,包括业务效果的监控。
  3. 实时特征生成供模型实时使用,例如搜推广的ctr,cvr,实时反作弊等

这个过程中, 实时计算就是一个绕不开的话题, 而且每个场景都会有非常多的定制化需求。


图:广告系统业务端到检索端的基准+实时增量数据同步


图:实时反作弊,需要实时对用户点击反馈进行反作弊计算。

以上两个广告的例子,广告系统业务端到检索端数据同步,以及实时反作弊,都会涉及到较多的实时计算。

挑战 & 实现

在我们的场景, 对实时计算有以下要求:

  1. 实时性: 实时计算的延迟很多场景需要缩短到毫秒级别,才能在很多场景满足用户需求。例如:广告实时性能力建设 《风向标逻辑》
  2. 极低的接入成本:理想情况希望业务方的工程OR算法就能通过平台操作攒出满足自己需求的实时数据计算,满足自己的需求。

基于以上两个要求, 我们定制了基于Blink Data Streaming的实时计算配置平台。
Why Blink? 很简单,flink在实时计算很有优势,流批一体, 且Blink基于flink,是阿里的。
Why Data Streaming:Data Streaming更底层,可以做更深层次的定制和性能优化。


图:基于Blink Data Streaming的实时数据平台架构

在具体实现的时候。 我们将系统抽象成以下几层:

数据层
其功能是对各种来源的数据,按照规范进行数据的normalizing, 因为高德是LBS场景, 所以所有的原始数据实时进入系统的时候, 都会被规范化为<time, location, userid, object, event>, 也就是时间地点人物事件,以及事件处理到的对象。
此处的userid及object并没有带维度属性,维度属性由离线batch逻辑生成。 并在引擎层进行id和维度属性的自动关联。

引擎
此处的引擎主要有两个作用:

  1. 定义算子: 我们使用blink 的data streaming api开发并优化了常用的实时数据算子, 以便引擎能够将各种算子攒成任务, 此处的算子可以灵活定义并根据需求开发, 类似于一个faas平台。
  2. 任务调度: 单个算子仅进行实时数据的一步原子计算, 需要引擎层中的任务调度, 根据上对层平台计算任务配置的解析, 组合成完成整个实时计算逻辑的task任务。 此处比较像tensorflow在运行时, 将各个operator按照有向无环图编排任务进行计算的过程。

服务层
服务层的两个作用:

  1. 任务配置: 负责给平台使用者提供UI,以便用户进行任务的配置。目前开源有很多这样的配置管理组件可以使用, 我们内部使用Diamond平台
  2. 资源状态管理: 从系统的角度对任务进行调度, 资源分配。

效果

目前我们团队开发的实时计算平台已经在各个业务中使用, 初步实现了配置化实时任务的生成, 启动,管理, 监控。 连写blink sql都免了, 用主要负责开发的同学的话说: '该平台再完善完善, 写blink sql的同学也可以失业了。。'

如果你对我们的工作感兴趣, 可以联系我们, 需要更多同学进行类似平台的建设和完善。

参考文献

  1. 广告实时性能力建设
  2. 在高德吃喝玩乐!LBS信息的AI技术应用

广告预估校准机制介绍

背景

说搜推广的时候,我们会用到很多的模型来对效果进行预估,包括ctr的模型和cvr模型。这就会涉及到使用对应的指标,对模型的效果进行衡量。

一般情况下,我们使用最多的指标就是auc,因为auc可以来评判排序的效果好坏。很多时候我们也会使用auc来评判广告中的ctr或者cvr模型的好坏。而且一般我们在特定的场景也会有一个auc和线上效果的大致转化关系。例如,我们会有这样的经验:线下auc提升一个点,线上的收入提升n个点。不同的广告平台会有很大差异。

但是随着广告效果的精细化,以及引入了更多的机制,这样的模式就会存在明显问题。例如对于cpc产品我们的rpm的预估收入公式是:ecpm=ctr*bid。这就要求我们不仅要保证预估ctr的排序正确,同时需要保证ctr预估的值也足够的准确。

这就是搜索推荐与广告在对于ctr预估的准确度上的区别:搜索推荐只考虑排序的正确性,但广告需要考虑ctr预估的准确性

解决广告ctr预估准确性的手段主要就是两种,第一就是让模型足够准确,狂怼模型预估能力;第二就是增加合理的校准逻辑。

这个地方再详细展开说一下,为什么广告中对于预估的准确性那么重要,主要由以下几个原因:

  1. 只有ctr足够准收入,收入预估才足够准, 如上 ecpm=ctr*bid
  2. 还是ecpm=ctr*bid,因为本质上广告主关注的还是效果,roi,所以如果转化率预估的足够准,我们是可以对好的流量进行提价的,也就是增加bid,同样可以提升收入。 具体参见:CVR优化的重要性
  3. 现在很多广告平台都同时支持cpc广告和ocpc广告混排,这就需要将不同模式的广告效果进行拉齐排序,也要求预估足够的准确,否则变现效果不可比.
  4. 自然结果和广告需要进行混排,而且很多时候收入和自然结果的体验会有对应的量化折算关系,也要求预估足够准确。具体参见:多目标广告混排机制在超级APP中的技术

具体如何让ctr预估模型更加准确,可以参见:推荐系统,变现系统CTR&CVR预估算法演进-模型,更多的是介绍如何让校准更加准确。

校准的要求

一般情况下,校准是在预估打分之后,机制之前进行的。因为线上的计算逻辑较重,所以一般都希望校准能够相对简单,并且可解释。同时,最好校准逻辑不要跟有业务逻辑绑定,需要通用。


图:预估校准阶段,在排序机制4(预估)之后,5(机制逻辑)之前

正所谓没法衡量,就不存在优化,所以和所有的算法逻辑一样,校准也有对应的标准来进行效果的衡量。目前经常使用的衡量指标有如下三种:

PCOC:该指标的基本思想就是平均预估值/统计真实值;该指标逻辑相对简单,但是不能反映分布的差异。

CAL-N:该思路对PCOC进行分桶统计,不同桶上的误差会累计,相当于一定程度上体现了分布的值。具体的计算逻辑为:

$CAL-N=\sqrt{\frac{\sum_{i=1}^N error_i^2}{N}}$

其物理含义,就是单独计算分桶的PCOC(或error), 然后求平均误差。

GC-N:该指标就更进一步,针对某一个特定的维度去进行加权,毕竟什么事物都有个优先级重要性。例如在广告中根据单元或者计划的pv或者收入去进行加权。具体计算逻辑为:

$GC-N=\frac{\sum_{j=1}^m w_j Cal-Nj}{\sum{j=1}^m w_j}$

其物理含义, 就是分某个维度后, 在维度上计算CAL-N,然后再进行加权汇总。 例如在广告系统中, 此处的维度可以是广告计划维度, 权重为该计划的PV或者消费。

具体实现

知乎上《阿里妈妈展示广告预估校准技术演进之路》 中介绍的已经非常详细,写的非常赞。我们团队也是借鉴了阿里妈妈的技术,所以这个地方就不详细展开,大家可以上知乎看看同学的文章写得非常详尽。 此处仅介绍传统的方法和我们团队借鉴的SIR方法。

传统校准方法

主要有以下3种:

Platt's Method
该方法的思路是对预估的值在使用实际的label进行一次参数化的映射,使用LR方式进行参数化学习。 校准函数为:

$f(x)=\frac{1}{1+e^{ax+b}}$

其中a,b为学习出来的参数。该方式优点是比较简单,且是学习出来的结果, 缺点是对于假设空间有过强的假设(认为是sigmoid函数)

Isotonic Regression
该方式的思路是使用一个单调函数来最小化预估值和label之间的square error,对结果进行保序的校准。 该方式隐含的假设, 是预估值至少能够保证预估顺序的正确性。 该方式的缺点,是处理不好预估值在突变的情况

Binning Method
该方式的思路, 是将预估值进行排序后分桶,然后统计正样本占比。


图:Smoothed Isotonic Regression(SIR)方法

具体的计算逻辑为:

  1. line 1-3进行排序分桶
  2. line 4-9对每个桶,计算预估样本上下界,以及正样本概率
  3. line 11-23构建每个分桶的线性插值函数。
    之后,对于任意x,使用x所落在的空间,使用该区间的线性差值函数即可进行预估数值的校准。

该方式可以按天分小时进行计算,以便体现时间上的ctr值得差异, 特别是在LBS场景, 中午餐饮行业, 下午晚上的休闲娱乐酒店的分布还是有较大差异的。

线上效果

进行SIR校准后, 在我们的场景, 效果有5%左右的相对提升, 另外理论上该机制也能够更好地平衡CPC & OCPC广告的混拍。 所以先不管提升是多少, 就是一个需要去做的正确的工作 。

末了附上一句阿里土话:if not now, when? if not me, who? -- 此时此刻,非你莫属

CVR优化的重要性

还是先插个招聘信息: 急招推荐,搜索,语音算法,数据挖掘,工程人才,阿里P5~P9,欢迎推荐和自荐,微信扫码关注以下二维码了解详细信息

背景

在广告这个领域,CTR的优化有较为悠久的历史, 这些年也出现了较多系统性的优化方法, 包括样本如何选取, 各种模型的出现和创新,在整个领域都有较深的研究沉淀。 从事这个行业的同学也都较为了解。

但当CTR优化达到较高的水平,因为预估的ecpm=ctr*bid,收入的优化会逐渐达到瓶颈,此时如果要继续优化广告的效果,就需要加入其他更多的优化链路和环节,从更多的维度,更高的视角去进行整个系统的优化,其中非常重要的一个环节, 就是CVR的优化。


图:广告cvr在检索端位置

CVR优化的重要性

那CVR优化为什么重要?

下面就详细说下这个问题。
先补充个背景:我们可以认为, 广告和搜索&推荐这样的自然信息分发有本质区别的地方: 搜索&推荐这样的自然信息分发的主体是平台,平台完全自主决定了分发的机制; 但广告不一样,广告的主体是广告主,广告主会对自己的广告,也就是广告平台分发的内容增加约束(例如出价,定向条件,时段等),而各个广告主的约束总体又形成了带约束的竞争环境。
这些约束条件,就是广告分发和搜索&推荐分发的本质区别。

而从广告平台的角度,传统上我们认为平台能够调整的因素, 主要是CTR, 因为 :

$ecpm = Q * Bid$

而且一般情况下,Q就是CTR,而Bid是广告主设定的,原则上Bid是广告主设定的,是不能改变的, 这就导致了广告平台能够直接影响的因素, 就是优化好CTR(其实也可以影响Bid,这个待会会介绍),将CTR预估做这也是为什么之前很长时间,大家提到搜推广,第一反应就是CTR预估。

但从本质上来说,广告平台的主体是广告主,广告平台需要满足广告主的目标诉求和约束, 广告主最终的目标还是转化和ROI(不同的投放任务可能还细微不同),而不是固定的出价, 所以近些年出现的各种智能出价,包括OCPC,OCPM,就开始考虑广告主的转化了: 如果认为对于广告主这个流量价值比较高,是可以动态调整Bid的,而流量价值如何判断,就依赖于准确的CVR预估。考虑了CVR后,流量的价值可以拆分为:

$ecpm=ctr\cdot cvr \cdot abid$

此处abid为广告主对一次转化的出价。

而CVR预估做准后有两个比较大的好处:

  1. 就是能够进行动态调价,调Bid,直接增加单次流量的收益
  2. 广告主转化/ROI得到保障后,会有更多预算的投入,让广告平台的整个竞争环境更加充分,有利于广告平台生态的良性循环

以上就是CVR预估为什么重要的原因。

CVR优化和CTR优化的异和同

相同点:都是标准的预估任务, 按照样本,特征,模型的思路死磕预估效果。 各种创新机制都可以搞。具体可以参见:推荐系统,变现系统CTR&CVR预估算法演进-模型

不同点:转化很多时候都不是立即发生的,都会有延迟,例如APP应用下载安装的归因,可能是7天,甚至更长; 淘宝的下单,也可能会有数天的延迟, 这就存在延迟归因的问题。 另外就是转化的数据一般都会比较稀疏,这就衍生出来不一样的建模方式, 例如阿里妈妈的

而对于延迟归因,主要的解决思路又是‘样本回补’策略,通过重要性采样(importance sampling)技术来进行样本的纠偏, 具体可参见老文章:移动端转化延迟相关CPI转化率模型建模方法,同时还有很多其他的方法来对转化样本进行纠偏。

参考文献

  1. 移动端转化延迟相关CPI转化率模型建模方法
  2. 推荐系统,变现系统CTR&CVR预估算法演进-模型
  3. Ma X, Zhao L, Huang G, et al. Entire space multi-task model: An effective approach for estimating post-click conversion rate[C]//The 41st International ACM SIGIR Conference on Research & Development in Information Retrieval. 2018: 1137-1140.
  4. http://semocean.com

在高德吃喝玩乐!LBS信息的AI技术应用

还是先插个招聘信息: 急招推荐,搜索,语音算法,数据挖掘,工程人才,阿里P5~P9,欢迎推荐和自荐,微信扫码关注以下二维码了解详细信息

以下才是正文。。。。

从毕业步入职场到现在10年多的时间,就一直在搞两个技术领域:搜推广信息分发以及LBS。

搜推广不用说,近十年一直都是热门的领域,另一个是LBS的技术,可以说也是深入到我们生活的方方面面。过去既做LBS的信息分发,也做底层的实时路况,ETA以及RP算路,甚至更底层的地图匹配(或者叫抓路,绑路,map matching),目前,更多在做人地关系大数据,以及基于LBS的搜推广。相当于将两个领域结合到了一起。

更详细的LBS相关内容可参见:
GITC演讲-滴滴路况感知AI及应用
[LBS]地图Map-Matching流行算法及应用
[LBS]工业界ETA应用及滴滴WDR技术

《在高德如何吃喝玩乐!LBS信息分发的AI技术应用》就是团队的工作在高德技术开放日进行的介绍,感兴趣的同学可以在抖音,B站等平台观看交流。 具体B站的链接视频,参见‘阅读原文’

对于地图平台,无论是高德地图还是百度地图,腾讯地图,现阶段心智最强的功能还是出行。而在整个出行的用户交互过程当中,用户首先需要进行定位,确定自己所在的位置,然后进行POI的搜索,确定要去的目的地,之后就是怎么去的问题?包括路线规划导航ETA等相关技术。

随着地图平台的定位由出行工具逐渐转成吃喝玩乐相关的LBS本地生活平台,信息分发的范畴也在扩展:从原有的POI搜索,展到了交易的分发以及广告的分发。

同时,这个过程当中需要有非常多的内容的理解,包括文本,语音以及视频内容的建设。具体参见:ID+图像特征联合训练CTR模型

同时,分发的手段也有更多的扩展,由原来的搜索,扩展到推荐以及语音的更多的交互方式。包括搜前,搜中,搜后,语音主动提示等多种交互方式,和用户进行信息的交互。(完整的工业级搜索+推荐 用户交互机制实现参见:关键词推荐工具中的用户引导机制

同时,分发的形态,也由原来的单纯的POI list,扩展到视频,聚合榜单的更加丰富的模式。

对应的工作也包括最底层的数据建设,上层的引擎平台的建设,通用算法策略的建设,以及业务的定制。都是非常复杂的过程。

在这个过程当中,也会用到非常多机器学习相关的算法模型,当然,我们要时刻意识到,机器学习模型只是整个业务逻辑很小的一部分,虽然它起着无可替代的重要作用。

LBS的搜推广和传统的信息分发最大的区别,就是他会有很强的空间,时间的划分属性。

在LBS场景,每一个区域,或者每一个POI,都可以看成他是一个个的局域网,这些局域网之间其实是没有非常强的关系的,例如一个云南的用户,可能从来也不会去一个天津的饭馆吃饭,因为地域天然将这两个要素隔离开。 这和淘宝的信息分发是有本质的区别的,在淘宝上,一个云南的用户和一个天津的用户可能都会买同样一个商家的,同样一个商品,而且几乎代价是没有区别的。

因为地域,或者距离的差别,就会导致LBS的信息分发和传统的信息分发有本质的区别,这样就衍生出非常多的LBS信息分发独特的技术。

例如POI的别名挖掘,如何挖掘同一个地点的不同的别名。 以及反过来如何挖掘不同地点,有相同名称的POI,都是特有的结合LBS空间挖掘的技术。

同时,我们会依赖于用户的搜索,点击导航路线规划以及位置信息,去使用定制的序列模型挖掘用户的行为序列信息,去做更准确的用户个性化定向。

在地图场景,需要主动给用户展示信息的入口/场景非常多,而且不同的入口有不同的产品形态和定位,如果对每一个入口都定制一个推荐模型,那维护的成本是非常高的;同时,不同入口的信息无法共享,所以我们也是用了多任务的模型,对不同入口的推荐算法进行统一的建模。(具体ctr预估参见:推荐系统,变现系统CTR&CVR预估算法演进-模型

而且在地图场景,我们使用了丰富的LBS数据,却对用户的时间,空间,行为进行预测,例如,用户接下来会去的地点,区域和城市,并且取得了显著的效果。

这个领域的工作非常多,也非常有意思,而且LBS本地生活是非常重要,非常有前途的一个领域,也是目前各个大公司重兵投入的兵家必争之地。如果大家感兴趣,请联系我进行高德岗位的内推。