Protected Audience メディエーションによる複数の販売者が参加するオークションのサポート

販売側の広告プラットフォームでは通常、広告デマンドソースを多様化し、広告収入を最適化します。広告メディエーションでは、広告ネットワークまたはサービスが複数の広告ネットワークを呼び出して、特定の広告スロットに最適な広告を決定します。このプロポーザルでは、Android 版 Protected Audience API を拡張し、プライバシーの保護を図りながらウォーターフォール メディエーション機能を実装する方法を紹介します。現在、広告ネットワークには、複数の広告販売者の広告オークションをアプリ デベロッパーがメディエーションするさまざまな方法があります。

1. ウォーターフォール メディエーション: アプリ デベロッパーは、広告ネットワークの順序付きリストを定義します。ほとんどの場合、特定のネットワークの過去の eCPM に基づいてランク付けされます。このリストはメディエーション チェーンと呼ばれます。アプリ デベロッパーのメディエーション プラットフォームは、このリストを使用して、指定された順序で広告ネットワークを呼び出し、関連する広告のデマンドソースを決定します。
2. プログラマティック メディエーション: アプリ デベロッパーが広告配信機会の入札に参加できるように、複数の広告ネットワークが設定されます。これらのネットワークは、機会の評価に基づいて、リアルタイムで入札することができます。
3. ハイブリッド メディエーション: ウォーターフォールとプログラマティックのメディエーション手法の組み合わせ。

ウォーターフォール メディエーション

ウォーターフォール メディエーションでは、広告配信機会が発生すると、広告 SDK がバックエンド サーバーにリクエストを送信します。サーバーは落札された広告クリエイティブでリクエストに応答するのではなく、過去の eCPM で順序付けられた広告ネットワークのリストを含むメディエーション チェーンを返します。

図 1. ウォーターフォール メディエーション モデル。

従来のウォーターフォール モデルでは、広告 SDK はメディエーション チェーンで指定された順序で各広告ネットワーク（または独自のオークション SDK）を呼び出します。広告ネットワークが広告リクエストを満たせる場合は、その広告ネットワークで広告が表示されます。そうでない場合、リクエストはチェーン内の次のネットワークに送られます。このプロセスは、リクエストが満たされるか、チェーン全部の試行が完了するまで繰り返されます。

多くの場合、ウォーターフォール型メディエーションは、ファーストパーティの広告デマンドソースからの eCPM の再評価に基づいて、メディエーション チェーンを定期的に並べ替えることで最適化されます。

プログラマティック メディエーション

プログラマティック メディエーション（「ヘッダー入札」とも呼ばれます）は、広告リクエストを配信できる広告ネットワークを判断するための方法として、過去の eCPM の代わりに使用する方法です。プログラマティック メディエーションでは、プロバイダがライブ入札単価を使用して落札広告を特定します。

図 2: プログラマティック メディエーション モデル

ハイブリッド メディエーション

一部のプログラマティック メディエーション ソリューションでは、ウォーターフォールと入札のハイブリッド モードで広告ネットワークを組み合わせて、広告をより詳細に管理しています。また、ライブ eCPM を利用して広告ネットワークへの入札の収益を最大限に高められるというメリットもあります。

ハイブリッド メディエーション モデルでは、ウォーターフォールとリアルタイム ビッダーの要素を組み合わせることにより、広告ネットワークとメディエーションのプロバイダがアプリ デベロッパーの柔軟性を向上させることができます。ハイブリッド モデルでは、アプリ デベロッパーは過去の eCPM に基づいて広告ネットワークを設定できます。これにより、参加ネットワークによるリアルタイム ビッダーの前に広告を表示し、広告配信機会を満たせます。

Protected Audience のウォーターフォール メディエーション

Android 版 Protected Audience API では、メディエーション グラフの個々のノードごとに複数のオークションを実施することにより、ウォーターフォール メディエーションに対応しています。オークションでの落札がなかった場合は、次のネットワーク オークション ノードが呼び出されます。これはチェーン全体を使い切るまで繰り返されます。ウォーターフォール メディエーションのプロセスは、次のとおりです。

1. メディエーション SDK は、コンテキスト広告サーバー エンドポイントからメディエーション チェーンを取得します。これにより、コンテキスト広告またはメディエーション チェーンが返されます。
2. 広告サーバーのエンドポイントがメディエーション チェーンを返す場合、メディエーション SDK はチェーン内の各項目を順番に処理し、参加している広告ネットワークの SDK を呼び出してコンテキスト広告とリマーケティング広告を選択します。チェーン内の各項目は、特定のインプレッション数、クリック数、広告時間について、特定の価格で広告スペースを購入する広告ネットワークのリクエストを表します。
3. チェーン内のどの広告申込情報も落札広告を選択しなかった場合、メディエーション SDK は、リマーケティング広告とコンテキスト広告の両方を考慮に入れた Protected Audience 広告を選択することにより、独自の広告ネットワークの広告を表示することがあります。

