实时竞价(RTB)投放引擎技术说明文档
🌠实时竞价(RTB)投放引擎技术说明文档
type
status
date
slug
summary
tags
category
icon
password
Status

实时竞价(RTB)模型服务器技术说明文档

第1章:程序化广告生态系统

本章旨在建立对实时竞价(RTB)模型服务器运行环境的基础认知。在深入探讨服务器的具体技术细节之前,必须首先理解其所处的复杂、多方参与的生态系统。RTB服务器并非一个孤立的实体,而是在一个由买方、卖方和中介机构组成的庞大、互联的网络中扮演着关键节点的角色。

1.1. 核心参与者与平台

程序化广告生态系统的基本结构由供需双方的动态关系所定义。多个关键角色及其所依赖的技术平台共同构成了这个市场的骨架,驱动着每一次广告展示的交易过程。
  • 广告主(需求方): 广告主是希望向特定目标受众展示广告以达成营销目标的实体,例如提升品牌知名度、促进产品销售或获取用户注册。他们是需求方平台(DSP)的主要使用者 。
  • 媒体(供应方): 媒体,也称为发布商,是拥有网站或移动应用等数字资产并提供广告库存(即广告位)的所有者。他们的核心目标是通过出售这些广告位来实现收入最大化。他们是供应方平台(SSP)的主要使用者 。
  • 需求方平台(Demand-Side Platform, DSP): DSP是服务于广告主的技术平台,旨在自动化地从多个来源采买广告库存。其核心能力在于能够在极短的时间内(通常小于100毫秒)实时分析单次广告展示机会的价值,并根据广告主设定的标准决定是否竞价以及出价多少 。本文档所描述的RTB模型服务器正是DSP系统的大脑和决策中枢。
  • 供应方平台(Supply-Side Platform, SSP): SSP是服务于媒体的技术平台,旨在自动化地将其广告库存出售给出价最高的买方。它通过连接多个广告交易平台和DSP,帮助媒体方最大化其广告填充率和收益 。
  • 广告交易平台(Ad Exchange, AdX): AdX是一个中立的数字化市场,它如同一个拍卖行,连接着来自众多SSP的广告库存和来自众多DSP的广告预算,促进广告库存的实时买卖 。
这些平台之间的关系并非简单的协作,而是由一种内在的经济张力所塑造。RTB生态系统的基础架构源于其主要参与者之间固有的利益冲突:DSP的存在是为了以尽可能低的价格为广告主获取最有价值的广告库存;而SSP的存在则是为了以尽可能高的价格为媒体方售出其广告库存 。广告交易平台(AdX)则是在每一次广告展示的瞬间,解决这一冲突的中立战场。这种对抗性的关系是该领域技术创新的主要驱动力。
为了在这场逐次展示的零和博弈中胜出,各方都发展出了复杂的技术。DSP投入巨资研发复杂的预测模型,以精准评估每次展示的价值,从而避免浪费预算并提高投资回报率(ROI)。与此同时,SSP则开发了诸如头部竞价(Header Bidding)之类的技术,通过同时向多个需求方发起询价来加剧竞争,打破了过去效率低下的“瀑布流”模式,从而抬高了售卖价格 。因此,从预测建模到拍卖机制,整个技术栈的演进都是这一基本经济冲突的直接产物,构成了一场持续的优化算法军备竞赛。
平台
主要用户
核心功能
主要目标
需求方平台 (DSP)
广告主、广告代理商
自动化广告采买与优化
最大化广告主投资回报率 (ROI)
供应方平台 (SSP)
媒体、应用开发者
自动化广告售卖与收益管理
最大化媒体方广告收入
广告交易平台 (AdX)
DSP 与 SSP
提供中立的、集中的实时拍卖市场
促进市场交易效率
数据管理平台 (DMP)
广告主、媒体及其他平台
用户数据收集、细分与扩充
提供可操作的受众洞察
导出到 Google 表格

1.2. 一次实时广告展示的生命周期

