Servicio de licitación

El servicio de licitación conecta a un ofertante al bus de impresión de Xandr y permite que el ofertante y el bus de impresión comiencen la comunicación. Su representante de Xandr creará el licitador en el sistema y usted utilizará el Servicio de licitación para realizar modificaciones o recuperar su identificación de licitante.

Es posible que necesite su identificador de licitación para algunos de los Servicios. Para averiguar cuál es su identificador de licitador, ejecute el comando "ver todos los licitadores" que se describe a continuación.

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

Modificación de los campos del proveedor de datos (a través PUT): requiere un acuerdo de acceso a datos con cada proveedor

En los entornos de sandbox de ofertantes, toda la funcionalidad está disponible para fines de integración.

API de REST

Método HTTP Endpoint Description
GET https://api.adnxs.com/bidder/ Vea el licitador para el que tiene permisos. No mostrará los postores de otros usuarios.
GET https://api.adnxs.com/bidder/BIDDER_ID Ver un postor en particular.
POST https://api.adnxs.com/bidder
(ofertante JSON)		 Agregar un nuevo postor.
PUT https://api.adnxs.com/bidder/BIDDER_ID
(ofertante JSON)		 Modificar un licitador existente.
DELETE https://api.adnxs.com/bidder/BIDDER_ID Eliminar un ofertante existente.

Campos JSON

Campo Obligatorio Tipo Descripción
id Sí, en actualización Entero El identificador del ofertante.
short_name Sí (al agregar) string Un nombre corto opcional para el postor. Aunque no es técnicamente necesario, este campo es necesario para las métricas, por lo que debe considerarse obligatorio.

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

