Koleksiyonlar ile düzeninizi koruyun
İçeriği tercihlerinize göre kaydedin ve kategorilere ayırın.
RTB hizmetinin gecikme kısıtlamalarını karşılamak için sunucularınızı aşağıda listelenen işlem konumlarına yakın bir yere yerleştirmeniz gerekir. Daha fazla bilgi için teklif verenlerinizi bulma konulu tartışmaya göz atın.
Değişim yerleri
Ticaret konumu, coğrafi olarak dağıtılmış bir sunucu kümesinin, teklif veren uygulamasını barındıran altyapının gecikme açısından en fazla fayda sağlayabileceği en uygun noktasıdır. Gerçek zamanlı teklif verme açıklama metinleri, işleme konumundan gelmekle birlikte kümenin başka bir yerinden de gelebilir. Örneğin, Avustralya'dan Singapur'a kadar uzanan Asya Pasifik kümesinin ticari konumu Singapur'dur.
Aşağıdaki tabloda, gecikmeyi değerlendirmek ve sunucunuz için en iyi konumları tahmin etmek üzere kullanılabilecek referans alanlar listelenmiştir.
Sunucu Kümesi
İşlem yapılan yer
Referans alanı
Kuzey Amerika (Doğu Kıyısı)
Kuzey Virginia, ABD
rtb-us-east.g.doubleclick.net
Kuzey Amerika (Batı Kıyısı)
San Francisco Körfez Bölgesi, Kaliforniya, ABD
rtb-us-west.g.doubleclick.net
Avrupa
Amsterdam, Hollanda
rtb-europe.g.doubleclick.net
Asya Pasifik
Singapur
rtb-asia.g.doubleclick.net
Teklif veren konumu
Teklif isteklerini, kullanıcının konumuna en yakın alım satım yerine göndermeye çalışırız. Ancak belirli bir kullanıcının gösterimleriyle ilgili teklif isteklerinin her zaman en yakın alım satım yerine gönderileceğini garanti edemeyiz. Bu nedenle, tüm gösterimleri almak için tüm konumlardan erişilebilen sunuculara sahip olmanız gerekir. Yalnızca gösterimlerin bir alt kümesini istiyorsanız sunucuları bir konum alt kümesinde çalıştırmak yeterli olabilir. Örneğin, Kuzey Amerika trafiğinin tümü olmasa da çoğu, doğu ve batı kıyılarından erişilebilen sunucuları çalıştırarak alınabilir.
Teklif yanıtı göndermeniz gereken son tarih BidRequest.tmax'te belirtilmiştir. Son tarih genellikle 80 ila 1.000 ms arasındadır.
Yanıtların yüzde 85'inin, alım satım konumu açısından son tarihe kadar alınmasını zorunlu tutarız ve bunu tutarlı bir şekilde yapamayan teklif verenlerin tekliflerini sınırlandırırız. Bu son tarih, hem işleme yeri ile teklif vereniniz arasındaki ağ süresini hem de teklif vereninizin yanıt oluşturması için gereken süreyi içerir. Teklif vereniniz ile işlem konumu arasındaki ağ gecikmesinde beklenmedik değişikliklere karşı bir tampon bırakmak için toplam süreyi son tarihin çok altında bir değerde hedeflemenizi öneririz.
Eşleme
Google, çok sayıda istek alan GZT alıcılarının gecikmeyi ve gecikme dalgalanmasını azaltmak için bizimle eşleme istekleri oluşturmasını önerir.
Herhangi bir ağ, Google'ın teknik şartlarını (ör. herkese açık ASN'ye sahip olmak) karşıladığı sürece eşleşir. Daha fazla bilgi için teknik şartlara göz atın. RTB müşterileri için trafik şartının kaldırıldığını unutmayın. Daha fazla bilgi için Google'ın Eşleme Politikası'na bakın.
Eşleme isteği başlatmak için eşleme isteği formumuzu doldurun. Ardından, teknik hesap yöneticinizle yapacağınız takiplerde kullanabileceğiniz bir destek kaydı numarası e-postayla size gönderilir.
[[["Anlaması kolay","easyToUnderstand","thumb-up"],["Sorunumu çözdü","solvedMyProblem","thumb-up"],["Diğer","otherUp","thumb-up"]],[["İhtiyacım olan bilgiler yok","missingTheInformationINeed","thumb-down"],["Çok karmaşık / çok fazla adım var","tooComplicatedTooManySteps","thumb-down"],["Güncel değil","outOfDate","thumb-down"],["Çeviri sorunu","translationIssue","thumb-down"],["Örnek veya kod sorunu","samplesCodeIssue","thumb-down"],["Diğer","otherDown","thumb-down"]],["Son güncelleme tarihi: 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."]]