RTB的全过程发生在用户加载网页或应用的几百毫秒之内,这是一个高度自动化、时间敏感的流程,构成了RTB模型服务器的宏观操作环境 。
  1. 用户访问: 用户通过浏览器访问媒体网站或打开移动应用 。
  1. SSP启动: 页面中的广告代码触发媒体方集成的SSP。SSP随即收集关于该用户(通过Cookie或设备ID获取的人口属性、地理位置、浏览历史等)和广告位(尺寸、位置等)的信息 。
  1. 竞价请求广播: SSP将包含这些信息的“竞价请求”(Bid Request)发送给一个或多个广告交易平台(AdX)。
  1. AdX转发至DSP: AdX接收到竞价请求后,会将其广播给所有与之集成的DSP。这是本文档所讨论的RTB模型服务器的数据入口点 。
  1. DSP分析与竞价(服务器核心功能): 各个DSP的竞价服务器接收到请求,解析其中被称为“竞价流数据”(Bidstream Data)的用户与情境信息 。服务器内部的预测模型会迅速评估这次展示的价值,同时检查广告活动的预算、频次控制等约束条件。如果认为值得竞价,服务器将构建一个“竞价响应”(Bid Response),其中包含出价和广告素材信息,并将其发回AdX。整个过程必须在严格的超时限制内(通常为100毫秒)完成 。
  1. 拍卖裁决: AdX收集所有DSP返回的有效出价,进行一次拍卖(通常为“次高价密封拍卖”,即出价最高者获胜,但只需支付第二高的出价金额),并确定获胜者 。
  1. 广告投放: 获胜DSP的广告素材通过AdX -> SSP -> 媒体页面的路径回传,并最终在用户的设备上渲染展示 。
以下序列图详细描绘了这一完整的交互流程:
notion image
这个生命周期不仅是一个交易流程,更是一个大规模、高速度的数据广播机制。单次页面加载就会导致用户的个人数据(如地理位置、浏览历史、设备ID)被复制并发送给数十甚至上百家公司(所有参与竞价的DSP),尽管最终只有一家会赢得展示机会 。这种架构模式带来了深远的系统性影响。首先,它引发了严重的隐私问题,因为用户的敏感数据被广泛传播,这与用户的合理预期相悖,并为数据滥用打开了方便之门 。其次,这种系统性的隐私风险直接催生了严格的法规监管,其中最著名的就是欧盟的《通用数据保护条例》(GDPR)。为了应对法规要求,广告技术行业不得不引入新的技术组件——同意管理平台(Consent Management Platform, CMP),它在受监管地区成为了整个RTB流程启动的前置条件,负责获取和管理用户的同意授权 。因此,RTB拍卖的一对多广播架构,直接导致了隐私危机,进而推动了法规出台,最终又迫使生态系统演化出新的技术(CMP)来弥补其固有的缺陷。

第2章:系统架构与数据流

本章将聚焦于RTB模型服务器本身,明确其在DSP整体基础设施中的定位,并详细阐述制约其运行的数据契约,即其输入(竞价请求)和输出(竞价响应)的结构与内容。

2.1. 竞价服务器的架构定位

竞价服务器(Bidding Server 或 Bidder)是DSP系统中负责实时处理竞价请求的核心组件。它必须是一个具备极低延迟和极高吞吐能力的系统,以应对来自广告交易平台的海量并发请求。在架构上,它由一系列支持系统辅助:
  • 离线系统: 负责模型训练、广告活动管理和数据报告生成。
  • 近实时系统: 负责预算消耗跟踪和用户频次控制数据的更新与查询。
  • 在线系统(竞价服务器本身): 负责在低于100毫秒的严格时限内,完成对单次广告展示机会的评估、决策并返回竞价 。
典型的部署架构如下所示,其中竞价服务器集群是处理实时流量的关键部分。
notion image
 

2.2. 上游数据入口:竞价请求剖析

