Prácticas recomendadas y requisitos para las pujas

Requisitos de integración de las pujas

Todas las integraciones internas deben seguir los criterios que se describen a continuación para implementar una integración correcta y óptima.

  • Enviar solicitudes para el 100 % de las impresiones de anuncios que se pueden conseguir (por ejemplo, las que no son de venta directa).
  • Enviar solo una solicitud para cada oportunidad de impresión.
  • No combinar las pujas con las solicitudes estándar (o de etiquetas) para el mismo anuncio.
  • No enviar solicitudes tanto en cascada como en puja para la misma oportunidad de impresión.
  • Enviar notificaciones de tiempo de espera, pérdidas y ganancias con los códigos de pérdidas adecuados.
  • Obtener el valor de buyeruid del cliente mediante el SDK de Audience Network. El valor de buyeruid es el identificador de postor del usuario generado en el lado del cliente con el método getBidderToken del SDK de Audience Network.
  • Usar el SDK de Audience Network para recuperar y mostrar anuncios.
  • Solicitar el anuncio solo si la puja gana la subasta.
  • Enviar solicitudes de puja usando el identificador de autenticación (clave secreta de la aplicación e identificador de la solicitud).
  • Añadir un encabezado HTTP a cada solicitud, denominado x-fb-pool-routing-token, que contenga el identificador del postor como valor.
  • Configurar varios precios mínimos en otros orígenes del pedido que se encuentren en una cascada tradicional al combinarlos con las pujas. El uso de dos precios mínimos suele ser un buen punto de partida. De este modo, se proporciona un control más detallado en el modo en que la subasta compite con la cascada que aumentará el rendimiento general.

Para obtener más información sobre cómo combinar las pujas y las cascadas existentes, consulta Integrar subastas basadas en pujas con cascadas existentes.

Prácticas recomendadas para las pujas

Además de los criterios óptimos de integración, recomendamos seguir estas prácticas.

  • Establecer un valor de tiempo de espera de la solicitud de puja de al menos un segundo.
  • Recuperar el identificador de postor en el servidor para cada solicitud de puja.
  • Enviar un identificador único para cada solicitud.
  • Leer y registrar el encabezado HTTP x-fb-an-errors en las respuestas de las pujas que tengan un código de estado distinto a 200 a fin de usarlo para la solución de problemas.
  • Leer y registrar el encabezado HTTP x-fb-an-request-id en todas las respuestas de pujas a fin de usarlo para la solución de problemas.
  • Usar los identificadores de ubicación existentes para las pujas en lugar de crear ubicaciones nuevas, a menos que se estén haciendo tests A/B o se esté usando una plataforma de socio que requiera la creación de nuevas ubicaciones.
  • Usar la integración de servidor a servidor cuando sea posible, a fin de cambiar el procesamiento y el uso de la red del dispositivo y la red del usuario a los servidores y la red de editor, así como permitir las modificaciones de la subasta y las pujas sin cambios en la aplicación.
  • Se puede pasar un cuerpo de la solicitud comprimido en GZIP si se proporciona un encabezado Content-Encoding:gzip en la solicitud.
  • No usar precios mínimos en las pujas, ya que se ignorarán.