アプリのテストとリリース

コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。

アプリケーションが完成し、内部でテストした場合、Google アカウント担当者がサーバーにテスト リクエストを送信する、標準化された一連のテストを受ける必要があります。アプリがこれらのテストに合格すると、リリースが可能になります。次のトピックでは、テストとリリースのプロセスについて説明します。

Google トラフィックでテストする

Google から送信されたトラフィックでテストを開始する準備ができたら、認定バイヤーの担当者にお問い合わせください。次のようなさまざまな情報を入力するよう求められます。

  • エンジニアリングの連絡先情報。テストが期待どおりに続行されず、エンジニアリング上の問題に対処する必要がある場合は、この連絡先情報を使用してチームと直接やり取りします。
  • RTB リクエストに応答する SSL 対応の URL。
  • Cookie コード マッチング サーバーの SSL 対応 URL(この機能を使用する場合)。
  • Google のサーバーとの通信を最適化するための、RTB サーバーの物理的な場所(州、国)。
  • テスト終了後に各物理ロケーションから提供する QPS(秒間クエリの最大数)です。
  • RTB / Cookie コード マッチング サーバーをテスト用に公開する日付。この日付以降、Google からお客様のサーバーに RTB リクエストが送信されます。
  • サーバーが RTB リクエストの処理に使用する推定レイテンシ。
  • 価格の復号情報を送付するための PGP 鍵。
  • プレターゲティング UIプレターゲティングが設定されていることを確認します。

テストプロセス中に随時、この情報を変更するには、認定バイヤーの担当者にお問い合わせください。

テストには、合成トラフィックを使用して異なるロケーションからのレイテンシを検証する、いくつかのステップが含まれます。また、広告がレンダリングされ、クリック トラッキングが適切に行われるように、基本的なテストも行われます。(ほとんどは、独自のテスト時と認証時に行います)。また、落札価格の通知とクリックを受信してデコードできるかどうかの確認も求められます。これらの項目を確認したら、次のステップは数日間でライブ トラフィックを徐々に増やすことです。

リアルタイム ビッダーを使用する際のレイテンシ要件は、80 ~ 1,000 ミリ秒です。これは、Google が呼び出しを送信してから Google が返信を受け取るまでの時間で測定されます。この期限はフォーマットとオークションのタイプによって異なります。入札リクエストの tmax フィールドまたは response_deadline_ms フィールドで正確な値を確認してください。

特定のロケーションで処理されるインプレッションの対象となるには、リクエストの 2% がこの期限を超過する必要があります。これらの要件に基づいて複数の取引ロケーションからインプレッションを受信するには、通常、すべてのリージョンで入札サーバーを実行する必要があります。たとえば、米国東海岸と西海岸の両方からインプレッションを受信する場合、通常、東海岸と西海岸の両方で入札サーバーを運用する必要があります。

ネットワーク イベントまたはその他の問題が原因で一時的にタイムアウト率が高いビッダーは自動的にスロットリングされます。このスロットル処理により、数分間のトラフィックが自動的に増減します。長期間にわたってスロットリングが頻繁に発生する場合は、より一貫した処理が可能なレベルにトラフィック割り当てが調整されます。