竞价请求(Bid Request)是竞价服务器的主要输入。它是一个结构化的数据对象,行业内普遍遵循由IAB Tech Lab制定的OpenRTB协议。该对象包含了服务器做出决策所需的所有情境信息。
  • 核心对象: 一个典型的竞价请求由多个关键的JSON对象组成,包括:
    • imp:描述广告展示机会的细节,如广告位尺寸、类型(横幅、视频、原生)、底价等。
    • site / app:描述广告位所在的媒体信息,如网站域名或应用包名、内容分类等。
    • device:描述用户设备的信息,如设备类型(手机、PC)、操作系统、地理位置、IP地址等。
    • user:描述用户的信息,如用户ID(通常是Cookie ID或移动设备ID)、人口属性(年龄、性别)等 。
  • 媒体约束: 请求中还包含了媒体方设定的交易规则,例如:
    • bcat:屏蔽的广告主行业类别。
    • battr:屏蔽的广告素材属性(如弹窗、自动播放音频等)。
    • imp.secure:要求广告素材必须使用HTTPS 。
      • 竞价服务器必须严格遵守这些约束,否则其出价将被视为无效。
  • 数据增强: 在收到请求后,DSP通常会利用自有数据或来自数据管理平台(DMP)的数据对其进行增强,以获得更全面的用户画像,从而做出更精准的判断 。
从系统设计的角度看,竞价请求不仅仅是一个数据包,它本质上是为一个机器学习模型实时生成的、高维度的特征向量。从SSP收集用户与情境数据,到DSP进行内部数据增强,整个上游流程实际上构成了一个实时的特征工程管道。竞价服务器的核心任务,正是在毫秒级的时间内对这个特征向量完成一次模型推理。请求中的每一个字段,如 device.geo.countryuser.genderimp.banner.w 等,都可以直接映射为模型中的一个特征。这种视角将竞价服务器的角色从一个简单的交易处理节点,重新定义为一个高性能的机器学习推理引擎。竞价请求中“特征”的质量,直接决定了预测的准确性,并最终决定了广告主预算的使用效率。

2.3. 下游数据出口:竞价响应的构建

如果服务器决定参与竞价,它必须构建一个符合OpenRTB协议的竞价响应(Bid Response)。这个响应同样是一个结构严谨的数据对象。
  • 核心组件: 响应中必须包含以下几个关键字段:
    • price:出价,单位通常是CPM(每千次展示成本)。
    • crid:广告素材ID,用于标识具体的广告创意。
    • adm:广告素材标记(Ad Markup),即用于渲染广告的HTML/JavaScript代码片段或VAST XML(视频广告标准)。
  • 尺寸匹配: 响应中声明的广告素材尺寸必须与竞价请求中提供的可用尺寸之一完全匹配 。
  • 追踪URL: 响应中会包含一系列用于追踪和计费的URL,其中最重要的是:
    • burl (Billing URL) 或 impression_tracking_url:当广告被成功渲染时,用户的浏览器会调用此URL,用于通知DSP此次展示成功,并作为计费依据。
    • 这些URL中通常包含宏(Macros),如 ${AUCTION_PRICE},广告交易平台在获胜后会用实际的成交价替换这些宏,再进行调用 。
以下是一个竞价请求与响应的结构示意图:
notion image

2.4. 拍卖后的反馈闭环

DSP系统的智能并非一成不变,它依赖于从其竞价结果中持续学习。这一学习过程是通过一个由拍卖后信号组成的反馈闭环来实现的。
  • 竞价成功通知(Win Notification): 广告交易平台会向获胜的DSP发送一个成功通知,其中通常包含了清算价格(即DSP实际需要支付的价格)。这是进行成本效益分析和利润计算的关键数据。
  • 展示信标(Impression Beacon): 当广告在用户浏览器上被实际渲染出来时,竞价响应中嵌入的burl会被调用。这确认了展示的发生,是广告计费和衡量广告可见性的基础 。
  • 点击追踪(Click Tracking): 如果用户点击了广告,他们会被重定向到DSP的点击追踪服务器。服务器记录下这次点击事件,然后再将用户导向广告主的目标落地页。
  • 转化追踪(Conversion Tracking): 如果用户在点击广告后,在广告主的网站上完成了预设的目标(如购买商品、填写表单),广告主页面上预埋的转化追踪代码(Pixel)会被触发,将转化事件归因于相应的广告活动并回传给DSP。这是衡量许多效果广告活动最终成功的核心指标。
