次の方法で共有


AppNexus 入札プロトコル

重要

  • サポートされていません: AppNexus 入札プロトコルはサポートされなくなりました。このドキュメントは、レガシのみを目的としています。 これは非推奨になっています。
  • AppNexus と統合する新しい入札者の場合は、 OpenRTB 2.4 入札プロトコルを参照してください。

AppNexus プラットフォームに bidder インスタンスを登録すると、AppNexus Impression Bus によって一連の要求が送信されます。これは 、入札要求のキーです。 入札者は、一連の回答(重要なものは 入札応答)で応答します。 次に、要求と応答の一覧と、それぞれの使用状況の簡単な説明を示します。 入札者は、サポートする予定の各サービスに対して "ハンドラー" (入札要求ハンドラー、クリック ハンドラーなど) を構築する必要があります。

インプレッション固有の要求/応答

インプレッション バスを通過する標準インプレッションには、次の 3 つの要求/応答が使用されます。

入札プロトコル プロセスを示す図。

プロセス

  1. 広告リクエスト (クライアント側) は、パブリッシャー サイト上のユーザーのブラウザーから発信され、TinyTag を介してインプレッション バスに広告を要求します。
  2. インプレッション バスは、該当するすべての入札者に (サーバー側の) 入札要求 を送信し、応答を待機します。 各入札者のユーザー データは、入札要求と共に渡されます。
  3. 入札者はタイムアウト期間内にインプレッション バスに 入札応答 を送信します (現在、ほとんどの販売者は 100 ミリ秒、一部の販売者では長くなります)。 これには、入札者がオークションに勝った場合にユーザー データを変更するために使用される javascript コードが含まれます。
  4. インプレッション バスは、最高額の入札額を決定し、関連付けられているクリエイティブをユーザーのブラウザーに返します。
  5. 通知要求は、入札応答で送信されなかった入札者を含むすべての該当する入札者に送信され、オークションの結果が詳細に表示されます。

注:

このプロセスは、結果がセカンダリエクスチェンジに渡されるオークションでは若干異なります。

その他の要求/応答

Bidder の準備完了要求

すべての bidder インスタンス ( Bidder Instance Service を参照) には、 準備完了要求に応答する作業サービスが必要です。 これにより、Impression Bus はトラフィックを送信する必要があるインスタンスをリアルタイムで認識できます。

Bidder のクリック要求

入札者は、(必要に応じて) クリック要求のクリック ハンドラーを構築できます。 これは、入札者のメンバーがインプレッション バスを通じてクリックトラッキングを使用することを選択した場合にのみ必要です。 すべてのメンバーのクリエイティブがサード パーティ (DART や Atlas など) のタグであり、クリック追跡目的でのみサード パーティを使用することを選択した場合、入札者はこの要求の種類をサポートする必要がない場合があります。

入札者向けモバイル OpenRTB

モバイル需要パートナーは、OpenRTB API 仕様を使用して AppNexus と統合できます。 詳細については、「 Mobile OpenRTB Integration」を参照してください。