移动应用竞价目前仅对特定发行商开放。

服务器到服务器竞价

内部中介不公开提供

内部 Audience Network 竞价现在处于封测阶段,不公开提供。如有变化,我们将提供最新信息。

作为替代方案,您可以通过与我们合作的中介平台访问 Audience Network 竞价。

在本页面:

Facebook Audience Network 支持移动应用和移动网站中的竞价。移动应用竞价集成可以是从手机客户端到我们的服务器,也可以是从您的服务器到我们的服务器。本概览会介绍应用竞价的一般概念。

简介

什么是应用竞价

应用竞价是供发行商针对其广告库存开展公平开放式竞拍的方法,具体做法是把每一个广告投放机会实时提供给多个需求来源。每个需求来源都有机会参与竞价,并在出价最高时赢得每次展示。

为什么要开展应用竞价

  • 实时竞拍让您有机会针对每个广告请求作出优化。
  • 让您了解广告库存的真正价值。
  • 易于维护,而且需要的广告运作资源较少。

集成架构

应用竞价是通过实施开放实时竞价 (ORTB) 协议的端点提供,用以提供单个展示机会的竞价。您需要在应用竞价中使用 Audience Network SDK 来执行以下操作:

  • 获取 buyeruid(在 Audience Network SDK 中的名称为 bidderToken)。该口令是竞价请求中的必要字段,对于每位用户和每个应用具有唯一性。该口令对其他用户或应用无效。
  • 加载竞价响应,并在竞价者赢得竞拍时展示广告。
  • 记录展示次数和点击量。

竞价流程的关键步骤

  1. 获取竞价者口令。Audience Network 需要通过此非明文字符串来响应竞价请求。
  2. 发送竞价请求并获得竞价响应。这是您与竞价端点之间的主要互动。在此步骤中,您先发送 ORTB 竞价请求,然后会收到有效的竞价响应或错误。
  3. 执行竞拍。执行竞拍并在竞价响应中选择得标者。部分需求来源不支持实时竞价,因此大多数竞拍会将实时竞价和来自其他需求来源的预估千次展示费用(如历史平均千次展示费用)进行比较。您可通过以下途径执行竞拍:
    • 执行您自定义竞拍逻辑的内部服务器
    • 第三方竞拍服务器
    • 用户设备上的客户端
  4. 通过竞价响应检索广告。若 Audience Network 赢得竞拍,则可在用户设备上通过将 adm 字段从竞价响应传递至 Audience Network SDK 来加载广告。请注意,adm 字段并不包含实际广告,而仅包含使 SDK 能够从 Audience Network 服务器检索广告的信息。

集成类型

在执行竞拍时(上述竞价流程第 3 步),可将集成托管在客户端服务器端。下方列出了 3 种不同的集成类型:

服务器到服务器集成架构

在服务器到服务器集成中,竞拍服务器会调用 Facebook Audience Network 竞价端点和其他所有需求来源来获取竞价响应。然后,竞拍服务器便会执行竞拍,并选择中标竞价。此竞拍服务器可以是运行您所构建拍卖逻辑的内部服务器,也可以是与 Audience Network 的应用竞价集成的第三方服务器。这样,您可以利用服务器资源和可用网络来调用广告网络的竞价端点。此外,您还可以更改这些端点集成,而无需更新客户端。


外部广告服务器集成

借助外部广告服务器集成,您可以在当今的瀑布策略中介与应用竞价之间建立联系。为达到此目的,我们要实现与支持应用竞价的需求来源的服务器到服务器集成,然后将竞拍得标者传递至运行瀑布策略并选择整体得标需求来源的瀑布策略中介平台。此集成作为瀑布策略中介和应用竞价之间的临时桥梁。借助此集成类型,您无需编写自己的竞拍逻辑。

ORTB 请求/响应和支持的广告格式

ORTB 请求

我们的竞价端点支持 OpenRTB 协议 v2.5 的子集。

注意:如需查看完整的请求示例,请参阅竞拍服务器设置指南

'id' => string, // platform's auction identifier,
'imp' => vec< // slots to bid on
shape(
'id' => string, // platform's identifier for this slot auction
// only for banner impression opportunities
'banner' => shape(
'w' => int, // width
'h' => int, // height
),
// only for native impression opportunities
'native' => shape(
'w' => int, // width 
'h' => int, // height 
),
// only for video impression opportunities
'video' => shape(
'w' => int, // width
'h' => int, // height
'linearity' => int, // 1 = instream, optional
'ext' => shape(
'videotype' => string, // 'rewarded' for Rewarded Video impression opportunities, optional
),
),
'tagid' => string, // Placement ID
'instl' => int, // interstitial flag, 1 = On, 0 = Off, optional
)
>,
// app details (in-app bidding only)
'app' => shape( 
'publisher' => shape(
'id' => string, // publisher app ID
),
),
'device' => shape(
'ua' => string, // device user-agent
'ifa' => string, // ID sanctioned for advertiser use
// Do not send ip or ipv6 if you are requesting bids from the client device.
// For server-side bid requests set ip or ipv6.
'ip' => string, // device IPv4
'ipv6' => string, // device IPv6
'dnt' => int, // "do not track", 1 = On, 0 = Off, optional
'lmt' => int, // "limit ad tracking", 1 = On, 0 = Off
),
'regs' => shape( // regulations object
'coppa' => int, // US FTC regulations for Children's Online Privacy Protection Act, 1 = On, 0 = Off, optional
),
'user' => shape(
'buyeruid' => string, // Audience Network Identity Token, mandatory
),
'ext' => shape(
'platformid' => string, // Mediation partner Platform ID or publisher FB app ID, mandatory
'authentication_id' => string // Authentication token to validate the originator of the request                     
),
'at' => int, // auction type: 1 = First Price, 2 = Second Price
'tmax' => int, // auction timeout in milliseconds
'test' => int, // 0 = normal, 1 = test-mode (we bid $99.99, but don't pay out), optional