这个反馈闭环是驱动整个系统学习和演进的根本机制。每一次成功的通知、展示、点击和转化,都是一个宝贵的数据点,用于训练和迭代预测模型。可以将竞价请求中的特征向量视为训练数据(X),而这些反馈信号则提供了与之对应的真实标签(Y),例如 clicked=1converted=0 。因此,这个反馈闭环在功能上等同于一个机器学习流水线的数据标注与收集阶段。该闭环中的任何延迟或数据丢失,都会直接损害系统未来的性能。例如,由于广告拦截器导致展示信标未能触发,或广告主的转化代码配置错误,都会使模型在不完整或有偏的数据上进行训练。这会形成一个恶性循环:质量差的反馈数据导致模型准确性下降,进而导致次优的竞价决策,最终损害广告活动表现并可能产生更少的有效反馈数据。因此,维护这个反馈闭环的数据完整性和时效性,对于DSP系统的长期智能和商业可行性至关重要。

第3章:核心展示价值评估与预测建模

本章是本文档的核心,旨在揭示RTB模型服务器的“智能”所在。它将详细阐述如何将一个抽象的广告展示机会,通过量化分析和预测,转化为一个具体的货币价值,并以此为基础做出竞价决策。

3.1. 展示价值评估原则

竞价服务器的首要任务是为每一次广告展示机会,计算其对于特定广告活动的期望价值(Expected Value)。这个价值是用户采取期望行动(如点击、转化)的概率与该行动为广告主带来的价值的乘积 。一个以效果为导向的广告活动,其核心价值评估逻辑可以概括为:
期望价值=P(点击)×P(转化∣点击)×单次转化价值
为了实现正向的投资回报率,竞价服务器的出价必须低于这个计算出的期望价值。

3.2. 效果预测模型:pCTR 与 pCVR

上述价值公式中的概率项是未知的,必须通过机器学习模型进行预测。这些模型是竞价服务器决策质量的基石。
  • pCTR (predicted Click-Through Rate) 模型: 预测点击率模型。该模型以竞价请求中的海量特征(用户、设备、媒体、情境等信息)作为输入,输出一个概率值,表示在当前情境下,特定用户点击特定广告的可能性。
  • pCVR (predicted Conversion Rate) 模型: 预测转化率模型。该模型预测用户在点击广告之后,完成最终转化行为(如购买、注册)的概率。
这些模型通常是基于海量历史竞价数据和其最终结果(是否被点击、是否转化)训练而成的大规模机器学习模型,例如逻辑回归(Logistic Regression)、梯度提升决策树(Gradient Boosted Trees, GBT)或深度神经网络(Deep Neural Networks, DNN)。模型的准确性直接决定了DSP的竞价效率和盈利能力。

3.3. 应对冷启动问题

预测模型面临的一个关键挑战是“冷启动”问题:当遇到新的广告素材、新用户或新媒体时,由于缺乏历史互动数据,模型无法做出准确的预测。模型中基于ID的特征嵌入(Embeddings)要么训练不足,要么根本不存在,这严重影响了新项目的推广效果 。
应对冷启动问题的策略包括:
  • 利用内容特征: 依赖那些不需要历史互动数据的特征,例如广告素材的文本描述、媒体网站的内容分类、用户的基本人口属性等。
  • 生成式嵌入: 采用先进技术(如扩散模型)为新项目生成一个“预热”的嵌入向量。例如,一个新款跑鞋广告的嵌入可以基于其“体育用品”的属性,被初始化在其他运动服饰广告嵌入向量的附近,从而获得一个合理的起点 。
  • 探索-利用(Explore-Exploit)算法: 在初期,系统性地分配一小部分预算,采用探索性策略(如“上置信界”算法 - UCB)对新项目进行竞价,以快速收集性能数据。一旦积累了足够的数据,再切换到基于模型预测的“利用”策略。

