このドキュメントには、サプライ パートナーが新しい OpenRTB 統合をレビュー、計画、実行したり、カスタム SSP プロトコル統合から OpenRTB 標準に自分のペースで移行するために必要な情報が含まれています。
注:
[統合プロセス] ページは、外部供給パートナーのみを対象としています。
前提条件のチェックリスト
注:
カスタマー サポート ポータル アカウントをまだお持ちでない場合は、[ ログイン] ページにアクセスし、ゲストとして続行し、新しいユーザー登録を要求します。
- アカウント マネージャーに連絡 (またはサポート チームでチケットを作成) して、次の情報を確認します。
- メンバー シート ID と、まだ要求されていない場合は、Xandr の API 用の新しいメンバー シートの作成と API ログイン資格情報。
- 受信入札要求のエンドポイント。まだ要求されていない場合は、Xandr での新しいエンドポイントの作成。
- 以下に概説するドキュメントを確認し、未解決の質問について話し合います。
注:
前提条件のチェックは、契約が署名され、メンバー ID が作成された後にのみ完了します。 それより前は、ポイント 1a. のみ処理できます。 ただし、契約が副署されるまでは、プロセスに慣れて技術的な質問にすぐに対処できるように、統合チームとの会話を開始したいと考えています。
- エンゲージメントには 3 〜 4 週間かかると予想されます。
- クライアントは、前提条件チェックリスト (このドキュメント) を完全に確認し、以下の手順に従う前にすべての情報を収集する必要があります。
手順 1: セルフガイド API/UI トレーニングとパブリッシャーおよび配置オブジェクトの作成 (推定時間: 7 - 10 日)
Xandr オブジェクト階層 と API/UI のドキュメントを確認します。
初期テストに必要なオブジェクトを API 経由でプロビジョニングします。 詳細については 、API ドキュメント を参照してください。
UI/API を使用して在庫 (少なくとも初期機能テストに必要なもの) を同期する販売側オブジェクトを作成する
- Xandr オブジェクト階層の確認: メンバー → パブリッシャー →配置グループ →配置
- テストのパブリッシャーと配置を作成する
- 各オブジェクト内では、コード値に、SSP が 入札要求で渡す外部識別子を入力する必要があります。
- 関連する API ドキュメント
パブリッシャーレベルとメンバー レベルで既定の配置を設定します。 (入札要求から在庫を特定できない場合、インプレッションはその既定の配置に記録されます。)
[
code] フィールドを使用して、入札要求をパブリッシャーとプレースメントにマップします。 詳細と例については、 統合に関する FAQ を参照してください。注:
購入者に透明性を提供し、最適化を改善するために、パートナーはパブリッシャー別にインベントリを分類する必要があります。 インベントリ構造標準の詳細については、Wiki ページを参照してください。 API を使用してインベントリ構造を同期します。
パブリッシャー サービスを使用して、インベントリにマップされるパブリッシャーを作成します。
注:
-
codeフィールドは、パブリッシャー レベルとプレースメント レベルの両方のすべての外部販売者に必要であり、他のすべての販売者は、在庫を可能な限り細かくして、品質の問題、特にドメインの検出可能性について正確に調査できるようにすることを強くお勧めします。 この手順は、インベントリを検出性の高いタグと検出しにくいタグに分割するのに役立ち、検出不可能なドメインがインベントリの残りの存続可能性に与える影響を分離することができます。 - または API でパブリッシャーを作成または編集するには、 インベントリ関係を宣言する必要があります。 要求された情報は、インベントリへのアクセス方法に関する基本的なビジネス情報であり、Xandr のインベントリ品質の取り組みをサポートするために使用されます。 フィールドの完全な一覧とその使用要件については、 パブリッシャー サービスの ドキュメントを参照してください。
-
ユーザー同期のセットアップ
getUID サービスを使用して、Xandr と自分のの間でユーザー マッピング テーブルを保存します。 詳しくは、ユーザー ID マッピングをご覧ください。
手順 2: OpenRTB 入札要求エンドポイント テスト (推定時間: 3 - 4 日)
Xandr は、すべてのメディア タイプのインプレッションを受信するための OpenRTB 2.4 プロトコルをサポートしています。 IAB の OpenRTB 2.4 仕様に従います。
以下のエンドポイントを使用して、サーバー間の OpenRTB 入札要求を Xandr に送信します。
http://MEMBER_ALIAS-useast..com/openrtb2member_id=MEMBER_ID&test=1http://MEMBER_ALIAS-uswest..com/openrtb2member_id=MEMBER_ID&test=1http://MEMBER_ALIAS-emea..com/openrtb2?member_id=MEMBER_ID&test=1http://MEMBER_ALIAS-apac..com/openrtb2?member_id=MEMBER_ID&test=1
注:
MEMBER_ID
MEMBER_ALIASは、個々のパートナー メンバー ID とエイリアスで置き換える必要があります。
ページ「SSP からの受信入札要求」ページの入札要求の例を自由に使用し、それに応じてコード フィールドを調整して、パブリッシャーとプレースメントの在庫マッピングに一致するようにしてください。
テスト インプレッションを特定するには、呼び出しで "test=1" クエリ文字列パラメーターを使用する必要があります。 レポートにはログインされません。
手順 3: 手動テスト
入札要求のサンプルを Xandr に提供します。
Xandr プラットフォームで テスト 配置を設定し、インベントリが正しくマッピングされていることを確認します。
テスト配置のすべての要件を満たすサンプル クリエイティブを提供します。
Xandr テスト購入者がテスト配置のインプレッションを購入することのみを許可する広告品質ルールを設定します。
テストの開始時に、エンドポイント クエリ文字列から
"&test=1"を削除します。注:
"&test=1"を削除しない場合、imp は Xandr 側にログオンしません。テスト プレースメントから手動でトラフィックを発生させ、入札応答の受信、提供されたクリエイティブ、および味方で記録されたインプレッションを確認します。
Xandr は、専用の購入側メンバー シートから配信テストを実行し、インベントリをさらにスケーリングする前に不一致があることを通知します。
Xandr は OpenRTB 入札リクエストを検証し、形式を修正する必要がある場合は通知します。
手順 4: プログラムによる機能テスト (ライブ トラフィック)
- 確立された エンドポイント で Xandr へのトラフィックの小さいながらもかなりの部分を開きます (1 日あたり少なくとも数千 imps)。 Xandr は、送信されたトラフィックの量を確認し、インプレッションがレポートを通じて流入し、内部レポートと一致していることを確認します。
- テストを 1 日ほど実行し、数値を比較して、レポートと Xandr レポートの不一致が許容できることを確認します。
手順 5: 公開する
- 100% のトラフィックで公開する前に、Xandr プラットフォーム上のすべてのインベントリをマッピングします。
- 在庫マッピングが完了したら、トラフィックを増やし、国の事前ターゲティング、デバイスの事前ターゲティング、入札単価ボリューム調整などのテスト中に適用される可能性のあるフィルターを削除します。
ステップ 6: 完了/フォローアップ (推定時間: 2 - 3 日)
インベントリの個別の部分が Xandr に送信される、段階的なトラフィックの増加を奨励します。 一般的な推奨事項は、トラフィックの小さなチャンク (100-200 QPS) から始めることです。
セルフペースでの統合/移行の完了について、Xandr の連絡先に通知します。連絡先が最終的な OpenRTB 要件検証テストを開始し、最終結果とフィードバックを提供します。