In-app Bidding推动移动开发者广告商业化新增长
2021年11月19日

随着移动互联网广告相关法律法规落地,对整个行业产生不小的冲击。虽然APP广告商业化环境愈发透明合规化,但是原有变现方案效果都出现不同程度下滑。如果想帮助APP开发者有效提升广告收入,就需要重新思考广告变现方案中蕴含的可能性,并积极寻找变现新优解,而In-app Bidding极有可能就是提升变现收益的新优解。

在介绍In-app Bidding之前,我们先介绍一下占据传统广告变现半壁江山的Waterfall模式。可以帮助开发者更好地了解移动广告程序化的发展趋势,以及认识到实时竞价拍卖环境对于app内广告变现的重要性。

一、 Waterfall 是什么?

对于移动开发者而言,最简单的变现方式就是集成广告网络SDK并向流量需求端(预算方)请求广告,在接受返回广告后,对用户进行展示,从而实现获利。

但如果仅集成一个广告网络SDK,应用的广告填充率和eCPM都难以达到开发者的变现需求。因此,为了接触到尽可能多的潜在买家,许多开发者开始在应用中添加更多的广告网络SDK。这时候,对各家广告网络SDK的高效管理需求则催生了广告聚合平台的诞生。广告聚合平台需要帮助开发者采用一种方式来确定这些广告网络SDK填充广告的顺序,而广告网络SDK或需求来源的有序列表就被称之为“Waterfall”。

在Waterfall模式中,广告请求和广告返回按照有序列表的顺序依次进行。这个排列顺序通常基于手动设置的优先顺序规则或者历史平均价格数据。广告聚合平台帮助开发者向有序列表的第一个广告网络A发出请求,A广告网络响应则返回广告;如无响应,则展示广告机会将传递给第二个广告网络B,然后第三个广告网络C,以此类推。一旦有广告网络响应该广告展示机会并填充广告,该次广告展示的变现流程便会直接结束,而随后的广告网络SDK也将无法再参与。

Waterfall的这种有序请求和填充广告的模式,在一定程度上保障了高价值的广告网络或买方可以优先获得广告展示的机会,并且帮助开发者解决了广告管理的效率问题。

二、Waterfall模式的缺点

虽然Waterfall模式很有效,但是随着开发者追求成本效益最优的需求越来越强烈,它的缺点也逐渐显现。

存在“暗箱”问题

在Waterfall模式中,广告网络优先级的排序至关重要,优先级排序靠后的广告网络极有可能得不到广告展示的机会。因此,一些广告网络可能会事先与开发者达成交易,占取Waterfall有序列表中的头部位置,以获得优先访问开发者广告库存的机会。此外,由于Waterfall模式中每次广告请求仅有一家广告网络参与出价,缺乏竞争性,开发者难以获取丰富的广告源。因此,开发者也无法获得更多的数据来进行深度分析、以更科学的方式优化广告收益。

无法满足请求返回响应要求

随着行业聚合技术不断成熟以及分层价格策略的广泛应用,广告网络被允许在Waterfall中以多个不同出价来填充广告,广告请求和返回的流程更长、更复杂,容易造成广告延迟无法满足行业响应要求。

广告收益无法最优化

Waterfall模式是按照预先设定或历史平均价格数据高低的优先级顺序进行广告请求和广告返回的,优先级靠前的广告网络更有机会获得广告展示机会,而优先级较低的广告网络即便出价更高也可能无法获得广告展示机会。这种按优先级填充广告的模式缺乏时效性与公平性,也无法确保开发者的每一次广告展示所获得的价格都是最高的,可能使开发者的广告库存价值被低估,无法真正实现广告收益最大化。

三、In-app Bidding重塑APP广告变现模式

为了解决 Waterfall 模式的现有问题,帮助应用开发者真正获得最大化的广告收益,In-app Bidding 开始引起技术服务商们的注意。

In-app Bidding 发展轨迹

In-app Bidding 允许多个广告源对开发者的广告库存进行同时竞价,最高出价者赢得该次广告展示机会。简而言之,开发者可以通过In-app Bidding 从众多广告源中获得最大化收益。

