Preguntas más frecuentes: Proceso de integración de asociados de suministro

OpenRTB

Hay especificaciones "2.4" y "Mobile 2.2" mencionadas en la wiki. ¿Cuál es la diferencia? Nosotros (el SSP) somos una empresa móvil. ¿Qué versión de oRTB debemos usar?

Xandr admite la especificación OpenRTB 2.4 para recibir todas las impresiones de tipo multimedia. Para determinadas integraciones móviles heredadas, Xandr sigue siendo compatible con versiones anteriores con la especificación de OpenRTB 2.2. Para los nuevos tipos de integraciones, siga la especificación de OpenRTB 2.4.

¿Cuál es la versión más actual de VPAID y MRAID que admite?

Actualmente, Xandr video admite las versiones 1 y 2 de VPAID y VAST 1, 2 y 3. Actualmente se admite mraid versión 2.0. para dispositivos móviles. Somos compatibles con versiones anteriores de OpenRTB 2.2 y 2.3.

Datacenters

¿Dónde se encuentran los centros de datos?

Actualmente, Xandr ejecuta cinco centros de datos: LAX1 en Los Ángeles, NYM2 en North Bergen, NJ, AMS3 en Ámsterdam, Países Bajos, FRA1 en Fráncfort, Alemania y SIN3 en Singapur.

¿Cómo puedo probar la latencia en los diferentes centros de datos?

Para probar la latencia en el centro de datos de la costa este (metro de Nueva York), puede hacer ping jump.nym1.adnxs.net. El centro de datos de la costa oeste se puede hacer ping con jump.lax1.adnxs.net y el centro de datos europeo está disponible en jump.ams1.adnxs.net.

La lista de comprobación de requisitos previos menciona los límites de tiempo de espera de la subasta global y la medición de latencia para nuestras direcciones IP (SSP). ¿Puede especificar qué tipo de pruebas se realizarán para esta actividad?

Xandr tiene la capacidad de establecer el tiempo máximo de subasta variable para cada SSP. Para ello, medimos la latencia máxima entre controladores de dominio SSP y controladores de dominio Xandr en todas las regiones. El resultado se usa para configurar el tiempo máximo de la subasta en Xandr antes de que se considere que se agotó el tiempo de espera de una respuesta de puja hacia el SSP. Supongamos que el tiempo máximo de subasta en su plataforma es de 100 ms. Calculamos 100 ms : (latencia superior entre controladores de dominio, por ejemplo, 18 ms) - búfer de 10 ms = 72 ms. El resultado es el tiempo máximo de subasta definido en Xandr para su SSP y las respuestas de pujas más lentas se descartan antes de llegar a su plataforma.

Nosotros (el SSP) observamos que la latencia es muy alta y parece que el parámetro tmax no se respeta en absoluto. ¿Usan tmax? Si es así, ¿es necesario habilitarlo o algo parecido en su extremo?

El tmax valor no se puede establecer dinámicamente en la solicitud de puja en la plataforma Xandr. El soporte técnico de Xandr debe establecerlo para su puesto de miembro y para cada uno de los centros de datos individualmente. El tmax campo también se resalta en las especificaciones de OpenRTB como se controla de forma diferente en la plataforma Xandr aquí.

Identificadores de miembro

¿Es posible tener nuestro MEMBER_ALIAS y MEMBER_ID?

Sí. Como es un requisito previo para nuestro proceso estándar, solicite su MEMBER_ALIAS y MEMBER_ID de su contacto de Xandr.

¿Dónde podemos (el SSP) encontrar nuestro id. de asiento para proporcionar a los clientes que quieran pujar en nuestra plataforma? ¿Es algo que está disponible públicamente para todos o es algo que podemos proporcionar caso por caso a nuestros anunciantes?

El id. de asiento también se conoce como id. de miembro y se asigna a cada asociado en la plataforma de Xandr una vez finalizado el contrato comercial. El id. de asiento o miembro sigue siendo el mismo durante toda la duración del objeto asociado y otros asociados pueden hacer referencia a él para ajustar por ejemplo su configuración de calidad de anuncios, para dirigir sus campañas específicamente al identificador de miembro o para permitir la lista de permitidos o bloquear determinados vendedores o compradores.

wseat es compatible, pero ¿cómo puedo usarlo? ¿Cuáles son los valores posibles y dónde encontrar la asignación?

wseat el campo de la solicitud de puja de OpenRTB contiene una matriz de identificadores de puestos de comprador colocados en listas de permitidos (por ejemplo, anunciantes, agencias) que pueden pujar por esta impresión. En la convención de nomenclatura de Xandr, los identificadores de asiento y los identificadores de miembro son los mismos. Por lo tanto, la wseat matriz debe rellenarse con identificadores de miembro válidos que se pueden recuperar a través del servicio de miembro de la plataforma.

