¿Qué campos son obligatorios en una respuesta de puja OpenRTB?

La respuesta necesita un id que devuelva el de la petición. Cada puja necesita id, un impid que corresponda a una impresión, un precio y el creativo como adm o nurl. Lo demás es opcional en la especificación, aunque no en la práctica.

¿Qué significa el campo nbr?

Motivo de no puja. Es un código entero que explica por qué no se devolvió puja —2 para petición inválida, 8 para usuario no reconocido— y permite al exchange informar de por qué un bidder pasa.

¿Por qué nurl necesita la macro AUCTION_PRICE?

Porque el exchange sustituye en ella el precio de cierre cuando la puja gana. Sin la macro, el aviso de victoria se dispara sin precio y tus registros anotan la puja en lugar de lo que has pagado.

¿Qué diferencia hay entre adm y nurl?

adm lleva el creativo en línea dentro de la respuesta; nurl es una URL que el exchange llama para obtenerlo al ganar. Hoy predomina el creativo en línea porque elimina un viaje de ida y vuelta.

¿mtype sustituye a algo de la 2.5?

Hace explícito lo que antes se deducía. En 2.5 el tipo de medio venía del objeto que llevaba la impresión, lo que se rompía con impresiones multiformato; en 2.6 la puja lo declara sin ambigüedad.

Validador de respuesta de puja OpenRTB

Comprueba una respuesta de puja en busca de campos ausentes, precios mal tipados y macros olvidadas.

El Validador de respuesta de puja OpenRTB funciona por completo en tu navegador, así que las respuestas con identificadores de acuerdo y precios reales se comprueban en tu dispositivo.

Validar una petición de puja

Acerca de Validador de respuesta de puja OpenRTB

La respuesta de puja es la mitad corta de la conversación OpenRTB, y casi todo lo que falla en ella es estructural y no ingenioso: una puja sin impid que la ate a una impresión, un precio enviado como cadena, un creativo que nunca declara su dominio de anunciante, o un aviso de victoria que olvida la macro del precio de subasta y por tanto informa de un precio de cierre equivocado. Este validador recorre la respuesta como haría un exchange, separando los campos que exige la especificación de aquellos que rechazan compradores y editores en la práctica. Cada hallazgo lleva una ruta JSON y señala la puja concreta.

Características

Comprueba los campos obligatorios en respuesta, seatbid y puja
Errores, avisos y notas separados, cada uno con su ruta JSON
Comprobación de tipos en precio, dimensiones, adomain y campos de identificador
Tratamiento consciente de la versión para mtype, que llegó en OpenRTB 2.6
Señala avisos de victoria sin macro de precio y URL de notificación inseguras
Valida respuestas sin puja y sus códigos nbr
Detecta identificadores de puja duplicados y varias pujas a la misma impresión
Tablas de referencia de motivos de no puja y tipos de medio

Cómo usar Validador de respuesta de puja OpenRTB

Pega el JSON que ha devuelto tu bidder
Elige la versión del protocolo que usa el exchange
Resuelve primero los errores y luego los avisos
Usa la ruta JSON de cada hallazgo para localizar la puja afectada

Ejemplo

Entrada

{ "id": "1", "seatbid": [{ "bid": [{ "id": "b1", "impid": "1", "price": "2.15" }] }] }

Salida

error seatbid[0].bid[0].price — price has to be a number, not a string

Un precio entrecomillado es el motivo más habitual de que una puja se descarte en silencio.

Errores comunes y solución de problemas

La puja es válida aquí pero el exchange la descarta igual. — Los exchanges añaden sus propios requisitos: un identificador de seat que reconozcan, categorías de una taxonomía concreta o un creativo ya aprobado. Consulta su guía de integración junto a esto.
Un aviso sobre adomain en un anuncio propio. — Rellénalo igualmente. Los editores bloquean por dominio de anunciante, y una puja sin él se descarta a menudo antes de considerar nada más.
Se señala mtype en una integración 2.5. — Llegó en OpenRTB 2.6 y un exchange 2.5 lo ignora. Cambia el selector de versión al protocolo que use realmente el exchange; enviarlo no hace daño.
Un array seatbid vacío solo genera un aviso. — Porque es legal aunque poco útil. La forma limpia de declinar es un HTTP 204, o una respuesta con un código nbr para que el exchange registre por qué has pasado.

Preguntas frecuentes

¿Qué campos son obligatorios en una respuesta de puja OpenRTB?: La respuesta necesita un id que devuelva el de la petición. Cada puja necesita id, un impid que corresponda a una impresión, un precio y el creativo como adm o nurl. Lo demás es opcional en la especificación, aunque no en la práctica.
¿Qué significa el campo nbr?: Motivo de no puja. Es un código entero que explica por qué no se devolvió puja —2 para petición inválida, 8 para usuario no reconocido— y permite al exchange informar de por qué un bidder pasa.
¿Por qué nurl necesita la macro AUCTION_PRICE?: Porque el exchange sustituye en ella el precio de cierre cuando la puja gana. Sin la macro, el aviso de victoria se dispara sin precio y tus registros anotan la puja en lugar de lo que has pagado.
¿Qué diferencia hay entre adm y nurl?: adm lleva el creativo en línea dentro de la respuesta; nurl es una URL que el exchange llama para obtenerlo al ganar. Hoy predomina el creativo en línea porque elimina un viaje de ida y vuelta.
¿mtype sustituye a algo de la 2.5?: Hace explícito lo que antes se deducía. En 2.5 el tipo de medio venía del objeto que llevaba la impresión, lo que se rompía con impresiones multiformato; en 2.6 la puja lo declara sin ambigüedad.

Herramientas relacionadas

Validador de bid request OpenRTB — Valida bid requests OpenRTB 2.5 y 2.6 contra las reglas del IAB.
Generador de bid request OpenRTB — Construye bid requests OpenRTB 2.5 y 2.6 desde un formulario.
Referencia de enums OpenRTB — Consulta cada lista enumerada de OpenRTB 2.x con su significado.
Validador de VAST — Comprueba tu XML VAST contra las reglas del IAB en el navegador.
Generador de ad units de Prebid — Construye una configuración de ad unit de Prebid.js y su snippet pbjs.
Constructor de schain — Construye y valida el objeto SupplyChain (schain) de OpenRTB.