Este documento se ha actualizado.
La traducción en Español (España) no está disponible todavía.
Actualización del documento en inglés: 1 jul.
Actualización del documento en Español (España): 5 abr. 2021

Actualmente, las pujas en apps para celulares solo están disponibles para algunos editores.

Pujas de servidor a servidor

La mediación interna no está disponible al público

Por el momento, la puja interna con Audience Network se encuentra una versión en beta cerrada y no está disponible al público. Brindaremos actualizaciones si se produce algún cambio.

De manera alternativa, puedes acceder a las pujas en Audience Network a través de alguna de las plataformas de mediación con las que estamos asociados.

En esta página:

Facebook Audience Network admite las pujas en apps y sitios web para celulares. Las integraciones de pujas en apps para celulares pueden originarse desde el cliente de telefonía celular hacia nuestro servidor o desde tu servidor hacia el nuestro. Esta información general abarca los conceptos básicos de las pujas en apps.

Introducción

¿Qué son las pujas en la app?

Las pujas en la app permiten que los editores establezcan una subasta imparcial y abierta sobre su inventario de anuncios ofreciendo cada oportunidad de anuncio a varias fuentes de anuncios en tiempo real. Cada origen de demanda puede competir y ganar cada impresión, cuando el valor es el más alto.

¿Por qué usar las pujas en la app?

  • Una subasta en tiempo real es una oportunidad para optimizar cada solicitud de anuncio.
  • Aporta visibilidad del valor verdadero del inventario de anuncios.
  • Es fácil de mantener y requiere menos recursos de operaciones con los anuncios.

Arquitecturas de integración

Las pujas en apps se ofrecen mediante un punto de conexión que implementa el protocolo de pujas en tiempo real (ORTB) a fin de proporcionar pujas en oportunidades de impresión individuales. El SDK de Audience Network es obligatorio en las pujas en la app para realizar las siguientes acciones:

  • Obtener buyeruid (se llama bidderToken en el SDK de Audience Network). Este token es un campo obligatorio en la solicitud de puja y, a su vez, es único para el usuario y para la app. El token no sirve para otro usuario ni otra app.
  • Cargar la respuesta de puja y mostrar un anuncio en caso de ganar una subasta.
  • Registrar las impresiones y los clics.

Pasos clave en el flujo de puja

  1. Obtén el token de la puja. Audience Network requiere esta cadena opaca para responder una solicitud de puja.
  2. Envía la solicitud y obtén la respuesta de la puja. Esta representa la interacción principal con el punto de conexión de puja. En este paso, envías una solicitud de una puja en tiempo real y luego recibes una respuesta de la puja o un error.
  3. Efectúa la subasta. Efectúa la subasta y selecciona un ganador entre las respuestas de la puja. La mayoría de las subastas comparan las pujas en tiempo real con los CPM estimados de otros orígenes de demanda (por ejemplo, los CPM promedio históricos). Esto sucede porque algunos orígenes de demanda no son compatibles con las pujas en tiempo real. Las subastas podrán ser efectuadas por alguno de los siguientes:
    • Un servidor interno que administra nuestra propia lógica de la subasta
    • Un servidor de subasta de terceros
    • El cliente en el dispositivo del usuario
  4. Recupera el anuncio con la respuesta de la puja. Si Audience Network gana la subasta, carga el anuncio pasando el campo adm desde la respuesta de la puja al SDK de Audience Network del dispositivo del usuario. Ten en cuenta que el campo adm no contiene el anuncio en cuestión; solo incluye información que permite al SDK recuperar el anuncio del servidor de Audience Network.

Tipos de integración

Cuando se lleva a cabo la subasta (el tercer paso del flujo de puja descrito arriba), es posible alojarla en el cliente o en el servidor. A continuación se muestran tres tipos de integración diferentes:

Arquitectura de integración de servidor a servidor

En una integración de servidor a servidor, un servidor de subastas llama a un extremo de pujas de Facebook Audience Network y al resto de orígenes de pedido para obtener respuestas a la puja. A continuación, el servidor de subastas realiza la subasta y elige la puja ganadora. Este servidor de subastas puede ser un servidor interno que ejecute la lógica de la subasta que creaste o un servidor de terceros integrado con las pujas de la aplicación de Audience Network. Esto te permite utilizar los recursos del servidor y la red disponible para llamar a los extremos de pujas de los orígenes de pedido. También te permite hacer cambios en estas integraciones de extremo sin necesidad de solicitar actualizaciones de cliente.