3.4. 从预测到出价:竞价计算公式

本节将给出具体的公式,展示如何将模型的预测输出与广告主的业务目标相结合,计算出最终的竞价。对于一个设定了目标转化成本(Target CPA)的广告活动,其理想出价可以表示为:
出价=pCTR×pCVR×Target CPA
这个公式计算出的价格,代表了在满足平均转化成本目标的前提下,广告主愿意为单次广告展示支付的最高金额。竞价服务器会以此为基准,再结合预算调控、利润率、拍卖动态等其他因素,进行调整后得出最终提交的出价。

第4章:高级竞价策略与优化

本章将探讨核心价值评估逻辑如何被扩展,以适应多样化的广告主目标,并实现超越简单出价的性能优化。这包括如何在一个统一的拍卖环境中处理不同类型的竞价,以及如何通过目标驱动的智能出价策略来最大化广告效果。

4.1. 统一异构出价:eCPM 的作用

在RTB生态中,广告交易平台通常以CPM(每千次展示成本)为基础进行拍卖和结算。然而,广告主的目标却多种多样,可能基于点击(CPC)或转化(CPA)。为了让这些不同计费模式的广告活动能在同一个拍卖中公平竞争,它们的出价必须被换算成一个通用货币——eCPM(effective Cost Per Mille,有效千次展示成本)。
  • eCPM换算公式:
    • 从CPC出价换算:eCPMCPC=CPC出价×pCTR×1000
    • 从CPA目标换算:eCPMCPA=目标CPA×pCVR×pCTR×1000
系统会为每个潜在的广告活动计算其eCPM值,并选择eCPM最高的那个参与竞价。这确保了最有可能为媒体方带来最高收入(同时也为广告主创造最大价值)的出价能够胜出 。
竞价模型
计费事件
典型广告主目标
主要风险承担方
CPM
广告展示
品牌知名度、曝光量
广告主(无论效果如何均需付费)
CPC
广告点击
网站流量、用户互动
媒体(仅在发生点击时获得收入)
CPA
用户转化/行动
销售额、潜在客户、应用安装
媒体(仅在发生转化时获得收入)
eCPM的换算不仅是数学上的标准化,其背后更是一种深刻的风险转移机制。在一个纯粹的CPC计费模式下,如果广告被展示但未被点击,媒体方将得不到任何收入,风险由媒体方承担 。但在RTB拍卖中,交易的标的是“展示权”,支付基于最终的CPM成交价。当DSP将一个CPC目标通过
CPC * pCTR * 1000 的公式转换为eCPM出价时,它实际上做出了一个基于概率的承诺。它向交易平台声明:“根据我的预测,这次展示值这个CPM价格,我愿意为此立即付款。” 如果DSP赢得拍卖并支付了费用,但用户最终没有点击,那么这次展示的成本就由DSP和其背后的广告主承担了。媒体方已经安全地获得了该次展示的收入。因此,eCPM的计算和竞价过程,将单次展示的效果风险从卖方(媒体)转移到了买方(DSP)。DSP的盈利能力,从根本上取决于其pCTR和pCVR模型的长期预测准确性。

4.2. 目标导向型竞价 I:优化点击成本 (oCPC)

oCPC(Optimized Cost Per Click)是一种智能化的自动出价策略。广告主设定一个期望的平均点击成本(Average CPC),系统则实时调整出价,以在达成该成本目标的前提下,最大化总点击次数 。
  • 工作机制: 系统利用其pCTR模型来识别那些具有高点击可能性的展示机会。对于高pCTR的流量,系统会提高出价以增加竞得概率;而对于低pCTR的流量,则会降低出价甚至不出价。其优化的目标是控制大量点击的平均成本,而非单次点击的成本 。oCPC策略通常需要一个“学习期”,在此期间系统会收集足够的点击和转化数据(例如,至少50次转化),以构建一个可靠的预测模型,之后才能稳定地进行优化 。

4.3. 目标导向型竞价 II:优化千次展示成本 (OCPM)

