Para cumplir con las restricciones de latencia del servicio de RTB, debes ubicar tus servidores cerca de las ubicaciones de operaciones que se enumeran a continuación. Consulta el debate sobre cómo ubicar a tus ofertantes para obtener más información.
Ubicaciones de comercio
Una ubicación de comercio es el punto óptimo de un clúster de servidores dispersos geográficamente, en el que la infraestructura que aloja una aplicación de ofertantes puede beneficiarse más en términos de latencia. Las solicitudes de oferta de ofertas en tiempo real no necesariamente se originan en la ubicación de la operación y pueden provenir de otro lugar del clúster. Por ejemplo, Singapur es la ubicación de comercio del clúster de Asia-Pacífico, que va de Australia a Singapur.
En la siguiente tabla, se enumeran los dominios de referencia que se pueden usar para evaluar la latencia y estimar las mejores ubicaciones para el servidor.
| Clúster de servidor | Ubicación de la operación | Dominio de referencia |
|---|---|---|
| Norteamérica (Costa Este) | Virginia del Norte, Estados Unidos | rtb-us-east.g.doubleclick.net |
| Norteamérica (Costa Oeste) | Área de la Bahía de San Francisco, California, Estados Unidos | rtb-us-west.g.doubleclick.net |
| Europa | Ámsterdam, Países Bajos | rtb-europe.g.doubleclick.net |
| Asia-Pacífico | Singapur | rtb-asia.g.doubleclick.net |
Ubicación del ofertante
No garantizamos que las solicitudes de oferta para las impresiones de un usuario determinado se envíen siempre a través de la misma ubicación de comercio. Por lo tanto, para recibir todas las impresiones, debes tener servidores accesibles desde todas las ubicaciones. Si solo quieres un subconjunto de impresiones, puede ser suficiente ejecutar servidores en un subconjunto de ubicaciones. Por ejemplo, la mayoría del tráfico norteamericano, pero no todo, se puede recibir mediante la ejecución de servidores accesibles desde la costa este y oeste.
El plazo límite para el que debes enviar una respuesta de oferta se indica en BidRequest.tmax o BidRequest.response_deadline_ms en el protocolo de RTB de Google obsoleto. El plazo suele variar entre 80 y 1,000 ms.
Exigimos que el 85% de las respuestas se reciban dentro del plazo desde la perspectiva de la ubicación de la operación y limitaremos a los ofertantes que no puedan lograrlo de manera coherente. Este plazo incluye el tiempo de red entre la ubicación de la operación y tu ofertante, además del tiempo que le toma al ofertante generar una respuesta. Te recomendamos que te orientes a un tiempo total muy por debajo del plazo límite para dejar un búfer en caso de cambios inesperados en la latencia de la red entre tu ofertante y la ubicación de la operación.
Intercambiando tráfico
Google recomienda que los compradores de RTB que reciben un gran volumen de solicitudes configuren solicitudes de intercambio de tráfico con nosotros para reducir la latencia y la volatilidad de la latencia.
Intercambio de tráfico con cualquier red, siempre que cumpla con los requisitos técnicos de Google (como tener un ASN público) Consulta los requisitos técnicos para obtener más detalles. Ten en cuenta que no se aplica el requisito de tráfico para los clientes de RTB. Consulta la Política de intercambio de tráfico de Google para obtener más información.
Para iniciar una solicitud de intercambio de tráfico, completa nuestro formulario de solicitud de intercambio de tráfico. Luego, te enviaremos un número de ticket por correo electrónico que podrás usar en cualquier seguimiento con tu administrador técnico de cuentas.