In-app Bidding 也被视为移动端的“头部竞价”(Header Bidding为PC端)。头部竞价是一种用于PC端网页广告的竞价方式,最早由海外广告平台AppNexus于2015年提出。当时,海外头部广告交易平台(Ad Exchange)DoubleClick形成寡头垄断,大部分网页开发者只接入一家广告交易平台进行广告变现,这对于其他广告交易平台产生了较大的影响。AppNexus为了解决这个问题,发布了一系列开源的代码,网页开发者只需将代码嵌入在网页代码的Head片段中,即可同时向不同的广告交易平台发送广告请求,并按照返回价格进行“价高者得”的竞价,从而获得更高的收益。由于代码是嵌入在Head片段中,因此最初这种模式被称作“Header Bidding”。头部竞价在PC端被广泛采用,而随着越来越多的用户转向移动端,这种竞价技术也逐步被引入到移动应用中。但由于移动应用内没有实际的Head,因此我们将它称作“In-app Bidding”。

In-app Bidding 的工作原理

In-app Bidding实际上是以满足APP开发者的广告变现需求为主的程序化广告交易技术,其运作方式类似于“竞拍”,具体工作原理如下:

开发者作为“拍卖方”,同时向多个广告网络发起询价;广告网络同时竞价并向开发者及时返回价格;出价最高者赢得该次广告展示机会;由最高出价的胜出者的SDK展示广告。

实际上,In-app Bidding是传统RTB(实时竞价)模式在应用内广告流量上的竞价延伸。从In-app Bidding的工作原理逻辑中,可以概括为最高单价成交、共同竞价。

最高单价成交,In-app Bidding允许多个广告网络针对每一次广告展示进行统一竞价,并且由最高出价者获得该广告展示机会,采用第一价进行结算,确保了开发者可以获得更高的广告收益。

In-app Bidding与RTB模式的核心区别在于,应用内广告的创意和模板渲染高度依赖于SDK。而传统RTB模式在对接时并不需要竞价方的SDK,这就造成了RTB模式无法体现出各家广告网络的创意和模板能力的问题,可能会导致广告网络出价较低,进而影响开发者的收益增长。

共同竞价,In-app Bidding可以支持开发者同时向多个广告网络发送广告请求,所有参与竞价的广告网络同步出价,广告请求和竞价实时发生。因此,开发者的每一次广告请求都可以同时获得更多广告源,而不是传统Waterfall模式仅有的一个广告网络优先级的排序。

四、In-app Bidding如何解决Waterfall模式存在的问题

对于Waterfall模式所存在的一些问题,In-app Bidding主要从以下四个方面进行了改良与提升:

透明竞价

In-app Bidding可以让开发者更透明地了解自己的每一次广告请求和竞价的过程,并且收集到更多有意义的数据,譬如每一次广告展示的价格、谁在参与竞价、竞价的参与度、出价趋势等,甚至洞察到最具有广告价值的用户所对应的时间和场景。因此,在应用内竞价中,开发者可以更加了解自己的广告库存价值,并在后续的其他环节进行深度优化,进一步提升广告收益。

降低响应时间

与Waterfall模式按顺序进行广告请求、一次只请求一个广告网络的流程相比,In-app Bidding实时、并行的拍卖模式减少了广告调用与等待的时间,因此也大大减少Waterfall模式的延迟问题,让广告可以更快地被投放和展示。

收益最优化

In-app Bidding针对每一次广告展示进行竞价,允许多个广告买家同时参与出价,遵循“价高者得”的竞价逻辑。更多广告源的参与、更高的竞价密度和更激烈的竞争,对开发者来说意味着可以获得更高的出价。因此,应用内竞价使每一次展示都可以最大化提升广告收益。同时,因为应用内竞价的过程是实时的,相较于历史平均CPM数据来说,实时CPM出价对每一次展示的预估更为精准,从而使开发者的每次展示都能够以更真实的价值进行售卖。

五、In-app Bidding提升广告投放体验

In-app Bidding除了能帮助开发者解决传统Waterfall模式的问题、优化广告收益外,对于广告主也大有价值。

广告投放环节透明化

In-app Bidding使广告投放的流程更加透明,能让广告主通过数据明确自己的预算消耗在哪些渠道和用户群上,并且整体分析用户的转化和行为,进一步优化后续的投放。

广告覆盖效果更优

