现阶段的服务端Header Bidding约等于RTB
2022年03月25日

一、RTB和Header Bidding简介

RTB（RealTime Bidding）实时竞价，是一种利用第三方技术在数以百万计的网站/APP上针对每一个用户展示行为进行评估以及出价的竞价技术。

Header Bidding（头部竞价），又叫做预先竞价（Pre-bidding）、提前竞价（Advance bidding），包含应用内竞价/客户端竞价（In-app Bidding ）和服务端竞价（比如GroMore等产品)。Header Bidding允许多个广告源对开发者的广告库存进行实时竞价，最高出价者赢得该次广告展示机会。简而言之，开发者可以通过Header Bidding从众多广告源寻找“实时竞拍价高者得”。

二、RTB和服务端Header Bidding运作基本原理

RTB成交规则广义二阶定价

RTB的实际成交价是按照第二高价+1分来结算，这是为了最大化保障卖方（APP)和买方的利益。一方面，既避免了恶意DSP通过不断降低出价来试探出成交价，又可以让买方在市场上公平竞争，得出更高的最终成交价，使卖方(APP)的利益得到维护。另一方面，第二高价也为买方提供了保护作用，可以让流量真实的定价由市场决定，避免卖方违背市场规律性的抬价涨价行为。

RTB竞价基本原理

以APP RTB流程举例

流程1：用户在手机上访问APP。

流程2：APP通知广告交易平台：640*100（假定值） banner广告位要向用户展现广告。

流程3：广告交易平台根据这个竞价请求组织一次竞价。由竞价发起服务向各需求方发送竞价请求（Bid Request），询问是否需要竞价，并传输用户A的User ID（广告交易平台的用户cookie或者移动设备ID等），用户IP和广告位信息（页面URL、广告位置等）。

流程4：需求方监听服务接收到广告交易平台发来的竞价请求后，将竞价请求信息传输给竞价引擎。

流程5：竞价引擎根据广告交易平台User ID向用户数据中心查询用户相关信息。

流程6：用户数据中心向竞价引擎返回用户A的信息，如性别、年龄、兴趣爱好等。返回的具体用户信息需要参照用户数据中心的信息维度而定。

流程7：竞价引擎将用户数据和投放需求进行匹配，决定是否参与出价以及CPM出价。

流程8:竞价监听服务将竞价应答并发送CPM价格和广告代码反馈给竞价决策服务。

流程9：广告交易平台收到所有需求方的出价响应后由竞价决策服务进行竞拍。价格高者得，次高价结算，即出价最高的需求方赢得本次展现，并以第二高的投标价格（比第二高多1分钱）跟广告交易平台结算。同时，竞价决策服务需要为供应方（APP）返回赢得本次竞价的需求方的竞价信息（CPM价格和广告代码）

流程10：app向需求方请求广告物料的展示。

流程11：需求方物料管理服务返回对应的广告物料。需要说明的是，广告物料必须先经过CDN服务再呈现在广告位。另外，需求方平台还会收到广告交易平台发送的竞价消息（Win Notice），表示该次展现已经竞价成功。

流程12：用户看到广告，当前竞价流程结束。

图片来源：倍业科技RTB竞价流程

服务端Header Bidding成交规则最高价定价

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

服务端Header Bidding基本原理

以APP的服务端Header Bidding为例

将RTB的竞价流程流程10和11换成以下4步，其他步骤相同

第一步，开发者客户端获取Token向服务端发起请求；

第二步，服务端会向各参竞方发起请求，进行实时竞拍，价高者得并向开发者客户端返回报价；

第三步，开发者客户端向 SDK请求广告物料；

第四步，SDK返回广告物料，开发者客户端展示。

图片来源：优量汇

三、总结

对比上述流程发现，服务端Header Bidding和RTB除了成交定价“不同”和再次外部竞价的四步流程不同，其他流程完全一致。为什么定价“不同”的不同要打双引号？这是由于现阶段的服务端Header Bidding都是单一广告平台内的竞价，所以RTB二价成交价就是服务端Header Bidding的最高价。比如GroMore虽然提供了支持优量汇等接入的接口，但是并没有拿到优量汇等API接口，更谈不上获取实时报价，那这种意义上的服务端Header Bidding就是单一广告平台内的竞价。至于再次外部竞价的四步流程不同，并无法开展，也不过是空有形式的罢了。

