Solución de problemas de vendedores externos

Artículo
05/17/2024

En esta página se describen algunos de los problemas comunes a los que se enfrentan los vendedores externos e instrucciones para ayudar a resolver esos problemas. Para obtener más información, consulte las preguntas más frecuentes sobre el proceso de integración.

Solución de problemas de ofertas

Si está experimentando una falta de entrega de ofertas específicas, estos son algunos pasos que debe seguir:

Asegúrese de que la oferta existe en el sistema Xandr. Use el Servicio de oferta para confirmar que la oferta existe, está activa y se ofrece al miembro comprador de Xandr correcto. Para obtener instrucciones completas sobre la creación de ofertas, consulte Venta de ofertas en Xandr.
Compruebe que se están enviando solicitudes para esta oferta. El campo de código del objeto de transacción Xandr debe coincidir con el identificador de transacción que se envía en la solicitud OpenRTB (pmp.deals.id). Para obtener ejemplos, consulte Vender ofertas en Xandr.
Las solicitudes para esta oferta deben cumplir nuestras especificaciones generales y apuntar a objetos válidos y activos en nuestro sistema. Consulte Solución de problemas generales de entrega a continuación.
Asegúrese de que el comprador está apuntando a la oferta.

Si ha confirmado los pasos 1 a 3, el siguiente curso de acción es ponerse en contacto con el comprador y asegurarse de que se dirigen activamente a la oferta. Si es así, el comprador debe enviar una incidencia de soporte técnico a través del Portal de clientes para que nuestro equipo de soporte técnico de compra pueda solucionar problemas.

Solución de problemas generales de entrega

Normalmente, los problemas generales de entrega apuntan a una falta de demanda para el inventario específico. 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. Además, tenga en cuenta que 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, pero pueden venderse a través de ofertas. Puede consultar nuestra página De procedimientos recomendados para partners de suministro para obtener más información sobre estos estándares. Si no es elegible para ofertas, consulte nuestros Requisitos de elegibilidad de la oferta.

Los pasos siguientes le guiarán a través de la solución de problemas de no entrega en Marketplace abierto.

Compruebe que las solicitudes son válidas según las especificaciones de Xandr.

Todas las solicitudes que se envían deben seguir la especificación Xandr OpenRTB.
Asegúrese de que las solicitudes enviadas incluyan identificadores válidos de sitio o aplicación y publicador.

Las solicitudes deben incluir un identificador de sitio (tagid, site.id) o un identificador de aplicación (app.id) que se corresponda con un objeto de selección de ubicación existente en el sistema Xandr. Para obtener ejemplos específicos sobre dónde incluir estos identificadores, consulte la especificación Xandr OpenRTB. El identificador enviado en la solicitud puede ser el identificador del objeto de selección de ubicación o el valor establecido en el code campo del objeto de selección de ubicación . Si la solicitud no contiene un sitio o un identificador de aplicación, o si el identificador enviado en la solicitud no existe en el sistema Xandr, la solicitud no se considerará válida. Lo mismo sucede con un publicador: el identificador incluido en la solicitud debe asignarse a un publicador activo válido en el sistema Xandr. Si no se incluye un identificador de publicador en la solicitud, el sitio o la aplicación incluidos también deben asignarse a una ubicación que exista en un publicador activo y un sitio (grupo de selección de ubicación) en nuestro sistema. Para obtener una explicación completa de nuestra jerarquía de objetos, así como instrucciones y procedimientos recomendados relacionados con la asignación de inventario, consulte Synchronize Your Inventory Structure (Sincronizar la estructura de inventario). Use los siguientes servicios de API para comprobar si cada objeto de la jerarquía está activo y se asigna a los códigos enviados en la solicitud:
Compruebe que se han desactivado las ubicaciones correspondientes.

Nuestro sistema puede desactivar las ubicaciones por motivos relacionados con la calidad del inventario. Si el id. de sitio o aplicación enviado en una solicitud se asigna a una ubicación desactivada, esta solicitud no será válida y recibirá un error HTTP 400 MALFORMED. Para obtener más información sobre las desactivaciones de calidad del inventario, consulte Desactivaciones de calidad de inventario.
Indique al comprador que envíe una incidencia de soporte técnico.