通过In-app Bidding,每个广告主都有机会针对每次广告展示进行出价。没有了传统Waterfall模式优先级顺序的限制,广告主可以在更大的可供选择的流量池中,更高效地覆盖合适用户群,快速实现大规模获客。

平等公平竞价

In-app Bidding允许多家广告网络针对每次广告展示机会进行同时竞价,不再是按优先级顺序进行出价。可以说,In-app Bidding对于广告主来说是一种更公平的竞价技术。

倍业科技成立于2015年,以“赋能媒体商业化”为使命和愿景。自主研发推出APP自己的商业化管理和运营产品Blink,先后获得了险峰华兴、竑观投资、颐成投资等机构的投资。业务涵盖视频、社交、金融、教育、交通出行、汽车、母婴、动漫、工具等多个领域媒体商业化。已与国内100多款知名媒体建立长期合作伙伴关系。倍业科技整合了API和SDK解决方案,结合了全栈式广告技术,通过流量管理和运营优化工具,为媒体充分挖掘每个流量的价值。此外,倍业科技的免费开源聚合广告SDK产品EasyAds,已在GitHub代码库、Gitee代码库、华为开发者联盟生态市场等平台上线。EasyAds旨在为移动开发者集成市面广告SDK时,可以实现安全拓展层面、迁移层面、开放层面的完全自主可控。


