Respuesta de puja de Open RTB 2.4

La respuesta para una solicitud de puja tendrá la siguiente estructura:

Objeto de respuesta de puja

Atributo	Descripción
id	ID de la solicitud de puja (string)
seatbid	Colección de pujas realizadas por el pujador en nombre de un asiento específico.

seatbid

Atributo	Descripción
puja	ID del objeto de impresión al que se aplica esta puja (string)

seatbid.puja

Atributo	Descripción
id	ID del objeto de puja elegido por el pujador (string)
impid	ID del objeto de impresión al que se aplica esta puja (string)
precio	Precio de la puja en CPM o CPC (float)
adm	Marcado de anuncio XML/JSON de ExoClick (string)
nurl	URL de notificación de victoria
cid	ID de campaña para ayudar con la verificación de calidad del anuncio (string)
crid	ID creativo para ayudar con la verificación de calidad del anuncio (string)
iurl	URL del creativo
ext	Extensión específica de ExoClick (objeto)

Se debe notificar la nURL para garantizar la limitación de campaña y evitar obtener la misma respuesta cada vez.

seatbid.puja.ext

Atributo	Descripción
btype	Modelo de precios. Valores: 1 = CPM, 2 = CPC*. Valor predeterminado = 1 (int). Nota: Cuando la respuesta sea para una solicitud de zona de Email Clicks, 1 = Smart CPC.
	Nota: Solo Push Notification, anuncios nativos, Direct Link y Email Clicks pueden pujar con el modelo de precios CPC.

Respuesta sin puja

Para responder a una solicitud de puja sin realizar una puja real, se enviará un código de respuesta HTTP 204 "No Content".

Notificación de victoria

Cuando el parámetro Objeto de respuesta de puja > Objeto de puja de asiento > Objeto de puja > nurl está en la respuesta de puja, se debe realizar una solicitud GET a esa URL.

Notificación de facturación

Cuando el parámetro Objeto de respuesta de puja > Objeto de puja de asiento > Objeto de puja > burl está en la respuesta de puja, se realiza una solicitud GET a esa URL cuando la impresión o el clic se vuelve facturable (CPM o CPC, según el btype campo). Esto permite contar la impresión o el clic a partir del evento facturable en lugar de hacerlo desde el seguimiento del lado del cliente, y proporciona métricas paralelas "Served" en las Estadísticas de RTB. que muestran la diferencia entre lo que se renderizó y lo que se facturó.

Si nurl y burl están presentes, ambos deben llamarse.

Lógica de conteo

• Cuando BURL está deshabilitado — La impresión o el clic dependen totalmente del rastreador del lado del cliente activado por el anuncio renderizado. El valor predeterminado actual para contar impresiones y clics.
• Cuando BURL está habilitado — La impresión o el clic se cuentan desde la llamada burl en lugar del seguimiento del lado del cliente.
• Cuando BURL está habilitado pero el socio no logra activarlo — El conteo de impresiones o clics cae a cero con fines de facturación, mientras que las impresiones servidas (lo que registró el navegador) permanecen. Esta discrepancia señala un problema de integración técnica.

Lo que permanece en el seguimiento del lado del cliente

• Limitación de frecuencia. FC sigue dependiendo de los eventos de impresión independientemente del ajuste de BURL.
• Todas las métricas de "Served", por definición.
• Zonas directas (no RTB), que no tienen concepto de BURL.

Ejemplos

Puedes encontrar ejemplos detallados de las respuestas que puedes recibir en la página de ejemplo.