Mantenha tudo organizado com as coleções
Salve e categorize o conteúdo com base nas suas preferências.
Para ajudar a atender às restrições de latência do serviço de RTB, localize
seus servidores perto dos locais de negociação listados abaixo. Consulte a discussão sobre
como localizar seus bidders para mais informações.
Locais de negociação
Um local de negociação é o ponto ideal de um cluster de servidores geograficamente dispersos
em que a infraestrutura que hospeda um aplicativo de bidder pode se beneficiar mais em termos de latência. Os destaques de lances em tempo real não são necessariamente originados no local de negociação e podem vir de outro lugar no cluster. Por exemplo, Singapura é o local de negociação do cluster da Ásia-Pacífico, que vai da Austrália até Singapura.
A tabela a seguir lista os domínios de referência que podem ser usados para avaliar
a latência e estimar os melhores locais para seu servidor.
Cluster de servidores
Local de operação
Domínio de referência
América do Norte (Costa Leste)
Virgínia, Estados Unidos
rtb-us-east.g.doubleclick.net
América do Norte (Costa Oeste)
Área da 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
Tentamos enviar solicitações de lance para o local de negociação mais próximo do usuário. No entanto,
não garantimos que as solicitações de lance para as impressões de um determinado usuário sejam sempre enviadas para o
local de negociação mais próximo. Portanto, para receber todas as impressões, você precisa ter servidores acessíveis
em todos os locais. Caso você queira apenas um subconjunto de impressões, talvez seja suficiente manter servidores em
um subconjunto de locais. Por exemplo, a maioria, mas não todo, o tráfego da América do Norte pode ser recebido por
servidores ativos acessíveis nas costas leste e oeste.
O prazo para enviar uma resposta do lance é indicado em
BidRequest.tmax. O prazo geralmente varia de 80 a 1.000 ms.
Exigimos que 85% das respostas sejam recebidas dentro do prazo
do local de negociação e vamos limitar os licitantes que
não conseguirem fazer isso de forma consistente. Esse prazo inclui o tempo de rede
entre o local de negociação e seu bidder e o tempo que seu bidder
leva para gerar uma resposta. Recomendamos definir um tempo total bem abaixo do
prazo para deixar um buffer para mudanças inesperadas na latência
da rede entre o 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 conosco para reduzir a latência e a volatilidade.
Fazemos peering com qualquer rede, desde que ela atenda aos requisitos técnicos
do Google, como ter um ASN público. Consulte os requisitos técnicos para
mais detalhes. O requisito de tráfego é dispensado para clientes do RTB. Consulte a
política de peering
do Google para mais informações.
Para iniciar um pedido de peering, preencha nosso formulário de solicitação de peering. Em seguida, enviaremos um número de tíquete por e-mail que você poderá usar em qualquer acompanhamento com o
gerente técnico da conta.
[[["Fácil de entender","easyToUnderstand","thumb-up"],["Meu problema foi resolvido","solvedMyProblem","thumb-up"],["Outro","otherUp","thumb-up"]],[["Não contém as informações de que eu preciso","missingTheInformationINeed","thumb-down"],["Muito complicado / etapas demais","tooComplicatedTooManySteps","thumb-down"],["Desatualizado","outOfDate","thumb-down"],["Problema na tradução","translationIssue","thumb-down"],["Problema com as amostras / o código","samplesCodeIssue","thumb-down"],["Outro","otherDown","thumb-down"]],["Última atualização 2025-09-04 UTC."],[[["\u003cp\u003eTo minimize latency in the Real-Time Bidding (RTB) service, position your servers near the specified trading locations, such as Northern Virginia, San Francisco Bay Area, Amsterdam, and Singapore.\u003c/p\u003e\n"],["\u003cp\u003eTrading locations serve as optimal points for server clusters to reduce latency, but bid requests can originate from anywhere within the cluster and are not guaranteed to always be sent to the geographically closest location.\u003c/p\u003e\n"],["\u003cp\u003eTo receive all potential impressions, ensure your servers are reachable from all listed trading locations; however, running servers in a subset of locations can suffice if only a specific subset of impressions are desired.\u003c/p\u003e\n"],["\u003cp\u003eBidders must respond to bid requests within a deadline, typically between 80 to 1000 ms, with a requirement that 85 percent of responses meet this deadline.\u003c/p\u003e\n"],["\u003cp\u003eFor high-volume RTB buyers, Google recommends setting up peering to decrease latency and latency volatility, with traffic requirements being waived specifically for RTB clients.\u003c/p\u003e\n"]]],[],null,["To help meet the latency restrictions of the RTB service, you should locate\nyour servers close to the trading locations listed below. See the discussion on\n[locating your bidders](#bidder-location) for more information.\n\nTrading locations\n\nA trading location is the optimal point of a geographically dispersed server\ncluster where infrastructure hosting a bidder application can benefit most in\nterms of latency. Real-time bidding callouts do not necessarily originate at\nthe trading location, and can come from elsewhere in the cluster. As an\nexample, Singapore is the trading location for the Asia Pacific cluster\nspanning from Australia to Singapore.\n\nThe following table lists reference domains that can be used to assess\nlatency and estimate the best locations for your server.\n\n| Server Cluster | Trading Location | Reference Domain |\n|----------------------------|---------------------------------------------------|-------------------------------|\n| North America (East Coast) | Northern Virginia, United States | rtb-us-east.g.doubleclick.net |\n| North America (West Coast) | San Francisco Bay Area, California, United States | rtb-us-west.g.doubleclick.net |\n| Europe | Amsterdam, Netherlands | rtb-europe.g.doubleclick.net |\n| Asia Pacific | Singapore | rtb-asia.g.doubleclick.net |\n\n| **Note:** We provide these domains for approximate estimation of latencies only. Routing outside of Google's network and Google's deployment of the service may change over time. In addition, network congestion or short term maintenance issues may leave these domains unreachable or too distant from a given location for extended periods.\n\nBidder location\n\nWe attempt to send bid requests to the trading location closest to the user's location. However,\nwe do not guarantee that bid requests for a given user's impressions will always be sent to the\nclosest trading location. Therefore, to receive all impressions, you need to have servers reachable\nfrom all locations. If you only want a subset of impressions, it may be sufficient to run servers in\na subset of locations. For example, most, but not all, North American traffic can be received by\nrunning servers reachable from the East and West coasts.\n\nThe deadline that you must send a bid response by is indicated in\n`BidRequest.tmax`. The deadline typically ranges from 80 to 1000 ms.\n\nWe require that 85 percent of responses be received within the deadline\nfrom the perspective of the trading location and will throttle bidders that\ncannot consistently achieve this. This deadline includes both the network time\nbetween the trading location and your bidder, and the time it takes your bidder\nto generate a response. We recommend targeting a total time well below the\ndeadline in order to to leave a buffer for unexpected changes in network\nlatency between your bidder and the trading location.\n\nPeering\n\nGoogle recommends that RTB buyers receiving a large volume of requests set\nup peering requests with us to reduce latency and latency volatility.\n\nWe peer with any network as long as they meet Google's technical\nrequirements, like having a public ASN. See the [technical requirements](//www.peeringdb.com/view.php?asn=15169) for\nmore details. Note that the traffic requirement is waived for RTB clients. See\nGoogle's [Peering Policy](//peering.google.com/#/options/peering)\nfor additional information.\n\nTo initiate a peering request, fill out our [peering request form](//isp.google.com/iwantpeering). We will then\nemail you a ticket number which you can use in any followups with your\ntechnical account manager."]]