应用内竞价/客户端竞价（In-app Bidding ）相对来说，和RTB的区别就有本质不同：SDK在客户端自动执行共同竞价胜出规则，保证最高价成交。同时会提高填充率，降低流量退回率。
最高单价成交，Header Bidding允许多个广告网络针对每一次广告展示进行统一竞价，并且由最高出价者获得该广告展示机会，采用第一价进行结算，确保了开发者可以获得更高的广告收益。

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

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


Card image cap
倍业科技告警服务，让APP流量变现安心更放心
2022年11月25日
在APP流量广告变现时，若流量交易至广告展现任一环节系统异常，又或者是运营人员操作配置不当，都会导致公司产生大笔收入亏损。因此，业务监控告警在APP广告商业化路径中至关重要，这不仅是一线运营开展业务的底层数据资源，更是媒体广告商业化完整闭环的关键所在，对于商业化团队来说，业务监控预警与其工作形态密切相关，而完备的故障监控和预警系统对于广告商业化业务的稳定运行，也起着基础保障作用。倍联Blink告警架构一、监控什么？日常监控主要包含两个层面：接口监控在很多情况下，流程异常都是接口先报错，进而影响到后续流量变现业务，所以接口一般会比业务数据更快的暴露问题。比如新的广告平台对接接口、新的广告位创建接口等。系统会监控接口报错次数，正常情况下接口会正常运行并返回结果。但当接口报错时，意味着无法正常返回结果，会导致流程阻塞，那么就会自动触发告警，通知技术研发人员实时修改。如果接口在某一段时间内，数据量陡增超过设置的正常阀值，那意味着该接口可能存在异常，则会触发业务数据实时监控。业务数据监控对于广告商业化运营人员来说，最需要关注的就是流量变现业务数据，比如当天的填充率、广告返回率、素材拦截数、曝光率、超时率等。因所有业务数据都在实时跑，且受限于每个APP广告商业化团队的资源和实力，大家普遍T+1查看并分析前一天的详细数据，这就造成很大的业务风险。对此，倍联Blink却针对以上核心业务数据进行实时监控。如果发现在某个时间段内，有核心业务数据指标突然急剧下滑或者上升，那么很可能是业务出现异常，倍联Blink则会自动触发告警，通知运营人员及时调整。针对业务数据监控，倍联Blink重点观察核心业务数据变化趋势和极端绝对值。综上所述，倍联Blink监控的内容包括：接口报错监控，实时监控接口的报错情况。业务报错监控，实时监控业务数据核心指标的变化趋势。二、如何告警？如何监控告警，实际上蕴含了三个问题：针对什么进行告警？、什么情况下进行告警？、怎么告警通知？针对什么进行告警？针对什么进行告警，其实在上文需要监控什么中已经有所交代，我们一般需要对研发接口的报错情况和业务数据进行监控并告警。什么情况下进行告警？我们还要知道什么情况下进行告警，此处可以理解为设置告警规则，命中规则的情况下，就启动告警。举个例子，我们对30分钟内填充率、广告返回率等进行监控，如果其绝对值小于x，或者同比昨日30分钟内广告返回率低20%，则启动告警。怎么告警通知？当倍联Blink针对某个指标设置的告警规则生效后，需要如何通知接受人呢？这个问题的实质是倍联Blink对告警级别的处理，不同级别的告警有不同的运行频率和通知机制。我们大致可以分为以下二种：普通告警普通告警一般为数据变化存在异常，需要运营或者研发进行确认是否存在问题，此时不一定有业务风险，可能是活动等原因造成的波动。通知方式是通过绑定的企业微信或者钉钉发送告警信息。致命告警致命告警为数据绝对值出现明显异常，需要马上解决问题。例如广告填充率、曝光率等任一指标突然降为0，素材拦截数等任一指标突然变为100%，一般为每10分钟或每30分钟运行一次。当这类重大业务风险出现时，除了通过绑定的企业微信或者钉钉发送告警信息，还会人工电话联系APP合作伙伴。此外，倍联Blink告警除了能洞察媒体流量商业化业务服务异常，自动执行告警规则。在获得多方授权的前提下，能够依托深度学习技术自动采集，并训练策略模型，提升流量变现防范效率，守护媒体广告商业化业务持续性安全发展。更多详情可前往倍业科技官网了解咨询倍业科技 - app自己的商业化平台​www.bayescom.com/倍业科技成立于2015年，以“赋能媒体商业化”为使命和愿景。自主研发推出APP自己的商业化管理和运营产品Blink，先后获得了险峰华兴、竑观投资、颐成投资等机构的投资。业务涵盖视频、社交、金融、教育、交通出行、汽车、母婴、动漫、工具等多个领域媒体商业化。已与国内100多款知名媒体建立长期合作伙伴关系。倍业科技整合了API和SDK解决方案，结合了全栈式广告技术，通过流量管理和运营优化工具，为媒体充分挖掘每个流量的价值。
Card image cap
聚焦APP流量变现场景痛点，将推出颗粒化系列解决方案
2022年11月04日
全域融合实时Bidding厂商倍业科技，基于旗下Blink（倍联）流量管理、A/B Test、AI素材审核、智能告警、诊断分析、全方位数据报表、投放管理、资产管理等功能，聚焦APP流量变现日常工作场景中的高频痛点难点，向移动开发者有针对性地推出颗粒化系列解决方案，让使用者有情感共鸣，让客户有价值认同。倍业科技为合作伙伴免费开放各项产品功能，以及全流程技术和运营支持，并提供API和SDK两种对接方式，为APP提供全生命周期流量变现服务。灵活成熟的功能模块，助力APP长期良性变现APP增加广告变现后，一般会对用户体验产生影响，比如广告展示过多往往会影响用户留存。倍业科技流量分组可以针对不同的用户群体多维度设置分层请求排序，实施不同的流量变现策略、控制广告展示频次；比如A/B Test可以对比同一流量分组下倍业Bidding、传统Waterfall等不同变现策略广告变现效果，从中选取效益最优的广告变现策略。要想在广告变现和用户体验中取得平衡，实现长期良性流量变现，移动开发者需要针对大量的数据进行分析，持续优化流量变现策略。为此，倍业科技提供全方位数据报表有效帮助移动开发者全面分析广告变现收益，分析上游广告渠道采买填充行为和用户观看点击广告素材意愿，优化广告展示频次，实时调整流量变现策略。多元化的广告类型和丰富的广告渠道储备，节省研发集成时间APP类型往往决定其功能比较垂直，好效果的广告位选择空间也相对较少。为了在用户有限的停留时长内尽量多的展示广告，移动开发者需要在不同的广告场景下增加不同样式的广告。针对APP广告场景特点，倍业科技提供穿山甲、腾讯优量汇、百度百青藤、快手联盟等300+市面主流广告平台，以及各自对应的开屏、激励视频、信息流、横幅、全屏视频等广告类型一站式快捷适配。同时支持自定义更多广告API/SDK配置，满足移动开发者在不同的场景下使用不同素材和不同广告类型的诉求，进一步提高了移动开发者的集成效率。SDK代码透明化和私有化部署SaaS并举，最大化保障APP安全面对移动开发者特别是中腰部APP,不断增加的数据安全自主需求。一方面，倍业科技将SDK代码透明化开源，确保数据从采集、传输、使用全链条实现技术可视化。另一方面，倍业科技研发的私有化部署SaaS，可以直接克隆Blink(倍联）平台功能和后台，一站式迁移至移动开发者自有服务器，从源头实现数据安全自主可控。此外，私有化部署SaaS还满足移动开发者专项定制研发、品牌logo展示等个性化需求。截止目前，倍业科技已服务过韩剧TV、人人视频、快对、soul、爱尚天气、驾考宝典、动漫之家等APP，处理过亿级请求量、实现了日千万级曝光量，并保持APP高填充率。当然上述介绍只是提炼的部分APP流量变现场景痛点，以及对应的颗粒化解决方案。后续倍业科技将着重介绍已推出的更多颗粒化解决方案，帮助移动开发者更好实现成本优化或效益提升，为大家提供新的价值创造动能。更多详情可前往倍业科技官网了解咨询倍业科技 - app自己的商业化平台​www.bayescom.com/倍业科技成立于2015年，以“赋能媒体商业化”为使命和愿景。自主研发推出APP自己的商业化管理和运营产品Blink，先后获得了险峰华兴、竑观投资、颐成投资等机构的投资。业务涵盖视频、社交、金融、教育、交通出行、汽车、母婴、动漫、工具等多个领域媒体商业化。已与国内100多款知名媒体建立长期合作伙伴关系。倍业科技整合了API和SDK解决方案，结合了全栈式广告技术，通过流量管理和运营优化工具，为媒体充分挖掘每个流量的价值。