Nota:
- Debe notify_uri ser un URI relativo. Xandr actualmente no admite poner el bid_uri and notify_uri en hosts separados.
- Si es nulo, el licitador no recibe solicitudes de notificación.
click_uri no cadena(255) El URI de las solicitudes de clic (por ejemplo, /click). Use null, no una cadena vacía, para ponerlo en blanco. Consulte Solicitud de clic.
pixel_uri no cadena(255) El URI de las solicitudes de píxeles (por ejemplo, /pixel). Use null, no una cadena vacía, para ponerlo en blanco. Consulte Solicitud de píxeles.
ready_uri Sí (al agregar) cadena(50) El URI de una comprobación de estado de la instancia de ofertante (por ejemplo, /ready).
audit_notify_uri no cadena(255) El URI para pasar actualizaciones de auditoría creativa (p. ej https://send.mycompany.com/auditnotifyrequests.)
parent_profile_id no Entero El identificador del perfil del ofertante principal. Los perfiles de licitante se pueden usar para filtrar el tráfico de solicitud de oferta que llega a un licitante. Consulte el servicio de perfil de licitador heredado y el perfil de licitador - Preguntas frecuentes.
child_profiles no Array de objetos con el ID de los perfiles de los ofertantes. Matriz de objetos que especifican los perfiles secundarios que se van a usar. Por ejemplo: [{"id":123}, {"id":124}].
dongle no string Una contraseña que protege la salida de depuración de un ofertante en una impresión de depuración. Consulte debug_text en la respuesta a la licitación. Disponible solo para usuarios de tipo "ofertante".
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 pendientes (post_pending establecidas true 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 licitante sobre 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 true, el licitador es notificado sobre todas las ofertas perdidas.
- Si false, el licitador solo es notificado sobre ofertas perdidas con ID de código de error de solicitud de notificación superiores a 100. No registramos errores ni enviamos notificaciones de pérdida si el identificador de error es inferior a 100 para los licitadores de OpenRTB.
notify_pending No, el valor predeterminado es false Booleano Indica si el licitante recibe una notificación 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 licitante cuando el licitador no tiene una oferta para 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 Excluya el inventario que no sea propiedad de un miembro asociado con este ofertante.
send_unaudited No, el valor predeterminado es false Booleano Esta marca determina si a su licitador se le enviará o no tráfico no auditado.

Advertencia: Estrictamente hablando, este campo está en desuso, pero SIEMPRE debe establecerse en true. Si este campo se establece en false, su ofertante no recibirá ninguna solicitud de oferta.
bid_percent no Entero El porcentaje (50 = 50 %) del tráfico total de la plataforma que desea recibir. Las solicitudes que se envían a su postor se eligen al azar, aunque puede elegir que su postor siempre reciba solicitudes de usuarios en segmentos de miembros asociados con su postor. Si estableces bid_percent en 0, tu ofertante solo recibirá solicitudes de usuarios en al menos uno de los segmentos de tus miembros. Este filtro se aplica al tráfico que pasa por el servicio de perfiles de licitador heredado.
always_send_owned_segments no Booleano Determina si las impresiones de los usuarios de los segmentos propiedad del licitante o compartidos con él deben omitir passthrough_percent en los perfiles de los licitantes.

Nota: Esto solo anula el passthrough_percent en el perfil del licitador; Todas las demás restricciones, como los filtros de país o región, miembro, tamaño o dominio, se seguirán teniendo en cuenta al decidir si se enviará una impresión al ofertante.
object_limit_notify_email no matriz de cadenas Xandr limita la cantidad de objetos que cada postor puede crear y usar en la plataforma. Este límite incluye los 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. Describe el protocolo asociado con 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 OpenRTB 2.0 para su integración con Xandr. El valor de integración predeterminado para un licitador recién creado es 1, none. Este es el protocolo predeterminado, tal y como se define en la solicitud de puja y la respuesta a la puja. Los licitadores con una protocol_id de 6 se integran de acuerdo con la especificación OpenRTB 2.0 (PDF).
Especificaciones 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. El nombre del protocolo asociado con este ofertante. 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 marca de tiempo La marca de tiempo de la última modificación en esta instancia de licitador.
max_seats no Entero Los licitadores que oferten con identificadores de asiento de comprador personalizados harán que este campo incluya un valor mayor que 0. Este es el número máximo de asientos que se pueden registrar bajo un licitador.

Nota: Esta característica se encuentra actualmente en fase beta cerrada. Si está interesado en participar, comuníquese con su representante de Xandr.
default_member no Objeto Los licitantes que utilicen la oferta del identificador de asiento del 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 ofertante y también se utilizará como ID de miembro para el registro de creatividades.

Nota: Esta característica se encuentra actualmente en fase beta cerrada. Si está interesado en participar, comuníquese con su representante de Xandr.

Nota:

Use el Servicio de perfiles de ofertante para filtrar y limitar.

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

Campos en desuso

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

Nota: También es posible limitar por clase de inventario a través del servicio de perfiles de licitador heredado.

Advertencia: Debe establecer este campo para ver las solicitudes de oferta
Debe establecerlo send_unaudited para true que el licitante reciba las solicitudes de oferta. Para obtener más información, consulte Integrar un ofertante.
send_owned_blocklist no Booleano Envíe inventario de la lista de bloqueados si es propiedad de un miembro asociado con este ofertante.
userdata_entity_id no Entero Este campo está en desuso.
userdata_javascript no string Funciones personalizadas de JavaScript a las que se puede llamar cuando un ofertante actualiza los datos de cookies de un usuario.
setuid_function no string El nombre de la función JavaScript que se usará en las llamadas SetUID .

Ejemplos

Token de autenticación

La autenticación es siempre el primer paso al utilizar 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.

Ver información del ofertante

Si Xandr ya ha agregado el ofertante por ti, ya tendrás información del ofertante, como el identificador del ofertante, 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"
      }
   }
}

Modificar un licitador

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

Nota:

Estos campos incluidos se actualizarán. El resto de los campos no cambiarán.

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

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

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

Ahora, cuando vea Bidder 4, obtendrá:

$ 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"
      }
      }
}
  • Last updated on