図 3. Protected Audience API を使ったウォーターフォール メディエーション

上の図は、メディエーション SDK で実装可能で、ファースト パーティ広告ネットワークによる最適化はできない、ウォーターフォール メディエーションのアルゴリズムの例を示しています。Protected Audience API では、広告選択ワークフローのチェーンを可能にし、落札インプレッション数を報告することで、ファースト パーティ広告ネットワークの最適化をサポートします。

AdSelection の結果

selectAds() の戻り値の型は AdSelectionOutcome オブジェクトです。 AdSelectionOutcome には、落札された広告のレンダリング URI と AdSelectionId: 落札者を識別する opaque 型の整数 関連付けられます

AdSelectionOutcome {
  Uri renderUri;
  Long AdSelectionId;
}

AdSelectionId は AdSelectionOutcome へのポインタとして機能します。現在、AdSelectionId は、reportResult() メソッドに ReportImpressionInput パラメータとして渡され、reportWin() メソッドと reportResult() メソッドが呼び出される広告を正しく識別できるようにします。

チェーン広告選択の提案

selectAds() を AdSelectionFromOutcomesConfig でオーバーロードすることをおすすめします。

val config = AdSelectionFromOutcomesConfig.Builder()
        .setSeller(seller)
        .setAdSelectionIds(listOf(outcome1pAdSelectionId))
        .setSelectionSignals({"bid_floor": bidFloorOfNextNetworkInline})
        .setSelectionLogicUri(selectionLogicUri)
        .build()
adSelectionClient.selectAds(config)

これにより、メディエーション SDK は落札広告の入札単価を、インライン内の次のネットワークの入札下限と比較できます。

例 1:

例 2:

落札インプレッションを報告する

selectAds(AdSelectionFromOutcomes) に落札者がいる場合は、その広告が落札します。 使用します。次に、selectAds(AdSelectionFromOutcomes) の落札広告の広告選択 ID と対応する AdSelectionConfig を指定して reportImpression が呼び出されます。

いずれかのネットワークの selectAds(AdSelectionConfig) から落札者が返された場合、その呼び出しの広告選択 ID と設定を使用して reportImpression が呼び出されます。

ウォーターフォール メディエーションを実行する

ウォーターフォール メディエーションのプロセスの実行順序は次のとおりです。

1. 自社の広告選択を実行します。
2. メディエーション チェーンを反復処理します。サードパーティ ネットワークごとに次の操作を行います。
   1. ファーストパーティの outcomeId とサードパーティの SDK の入札単価の下限を含む AdSelectionFromOutcomeConfig を作成します。
   2. 前のステップの config を使用して selectAds() を呼び出します。
   3. 結果が空でない場合は、広告を返します。
   4. 現在の SDK ネットワーク アダプターの selectAds() メソッドを呼び出します。結果が空でない場合は、広告を返します。
3. チェーンで落札広告が見つからなかった場合は、ファースト パーティ広告を返します。

ベスト プラクティス

ファーストパーティの最適化を行う前にコンテキスト オークションを実施する

リマーケティングの需要が高いと、メディエーション チェーンでの落札結果につながる高い入札額が見込めます。切り捨てとは、リマーケティング オーディエンス リストを絞り込むことで、ファースト パーティの最適化を有効にするためによく使用される手法です。

Protected Audience API のリマーケティングの需要は、Protected Audience オークションでのクライアントサイドでのみ利用できます。その結果、サーバーサイトでファースト パーティの最適化を有効にすることが困難になる場合があります。ファースト パーティの最適化の問題を軽減するには、まずコンテキスト オークションを実行し、次にこのページの前半で説明したように、落札広告の結果に基づいてファーストパーティの最適化を実行します。

デバイス上のメディエーション チェーンを小さくする

最適なパフォーマンスを得るには、デバイス上のメディエーション チェーンを小さくする必要があります。デバイス上での実行に関するコンピューティング コストは、メディエーション チェーンの一部として評価されたオークションの数に比例する場合があります。つまり、ノード数が増えると、計算サイクルの要件が増え、レイテンシが増加します。ノードをデバイス上のメディエーション評価に渡す際には、収益に対するレイテンシの影響を考慮してください。

その他の考慮事項

Protected Audience API では現在、複数の広告スロットのメディエーションを行うための包括的なソリューションは提供していません。各広告スロットは個別に処理する必要があります。

Protected Audience メディエーション API は、ウォーターフォール メディエーションと制限付きプログラマティック メディエーションをサポートしています。他のプログラマティック メディエーションのユースケースに関する詳細は、今後お知らせします。

Protected Audience 広告の選択は、コンテキスト広告の取得後に実行されるため、Protected Audience API を呼び出すと、広告リクエストのエンドツーエンドのレイテンシに影響する可能性があります。