Card image cap
倍业科技:巧用Blink自主调优Bidding效果
2022年10月21日
上篇我们介绍了倍业科技新推的SDK/API全域实时Bidding ABTest功能,详细描绘了倍业AB Test如何协助移动开发者衡量广告收益提升,破解接入倍业Bidding后高频测试择优困惑,直观感受SDK/API全域实时Bidding深度挖掘流量价值效果。本篇我们主要介绍倍业科技Blink(倍联)全方位数据看板、预警、诊断等功能如何帮助移动开发者优化Bidding效果。倍业科技SDK/API全域融合实时 Bidding(实时竞价)是旨在帮助移动开发者增收、降本、提效,从竞价策略层面重新定义APP广告变现技术架构的解决方案。目前已有数十款APP正在使用倍业科技SDK/API全域融合实时 Bidding,并实现了收益提升30%,APP广告整体填充率提升至95%。为了能最大化帮助移动开发者提升收益, 特地奉上巧用Blink全方位数据看板,搭配预警诊断等功能,轻松实现全链路数据清晰可见,助力移动开发者自主调优倍业科技SDK/API全域融合实时 Bidding效果。Bidding数据全景洞察 实现业务安全和诊断排查自主调优移动开发者使用倍业全域融合实时 Bidding 后,倍业科技Blink(倍联)将为移动开发者提供 Bidding 全链路数据预警诊断解决方案:首先,移动开发者可通过Blink全方位数据看板洞察 Bidding 核心数据;其次,Blink(倍联)将提供系统化异常预警和诊断排查指引,供移动开发者在使用期间轻松完成业务安全和自主诊断排查调优,顺利获取 Bidding 的最优使用体验,实现效率和效益的双向提升。一、全方位数据看板洞察Bidding效果只需登录Blink(倍联)平台 ,点击左侧 TAB「数据报表-媒体数据」,接入倍业全域融合实时 Bidding 的移动开发者后台会自动展开关键指标,同时支持“自定义配置数据指标”洞察Bidding效果。二、异常预警,实现业务安全点击Blink(倍联)左侧TAB「流量监管-告警规则」,自定义配置广告曝光率、竞价率、请求数、拦截数、参与竞价率和成功竞价率等Bidding通用性指标,进行阈值设定及数据监控。告警规则配置完成后,设置通知方式,Blink即可实时监控并按照维度进行阈值判定,并向钉钉或企业微信发送Bidding异常详细数据警报。三、诊断排查指引,自主调优当遇到Bidding异常情况,由于广告请求量大、路径复杂、技术等门槛,普通移动开发者能够采取的应对措施相当有限。倍业科技诊断分析功能,基于渠道填充诊断技术+Blink平台,洞察你想见的Bidding异常详情,针对性解决了移动开发者与Bidding采买填充自检和优化调整难题,通过诊断分析功能,筛查每次Bidding异常原因,同时基于行业经验,判断该次Bidding是否存在优化调整空间,并列明异常具体原因以及生成相关调整建议,方便移动开发者诊断排查指引,自主调优 Bidding 变现效果。使用说明:1.填充异常统计数据(优化):在“未填充异常占比”中用蓝色表示当前已知原因占比,检查归纳总结出“填充失败原因占比”,生成“未填充原因详情”。从而清晰看出各种填充失败原因占比,有针对性地对未填充渠道进行优化。2.APP/广告位/渠道数据:“媒体选项”表示该开发者旗下不同APP对应的填充统计数据,“广告位选项”表示APP内不同广告位对应的填充统计数据,“渠道选项”表示上游不同渠道竞价采买填充统计数据。3. 填充诊断周期数据:自选“20xx年xx月xx日 xx:xx - 20xx年xx月xx日 xx:xx”,表示此次填充诊断分析结果是以年/月/日/h周期的数据为分析基础。此外,Blink填充诊断每小时更新一次最新数据。渠道填充诊断数据只是对APP过去数据(填充请求、渠道竞价等)的统计分析反馈,如果想要实现填充率优化,需要对未填充原因进行排查调整改进。以上图(已授权并脱敏)填充失败原因较多的3点举例,49.35%未命中制造商定向是由于请求为非广告主投放的目标用户,这时需要根据原因详情找出上游渠道,再结合市场商务反馈,判断是否此类广告主在该渠道为短期还是长期投放,实时调整该渠道广告填充竞价请求顺序。37.08%命中反作弊规则说明无效流量或者误判无效流量过多,需要自检是否存在作弊流量,以及研究如何对抗黑灰流量,减轻自身流量品牌信誉损失,降低长期收益损失。10.31%渠道没有广告返回,这就需要查看是否存在请求配置参数错误、拦截还是上游问题。针对相关问题,梳理出高频原因,做好运营技术培训,降低同类型问题出现频率。当然以上只是部分情况,此外高频发生的还有上游渠道有广告返回,可是由于排序优先级、广告素材质量、与其他类型需求方联盟渠道比价失败等原因,这时候既要调整相关优先级顺序,更要进行相关频次设置,避免超频繁地成功竞价填充缺投放展现失败,失去流量采买渠道,拉低整体收益。倍业科技成立于2015年,以“赋能媒体商业化”为使命和愿景。自主研发推出APP自己的商业化管理和运营产品Blink,先后获得了险峰华兴、竑观投资、颐成投资等机构的投资。业务涵盖视频、社交、金融、教育、交通出行、汽车、母婴、动漫、工具等多个领域媒体商业化。已与国内100多款知名媒体建立长期合作伙伴关系。倍业科技整合了API和SDK解决方案,结合了全栈式广告技术,通过流量管理和运营优化工具,为媒体充分挖掘每个流量的价值。
Card image cap
倍业Bidding:重新定义APP广告变现技术架构
2022年08月26日
移动开发者追求的是APP广告收益最大化,可如何实现APP收益最优化且稳定呢?那就要在技术架构上对现有“广告请求-广告竞拍”的核心逻辑进行改造激发沉默流失收益。APP广告变现业务痛点目前的业务流程,当APP内某个广告位想请求并展示广告的时候,技术架构会按照Waterfall模式从上到下的广告源顺序来请求和展示广告,完成流量分配分发。某APP开屏广告位每日有400万个请求,经过测试估算出T广告源,50%填充率,40元/cpm;C广告源,80%填充率,30元/cpm,移动开发者怎样进行广告请求才能让收益最大化呢?A:将400万个请求都给T,广告收益=4000000 x 50% x 40/1000=80000B:将400万个请求都给C,广告收益=4000000 x 80% x 30/1000=96000方案B的总体收益最高。 虽然C广告源虽然价格低,但是填充率高抬高了整体收益。有没有一种方法能实现在已知价格和填充率高低,整合方案A和B,实现对T广告源高价和C广告源高填充充分开发的优化方案呢?在现有Waterfall模式下( 方案W):将400万个请求先给T广告源,未填充的给C广告源,理论收益最优= 4000000 x 50% x 40/1000 + 4000000 x(1-50%)x 80% x 30/1000 = 128000很明显方案W优于AB,广告请求拍卖在Waterfall模式下,一定程度下保证了高cpm和高填充率。可在实际业务中,这400万的广告请求是广告位单日多次请求的总和,T广告源和C广告源因时间段、用户画像等因素针对每次请求给予的采买价格和填充量都不是固定的。无论40元30元还是50%80%都是一种基于前日的预估,可能在多次广告请求中,C广告源的采买价格都高于T广告源(只是填充量相对于整日填充量较少,所以拉低了C广告源价格的预估),每次都给T广告源优先填充,这样也造成了很多的沉默广告价值流失。那又有什么方法可以实现每次请求广告收益最优,从而实现请求总和的广告收益优化从量变到质变的转化吗?倍业Bidding,国内SDK/API全域融合实时Bidding开创者。倍业Bidding针对APP广告位每一次请求进行全域融合实时竞拍,并遵循“价高者得”的竞拍规则。通过局部每一次“广告请求-广告竞拍”最优化,达成移动开发者追求整体广告收益最优化的目标。相较于传统单一的Waterfall模式,倍业Bidding重新定义APP广告变现技术架构,已经帮助合作的上述APP实现了收益提升30%,APP广告整体填充率提升至95%。倍业Bidding已将SDK客户端竞价(Client Bidding)和API服务端竞价(Server Bidding)融合进行Bidding,目前已完成对穿山甲gromore、腾讯广告优量汇、阿里tanx、快手、拼多多、京东等进行技术集成。此外,我们发现部分APP主要预算来源的广告平台并不支持外部Bidding,我们也为此推出了倍业Bidding + Waterfall的混合竞价优化方案,同时支持自定义添加更多广告平台配置,满足该类移动开发者尝鲜增收的意愿。倍业Bidding + Waterfall:倍业Bidding + Waterfall优化缩减了单一Waterfall模式下的多个ID和分层。具体表现为多个实时竞价渠道在倍业Bidding后,胜出者进入Waterfall的预留Bidding ID位,减少了未胜出的竞价渠道ID设置和Waterfall的层级。倍业Bidding胜出者再按照Waterfall顺序,从上到下逐层与不支持Bidding的优质广告源预设价格“竞价”,最终胜出者获得该次广告填充展示。倍业Bidding两种技术对接特点在集成倍业Bidding SDK时,发布商可通过C2S(Client-to-Server)或S2S(Server-to-Server)方式进行集成。移动开发者需根据两种对接方式的特点,结合自己的实际情况选择合适的方案进行对接。C2S步骤C2S的询价发起方为客户端的SDK,移动开发者调用SDK接口进行询价,通常在应用的客户端本地进行竞价。这种方式集成简单、直接,但由于竞价逻辑在客户端,调整灵活性相对较低,且客户端受网络环境影响较大,一旦网速差就会延迟高,竞价信息传输速度可能会受到一定的影响。S2S步骤S2S的询价发起方为移动开发者或广告聚合平台的服务器(通常为OpenRTB请求),并且竞价逻辑在移动开发者或广告聚合平台的服务器上完成。这种方式的服务端通信延迟低、耗时短,同时竞价逻辑调整更灵活,但集成成本相对较高,需要发布商自建服务器。倍业Bidding除了收益优化这一核心亮点,在响应时长(出价和广告加载)也上有显著提升。此外,倍业Bidding与Blink的流量管理、AI监管(智能素材审核+智能预警)、诊断分析、资产管理、到投放管理等管理工具相嵌合,而且还对正式合作伙伴开放数据采集等代码,从源头保证合作伙伴数据等安全。倍业科技整合多家数据,为开发者提供多维度全方位数据报表,开发者可在Blink平台及时全方位洞察分析判断效果。更多惊喜请报名参与倍业Bidding测试!倍业科技成立于2015年,以“赋能媒体商业化”为使命和愿景。自主研发推出APP自己的商业化管理和运营产品Blink,先后获得了险峰华兴、竑观投资、颐成投资等机构的投资。业务涵盖视频、社交、金融、教育、交通出行、汽车、母婴、动漫、工具等多个领域媒体商业化。已与国内100多款知名媒体建立长期合作伙伴关系。倍业科技整合了API和SDK解决方案,结合了全栈式广告技术,通过流量管理和运营优化工具,为媒体充分挖掘每个流量的价值。