OCPM(Optimized Cost Per Mille)是一种更为高级的竞价策略,它直接以最终的业务转化为优化目标。广告主设定一个转化目标(如购买、注册),系统则利用其pCVR模型,将广告预算优先投放给最有可能完成转化的用户 。
  • 工作机制: 尽管计费方式仍然是基于展示(CPM),但系统的出价逻辑完全由预测的转化价值驱动。对于一个被模型判断为极有可能转化的用户,系统会非常激进地出高价;而对于转化可能性低的用户,则出价极低。这种策略能够将广告预算更高效地用于刀刃上,最大化转化次数,是效果导向型广告的终极形态 。OCPM策略尤其适用于拥有大量用户数据、能够支撑精准转化预测的平台和广告主。

第5章:广告活动执行与约束管理

本章将介绍在价值评估和竞价策略之上应用的运营逻辑层。这些是确保广告活动平稳运行、遵守广告主设定限制,并提供良好用户体验的关键控制系统。

5.1. 算法化预算调控

一个广告活动通常有固定的总预算和投放周期(例如,一周内花费10,000元)。如果采用一种朴素的竞价策略,很可能会在投放初期的几个小时内就耗尽全部预算,从而错失后续时间段内更有价值的展示机会。预算调控(Budget Pacing)算法的目的就是控制花费速度,确保预算在整个投放周期内平滑、合理地分配 。
  • 常用算法:
    • 流量节流(Throttling): 这是一种简单的方法,竞价服务器按照一个动态计算的比例,随机地放弃参与一部分拍卖,从而减缓花费速度 。
    • PID控制器(Proportional-Integral-Derivative Controller): 这是一种源于控制系统工程的更高级方法。系统会设定一条理想的“预算消耗曲线”(例如,一条直线),并持续将实际消耗与之对比。根据两者之间的误差(偏差)、误差的累积(积分)和误差的变化率(微分),PID控制器会动态调整一个全局的出价乘数,从而使实际消耗曲线能紧密跟随理想曲线。这是工业界广泛采用且行之有效的方法 。
    • 非线性/自适应控制: 这是最复杂的调控方法。系统利用模型预测未来的流量成本和可用性,然后主动地解决一个优化问题,将预算在不同时间段(例如,流量高峰期和低谷期)之间进行非均匀但最优的分配,以期在预算约束下最大化广告效果 。
下图展示了不同预算调控策略下的花费曲线对比:
notion image

5.2. 用户曝光管理:频次与新近度控制

向同一用户反复展示相同的广告,会导致“广告盲视”(Banner Blindness)、用户反感和广告预算的浪费。频次控制(Frequency Capping)旨在限制在特定时间窗口内,单个用户看到同一个广告、素材或广告活动的最大次数(例如,每24小时最多3次)。
  • 技术实现:
    • 用户识别: 依赖于一个稳定的用户标识符,如Cookie ID或移动设备广告ID(IDFA/GAID)。
    • 数据存储: 需要一个极低延迟的键值(Key-Value)数据库,如Redis或Aerospike,供竞价服务器在收到请求时实时查询。数据库的键是用户ID,值则是一个记录该用户对不同广告活动/素材的展示次数和时间戳的数据结构。
    • 实时检查: 在评估一个竞价请求时,服务器首先会查询这个数据库。如果发现针对该用户和当前候选广告的频次上限已达到,则会立即中止对该广告的后续竞价流程。
频次控制的技术实现,催生了DSP架构中一个至关重要的基础设施——高性能、集中式的用户画像库(User Profile Store)。这个系统的存在,不仅仅是为了满足频次控制这一项运营需求。一旦这个以用户ID为键、能够进行毫秒级读写的存储系统被建立起来,它的功能便可以被极大地扩展。其存储的“值”不再局限于简单的展示计数器,还可以包含更丰富的信息,如用户所属的受众分群标签(例如“体育爱好者”)、用户近期浏览过的商品(用于重定向营销)、用户与品牌广告互动的完整时间线等。因此,一个看似简单的运营需求,实际上成为了构建一个核心基础设施的催化剂。这个用户画像库从一个简单的计数器,演变成了DSP最强大的定向和个性化能力的基础,是整个系统用户智能的中央存储库。

