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 subasta llama al extremo de puja de Facebook Audience Network y a todos los demás orígenes de demanda para obtener respuestas de puja. A continuación, el servidor de subasta ejecuta la subasta y elige la puja ganadora. Este servidor de subasta puede ser un servidor interno que ejecuta la lógica de la subasta que desarrollaste, o bien puede ser un servidor de un tercero, que está integrado en las pujas de la aplicación de Audience Network. De este modo, puedes utilizar los recursos del servidor y la red disponible para llamar a los extremos de pujas de los orígenes de demanda. También te permite hacer cambios en estas integraciones de extremos sin que se requieran actualizaciones del cliente.


Integración de servidor de anuncios externo

La integración del servidor de anuncios externo permite establecer una conexión entre el mundo actual de la mediación de cascada y las pujas en la aplicación. Se realiza una integración de servidor a servidor con los orígenes de demanda que admiten pujas en la aplicación y, a continuación, se pasa el ganador de la subasta a la plataforma de mediación de cascada que ejecuta la cascada y elige el origen de demanda que ganó. Esta integración es una suerte de conexión provisional entre los mundos de la mediación de cascada y las pujas en la 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 anuncios admitidos

Por el momento, admitimos cuatro tipos de anuncios que se pueden solicitar a través de OpenRTB: banner, nativo (nativo o banner nativo), video (video con premio o instream) e intersticial. Nota: Los objetos banner, nativo y video son mutuamente exclusivos, pero es obligatorio usar uno de ellos.

Esta es una lista de los formatos de anuncios admitidos en la solicitud de puja:

Formato de anuncio Parámetros en 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}

Video 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}}

Banner - Altura: 50

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

Banner - Altura: 250*

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

* Puedes crear una ubicación de un banner o medio rectángulo 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

Requerimos notificaciones de éxito, pérdida, capacidad de facturación y tiempo agotado con los códigos de pérdida correspondientes, según se define en ORTB. ORTB nurl, lurl y burl se proporcionan en la respuesta de puja. Consulte la sección anterior para ver ejemplos de respuestas de puja. En caso de una puja con tiempo agotado, proporcionamos una ruta de informe alternativa.

Notificación de éxito

La nurl de éxito se incluye en la respuesta de puja. Debes completar el precio de adjudicación en la 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}: debe reemplazarse con el precio de adjudicación para la subasta, en la misma unidad que la puja (p. ej., USD o CPM).

Notificación de pérdida

La lurl de pérdida contiene dos marcas que debes completar:

"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}: debe reemplazarse con el código de pérdida de ORTB.
  • ${AUCTION_PRICE}: debe reemplazarse con el precio de adjudicación para la subasta, en la misma unidad que la puja (p. ej., USD o CPM).

A continuación, se incluye una lista con diferentes códigos de pérdida y sus correspondientes motivos de pérdida.

Motivo de pérdidaDescripciónCódigo de pérdida de ORTB v2.5

Respuesta de puja no válida

Puja no válida (pero a tiempo; no es sin puja y es lo suficientemente válida para extraer la nurl)

3

Tiempo agotado de la puja *

Respuesta de la puja recibida, pero demasiado tarde para el corte de la subasta

2

Sin puja

Los casos sin puja se indican como HTTP 204 (p. ej., sin una nurl para llamar), pero puede interpretarse la respuesta como sin puja (posible problema de integración). También puedes solicitar pujas para varias impresiones; pujaremos por algunas, pero no todas.

9

No es el pujador RTB más alto

Otro pujador nos ganó, incluso en pujas sintéticas (p. ej., intercambios que no son RTB) si se incluyen en la misma subasta.

102

El inventario no se materializó

Nuestra puja ganó la subasta, pero la impresión no se materializó (la página no era lo suficientemente larga para incluir esta posición o el usuario salió de la aplicación antes de que se utilizara el anuncio almacenado en caché). No todos los socios pueden ofrecer esto (es un no evento), por lo que inferimos que no se proporcionó.

4902

Envío a un servidor de anuncios

Envía esto si el último punto de contacto en el proceso de decisión envía nuestra puja alta al servidor de anuncios. Es posible que la impresión se pierda de todos modos entre los elementos de la línea faltante, que el servidor de anuncios anule la subasta o que el inventario no se materialice.

4900

Ganador de RTB no elegido por el servidor de anuncios

Ganamos la subasta de RTB, pero el servidor de anuncios anuló la subasta (de forma directa).

4903

Ganador

Ganamos el árbol de decisiones completo, y se colocó una etiqueta en la página (web) o se almacenó en caché el objeto de anuncio (aplicación). Es posible que la impresión visualizable no se materialice de todos modos.

0

Notificación de capacidad de facturación

Requerimos una notificación de capacidad de facturación en caso de que se active una devolución de llamada a la impresión en el SDK de Audience Network. Debes completar el precio de adjudicación en la 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}: debe reemplazarse con el precio de adjudicación para la subasta, en la misma unidad que la puja (p. ej., USD o CPM).

Notificación de tiempo agotado

En caso de una puja con tiempo agotado, proporcionamos una ruta de informe alternativa. Es la nurl genérica a la que puede llamarse sin necesidad de esperar que llegue la puja. El formato es el siguiente:

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

Nota:${PARTNER_FBID}, ${APP_FBID} y ${AUCTION_ID} deben completarse con los valores correspondientes. Estos valores se explican en la tabla a continuación.

ParámetroTipoDescripción

PARTNER_FBID

int

Identificador del servidor de subasta de anuncios emitido por Facebook. Utiliza el identificador de la aplicación aquí si no tienes un socio exclusivo para la subasta de anuncios.

APP_FBID

int

Identificador que Facebook emite para la aplicación/la empresa que inició una subasta.

AUCTION_ID

cadena

Identificador de la subasta, generado por el cliente, que se utiliza para emitir una solicitud de puja.

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, podemos asignar parte del tiempo de procesamiento a la representación (es decir, una puja más rápida puede significar un anuncio de representación más lenta; 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.