Leer en inglés

Compartir a través de


Servicio del licitador

El Servicio del Licitante conecta un postor con el bus de impresión de Xandr y permite que el postor y el bus de impresión comiencen a comunicarse. Su representante de Xandr creará el postor en el sistema y usará el Servicio del Licitador para realizar modificaciones o recuperar su id. de licitador.

Es posible que necesite su id. de postor para algunos de los Servicios. Para averiguar cuál es el identificador del pujador, ejecute el comando "Ver todos los licitadores" que se describe a continuación.

Algunas funciones del licitador solo son accesibles para determinados usuarios, ya que se basan en obligaciones contractuales:

Modificar los campos del proveedor de datos (a través PUTde ): requiere un contrato de acceso a datos con cada proveedor.

En los entornos de espacio aislado del licitador, toda la funcionalidad está disponible con fines de integración.

API de REST

Http (método) Endpoint Description
GET https://api.adnxs.com/bidder/ Vea el pujador al que el usuario tiene permisos. No mostrará los postores de otros usuarios.
GET https://api.adnxs.com/bidder/BIDDER_ID Ver un pujador determinado.
POST https://api.adnxs.com/bidder
(JSON del licitador)
Agregue un nuevo postor.
PUT https://api.adnxs.com/bidder/BIDDER_ID
(JSON del licitador)
Modificar un pujador existente.
DELETE https://api.adnxs.com/bidder/BIDDER_ID Elimine un pujador existente.

Campos JSON

Campo Obligatorio Tipo Description
id Sí, al actualizar Entero El identificador del licitador.
short_name Sí (al agregar) string Nombre corto opcional para el licitador. Aunque técnicamente no es necesario, este campo es necesario para las métricas, por lo que debe considerarse necesario.

Nota: Solo se permiten caracteres alfanuméricos (A-Z, 0-9) y caracteres de subrayado. No use espacios, caracteres especiales, puntos u otros signos de puntuación.
name Sí (al agregar) string Nombre asociado al licitador.
active No, el valor predeterminado es true Booleano Si el licitador recibirá solicitudes o no.
bid_uri Sí (al agregar) string(255) Uri de las solicitudes de puja (por ejemplo, /bid).
notify_uri no string (255) URI para las solicitudes de notificación (por ejemplo, /notify). Use null, no una cadena vacía, para establecerlo en blanco.

