Mantieni tutto organizzato con le raccolte
Salva e classifica i contenuti in base alle tue preferenze.
Per contribuire a soddisfare le limitazioni di latenza del servizio RTB, devi posizionare i tuoi server vicino alle località di scambio elencate di seguito. Per ulteriori informazioni, consulta la discussione su come individuare gli offerenti.
Sedi di scambio
Una località di scambio è il punto ottimale di un cluster di server distribuiti geograficamente in cui l'infrastruttura che ospita un'applicazione di offerente può trarre il massimo vantaggio in termini di latenza. I callout delle offerte in tempo reale non provengono necessariamente dalla località di scambio e possono provenire da altre parti del cluster. Ad esempio, Singapore è la località di scambio per il cluster Asia Pacifico che si estende dall'Australia a Singapore.
La tabella seguente elenca i domini di riferimento che possono essere utilizzati per valutare la latenza e stimare le posizioni migliori per il server.
Cluster di server
Località di scambio
Dominio di riferimento
Nord America (costa orientale)
Virginia del Nord, Stati Uniti
rtb-us-east.g.doubleclick.net
Nord America (costa occidentale)
San Francisco Bay Area, California, Stati Uniti
rtb-us-west.g.doubleclick.net
Europa
Amsterdam, Paesi Bassi
rtb-europe.g.doubleclick.net
Asia Pacifico
Singapore
rtb-asia.g.doubleclick.net
Posizione dell'offerente
Cerchiamo di inviare le richieste di offerta alla sede di negoziazione più vicina alla località dell'utente. Tuttavia,
non garantiamo che le richieste di offerta per le impressioni di un determinato utente verranno sempre inviate alla
piazza di scambio pubblicitario più vicina. Pertanto, per ricevere tutte le impressioni, devi avere dei server raggiungibili da tutte le località. Se vuoi solo un sottoinsieme di impressioni, potrebbe essere sufficiente operare su server in un
sottoinsieme di località. Ad esempio, la maggior parte, ma non tutto, il traffico nordamericano può essere ricevuto da
server in esecuzione raggiungibili dalle coste orientale e occidentale.
La scadenza entro la quale devi inviare una risposta all'offerta è indicata in
BidRequest.tmax. La scadenza in genere varia da 80 a 1000 ms.
Richiediamo che l'85% delle risposte venga ricevuto entro la scadenza
dal punto di vista della località di scambio e limiteremo gli offerenti che
non riescono a raggiungere questo obiettivo in modo coerente. Questa scadenza include sia il tempo di rete tra la località di scambio e lo strumento di offerta sia il tempo necessario allo strumento di offerta per generare una risposta. Ti consigliamo di scegliere come target un tempo totale molto inferiore alla scadenza per lasciare un buffer per eventuali variazioni impreviste della latenza della rete tra l'offerente e la località di scambio.
Peering
Google consiglia agli acquirenti RTB che ricevono un volume elevato di richieste di configurare richieste di peering con noi per ridurre la latenza e la volatilità della latenza.
Eseguiamo il peering con qualsiasi rete, a condizione che soddisfi i requisiti tecnici di Google, ad esempio disponga di un ASN pubblico. Per ulteriori dettagli, consulta i requisiti tecnici. Tieni presente che il requisito relativo al traffico non si applica ai clienti RTB. Per ulteriori informazioni, consulta le norme sul peering di Google.
Per avviare una richiesta di peering, compila il nostro modulo di richiesta di peering. Ti invieremo poi un numero di ticket che potrai utilizzare per eventuali follow-up con il tuo Technical Account Manager.
[[["Facile da capire","easyToUnderstand","thumb-up"],["Il problema è stato risolto","solvedMyProblem","thumb-up"],["Altra","otherUp","thumb-up"]],[["Mancano le informazioni di cui ho bisogno","missingTheInformationINeed","thumb-down"],["Troppo complicato/troppi passaggi","tooComplicatedTooManySteps","thumb-down"],["Obsoleti","outOfDate","thumb-down"],["Problema di traduzione","translationIssue","thumb-down"],["Problema relativo a esempi/codice","samplesCodeIssue","thumb-down"],["Altra","otherDown","thumb-down"]],["Ultimo aggiornamento 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."]]
