تنظيم صفحاتك في مجموعات
يمكنك حفظ المحتوى وتصنيفه حسب إعداداتك المفضّلة.
للمساعدة في استيفاء قيود وقت الاستجابة لخدمة RTB، يجب تحديد موقع
خوادمك بالقرب من مواقع التداول المدرَجة أدناه. اطّلِع على المناقشة حول
تحديد موقع مقدّمي عروض الأسعار للحصول على مزيد من المعلومات.
المواقع الجغرافية للتداول
الموقع الجغرافي للتداول هو النقطة المثلى لتجمع كثيف من الخوادم المُوزّعة جغرافيًا، حيث يمكن للبنية الأساسية التي تستضيف تطبيق مقدّم عروض الأسعار الاستفادة إلى أقصى حدّ من وقت الاستجابة. لا تنشأ التعليقات التوضيحية لعروض الأسعار في الوقت الفعلي بالضرورة من
الموقع الجغرافي للتداول، بل يمكن أن تأتي من مكان آخر في المجموعة. على سبيل المثال، سنغافورة هي الموقع التجاري لمجموعة آسيا والمحيط الهادئ التي تمتد من أستراليا إلى سنغافورة.
يسرد الجدول التالي النطاقات المرجعية التي يمكن استخدامها لتقييم وقت الاستجابة وتقدير أفضل المواقع الجغرافية لخادمك.
مجموعة الخوادم
الموقع الجغرافي للتداول
النطاق المرجعي
أمريكا الشمالية (الساحل الشرقي)
فرجينيا الشمالية، الولايات المتحدة
rtb-us-east.g.doubleclick.net
أمريكا الشمالية (الساحل الغربي)
منطقة خليج سان فرانسيسكو، كاليفورنيا، الولايات المتحدة
rtb-us-west.g.doubleclick.net
أوروبا
أمستردام، هولندا
rtb-europe.g.doubleclick.net
آسيا والمحيط الهادئ
سنغافورة
rtb-asia.g.doubleclick.net
الموقع الجغرافي لمقدّم عرض السعر
نحاول إرسال طلبات عروض الأسعار إلى موقع التداول الأقرب إلى الموقع الجغرافي للمستخدم. ومع ذلك،
لا نضمن أنّ طلبات عروض الأسعار لمرّات ظهور مستخدِم معيّن ستُرسَل دائمًا إلى
أقرب موقع تداول. لذلك، لتلقّي جميع مرّات الظهور، يجب أن تكون لديك خوادم يمكن الوصول إليها
من جميع المواقع الجغرافية. إذا كنت تريد مجموعة فرعية فقط من مرّات الظهور، قد يكون كافيًا تشغيل الخوادم في مجموعة فرعية من المواقع الجغرافية. على سبيل المثال، يمكن أن تتلقّى معظم الزيارات الواردة من أمريكا الشمالية، وليس كلها،
من خلال خوادم قيد التشغيل يمكن الوصول إليها من الساحل الشرقي والساحل الغربي.
يُشار إلى الموعد النهائي الذي يجب إرسال ردّ على عرض السعر بحلوله في
BidRequest.tmax. تتراوح المهلة عادةً بين 80 و1000 ملي ثانية.
نطلب تلقّي 85% من الردود في غضون الموعد النهائي
من منظور موقع التداول، وسنحظر مقدّمي عروض الأسعار الذين
لا يمكنهم تحقيق ذلك بشكلٍ منتظم. ويشمل هذا الموعد النهائي وقت الشبكة
بين موقع التداول ونظام عروض الأسعار، والوقت الذي يستغرقه نظام عروض الأسعار
لإنشاء استجابة. ننصحك باستهداف وقت إجمالي أقل بكثير من
الموعد النهائي من أجل ترك فترة انتظار للتغييرات غير المتوقّعة في وقت استجابة
الشبكة بين مقدّم عروض الأسعار وموقع التداول.
تبادل معلومات بين الشبكات
تنصح Google مشتري عروض الأسعار في الوقت الفعلي الذين يتلقّون عددًا كبيرًا من الطلبات بإعداد
طلبات الربط معنا لتقليل وقت الاستجابة وتقلباته.
نربط أي شبكة طالما أنّها تستوفي المتطلّبات الفنية
لـ Google، مثل توفُّر رقم تعريف مزود خدمة شبكة عام. يمكنك الاطّلاع على المتطلبات الفنية للحصول على
مزيد من التفاصيل. يُرجى العلم أنّه تمّ إلغاء شرط عدد الزيارات لعملاء عروض الأسعار في الوقت الفعلي. يمكنك الاطّلاع على سياسة الربط
التي تتّبعها Google للحصول على معلومات إضافية.
لبدء طلب ربط الشبكات، يُرجى ملء نموذج طلب ربط الشبكات. سنرسل إليك بعد ذلك
رقم طلب عبر البريد الإلكتروني يمكنك استخدامه في أيّ عمليات متابعة مع
مدير الحساب الفني.
تاريخ التعديل الأخير: 2025-08-18 (حسب التوقيت العالمي المتفَّق عليه)
[null,null,["تاريخ التعديل الأخير: 2025-08-18 (حسب التوقيت العالمي المتفَّق عليه)"],[[["\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,["# Latency Restrictions and Peering\n\nTo 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-----------------\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---------------\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-------\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."]]
