Para ajudar a atender às restrições de latência do serviço RTB, localize seus servidores próximos dos locais de operação listados abaixo. Confira a discussão sobre como localizar seus bidders para mais informações.
Locais de operação
Um local de operação é o ponto ideal de um cluster de servidor geograficamente disperso, em que a infraestrutura que hospeda um aplicativo proponente pode se beneficiar mais em termos de latência. As chamadas de lances em tempo real não se originam necessariamente do local de operação e podem vir de outro lugar no cluster. Por exemplo, Singapura é o local de operação do cluster da Ásia-Pacífico, da Austrália a Singapura.
A tabela a seguir lista domínios de referência que podem ser usados para avaliar a latência e estimar os melhores locais para seu servidor.
| Cluster de servidor | Local de operação | Domínio de referência |
|---|---|---|
| América do Norte (Costa Leste) | Norte da Virgínia, Estados Unidos | rtb-us-east.g.doubleclick.net |
| América do Norte (Costa Oeste) | Baía de São Francisco, Califórnia, Estados Unidos | rtb-us-west.g.doubleclick.net |
| Europa | Amsterdã, Países Baixos | rtb-europe.g.doubleclick.net |
| Ásia-Pacífico | Singapura | rtb-asia.g.doubleclick.net |
Local do bidder
Não garantimos que as solicitações de lance para as impressões de um determinado usuário sempre sejam enviadas pelo mesmo local de operação. Portanto, para receber todas as impressões, você precisa ter servidores que possam ser acessados de todos os locais. Se você quiser apenas um subconjunto de impressões, pode ser suficiente executar servidores em um subconjunto de locais. Por exemplo, a maior parte do tráfego norte-americano, mas não todo, pode ser recebida pela execução de servidores acessíveis das costas leste e oeste.
O prazo para enviar uma resposta do lance é indicado em BidRequest.tmax ou BidRequest.response_deadline_ms no protocolo RTB do Google descontinuado. O prazo geralmente varia de 80 a
1.000 ms.
Exigimos que 85% das respostas sejam recebidas dentro do prazo do ponto de vista do local de operação e vamos limitar proponentes que não conseguirem atingir isso consistentemente. Esse prazo inclui o tempo de rede entre o local de negociação e seu bidder, além do tempo necessário para gerar uma resposta. Recomendamos segmentar um tempo total bem abaixo do prazo para deixar um buffer para mudanças inesperadas na latência de rede entre seu bidder e o local de negociação.
Peering
O Google recomenda que os compradores de RTB que recebem um grande volume de solicitações configurem solicitações de peering com o Google para reduzir a latência e a volatilidade da latência.
Fazemos o peering com qualquer rede, desde que ela atenda aos requisitos técnicos do Google, como ter um ASN público. Veja os requisitos técnicos para mais detalhes. Clientes de RTB estão isentos da exigência de tráfego. Consulte a política de peering do Google para mais informações.
Para iniciar uma solicitação de peering, preencha nosso formulário de solicitação de peering. Em seguida, enviaremos um e-mail com um número de tíquete, que pode ser usado em qualquer acompanhamento com o gerente técnico de contas.