Si los pasos anteriores no resolvieron el problema y hay un comprador específico implicado que no puede realizar transacciones en su inventario, el siguiente curso de acción es hacer que el comprador envíe una incidencia de soporte técnico a través del Portal de clientes para que nuestro equipo de soporte técnico de compra pueda solucionar problemas adicionales.

Escalados de infracciones de directivas o malware

Cualquier escalamiento con respecto al malware o las infracciones de nuestras Políticas de Servicio se puede enviar a nuestro Equipo de Anti-Malvertising a través del Portal de clientes en la categoría Anti-Malvertising. Este equipo podrá revisar la creatividad y el dominio infractores con fines de lista de bloqueo de plataforma.

Dominios: si la escalación implica un dominio específico o una lista de dominios, asegúrese de incluir el motivo para marcar el dominio, así como un informe de un proveedor de análisis de terceros (como La confianza de medios o RiskIQ) si procede.
Creatividades: si la escalación implica una creatividad específica, asegúrese de que una o todas las siguientes opciones se incluyen en la solicitud de soporte técnico (que se muestra aquí en orden de importancia):
- Informe correspondiente de un proveedor de análisis de terceros (como The Media Trust o RiskIQ) si procede.
- Id. de creatividad extraído del contenido de la página final (por ejemplo, ) o del parámetro crid de la respuesta de la puja.
- Una de las siguientes direcciones URL:
  - ib.adnxs.com/if?
  - ib.adnxs.com/click?
  - ib.adnxs.com/ab?
  - ib.adnxs.com/vevent?
- Una lista completa de las llamadas de red realizadas a la página en el momento del incidente.

Bloques de calidad de anuncios & escalaciones

Las creatividades que no contienen elementos malintencionados o infringen las directivas de compra de plataformas todavía se pueden bloquear en todo el vendedor o en publicadores específicos para problemas como conflictos de marca, vídeos incompatibles, etc. Estos bloques de calidad de anuncios se controlan principalmente dinámicamente a través de OpenRTB, específicamente mediante los siguientes parámetros:

badv: dominios de anunciante de nivel superior que corresponden a direcciones URL de marca en el sistema Xandr
bcat: categorías de contenido
btype: tipos de medios creativos
battr: atributos técnicos

Para bloquear creatividades específicas o establecer la configuración de calidad de anuncios anterior en el sistema Xandr, use el Servicio de perfil de anuncios. Para conocer los procedimientos recomendados relacionados con el uso de la calidad del anuncio, consulta Definir reglas de calidad de anuncios. La configuración aplicada en el sistema Xandr funcionará junto con las enviadas dinámicamente en la solicitud OpenRTB; el bloque más restrictivo entre los dos siempre se aplicará. Para obtener una vista previa de la creatividad de un comprador, puede usar la dirección URL presente en el campo iurl de la respuesta de la oferta.

Si encuentras creativos que no cumplen esta configuración de calidad de anuncios (ya sea pasados a la solicitud de OpenRTB o establecidos en el servicio de perfil de anuncios) que sirven en tu inventario, esto se puede escalar a nuestro Equipo anti-malvertido a través del Portal de clientes en la categoría Anti-Malvertising.

Respuestas HTTP

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 identificador de sitio (tagid, site.id), id. de aplicación (app.id) o id. de publicador (app.publisher, id o site.publisher.id) que se asigna a un publicador inactivo o a un objeto de ubicación en el sistema Xandr. Para obtener más información, consulte El paso 2 anterior de solución de problemas de entrega general .

Si no recibe ninguna respuesta o la solicitud está agotando el tiempo de espera, compruebe que la configuración de tiempo de espera de la subasta global proporcionada durante la integración inicial sea correcta. Si esta configuración ha cambiado o no está seguro de la configuración de tiempo de espera que se envió inicialmente, envíe una incidencia de soporte técnico a través de nuestro Portal de clientes para confirmar y proporcionar la configuración correcta a nuestros equipos.

Discrepancias

Cuando varios sistemas están implicados en la conservación, es de esperar algún nivel de discrepancia en la generación de informes entre estos sistemas. Históricamente, los estándares del sector han considerado razonablemente aceptables las discrepancias de hasta un 10 %. Si experimenta una discrepancia mayor, uno de los escenarios siguientes podría ser la causa principal.