支持的广告格式

我们目前支持通过 OpenRTB 请求以下四类广告:横幅广告、原生广告(原生广告或原生横幅广告)、视频广告(奖励式视频广告或视频插播广告)以及插屏广告。注意:横幅广告、原生广告和视频广告的对象相互排斥,但您必须选择其中一个。

下面是竞价请求中支持的广告格式清单:

广告格式 竞价请求中的参数

原生广告

{'id': ${AUCTION_ID}, 'native': { 'h': -1, 'w': -1 }, 'tagid': ${PLACEMENT_ID}}

原生横幅广告

{'id': ${AUCTION_ID}, 'native': { 'h': -1, 'w': -1 }, 'tagid': ${PLACEMENT_ID}}

插屏广告

{'id': ${AUCTION_ID}, 'banner': { 'h': 0, 'w': 0 }, 'tagid': ${PLACEMENT_ID}, 'instl': 1}

激励视频广告

{'id': ${AUCTION_ID}, 'video': { 'h': 0, 'w': 0, 'ext': { 'videotype': 'rewarded' } }, 'tagid': ${PLACEMENT_ID}}

激励插屏广告

{'id': ${AUCTION_ID}, 'video': { 'h': 0, 'w': 0, 'ext': { 'videotype': 'rewarded_interstitial' } }, 'tagid': ${PLACEMENT_ID}}

横幅广告 - 高度:50

{'id': ${AUCTION_ID}, 'banner': { 'h': 50, 'w': -1 }, 'tagid': ${PLACEMENT_ID}}

横幅广告 - 高度:250*

{'id': ${AUCTION_ID}, 'banner': { 'h': 250, 'w': -1 }, 'tagid': ${PLACEMENT_ID}}

*您可以在变现管理工具中为此广告格式创建横幅或中矩形版位

ORTB 响应

竞价响应的有效期为 30 分钟。您可以在收到竞价响应后的 30 分钟内随时请求广告。所有由 30 分钟过后的竞价产生的展示皆不会得到付款。

注意:在您根据竞价响应请求广告后,广告可以在客户端缓存,但必须在加载后 60 分钟内展示。所有由缓存时间超过 60 分钟的广告产生的展示皆不会得到付款。

1  
'id' => string // platform's request identifier
'seatbid' => vec<
    shape(
        'bid' => vec<
            shape(
                'id' => string, // Our identifier for this bid
                'impid' => string, // platform's identifier for this slot auction
                'price' => float, // Our bid price on CPM basis, in USD
                'adm' => string, // Our creative - see Rendering The Ad
                'nurl' => string, // URL to get if we win the impression
                'lurl' => string, // URL to get if we lose the impression
            )
        >,
    ),
>,
'bidid' => string, // Our identifier for this response
'cur' => string, // bid currency: USD

得标/失标/可计费/超时通知

必须使用 ORTB 中定义的相应失标代码,以发送得标失标可计费超时通知。竞价响应中已提供 ORTB nurllurlburl。请查看前述部分中提到的竞价响应示例。如果竞价超时,我们会向您提供替代报告路径。

得标通知

竞价响应会提供得标 nurl。您需要在 nurl 中填充结算价格

"https://www.facebook.com/audiencenetwork/nurl/?partner=${PARTNER_FBID}&app=${APP_FBID}&placement=${PLACEMENT_FBID}&auction=${AUCTION_ID}&impression=${IMPRESSION_ID}&request=${BID_REQUEST_ID}&bid=${BID_ID}&ortb_loss_code=0&clearing_price=${AUCTION_PRICE}"
  • ${AUCTION_PRICE}:您应将此值替换为采用我们相同竞价单位的竞拍结算价格(即基于千次展示费用的美元金额)。

失标通知

我们的失标 lurl 包含 2 个需要您填充的标记:

"https://www.facebook.com/audiencenetwork/nurl/?partner=${PARTNER_FBID}&app=${APP_FBID}&placement=${PLACEMENT_FBID}&auction=${AUCTION_ID}&impression=${IMPRESSION_ID}&request=${BID_REQUEST_ID}&bid=${BID_ID}&ortb_loss_code=${AUCTION_LOSS}&clearing_price=${AUCTION_PRICE}"
  • ${AUCTION_LOSS}:您应将此值替换为 ORTB 失标代码
  • ${AUCTION_PRICE}:您应将此值替换为采用我们相同竞价单位的竞拍结算价格(即基于千次展示费用的美元金额)。

下方展示了各种失标代码和相应失标原因的列表。

失标原因说明ORTB v2.5 失标代码

无效的竞价响应

竞价无效(但响应准时,并非无竞价,并且足以有效提取 nurl)

3

竞价超时 *

已收到竞价响应,但远远晚于竞拍截止时间

2

无竞价

无竞价表示为 HTTP 204(即不存在可调用的 nurl),但您可以将我们的响应解释为无竞价(很可能是集成问题)。您还可以请求为某些展示竞价,如此我们便会为部分展示竞价,而非全部。

9

不是出价最高的 RTB 竞价者

另一位竞价者击败我们,包括合成竞价(例如非 RTB 交易)(如果他们进入同一竞拍)。

102

库存未能实现

我们的竞价赢得竞拍,但展示却未能实现(例如页面不够长而无法包含此版位,或者用户在我们使用缓存广告之前退出了应用)。并非所有合作伙伴都会提供此代码(这是非事件),若未提供,我们会将其推断出来。

4902

发送给广告服务器

如果决策流程中最后的接触点将高竞价发送给广告服务器,则发送此信息。展示仍会由于缺失行项目、广告服务器拒绝竞拍或库存未能实现而丢失。

4900

广告服务器未选择 RTB 得标者

我们赢得了 RTB 竞拍,但广告服务器拒绝了此竞拍(例如直接)。

4903

得标

我们赢得了完整的决策树,而且标签已置于页面(网页)或广告对象已缓存(应用)。系统可能仍然不会产生可查看的展示。

0

可计费通知

如果 Audience Network SDK 触发了展示回调,则我们需要获取可计费通知。您需要在 burl 中填充结算价格

"https://www.facebook.com/audiencenetwork/burl/?partner=${PARTNER_FBID}&app=${APP_FBID}&placement=${PLACEMENT_FBID}&auction=${AUCTION_ID}&impression=${IMPRESSION_ID}&request=${BID_REQUEST_ID}&bid=${BID_ID}&ortb_loss_code=0&clearing_price=${AUCTION_PRICE}"
  • ${AUCTION_PRICE}:您应将此值替换为采用我们相同竞价单位的竞拍结算价格(即基于千次展示费用的美元金额)。

超时通知

如果竞价超时,我们会向您提供替代报告路径。此为通用的 nurl,无需等待竞价即可调用。格式如下:

"https://www.facebook.com/audiencenetwork/nurl/?partner=${PARTNER_FBID}&app=${APP_FBID}&auction=${AUCTION_ID}&ortb_loss_code=2"

请注意:您应使用适当的值填充 ${PARTNER_FBID}${APP_FBID}${AUCTION_ID}。下表提供了对这些值的说明。

参数类型说明

PARTNER_FBID

整数

由 Facebook 发出的广告竞拍服务器编号。如果没有专属的广告竞拍合作伙伴,请在此处使用您的应用编号。

APP_FBID

整数

Facebook 发出的应用程序/公司编号,用于发起竞拍。

AUCTION_ID

字符串

客户端生成的用于发出竞价请求的竞拍编号。

进账、竞拍、可见性和延迟

价格和进账

竞拍中以美元为单位按千次展示费用报价(例如,4.25 表示如果我们得标,则我们将为每 1,000 次展示支付 $4.25 美元)。nurllurl 中的结算价格必须使用相同单位。款项会直接付予发行商。

竞拍机制

我们一律按第一价格开展竞价,即我们会按出价付款,并且竞价的前提是我们会全额付款。这意味着我们在第二价格竞拍中处于劣势,因为其他竞价者参与竞价的前提是其支付金额将会低于竞价金额。

可见性

对于应用展示,无论是否为最高出价者,我们都只会在有人观看展示时付费。

延迟

  • 为了将延迟降至最低,请在每次调用 API 时只请求单一竞价(即如果您要竞拍五个版位,则需要调用五次 API,每次竞价调用一次)。
  • 我们不提供特定于地区的端点。Facebook 基础架构会将竞价请求传送到距离最近的数据中心。
  • 使用 HTTP/2 持久连接。
  • 在竞价请求中使用竞拍超时填充 ORTB tmax 字段,我们会选择能够平衡延迟和性能的竞价策略。(如需有关 tmax 的更多信息,请查看上文的竞价请求示例
  • 为达到延迟目标,我们可能会将一些处理推迟到渲染时间(即竞价较快,可能意味着广告渲染速度较慢,如果竞价较慢,则广告渲染速度会较快)。
  • 我们正在积极改善延迟。目前,我们建议将服务器到服务器的竞价超时设为 800 毫秒。