Integración de servidor de anuncios externo

La integración del servidor de anuncios externo permite crear un puente entre el mundo actual de mediación en cascada y las pujas de aplicación. Esto funciona mediante la integración de servidor a servidor con los orígenes de pedido compatibles con las pujas de aplicación. A continuación, se pasa el ganador de la subasta a la plataforma de mediación en cascada, que ejecuta la cascada y elige el origen de pedido ganador general. Esta integración constituye un puente intermedio entre los mundos de mediación en cascada y las pujas de aplicación. Con este tipo de integración, no es necesario que escribas tu propia lógica de subasta.

Solicitud/respuesta de puja abierta en tiempo real (ORTB) y formatos de anuncios admitidos

Solicitud de ORTB

Nuestros puntos de conexión de pujas admiten un subconjunto del protocolo OpenRTB versión 2.5.

Nota: Puedes ver un ejemplo de solicitud completa en la Guía de configuración del servidor de subasta.

'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

Formatos de anuncio compatibles

Actualmente, se admiten cuatro tipos de anuncios que se pueden solicitar mediante OpenRTB: banner, nativo (anuncio nativo o banner nativo), vídeo (con premio o in-stream) e intersticial. Nota: Los objetos de banner, nativo y vídeo se excluyen mutuamente, pero se requiere uno de ellos.

A continuación, encontrarás una lista de los formatos de anuncio compatibles con las solicitudes de puja:

Formato del anuncio Parámetros de la solicitud de puja

Nativo

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

Banner nativo

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

Intersticial

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

Vídeo con premio

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

Intersticial con premio

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

Alto del banner: 50

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

Alto del banner: 250*

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

* Puedes crear una ubicación de banner o rectángulo mediano en el Administrador de monetización para este formato de anuncio.

Respuesta de ORTB

Una respuesta de puja es válida por 30 minutos. Puedes solicitar el anuncio en cualquier momento dentro de los 30 minutos posteriores a recibir la respuesta de puja. Las impresiones basadas en una puja ocurrida hace más de 30 minutos no se pagarán.

Nota: Una vez que solicitas un anuncio con una respuesta de puja, el anuncio puede almacenarse en caché en el cliente, pero debe mostrarse en un lapso de 60 minutos desde su carga. Las impresiones basadas en un anuncio que se almacena en caché por más de 60 minutos no se pagarán.

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

Notificaciones de capacidad de facturación/ganador/pérdida/tiempo agotado

We require win, loss, timeout and display notifications with the appropriate loss codes as defined in ORTB. ORTB nurl and lurl are provided in the bid response. Please check previous section for bid response example. In case of bid timeout, we provide you with an alternative reporting route.

Win Notification

The win nurl will be provided in the bid response. You need populate Clearing Price in 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}&phase=${PHASE}"
  • ${AUCTION_PRICE}: This should be replaced with the Clearing Price for the auction in the same unit as our bid (i.e. USD on CPM basis).
  • ${PHASE}: This should be replaced with 'auction' for win notification at auction time. For notifications at display time, please see Display Notification section below

Loss Notification

Our loss lurl contains 3 flags you need populate:

"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}&phase=${PHASE}"
  • ${AUCTION_LOSS}: This should be replaced with ORTB Loss Code.
  • ${AUCTION_PRICE}: This should be replaced with the Clearing Price for the auction in the same unit as our bid (i.e. USD on CPM basis). For loss code 100 case, this could be auction floor price.
  • ${PHASE}: This should be replaced with 'auction' for loss notification at auction time. For notifications at display time, please see Display Notification section below

Below is a list of different Loss Codes and corresponding Loss Reasons.

Loss ReasonDescriptionORTB v2.5 Loss Code

Internal error

Internal error (e.g. when we won the auction, but our ad failed to load)

1

Invalid bid response

Bid is invalid (but on-time, not a no-bid, and valid enough that you can extract the nurl)

3

Bid timeout *

Bid response received, but too late for auction cutoff

2

No bid *

No-bids are indicated as HTTP 204 (i.e. no nurl to call), but you may interpret our response as a no-bid (likely an integration issue). You may also request bids for several impressions, and we bid on some but not all. No need to send loss notification for this reason. No bid should be used as loss reason with timeout construction of lurl in cases where lurl is not available or unusable.

9

Bid was Below Auction Floor

Bidding price was below current auction floor. ${AUCTION_PRICE} will be auction floor price or clearing price.

100

Not highest RTB bidder