Diferencia en los tiempos de espera de los anuncios almacenados en caché

El recuento de impresiones para vendedores externos se basa en el sistema que recibe una llamada de notificación de victoria (/ab, /it, /openrtb_win, /vast_track); cualquier diferencia de tiempo de espera en sistemas externos puede causar discrepancias en el recuento de impresiones. En la plataforma Xandr, los tiempos de espera de cada tipo de medio (en relación con la hora de la subasta generada por la solicitud de OpenRTB) son los siguientes:

banner: 5 minutos
nativo: 360 minutos
vídeo: 360 minutos

En lo que respecta al seguimiento de clics, las diferencias de tiempo similares también tendrán en cuenta las discrepancias. La expiración de nuestra dirección URL de seguimiento de clics (/click) es de 120 minutos en relación con la hora de la impresión registrada; No se contarán los clics que se producen fuera de esta ventana.

Seguimiento de eventos diferentes

Como se describió anteriormente, Xandr se basa en una llamada de notificación de victoria para contar una impresión. Las discrepancias de visualización pueden surgir cuando un sistema externo realiza un seguimiento de las impresiones en un momento diferente en la cadena de llamadas de anuncios que la activación de esta llamada (por ejemplo, en la representación creativa frente a la entrega de contenido creativo a la página).

De forma similar, las discrepancias de vídeo suelen deberse a una diferencia en el evento de seguimiento VAST que se usa para contar la impresión. Xandr cuenta una impresión VAST cuando se activa la dirección URL de seguimiento de impresiones en nuestro contenedor VAST, que, según la especificación de IAB, debe enviar el reproductor una vez que se represente el primer fotograma del vídeo. Si un sistema externo está realizando un seguimiento de las impresiones en la entrega del contenido del anuncio, el evento de inicio o cualquier otro evento de seguimiento VAST, no es probable que los números de impresión registrados en este sistema se alineen con los registrados por Xandr.

Control incorrecto de la macro de precios de subasta

Como se muestra en la especificación de OpenRTB, los precios de las subastas de sistemas externos se pasan a Xandr mediante la macro ${AUCTION_PRICE}. Si esta macro no se rellena con un precio de ganancia válido, nuestro sistema no podrá registrar este precio, lo que puede dar lugar a discrepancias financieras.

Desactivaciones de calidad de inventario

Cuando se desactiva un objeto de selección de ubicación por un motivo relacionado con la calidad del inventario, se enviarán notificaciones como el identificador de objeto y el motivo de desactivación a los correos electrónicos especificados en el audit_notify_email campo bajo el servicio miembro.

Si emplea un examen creativo que carga direcciones URL /ab y estos puntos de conexión del analizador están causando desactivaciones de calidad de inventario, asegúrese de que el encabezado "X-is-test: 1" se incluya con cada llamada a la dirección URL /ab desde estos puntos de conexión. Este encabezado indicará que la llamada correspondiente a la dirección URL /ab es una prueba y evitará que nuestro sistema la registre. Si sigue experimentando problemas con este encabezado en su lugar, confirme también que el punto de conexión del analizador se resuelve en un nombre DNS; El uso de una dirección IP que no se resuelve en un nombre DNS provocará desactivaciones independientemente de si se usa el encabezado de prueba.

Nota:

El parámetro de cadena de consulta test=1 (que se usa para las solicitudes de prueba) NO funciona para las direcciones URL de /ab.

Límites de objetos

Para ver los límites de objetos actuales, use el servicio de límite de objetos. Tanto los objetos activos como los inactivos contarán para los recuentos de límites de objetos. Las notificaciones de límite de objetos se envían a los correos electrónicos especificados en el sherlock_notify_email campo bajo el servicio miembro. Si está cerca de los límites de objetos, puede eliminar objetos sin usar mediante el servicio de API correspondiente, ya que los objetos eliminados NO cuentan con este límite.

Comportamiento inesperado

Si experimenta un comportamiento que no está en consonancia con nuestra documentación o especificaciones, envíe una incidencia de soporte técnico a través de nuestro Portal de clientes con los registros pertinentes que muestren el problema o los pasos que se van a reproducir.

Compartir a través de