第6章:附录

A.1. 广告技术术语表

  • RTB (Real-Time Bidding): 实时竞价。一种程序化广告交易方式,对每一次广告展示都进行实时拍卖。
  • DSP (Demand-Side Platform): 需求方平台。服务于广告主,用于自动化采买广告库存的软件平台。
  • SSP (Supply-Side Platform): 供应方平台。服务于媒体,用于自动化售卖广告库存的软件平台。
  • AdX (Ad Exchange): 广告交易平台。连接DSP和SSP,提供广告库存实时交易的市场。
  • CPM (Cost Per Mille): 每千次展示成本。一种计费模式,按广告展示1000次计费。
  • CPC (Cost Per Click): 每次点击成本。一种计费模式,按广告被点击的次数计费。
  • CPA (Cost Per Acquisition/Action): 每次转化/行动成本。一种计费模式,按用户完成特定行为(如购买、注册)的次数计费。
  • eCPM (Effective Cost Per Mille): 有效千次展示成本。用于将不同计费模式(如CPC, CPA)的收入或成本统一换算成等价的千次展示成本,以便比较和优化。
  • CTR (Click-Through Rate): 点击率。广告被点击的次数占其总展示次数的百分比。
  • CVR (Conversion Rate): 转化率。完成转化的用户数占点击广告用户数的百分比。
  • oCPC (Optimized Cost Per Click): 优化点击成本。一种以最大化点击量为目标,同时控制平均点击成本的智能出价策略。
  • OCPM (Optimized Cost Per Mille): 优化千次展示成本。一种以最大化转化量为目标的智能出价策略,尽管计费基础仍是展示。
  • OpenRTB: 一种由IAB Tech Lab制定的、用于规范RTB生态中各平台间通信(如竞价请求和响应)的开放协议标准。

A.2. 关键竞价请求/响应字段参考

下表列出了基于OpenRTB 2.5协议的一些核心字段,为技术人员提供快速参考。
对象与字段
类型
描述
示例
BidRequest
id
string
竞价请求的唯一ID。
"80ce30c53c16e6ede735f123ef6e3236"
imp
array
一个或多个Imp对象,描述广告展示机会。
[{...}]
site
object
描述网站媒体信息的Site对象。
{"id": "13451351", "domain": "example.com"}
app
object
描述移动应用媒体信息的App对象。
{"id": "agltb3B1Yi1pbmNyDAsSA0FwcBisIMP-Aw", "bundle": "com.foo.mygame"}
device
object
描述用户设备信息的Device对象。
{"ip": "64.233.160.0", "ua": "..."}
user
object
描述用户信息的User对象。
{"id": "4567898765467898765"}
tmax
integer
DSP必须在此时间内响应(单位:毫秒)。
120
Imp Object
id
string
imp对象在请求内的唯一ID。
"1"
banner
object
描述横幅广告位信息的Banner对象。
{"w": 300, "h": 250}
video
object
描述视频广告位信息的Video对象。
{"mimes": ["video/mp4"], "w": 640, "h": 480}
bidfloor
float
媒体设置的最低竞价(底价),单位CPM。
0.5
BidResponse
id
string
对应竞价请求的ID。
"80ce30c53c16e6ede735f123ef6e3236"
seatbid
array
一个或多个SeatBid对象,代表DSP的出价。
[{...}]
SeatBid Object
bid
array
一个或多个Bid对象,包含具体出价信息。
[{...}]
Bid Object
id
string
DSP生成的竞价唯一ID。
"123456789"
impid
string
对应imp对象的ID。
"1"
price
float
出价金额,单位CPM。
1.23
adm
string
广告素材标记(HTML, VAST XML等)。
"<a href=...><img src=...></a>"
crid
string
广告素材的唯一ID。
"creative-123"
burl
string
竞价成功且广告展示后被调用的计费URL。
"http://dsp.com/win?price=${AUCTION_PRICE}"
广告投放引擎算法流程解析Higress浅剖析
Loading...