Another bidder beat us, including synthetic bids (e.g. non-RTB exchanges), if they are entered into the same auction.

102

Lost to a Bid for a PMP Deal

A PMP (tag or traditional waterfall) deal was picked over the bidders in the auction.

103

Inventory didn't materialise

Our bid won the auction, but the impression didn't materialize (e.g. page wasn't long enough to include this slot, or the user exited the app before the cached ad was used.) Not all partners can provide this (it's a non-event), so we will infer it if not provided.

4902

Sent to ad server

Send this if the last touchpoint you have with the decision process is sending our high bid to the ad server. The impression may still be lost through missing line items, the ad server overruling the auction, or the inventory not materializing.

4900

RTB winner not picked by ad server

We won the RTB auction, but the ad server overruled the auction (e.g. direct).

4903

Win

We won the full decision tree, and tag was placed on page (web) or ad object was cached (app). Viewable impression may still not result.

0

Timeout Notification

For the case of bid timeout or no bid due to unusable bid response (missing/unusable lurl), we provide you with an alternative reporting route. It is the generic nurl which might be called upon without the need to wait for the bid to arrive. The format is as follows:

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

Note: ${PARTNER_FBID}, ${APP_FBID} and ${AUCTION_ID} should be populated with appropriate values. The table below provides explanation about those values.

ParamTypeDescription

PARTNER_FBID

Int

Ad auction server id issued by Facebook. Use your app id here if you don't have a dedicated ad auction partner.

APP_FBID

Int

Facebook-issued Id of the application/business which initiated an auction.

AUCTION_ID

String

Client-generated id of the auction you used for issuing a bid request.

Display Notification

We encourage publishers to send display notifications to Facebook bidder when they're about to show the ad. If the bid from Facebook bidder won the auction, use the nurl to send display notifications

"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}&phase=${PHASE}"
  • ${AUCTION_PRICE}: Similar to win notification at auction time, this should be replaced with the Clearing Price for the auction in the same unit as our bid (i.e. USD on CPM basis).
  • ${PHASE}: This should be replaced with 'display' for win notifications at display time.

If the bid from Facebook bidding didn't won the auction, use the lurl to send display notifications

"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}&phase=${PHASE}"
  • ${AUCTION_LOSS}: Similar to loss notification at auction time, this should be replaced with ORTB Loss Code.
  • ${AUCTION_PRICE}: Similar to loss notification at auction time, this should be replaced with the Clearing Price for the auction in the same unit as our bid (i.e. USD on CPM basis). For loss code 100 case, this could be auction floor price.
  • ${PHASE}: This should be replaced with 'display' for loss notifications at display time.

Pagos, subastas, visibilidad y latencia

Precios y pagos

Los precios se cotizan en USD según un CPM (p. ej., "4.25" significa que pagaremos 4,25 USD/1.000 impresiones, si ganamos). La misma unidad debe usarse para el precio de adjudicación en nurl y lurl. Los pagos se realizan directamente al editor.

Mecánica de la subasta

Siempre pujamos en función del primer precio. Esto quiere decir que pagamos el monto por el que pujamos y pujamos suponiendo que pagaremos el monto completo. Esto implica estar en desventaja en una subasta de segundo precio, donde otros pujadores pueden pujar asumiendo que pagarán menos que el monto de la puja.

Visualización

En el caso de impresiones para una app, solo pagamos si la impresión fue vista, independientemente de que hayamos sido la puja más alta.

Latencia

  • En el caso de mínima latencia, solicita una única puja por llamada a la API (es decir, si estás subastando cinco posiciones, llama a la API cinco veces: una por puja).
  • No proporcionamos puntos de conexión específicos por región. La infraestructura de Facebook dirigirá la solicitud de puja al centro de datos más cercano.
  • Usa conexiones persistentes HTTP/2.
  • Completa el campo tmax de ORTB en la solicitud de puja con el tiempo de espera de la subasta; elegiremos una estrategia de puja que equilibre la latencia y el rendimiento. (Consulta el ejemplo de solicitud de puja anterior para obtener más información sobre el campo tmax).
  • Para cumplir con los objetivos de latencia, es posible que aplacemos parte del procesamiento hasta el momento de la representación (es decir, una puja más rápida puede significar una representación más lenta del anuncio; y una puja más lenta se traduce en un anuncio que se representa con mayor rapidez).
  • Estamos trabajando activamente para mejorar la latencia. Por el momento, recomendamos un tiempo de espera de 800 ms para las pujas de servidor a servidor.