RTB サービスのレイテンシ制限を満たすには、以下に示す取引ロケーションの近くにサーバーを配置する必要があります。詳しくは、ビッダーの場所に関する説明をご覧ください。
取引ロケーション
取引ロケーションは、地理的に分散したサーバー クラスタの最適なポイントであり、ビッダー アプリケーションをホストするインフラストラクチャがレイテンシの面で最もメリットを得られます。リアルタイム ビッダーのコールアウトは、必ずしも取引ロケーションから発生するわけではなく、クラスタ内の他の場所から発生する場合もあります。たとえば、シンガポールは、オーストラリアからシンガポールに広がるアジア太平洋クラスタの取引ロケーションです。
次の表に、レイテンシの評価とサーバーの最適なロケーションの見積もりに使用できる参照ドメインを示します。
| サーバー クラスタ | 取引ロケーション | 参照ドメイン |
|---|---|---|
| 北米（東海岸） | 北バージニア（米国） | rtb-us-east.g.doubleclick.net |
| 北米（西海岸） | サンフランシスコ ベイエリア（米国カリフォルニア州） | rtb-us-west.g.doubleclick.net |
| ヨーロッパ | Amsterdam, Netherlands | rtb-europe.g.doubleclick.net |
| アジア太平洋 | シンガポール | rtb-asia.g.doubleclick.net |
ビッダーの地域
同一ユーザーのインプレッションに対する入札リクエストが常に同じ取引ロケーションから送信されるとは限りません。したがって、すべてのインプレッションを受け取るには、すべてのロケーションからサーバーに到達可能である必要があります。インプレッションのサブセットのみが必要な場合は、ロケーションのサブセットでサーバーを稼働させるだけで十分な場合もあります。たとえば、北米のトラフィックの大部分は、東海岸と西海岸から到達可能なサーバーが稼働中の状態で受信される可能性があります。
入札レスポンスの送信期限は、BidRequest.tmax またはサポートが終了した Google RTB プロトコルの BidRequest.response_deadline_ms で示されます。この期限は通常、80 ～ 1,000 ミリ秒です。
取引ロケーションの観点から、レスポンスの 85% を期限内に受信することを求め、これを常に達成できないビッダーをスロットリングします。この期限には、取引ロケーションとビッダー間のネットワーク時間と、ビッダーがレスポンスを生成するのにかかる時間の両方が含まれます。入札者と取引ロケーションの間でネットワーク レイテンシの予期せぬ変化に対応できるように、デッドラインよりかなり短い時間の合計時間を設定することをおすすめします。
ピアリング
大量のリクエストを受信する RTB 購入者は、レイテンシとレイテンシの変動を軽減するために、Google とのピアリング リクエストを設定することをおすすめします。
パブリック ASN があることなど、Google の技術要件を満たしている限り、Google はネットワークとピアリングします。詳細については、技術要件をご覧ください。なお、RTB クライアントについてはトラフィック要件は適用されません。詳しくは、Google のピアリング ポリシーをご覧ください。
ピアリングのリクエストを開始するには、ピアリング リクエスト フォームにご記入ください。その後、Google からチケット番号がメールで届きます。この番号は、テクニカル アカウント マネージャーへのフォローアップに使用できます。