Nota:
notify_uri- debe ser un URI relativo. Xandr no admite actualmente la colocación de bid_uri y notify_uri en hosts independientes.
- Si es null, el licitador no recibe solicitudes de notificación.
click_uri no string(255) Uri de las solicitudes de clic (por ejemplo, /click). Use null, no una cadena vacía, para establecerlo en blanco. Consulte Solicitud de clic.
pixel_uri no string(255) URI de las solicitudes de píxeles (por ejemplo, /pixel). Use null, no una cadena vacía, para establecerlo en blanco. Consulte Solicitud de píxeles.
ready_uri Sí (al agregar) string(50) Uri de una comprobación de estado de la instancia del licitador (por ejemplo, /ready).
audit_notify_uri no string(255) Uri para pasar actualizaciones de auditoría creativa (por ejemplo https://send.mycompany.com/auditnotifyrequests, )
parent_profile_id no Entero Identificador del perfil del pujador primario. Los perfiles del licitador se pueden usar para filtrar el tráfico de solicitudes de puja que llega a un licitador. Consulte Servicio de perfil de licitador heredado y Perfil de licitador - Preguntas más frecuentes.
child_profiles no Matriz de objetos con el identificador de los perfiles del licitador. Matriz de objetos que especifican los perfiles secundarios que se van a usar. Por ejemplo: [{"id":123}, {"id":124}].
dongle no string Contraseña que protege la salida de depuración de un pujador en una impresión de depuración. Consulte debug_text en la respuesta de la oferta. Solo está disponible para usuarios de tipo "pujador".
notify_full_auction no Booleano Establecer esto en "true" significa que el bus de impresiones incluirá full_tag_info y bid_info en la solicitud de notificación. Las notificaciones posteriores a la espera (post_pending establecidas true en en la solicitud de notificación) no incluyen estas etiquetas porque aún no se ha recibido la devolución de llamada de aceptación de la oferta.
notify_lost No, el valor predeterminado es false Booleano Indica si se notifica al licitador todas las ofertas perdidas en el URI especificado en el notify_uri campo. Si no se proporciona ningún URI, no se envían notificaciones.
- Si truees , el postor recibe una notificación sobre todas las ofertas perdidas.
- Si falsees , el licitador solo recibe una notificación sobre las ofertas perdidas con identificadores de código de error de solicitud de notificación superiores a 100. No registramos errores ni enviamos notificaciones perdidas si el identificador de error es menor que 100 para los licitadores de OpenRTB.
notify_pending No, el valor predeterminado es false Booleano Indica si se notifica al licitador sobre las ofertas pendientes en el URI especificado en el notify_uri campo. Si no se proporciona ningún URI, no se envían notificaciones.
notify_no_bid No, el valor predeterminado es false Booleano Indica si se notifica al licitador cuando el licitador no tiene ninguna oferta por una solicitud. La notificación se envía al URI especificado en el notify_uri campo . Si no se proporciona ningún URI, no se envían notificaciones.
exclude_unowned no Booleano Excluir el inventario que no pertenece a un miembro asociado a este postor.
send_unaudited No, el valor predeterminado es false Booleano Esta marca determina si el licitador se enviará o no al tráfico no auditado.

Advertencia: En términos estrictos, este campo está en desuso, pero siempre debe establecerse en true. Si este campo está establecido en false, el pujador no recibirá ninguna solicitud de puja.
bid_percent no Entero Porcentaje (50 = 50 %) del tráfico total de la plataforma que desea recibir. Las solicitudes que se envían al postor se eligen aleatoriamente, aunque puede elegir que el licitador reciba siempre solicitudes para los usuarios en segmentos de miembros asociados con el postor. Si establece bid_percent en 0, el pujador solo recibirá solicitudes de usuarios en al menos uno de los segmentos de sus miembros. Este filtro se aplica al tráfico que lo hace a través del servicio de perfil del licitador heredado.
always_send_owned_segments no Booleano Determina si las impresiones de los usuarios en segmentos propiedad o compartidas con el Licitador deben omitir passthrough_percent en los perfiles del licitador.

Nota: Esto solo invalida el passthrough_percent en el perfil del licitador; todas las demás restricciones, como los filtros de país, miembro, tamaño o dominio, se seguirían teniendo en cuenta al decidir si se enviará una impresión al licitador.
object_limit_notify_email no matriz de cadenas Xandr limita el número de objetos que cada licitador puede crear y usar en la plataforma. Este límite incluye objetos inactivos y no utilizados. Este campo contiene las direcciones de correo electrónico que se notificarán cuando alcance el umbral del 85 %, 95 % y 100 % para los límites de objetos.
protocol_id no Entero Solo lectura. Esto describe el protocolo asociado a este licitador, que describe el tipo de licitador que es. Por ejemplo, un protocol_id de 6 significa que este licitador usa la especificación de OpenRTB 2.0 para su integración con Xandr. El valor de integración predeterminado para un pujador recién creado es 1, none. Este es el protocolo predeterminado definido en Solicitud de puja y Respuesta de puja. Los licitadores con un protocol_id de 6 se integran según las especificaciones de OpenRTB 2.0 (PDF).
Especificación para OpenRTB 2.4, protocol_id: 10.
Se admiten los siguientes valores (cada identificador va seguido del protocol_name asociado a ese identificador):
- 1: none
- 2: wp7
- 3: contentads
- 4: admarket
- 5: adexpert
- 6: openrtb2.0
- 10: openrtb2.4
protocol_name no string Solo lectura. Nombre del protocolo asociado a este licitador. Consulte la definición de protocol_id anterior para ver todos los valores aceptados de protocol_id y sus asignaciones a nombres.
last_activity no Timestamp Marca de tiempo de la última modificación en esta instancia del licitador.
max_seats no Entero Los licitadores que pujan con identificadores de puestos de comprador personalizados tendrán este campo con un valor mayor que 0. Este es el número máximo de puestos permitidos para ser inscritos bajo un postor.

Nota: Esta característica se encuentra actualmente en versión beta cerrada. Si está interesado en participar, póngase en contacto con su representante de Xandr.
default_member no Objeto Los licitadores que usen la oferta de id. de puesto de comprador tendrán un miembro predeterminado designado en este campo. Tenga en cuenta que el miembro predeterminado será el miembro de facturación principal del licitador y también se usará como identificador de miembro para el registro creativo.

Nota: Esta característica se encuentra actualmente en versión beta cerrada. Si está interesado en participar, póngase en contacto con su representante de Xandr.

Nota

Use el servicio de perfil del licitador para filtrar y limitar.

Para filtrar el tráfico que recibirá el licitador, use el Servicio de perfil de licitador heredado. Todavía existen algunos campos de filtrado y limitación en el Servicio del licitador, pero pronto se migrarán al Servicio de perfil de licitador. Los filtros de clase están disponibles en ambos; se recomienda usar el servicio de perfil del licitador para estos.

Campos en desuso

Campo Obligatorio Tipo Description
send_class_2 No, el valor predeterminado es true Booleano Esta marca determina si el licitador recibirá o no tráfico de clase 2. Tenga en cuenta que la limitación por clase de inventario también es posible a través del servicio de perfil del licitador heredado.
send_class_3 No, el valor predeterminado es true Booleano Esta marca determina si se enviará o no el tráfico de clase 3 al licitador. Tenga en cuenta que la limitación por clase de inventario también es posible a través del servicio de perfil del licitador heredado.
send_unaudited No, el valor predeterminado es false Booleano Esta marca determina si el licitador se enviará o no al tráfico no auditado.

Nota: La limitación por clase de inventario también es posible a través del servicio de perfil del licitador heredado.

Advertencia: Debe establecer este campo para ver las solicitudes de puja
Debe establecer send_unauditedtrue en para que el licitador reciba solicitudes de puja. Para obtener más información, consulte Integración de un licitador.
send_owned_blocklist no Booleano Enviar inventario de lista de bloqueos si pertenece a un miembro asociado a este postor.
userdata_entity_id no Entero Este campo está en desuso.
userdata_javascript no string Funciones de JavaScript personalizadas a las que se puede llamar cuando un licitador actualiza los datos de cookies de un usuario.
setuid_function no string Nombre de la función de JavaScript que se va a usar en las llamadas SetUID .

Ejemplos

Token de autenticación

La autenticación siempre es el primer paso cuando se usan los servicios de API. A continuación, el token de autenticación se puede escribir en nuestro archivo de cookies para su uso futuro. Para obtener instrucciones más detalladas, consulte Servicio de autenticación.

Visualización de la información del licitador

Si Xandr ya ha agregado el postor, ya tendrá información sobre el pujador, como el identificador del pujador, en formato JSON. Puede ver esta información con el siguiente comando.

S curl -b cookies -c cookies "https://api.adnxs.com/bidder"
{
   "response":{
      "status":"OK",
      "bidder":{
         "id":4,
         "name":"Test Bidder",
         "short_name":"TestBidder",
         "active":true,
         "parent_profile_id": 12345,
         "child_profiles":[{"id":1000},{"id":2000},{"id":3000}],
         "bid_uri":"/bid",
         "notify_uri":"/notify",
         "click_uri":null,
         "ready_uri":null,
         "pixel_uri":"/pixel",
         "audit_notify_uri":null,
         "last_activity":"2009-01-07 22:07:08"
      }
   }
}

Modificación de un pujador

Ahora que conoce el identificador del pujador, puede usar un archivo de texto en formato JSON para modificar el pujador. A continuación se muestra un JSON de ejemplo que cambiará el parámetro de URI ready.

Nota

Estos campos incluidos se actualizarán. Todos los demás campos no se modificarán.

$ cat bidder
{
      "bidder":{
         "id":4,
         "ready_uri":"/ready"
      }
   }

A continuación, use el PUT comando para actualizar estos datos en la caché del bus de impresiones.

$ curl -b cookies -c cookies -X PUT --data-binary @bidder 'https://api.adnxs.com/bidder/4'
{
   "response":{
      "status":"OK",
      "id":4
   }
}

Ahora, cuando vea el Licitador 4, obtendrá lo siguiente:

$ curl -b cookies -c cookies 'https://api.adnxs.com/bidder/4'
{
   "response":{
      "status":"OK",
      "bidder":{
         "id":4,
         "name":"Test Bidder",
         "short_name":"TestBidder",
         "active":true,
         "parent_profile_id": 12345,
         "child_profiles":[{"id":1000},{"id":2000},{"id":3000}],      
         "bid_uri":"/bid",
         "notify_uri":"/notify",
         "click_uri":null,
         "ready_uri":"/ready",
         "ready_string":"Ready:1"
         "pixel_uri":"/pixel",
         "audit_notify_uri":null,
         "last_activity":"2009-01-07 22:07:08"
      }
      }
}