"wseat": [
    "958",
    "1417"
]

Identificadores de publicador

¿Cómo debemos (el SSP) definir relaciones de inventario para objetos de publicador?

Para crear nuevos objetos de publicador en el puesto de miembro de SSP o modificar la configuración del publicador existente, la API o la interfaz de usuario requieren que envíe información de relación de inventario . En muchos casos, la relación es "Publicador único procedente directamente del publicador". En ese caso, por ejemplo, los campos necesarios para rellenarse a través del servicio publisher son:

{
    "publisher": {
        "name": "Standard Publisher",
        "state": "active",
        "code": "4321",
        "reselling_exposure": "public",
        "expose_domains": true,
        "final_auction_type": "First Price",
        "inventory_relationship": "indirect_single_publisher",
        "inventory_source": "other",
        "inventory_source_name": "Publisher name for indirect_single_publisher",
        "contact": {
            "name": "The name of the point of contact for this publisher.",
            "phone": "contact phone number",
            "email": "CSPFeedback@appnexus.com"
        },
        "billing_dba": "Publisher name as in inventory_source_name",
        "billing_address1": "The street information of the billing address.",
        "billing_address2": "The street information of the billing address cont.",
        "billing_city": "The city of the billing address.",
        "billing_state": "The state of the billing address.",
        "billing_zip": "10010",
        "billing_country": "The country of the billing address."
    }
}

Por lo tanto, si nosotros (el SSP) establecemos la exposición de reventa a privado, entonces no permitiremos que otros miembros revenderán nuestro suministro, ¿verdad? Sin embargo, ¿podremos participar en una subasta abierta y vender nuestro inventario a través de los identificadores de las ofertas?

No. El inventario se puede establecer como destino en los niveles de red y publicador. Solo se puede comprar en el nivel de grupo de colocación. Por lo tanto, para permitir a los compradores dirigirse y comprar su inventario, debe realizar las siguientes acciones:

• Exponer el inventario para que los compradores se dirijan a ellos: esto también se conoce como "exposición de reventa" y se puede hacer para toda la red o por publicador. Esto hace que sea targetable. Para obtener instrucciones sobre cómo alternar esta configuración, consulte Servicio de publicador.

• Habilitar los grupos de selección de ubicación (y todas sus ubicaciones) para revenderlos: para revenderlos a otros miembros, se debe habilitar un grupo de selección de ubicación para revenderlo al establecerlo para que participe en rtb marketplace. Esto hace que se pueda comprar. Para obtener instrucciones sobre cómo alternar esta configuración, consulte Servicio de sitio.

¿Puede informarnos (el SSP) sobre el nombre del publicador? ¿Le recomendamos que usemos el nombre o un identificador que represente al publicador en nuestro sistema interno?

Xandr sugiere encarecidamente usar los nombres de publicador que se identifican claramente con el publicador (name campo descrito en Uso de la API para sincronizar la estructura de inventario. No use los identificadores internos (de los SSP) que solo conoce la plataforma interna para la nomenclatura del publicador. Consulte un ejemplo de estructura de asignación de inventario a continuación:

¿Es publisher.is_oo importante en la API?

Como se describe en el Servicio de publicador, documentación, si este parámetro está establecido en true, el publicador es propiedad de la red y lo opera. Esto significa que la red obtiene el 100 % de los ingresos. Sin embargo, si se especifican y is_ooinventory_relationship , inventory_relationship se sobrescribirá is_oo con el valor adecuado en función de la relación.

¿Cómo se debe implementar Ads.txt / App-Ads.txt como parte de nuestra integración de SSP?

Revise la documentación sobre soporte técnico para Ads.txt y App-Ads.txt y póngase en contacto con los publicadores con las instrucciones de la sección "Publicadores" (o simplemente conéctelos a esa página) junto con el identificador de miembro para que puedan agregarle a su ads.txt/app-ads.txt archivo.

Identificadores de transacción

¿Tenemos que (el SSP) registrar previamente los identificadores de oferta (PMP) en la plataforma Xandr antes de enviarlos en el protocolo OpenRTB?

Para poder vender identificadores de oferta en la plataforma Xandr, debe registrarlos previamente mediante el Servicio de oferta.

{
    "deal": {
        "active": true,
        "code": "5612",
        "name": "Standard Deal",
        "start_date": "2017-04-10 00:00:00",
        "type": {
            "id": 1
        },
        "buyer": {
            "id": 882
        }
    }
}

Nuestro (el SSP) deal.id estará deal.code en el sistema Xandr. ¿Puede aclarar cómo se hará referencia a los SSP deal.id en la solicitud de puja? ¿O solo contendrá el identificador de la oferta de Xandr?

Se hace referencia a los identificadores de transacción de deal.code forma similar a la forma en que se asignan los objetos de inventario en Xandr. Los SSP deal.id se establecen deal code en en la plataforma de Xandr a través del servicio deal cuando se crea la oferta. La pmp.deals matriz de la solicitud de puja de OpenRTB debe incluir el SSP deal.idexterno. Xandr lee el externo deal.id de la solicitud de puja y lo asigna al objeto id. de oferta interno a través de la asignación proporcionada en el deal.code campo. Consulte el siguiente ejemplo de solicitud de oferta de OpenRTB (que hace referencia al objeto deal en la pregunta anterior):

[...] "pmp":{"deals":[{"id":"5612" [...]

¿Es cierto que se nos pedirá que pasemos el identificador de miembro comprador para cada oferta creada entre nosotros (el SSP) y Xandr? ¿Cuál es el proceso aquí? ¿Cada agencia que quiera comprar el inventario del publicador a través de Deal ID debe proporcionar un identificador de puesto de miembro único?

Las ofertas se crean sobre la base de una relación de 1 a 1 entre el vendedor y el comprador. El miembro vendedor de la oferta debe conocer el identificador de miembro del comprador para poder crear una oferta en la plataforma de Xandr.

Puntos de conexión

¿Debo (el SSP) seguir usando en &test=1 el punto de conexión para las solicitudes de oferta de OpenRTB de producción?

No. No se use &test=1 para solicitudes de puja de OpenRTB de producción, ya &test=1 que no se generarán datos de informes.

¿Xandr proporciona puntos de conexión de prueba para probar la funcionalidad de OpenRTB antes de que (el SSP) hayamos firmado el contrato?

No. Xandr no proporciona entornos de prueba o de espacio aislado independientes para las integraciones estándar de OpenRTB. Use en test=1 el punto de conexión de producción para indicar el tráfico de prueba.

¿Cambia mi dominio de punto de conexión Xandr al actualizar a OpenRTB?

No. La única parte que cambia es el punto de conexión real de /CUSTOM_ENDPOINT a /openrtb2. Por lo tanto, los nuevos puntos de conexión correctos para el protocolo OpenRTB2 son:

https://MEMBER_ALIAS-useast.adnxs.com/openrtb2?member_id=MEMBER_ID
https://MEMBER_ALIAS-uswest.adnxs.com/openrtb2?member_id=MEMBER_ID
https://MEMBER_ALIAS-emea.adnxs.com/openrtb2?member_id=MEMBER_ID
https://MEMBER_ALIAS-apac.adnxs.com/openrtb2?member_id=MEMBER_ID

Nota:

MEMBER_ID y MEMBER_ALIAS debe reemplazarse por su identificador y alias de miembro de asociado individual, proporcionados por el contacto de Xandr.

¿Es posible llamar a la dirección URL del aviso de victoria desde el marcado del anuncio con fines de prueba o auditoría sin desencadenar marcas de calidad de inventario y marcar la impresión como impresión de prueba?

Por supuesto. Use la siguiente información en el encabezado de la llamada para indicar que la /ab llamada o /openrtb_win es solo con fines de prueba:

curl -v --header 'X-is-test: 1' --header 'Host: ib.adnxs.com' 'https://nym1-ib.adnxs.com/ab?e=wqT_3QKoCfA8qAQAAAMA1gAFAQjQis3HBRCUvPSr_...&referrer=appnexus.com&pp=1'

Nota:

No use direcciones IP que no se resuelvan en la búsqueda de dominio para esta configuración de prueba.

Id. de usuario

La solicitud de puja contiene un valor no válido "buyeruid". ¿Tenemos que arreglar esto? Si es así, ¿puede proporcionar documentación?

Sí. El buyeruid campo contiene el id. de usuario de Xandr que nos envía para indicar al usuario que coincidió anteriormente a través del píxel de usersync. El objeto de solicitud de puja tiene que contener un identificador de usuario válido en el buyeruid campo, para que se considere una solicitud de puja con datos de usuario coincidentes. Obtenga más información sobre el objeto de usuario de la solicitud de puja en Solicitud de puja entrante de SSP.

La sincronización de usuarios estándar con Xandr requiere el hospedaje de la tabla de coincidencias de usuario, ¿correcto? ¿Iniciaría Xandr la sincronización del usuario? Si es así, ¿qué volumen podríamos anticipar aquí?

Las integraciones de SSP de OpenRTB estándar de Xandr requieren que el SSP almacene la asignación de usuarios en su propio sistema. Normalmente, un píxel de imagen 1x1 en las páginas SSP llama al servicio getUID de Xandr y devuelve UUID Xandr para el almacenamiento. El formato del píxel se puede encontrar en Asignación de id. de usuario. El servidor que recibe llamadas asincrónicas de usuario de Xandr debe poder controlar QPS 1K-3K.

¿Nos preguntamos si Xandr admite la sincronización de usuarios bidireccional?

Xandr no admite la sincronización de usuario bidireccional que implica almacenar tablas de asignación asincrónica de usuario de SSP en el lado Xandr. Sin embargo, la sincronización de usuarios iniciada por Xandr es totalmente compatible. Permite a Xandr quitar píxeles SSPs de usersync en todo el universo de identificadores de usuario de Xandr. La configuración del píxel asincrónico de usuario iniciado por Xandr forma parte del proceso de integración.

¿Cuál es la mejor manera de probar y confirmar que la sincronización de usuarios funciona según lo esperado?

La manera más fácil de comprobar si el buyeruid (id. de usuario de Xandr) está asignado correctamente es usar la subasta de depuración. Al anexar &debug=1 a la llamada de solicitud de puja, debería recibir status: success la salida como se indica a continuación:

[COOKIESHEET] cookie source: provided uid
[COOKIESHEET]   mobile optout action: none
[COOKIESHEET]   get request:
[COOKIESHEET]       uid source: provided uid
[COOKIESHEET]       uid: 5160786676315026726
[COOKIESHEET]       status: success
[COOKIESHEET]   map request: none
[COOKIESHEET]   mobile request: none

¿Xandr requiere que buyeruid el campo se rellene con identificadores de usuario de Xandr para In-App inventario móvil?

No buyeruid es obligatorio para In-App solicitudes de puja de OpenRTB; sin embargo, se recomienda proporcionar siempre para garantizar las buyeruid tasas de coincidencias de usuario más altas. Xandr intenta buscar primero coincidencias con los identificadores móviles y, en caso de que no coincida, intenta coincidir con .buyeruid Si se proporcionan ambos valores, los identificadores móviles coincidentes correctamente tienen prioridad sobre buyeruid.

¿Cuáles son los parámetros de intervalo para los desencadenadores de píxeles asincrónicos de usuario?

De forma predeterminada, Xandr define para el píxel asincrónico de usuario de SSP activa los parámetros max_interval=432000 internos (5 días) y min_interval=43200 (12 horas). Intervalo máximo: número máximo de segundos que esperaremos entre sincronizaciones para ese píxel. Por ejemplo, si no hemos activado píxeles en 5 días, inscríbalo en el algoritmo para seleccionar los píxeles asincrónicos de usuario que se van a activar. Intervalo mínimo: el número de segundos que esperaremos entre los reintentos de un píxel de sincronización si no podemos confirmar que la sincronización se produjo correctamente (tal vez se ha quitado el píxel pero no se ha desencadenado correctamente o el usuario ha navegado rápidamente). Por ejemplo, si acabamos de activar el píxel, no intente sincronizarlo de nuevo durante al menos 12 horas.

¿Cuánto tiempo almacena Xandr los datos de usuario?

Actualmente, el período de vida aproximado (TTL) para los datos de usuario (identificadores de usuario de Xandr) es de 60 días.

¿Cuál es la diferencia entre y /getuidnb el /getuid servicio?

En caso de que el usuario NO tenga el id. de Xandr almacenado en el espacio de cookies de Xandr y no tenga cookies permanentes:

• /getuid hacia delante con UID=0

• /getuidnb NO avanza con UID=0 (el SSP no recibirá 0 valores de entornos de cookies no permanentes)

Solicitudes de puja

Las solicitudes de puja de OpenRTB tienen el imp.tagid campo . ¿Xandr espera que ese campo contenga el correspondiente placement.id accesible desde el servicio de selección de ubicación? ¿O se espera que sea el placement.codvalor e (también administrado a través del servicio de selección de ubicación de API)?

imp.tagid sería el placement.code valor del servicio de selección de ubicación. Debe ser el mismo valor que el que va a pasar o app.id en site.id la solicitud de puja.

¿Cuál es la secuencia de búsqueda de inventario para los identificadores de objeto de solicitud de puja de OpenRTB?

Xandr coincide con los identificadores proporcionados en las solicitudes de puja de OpenRTB mediante la siguiente secuencia de búsqueda:

1. imp.tagid - used to lookup by placement code
2. bidrequest.app.id - used to lookup by placement code
3. bidrequest.site.id - used to lookup by placement code
4. use bidrequest.site.publisher.id or bidrequest.app.publisher.id to lookup publisher by code and try to get default publisher placement

La solicitud de puja incluye varios objetos mediatype. ¿Cuáles, si no todas, se enviarán a la parte de compra y, en última instancia, se realizarán transacciones?

OpenRTB admite solicitudes de varios formatos. Sin embargo, las respuestas de puja no están claramente definidas para varios tipos de medios. Como resultado, se admiten solicitudes de puja de varios formatos con priorización codificada de forma rígida entre tipos de medios. Por ejemplo, si una solicitud se incluye como nativa y de vídeo, se transforma en solo una solicitud de vídeo cuando se envía a la parte de compra. El orden es:

1. video
2. audio
3. banner
4. native

¿Qué ocurre con la impresión de solicitud de puja si un publicador no está asignado en la jerarquía de inventario del puesto de miembro?

En ese caso, el origen de impresión del publicador parece incorrecto y podría dar lugar a que se filtre. Xandr no modifica las propiedades de la impresión de ninguna manera. Sin embargo, el suministro vendido en el intercambio abierto de Xandr se analiza y analiza para asegurarse de que el inventario representa la ruta de compra más directa, transparente y eficiente para nuestros compradores. Las impresiones que no cumplen estos requisitos pueden ser inelegibles para la venta de RTB. Esas impresiones pueden venderse a través de ofertas. Si tiene problemas con la entrega en marketplace abierto, puede considerar la posibilidad de configurar un acuerdo con un comprador específico para monetizar el inventario.

¿Responde Xandr a varias impresiones en las solicitudes de puja? ¿O solo responde a un objeto de impresión por solicitud de puja?

Se admiten varios objetos de impresión en una solicitud de puja según las especificaciones de OpenRTB. Cada objeto de impresión ejecuta su propia subasta y obtiene ofertas individuales de los compradores.

¿Cuáles son las recomendaciones de Xandr para las definiciones típicas de recursos nativos en la solicitud de puja nativa?

Con el fin de facilitar la adopción y maximizar el alcance del vendedor entre los compradores nativos, se realizan recomendaciones para tamaños mínimos y proporciones de aspecto a continuación:

Campo	Directrices de Xandr
Title	Máximo de 25 caracteres
Body	Máximo de 300 caracteres
Icon/Logo*	Relación de aspecto 1:1 Nota: La especificación de OpenRTB combina el tipo 1 y el tipo 2 superpuestos anteriores como solo el tipo 1, que se usará para el icono de aplicación, el logotipo de marca o similar.
Image	Relación de aspecto 1.91:1 (600 px min / 150 KB max)
Sponsored By	Máximo de 40 caracteres (marca de anuncio)

El recurso de imagen de la solicitud de puja nativa usa el tipo 1 para el icono de aplicación, el logotipo de marca o similar. ¿Admite Xandr tamaños de icono específicos, por ejemplo, 50x50?

No. Los identificadores creativos de Xandr actualmente no contienen información sobre el tamaño de icono o logotipo de la creatividad nativa enviada por el comprador. Todas las solicitudes de puja nativas, incluido el tipo img 1, deben declararse como tamaño 0x0.

En la parte nativa de la solicitud ("native-request-native" campo): veo que espera una cadena codificada en JSON. ¿También puede aceptar un objeto normal?

El campo nativo dentro del nodo native.request debe ser una cadena. Dado que la especificación nativa 1.0 es técnicamente una especificación por sí sola y se puede usar teóricamente fuera de la especificación OpenRTB2.3, el contenido del campo nativo no puede formar parte de la estructura JSON y, por lo tanto, debe ser "escape" para poder aparecer como una cadena.

Sobre el interior de tagid la impresión de solicitud, ¿tenemos (el SSP) que asignar todas nuestras ubicaciones en Xandr? O bien, ¿podríamos dejar que este campo permanezca vacío o reemplazar el valor por ?site.id

¡Sí, no y no! Debe asignar todo el inventario a ubicaciones de Xandr. No deje vacío el tagid campo de la solicitud de puja, ambos campos, tagid y site.id asigne al mismo placement.code campo en el objeto de selección de ubicación Xandr.

El método de entrega de marcado predeterminado en Xandr es el bid.adm atributo de la respuesta de la puja, que nosotros (el SSP) no admitimos actualmente. ¿Admite la entrega alternativa de marcado de anuncios a través del bid.nurl atributo ?

Sí, se admite el marcado de anuncios que se sirve en el aviso de victoria. Según la especificación de OpenRTB, hay varios métodos estándar para transferir el marcado del licitador (Xandr) al intercambio (el SSP). El método de entrega de marcado de anuncios predeterminado en Xandr es a través del bid.adm atributo . El método de entrega de marcado alternativo a través del atributo win notice bid.nurl se elegirá si el SSP proporciona el BidRequestExtension atributo en la solicitud de puja entrante.

Nota:

Actualmente, el método de entrega de marcado alternativo no funciona para el tipo de medio nativo.

"ext": { "appnexus": { "markup_delivery": 1 } }

Cuando Xandr lee los dominios o direcciones URL de referencia de las solicitudes de puja de OpenRTB, ¿está Xandr mirando el domain campo o el page campo?

Estamos examinando ambos campos para determinar la dirección URL o el dominio del referenciador. El page campo se prefiere sobre la domainsolicitud de puja entrante del campo de los CSP.

¿Cómo se ajusta la respuesta de Xandr a la lista de bloqueos de nuestros editores, como dominios bloqueados, categorías o atributos? En otras palabras, ¿cómo nos aseguramos de que las creatividades que sirven a través de la integración de OpenRTB no infrinjan nuestras listas de bloques de editores?

Para ello, IAB introdujo los campos wseatde solicitud de puja , bcaty badvbapp en el protocolo OpenRTB. Además, la plataforma de Xandr permite una forma menos dinámica de configuración de bloques del publicador a través del servicio de perfil de anuncios.

¿La compatibilidad con varios objetos imp en la solicitud de puja requiere una configuración en el extremo?

Xandr admite de forma predeterminada varios imp objetos en las solicitudes de puja. Cada imp objeto se trata como una impresión independiente en la plataforma Xandr. El hecho de que se envíen varias impresiones a Xandr incluidos en la misma solicitud de puja no tiene otras implicaciones que ahorrar recursos de red y sobrecarga de conexión.

Xandr

¿Cómo controla 0 Xandr y los casos de borde null cuando se trata de valores de recursos nativos, por ejemplo wmin/hmin?

Por ejemplo: si los campos wmin/hmin de activos img nativos se establecen 0 en o null en la solicitud de puja, Xandr los trata lógicamente como si esos campos se omitían en la solicitud de puja. La implicación de esto es que los licitadores externos verán la misma solicitud de oferta enviada sin esos campos, es decir, con esos campos eliminados con fines de eficiencia.

¿Qué significa realmente en private_auction el pmp de las solicitudes de oferta y cuáles son las implicaciones de establecerla 1en , es decir, solo se aceptan ofertas para ofertas especificadas?

Si recibimos una impresión de subasta privada de un vendedor de OpenRTB, solo enviaremos ofertas que serán aceptadas en la subasta de terceros. La implicación de es pmp.private_auction=1 : Xandr NO enviará la solicitud de puja a ningún otro posible postor de compra que no se especifique en las ofertas de esa impresión.

¿Envía Xandr el imp.bidfloor campo desde la solicitud de puja de SSP OpenRTB a licitadores externos?

Sí. Xandr recibe y evalúa el precio del piso de nivel de impresión y pasa el imp.bidfloor a los compradores externos del postor.

Nosotros (el SSP) vemos una parte de nuestras solicitudes de puja devolviendo una respuesta HTTP 400 con formato incorrecto. ¿Por qué?

Este es el comportamiento actual para la ubicación inactiva, el grupo de selección de ubicación o el publicador y los tamaños de banner no válidos. Se devuelve HTTP 400 si no se encuentra ninguna impresión válida en la solicitud.

Respuestas de puja

¿Cuáles son las respuestas HTTP esperadas a las solicitudes de puja?

A continuación se enumeran las respuestas HTTP esperadas a las solicitudes de puja:

• 200 Ok: se ha devuelto una respuesta de puja válida.
• 204 SIN CONTENIDO: no se ha devuelto ninguna oferta.
• 400 MALFORMED: la solicitud de puja entrante contiene un site.idobjeto , app.id, app.publisher.ido site.publisher.id que se asigna a un publicador inactivo o a un objeto de ubicación en el sistema Xandr. Consulte El paso 2 de solución de problemas de entrega general para obtener más información.

Nosotros (el SSP) necesitamos un bid.adomain parámetro en todas las respuestas de pujas. ¿Todas las respuestas de puja de Xandr contendrán un bid.adomain campo rellenado? ¿Es posible obtener el dominio del anunciante, incluso si no está en el campo openrtb bid.adomain , pero en otro campo?

Xandr sigue muy de cerca la especificación de OpenRTB y no define el campo de dominio según sea necesario. Sin embargo, todas las creatividades tienen una marca asociada, incluida la marca desconocida (id. 1), que se asigna automáticamente a las nuevas creatividades no auditadas. La marca desconocida se vincula al appnexus.com adomain. Por lo tanto, esperamos que todas las respuestas de la oferta incluyan el adomain, excepto las que contienen creatividades asociadas a marcas que no tienen un dominio asociado a ellas (<0,08 % de todas las creatividades), debido a directivas internas u otros motivos.

¿Qué son las categorías NEX10-101 en la respuesta de la oferta de OpenRTB?

Omita esas categorías. Son redundantes con nuestras categorías de IAB y estarán en desuso en los próximos meses.

¿Puede el adm campo de la respuesta de puja ser un objeto normal?

No. adm contiene el marcado de anuncio que se enviará a la página o aplicación. No puede ser una estructura JSON.

Nosotros (el SSP) hemos visto que el ancho y el alto de la respuesta es 1x1. ¿Devuelve el ancho y el alto exactos del tamaño del anuncio de vídeo?

Para los tipos de medios que no son de banner: el ancho y el alto de la respuesta de la puja no representan el tamaño real de la creatividad (o el marcado del anuncio) que se va a entregar en la página del publicador. Por ejemplo: las creatividades de tipo multimedia de vídeo usan varios archivos multimedia para la entrega y se ofrece una flexibilidad similar para los tamaños de recursos de imagen nativos. Para esas creatividades, el ancho y el alto exactos se transportan en un nivel más profundo del objeto creativo, que se puede obtener en vista previa mediante la sintaxis siguiente:

Video: https://{DATACENTER}-ib.adnxs.com/cr?id={APN_CREATIVE_ID}&format=vast 
Native: https://{DATACENTER}-ib.adnxs.com/cr?id={APN_CREATIVE_ID}&format=json

¿Desea que nosotros (el SSP) hagamos algo con iurl? ¿Es relevante para las respuestas de pujas de vídeo? ¿Esta dirección URL tiene alguna directiva de expiración? He intentado iniciar sesión en uno de los ejemplos y parece que la dirección URL no es válida.

Iurl representa la versión preliminar creativa en nuestra plataforma y es una dirección URL estática (consulte la sintaxis anterior), es decir, no expira. Puede usarlo con fines de auditoría previa, almacenamiento en caché creativo, etc. El id parámetro representa el identificador creativo de Xandr y es único en nuestra plataforma. Para la versión preliminar de la creatividad de vídeo, adjunte el parámetro de formato "vast" al iurl para ver el xml, por ejemplo. https://fra1-ib.adnxs.com/cr?id=48265354&format=vast

¿Es el precio de la subasta en el marcado de anuncios dólares estadounidenses? Supongo que es CPM, ¿correcto?

Xandr sigue la especificación de OpenRTB aquí. El precio usa la misma moneda y unidades que la puja, en la mayoría de los casos USD y CPM.

¿Cómo podemos (el SSP) confirmar durante la prueba si la solicitud de puja devuelve una oferta sin puja o es sintácticamente incorrecta?

No dude en usar el debug=1 parámetro como se muestra a continuación en la llamada manual para ejecutar una subasta de depuración general.

Sugerencia: si no se devuelve absolutamente ninguna salida de depuración, lo más probable es que algo esté mal con la estructura de la solicitud de puja o que la ubicación no funcione.

https://MEMBER_ALIAS-useast.adnxs.com/openrtb2?member_id=MEMBER_ID&debug=1
https://MEMBER_ALIAS-uswest.adnxs.com/openrtb2?member_id=MEMBER_ID&debug=1
https://MEMBER_ALIAS-emea.adnxs.com/openrtb2?member_id=MEMBER_ID&debug=1
https://MEMBER_ALIAS-apac.adnxs.com/openrtb2?member_id=MEMBER_ID&debug=1

¿Cómo debemos pasar el precio final en la notificación ganadora? Nosotros (el SSP) vemos que hay una macro pp=$(AUCTION_PRICE). ¿Qué codificación o formato se necesita?

Si el auction type campo de la solicitud de puja se define como at=2 (subasta de segundo precio), el SSP debe rellenar la ${AUCTION_PRICE} macro para recibir el segundo precio. El precio de liquidación debe usar la misma moneda, unidades y formato/codificación que la puja (normalmente moneda USD y CPM).

Nota:

NO use caracteres de moneda como $ en el precio rellenado en la AUCTION_PRICE macro. En general, no use ningún otro carácter que el formato de número doble especificado. Si el precio de compensación de CPM es por ejemplo 0.47 dólares, reemplace como AUCTION_PRICE se indica a continuación:

Reemplazo de macro correcto AUCTION_PRICE

pp=0.47

¿Deberíamos (el SSP) usar el cifrado cuando le superemos el precio ganador? ¿Puede confirmar qué algoritmos de cifrado se admiten?

Todavía no se admite la codificación para la AUCTION_PRICE macro en integraciones estándar.

¿Cómo se debe implementar la representación del impulsor Xandr y clicktracker en la página del publicador? ¿Podemos implementar nuestro impulsor (SSP) para activar el evento de victoria de impresión y el impulsor Xandr en la impresión es un evento visible? ¿Eso daría lugar a discrepancias para los clics?

Sí, las diferencias en la implementación del impulsor entre el SSP y el evento de activación de Xandr provocarán un comportamiento discrepante. Los clics también se verán afectados, ya que dependen del tiempo del impulsor.

Ahora (el SSP) estamos en funcionamiento con OpenRTB nativo. ¿Tiene una tabla de coincidencia de campos para que podamos comunicar a los compradores qué campos de OpenRTB corresponden a qué campos creativos de Xandr?

Los compradores nativos, los compradores de plataforma y los proveedores de servicios externos tienen que registrar previamente las creatividades nativas según creative service. (Consulte los ejemplos para obtener más información).

¿El orden de las pujas en el JSON de respuesta de la oferta sigue un patrón determinado, por ejemplo, un orden descendente basado en el precio de la oferta?

No, no garantizamos ningún orden en la estructura de matriz JSON de respuesta de puja. Se recomienda evaluar las pujas y aplicar la lógica de selección de pujas estrictamente después de analizar la respuesta JSON completa.

¿Cuáles son los límites de tiempo de espera de las llamadas de notificación de impresión win?

Los límites de tiempo de espera de las llamadas de notificación de win varían para los distintos tipos de medios, y se aplican los siguientes tiempos de espera para /ab, /it las llamadas y /openrtb_win :

• banner: 5 minutes
• native: 60 minutes
• video: 360 minutes

¿Cuáles son los límites de tiempo de espera para el seguimiento de clics?

Para la dirección URL de seguimiento de clics, llama a la ventana de vista posterior de agregación después de que la impresión se haya transaccionado en la plataforma de Xandr:

• banner: 120 minutes
• native: 120 minutes
• video: 120 minutes

Nota:

Los informes de clics de Xandr no contarán las llamadas url de clic realizadas fuera de la ventana de vista atrás de agregación designada después de que la impresión se haya realizado en la plataforma. Esto es especialmente importante para las discrepancias de clic en las que el SSP cuenta más clics que los informes de Xandr.

Reporting

¿Cuáles son los informes y métricas disponibles en la plataforma de Xandr y cómo podemos (el SSP) recuperar esos informes?

El tipo de informe más común que ejecutan los CSP es el informe de Análisis de red. Este informe proporciona información sobre lo que suele servir, lo que está funcionando bien, tanto en el lado de la compra como de la venta. Todos los informes se obtienen a través de reporting API services. Consulte la lista completa de tipos de informe disponibles.

Este es un ejemplo de la secuencia de llamadas api necesaria para obtener un informe de Network Analytics de los últimos 7 días:

echo "AUTH to AppNexus API: "
curl -bc -cc -X POST -s -d '{"auth":{"username":"YOUR_USERNAME","password":"YOUR_PASSWORD"}}' "https://api.appnexus.com/auth"
{
    "response": {
        "status": "OK"
    }
}
 
echo "POST to report API service: "
curl -bc -cc -X POST -s -d '{ "report": { "report_type":"network_analytics", "columns":[ "hour", "seller_member_name", "buyer_member_name", "publisher_name", "publisher_id", "publisher_code", "imps", "clicks", "total_convs", "revenue", "ctr", "convs_rate" ], "report_interval":"last_7_days", "format":"csv" } }' "https://api.appnexus.com/report?member_id=MEMBER_ID"
{
    "response": {
        "report_id": "287efed55c091dc97e2c839580962cba",
        "status": "OK"
    }
}
 
echo "DOWNLOAD from report-download API service: "
curl -bc -cc -s "https://api.appnexus.com/report-download?id=287efed55c091dc97e2c839580962cba" 
hour,seller_member_name,buyer_member_name,publisher_name,publisher_id,publisher_code,imps,clicks,total_convs,revenue,ctr,convs_rate
2017-06-02 05:00,Member Inc.,Test Buyer,Example Publisher,777999,222333,0,0,0,0.000000,0.000000000000000000,0.000000000000000000
2017-05-31 13:00,Member Inc.,Test Buyer - Netherlands,Publisher Name AG,555777,100200,172,0,0,0.000000,0.000000000000000000,0.000000000000000000