FLEDGE: 統合ガイド

FLEDGE の実装には通常、広告主アプリ、パブリッシャー アプリ、販売者、購入者の間での統合を伴います。このガイドの対象は、カスタム オーディエンスの管理とオークションの実施を計画しているパートナーです。これには、購入者と販売者の両方として運営される広告テクノロジー ネットワークも含まれます。広告キャンペーンの目的はさまざまであるため、FLEDGE のすべての機能がすべてのユースケースで使用されるわけではありません。このガイドでは、できる限り特殊なケースのサポートに必要な手順を取り上げます。

パートナーは、FLEDGE を大規模な本番環境にデプロイする準備として、他の当事者との統合ポイントをモックすることでテストを開始できます。このガイドでは、統合の計画に役立つように、FLEDGE を Android アプリと統合する方法の全体像を提示します。これには、Android 版プライバシー サンドボックス デベロッパー プレビューの、現段階では実装されていない機能が含まれていることがあります。その場合は、タイムラインのガイダンスが提供されます。

FLEDGE の統合ワークフローは、さまざまなタイプの広告テクノロジー パートナーが主導する、次の 4 つの重要なステップから構成されます。

  1. 購入者がカスタム オーディエンスを作成します。
  2. 広告選択プロセスで落札広告が選択されます。
    1. 販売者アプリで広告選択が開始されます。
    2. 広告サービスがバイサイドのフィルタリングと入札コードを実行します。
    3. 広告サービスがセルサイドの決定コードを実行します。
  3. 落札広告が販売者アプリに表示されます。
  4. 広告インプレッションのレポートが購入者と販売者の両方に公開されます。

以下の図は、上記のステップを表しています。

広告選択のワークフローを表す図。
図 1: FLEDGE のカスタム オーディエンス管理と広告選択のワークフロー

用語

  • 広告主: 広告枠の購入という手段を通じてユーザーを引き付ける企業。
  • パブリッシャー: 空いている広告枠をコンテンツとともに販売する企業。
  • 購入者: 広告主による広告枠の購入を手助けする広告テクノロジー企業。
  • 販売者: パブリッシャーによる広告枠の販売を手助けする広告テクノロジー企業。
  • ネットワーク: 購入者と販売者を兼ねる広告テクノロジー企業。
  • 所有および運営: パブリッシャー、販売者、購入者を兼ねる企業。
  • 統合パートナー: FLEDGE との統合のために互いに連携する必要がある上述の企業。

前提条件、統合パートナーの関与、セットアップ

このセクションでは、FLEDGE の仕組み、FLEDGE の統合の始め方、および FLEDGE の実装における統合パートナーとの連携方法を理解するための一連の初期作業について概説します。これらの作業は並行して行うことができます。

FLEDGE 機能のロールアウト ガイドを示す図。
図 2: FLEDGE 機能のロールアウト ガイド

FLEDGE の理解を深める

最初のステップは、FLEDGE の API とサービスについてよく理解することです。

  1. まずは、設計案を読み、FLEDGE API とその機能をよく理解します。
  2. デベロッパー ガイドを読み、ユースケースに必要なコードや API 呼び出しを組み込む方法、FLEDGE との統合に必要なサービスを確認します。
  3. FLEDGE の API、サービス、ドキュメントの設計や実装についてのフィードバックを送信します。
  4. 登録して最新情報を受け取ることで、プライバシー サンドボックスの最新機能に関する情報を入手します。

サンプルアプリのセットアップとテスト

前述のように FLEDGE の基本に関する理解を深めたら、サンプルアプリをセットアップしてテストしてください。

  1. 統合を始める準備ができたら、最新のプライバシー サンドボックス デベロッパー プレビューを使って開発環境をセットアップします。
  2. 必要なサーバー エンドポイントをセットアップします。好みの API テスト ソリューションでサンプルのモックを使い、このプロセスを立ち上げます。
  3. サンプルアプリのコードをフォークして実行し、カスタム オーディエンスの管理、広告選択のワークフロー、およびインプレッションのレポート生成について理解を深めます。

統合パートナーの関与

当事者間で受け渡しするシグナルの形態など、Android 版 FLEDGE のテストと導入について協議するため、統合パートナーとの話し合いの場を設けます。購入者に関しては、オーディエンスをどう定義するかも含めて、カスタム オーディエンスを作成して参加するための戦略も議論する必要があります。統合パートナーと協力して、初期テストから導入までの統合のスケジュール、および各当事者が設計において担当する領域を定義します。

ベータ版のセットアップ（第 4 四半期に利用可能）

Android 版プライバシー サンドボックスに組織を登録します。登録は、広告テクノロジー デベロッパーがプライバシー サンドボックスのポリシーに従って作業するために必要となります。また、登録することで、広告テクノロジー デベロッパーが複数の SDK やドメインで利用可能な ID を定義できるようになります。

アーキテクチャに関する注意事項

購入者と販売者の両方には、FLEDGE によりデバイス上で広告オークションを実施する機能が導入されます。設計にあたっては、統合パートナーとともに、以下の重要な要素を考慮してください。

オーディエンスとリマーケティング広告はデバイスに保存される

現在のように広告をすべてサーバーに保存するのではなく、オーディエンス情報とリマーケティング広告はデバイスに保存されます。ターゲティングに関してデバイス内データに依存しないコンテキスト広告は、引き続きサーバーに残ります。広告テクノロジー プラットフォームは、サーバーやデバイスの間に広まっている広告デマンドを考慮して拡張する必要があります。

入札とオークションの処理はデバイス上で行われる

広告テクノロジー プラットフォームでは、サーバーでのオークションの実施に加え、デバイスに保存されている広告デマンドの価格設定とランク付けを行えるようにもなりました。

一般的なアプローチは、広告テクノロジーが現在と同じようにコンテキスト広告のオークションを実施するというものです。オークションの完了後、販売者はデバイス上でオークションを実施して、デバイスに保存されているリマーケティングのデマンドを評価できます。以上の処理はデバイス上で行われるため、さまざまなリマーケティングのユースケースにおいて、オークションが各統合パートナーの設計どおりにエンドツーエンドで実施されるよう、既存の制限を念頭に置くことが重要です。

データ戦略

広告テクノロジー プラットフォームでは、オークションで使用されるデータタイプを考慮する必要があります。現在、この情報はさまざまなソースから収集され、サーバーに一元化されています。FLEDGE のオークションでは、このデータを渡すためのさまざまな方法が用意されています。たとえば、予算残高などのリアルタイムのシグナルは信頼できるシグナルとして Key-Value サービスから取得されますが、時刻などのコンテキスト シグナルはオークションの実施時に販売者から送信されます。これらのシグナルについては、このガイドの関連するセクションでさらに詳しく説明しています。

ソリューションを構築する

FLEDGE を使ったオークションの実施には、いくつかの重要なステージがあります。購入者は、オーディエンスを作成して、入札データを供給し、広告をオーディエンスにターゲット設定して、入札をセットアップする必要があります。販売者は、オークションを設定してトリガーし、広告候補のスコアリングを行って、落札者を選択する必要があります。オークションを正しく実施するには、一部のステージで両方の当事者が協働する必要があります。以下のセクションでは、各ステージを詳しく説明し、どの当事者が実装を担当するかを明確に示します。

購入者: オーディエンスの作成

購入者は通常、カスタム オーディエンスを管理します。カスタム オーディエンスはデバイス上で管理されるため、カスタム オーディエンスを管理するための API は、デバイス上で呼び出されるように設計されています。

広告主アプリ内に独自の SDK がある場合、このコードは joinCustomAudience() を直接使って実装できます。

デバイスに独自の SDK コードがない場合、SDK プロバイダでもある既存の統合パートナーと提携することもできます。このようなパートナーを見つけて連携しながら、カスタム オーディエンスを定義して管理するための契約とフローを定義します。このガイドでは、どちらの方法を採用する場合でも「購入者」という用語を使用します。例として次のようなアプローチが挙げられます。

  • 購入者として、広告主にオーディエンスを定義してもらいます。デバイス上の統合パートナーの SDK は、アプリイベントを購入者に送信できます。既定の条件を満たしたら、購入者が SDK にメッセージを送信し、購入者に代わってクライアント上でカスタム オーディエンスに参加します。
  • SDK はオーディエンスを直接所有できます。広告主は、SDK プロバイダと連携してオーディエンスを定義します。SDK はアプリイベントを監視して適切なタイミングでオーディエンスに参加し、ユーザーがオーディエンスに参加したことを購入者に通知します。

リマーケティング キャンペーンのプロトタイプ: カスタム オーディエンスの設計

カスタム オーディエンスとは、パーソナライズド広告を配信できる、関心が似通ったユーザーのグループです。購入者は、広告主がユーザーの行動に基づいてアプリ内にカスタム オーディエンスを作成することを支援できます。

FLEDGE は、広告主が定義した特定のカスタム ユーザー エンゲージメントに対応するカスタム オーディエンスのコンテナを作ります。これには、そのオーディエンスに表示できる広告候補の集まりや、オークションの際に広告のフィルタや価格設定に使用できるカスタムの入札ロジックやデータの集まりが含まれます。

セットアップとプロトタイピング

設計に関する注意事項

購入者は、カスタム オーディエンスを設定することで、さまざまなユースケースに対応できます。これには、このオーディエンスをターゲットとする広告またはキャンペーンの種類に応じた入札ロジックの定義や広告候補リストの定義などの注意事項が含まれます。このセクションでは、カスタム オーディエンスの主要なフィールドに値を設定したり、それを使用したりする場合の設計上の注意事項について説明します。

入札ロジック URL

オークションはデバイス上で行われるため、購入者は、入札ロジックを JavaScript として返すエンドポイントをデプロイする必要があります。デベロッパー ガイドに必要なメソッド シグネチャを記載しています。入札ロジックからは、オークション中のユーザーに関する特定のシグナルにアクセスできます（以降のセクションを参照）。入札ロジックとユーザー シグナルのセットアップについては、この記事の後半で説明します。

ユーザー入札シグナル

購入者は、UserBiddingSignals を使用して、広告主または購入者自身が持っているユーザーについての情報を、デバイスでの今後のオークションに渡すことができます。これには、次のような情報が含まれます。

  • ユーザーが追加されているその他のオーディエンス
  • 広告主がユーザーに関して保有しているファーストパーティ インサイト

これらのシグナルはオークション中に利用できるため、購入者はオークション中に次のようなカスタム入札操作を実行できます。

  • 入札シグナルに基づいて入札単価の上げ下げをする
  • オークションから特定の広告を除外する

信頼できる入札データ

FLEDGE の実装の一環として、購入者は、オークション中に Key-Value サービスから取得するリアルタイムの情報にアクセスできます。一時的なメカニズムとして、購入者と販売者は、自社で運用するサービスを含め、どのサーバーからも入札シグナルを取得できます。典型的な例が、広告の残り予算を調べることです。開発時には、このサービスをモック化できるので、このモック エンドポイントを相手として開発できます。セットアップ手順については、GitHub のサンプルアプリ リポジトリにある FledgeServerSpec ディレクトリをご覧ください。

TrustedBiddingData フィールドは、URL とキーのセットで構成されます。使用するキーの構造を設計する際の注意事項は次のとおりです。

  • 単純なアプローチは、作成するオーディエンスと 1 対 1 でマッピングするキーを含めることです。そうすることで、Key-Value サービスに、オーディエンスに関連付けられているすべての関連情報を含めることができます。
  • 予算と広告のステータスは、リアルタイムで考慮することが重要です。
  • オークションで広告の価格決定に使用できる最高入札単価などのシグナル。この情報は AdData リストに広告と一緒に含めることができますが、Key-Value サービスに保存すると、必要に応じてより簡単に更新できます。

AdData リスト

リマーケティング キャンペーンを作る際、広告主は通常、ユーザーによるアプリでの過去のエンゲージメントに基づいてさまざまな割引を宣伝するなど、さまざまな種類の広告をユーザーに表示することを検討します。カスタム オーディエンスには、広告候補を保持する AdData リストが含まれます。

各広告に含める情報の量は、購入者が決められます。次の点に注意してください。

  • AdData リストの更新方法には、次の 2 つがあります。
    • アプリにフォアグラウンドで見える状態にあるアクティビティがある場合、アプリがユーザーをカスタム オーディエンスに加えるときに、このリストを開始できます。
    • 毎日の更新中にバックグラウンドで取得が開始される場合、デバイスは、joinCustomAudience 呼び出しに含まれる daily_update_url にリクエストを送信し、更新された AdData リストを含むレスポンスを受け取ろうとします。
  • 広告に関する追加情報は、オークションの際にリクエストできます。オークション前に、デバイスが joinCustomAudience の trustedBiddingData フィールドで指定された購入者の Key-Value サービスにリクエストを送信します。Key-Value サービスは、購入者の FLEDGE の実装の一部である新しいサービスです。このサービスの詳細については、以下で説明します。
  • 広告にクリエイティブ ID を含めると、特定のクリエイティブで特定のアクションを行えるようになります。たとえば、広告主が特定のクリエイティブを一時停止し、そのクリエイティブ ID をリアルタイムの Key-Value サービスから取得して AdData リスト内の広告と照合できます。

AdData には render_url を含める必要があります。落札されたリマーケティング広告のレンダリング URL は、広告のレンダリングに使用されます。次の点に注意してください。

  • レンダリング URL には k-匿名性のしきい値があるため、範囲の狭いパラメータを含めないでください。この k-匿名性のしきい値に関する詳しい情報は、後日公開されます。
  • この URL には、広告のレンダリングに必要な情報がすべて入っている必要があります。たとえば、特定の商品を表示する場合は、商品 ID をパラメータとしてこの URL に埋め込みます。

プロトタイピング中の場合、唯一の必須フィールドは、広告のレンダリング アセットを指す renderUri です。ソリューションの構築中は、AdData のメタデータ フィールドを無視できます。ソリューションを本番環境に移行する場合は、入札単価の生成中に入札単価の調整のために使用できるため、自分にとってどのメタデータが重要かを考慮する必要があります。

有効化時間と有効期限

有効化時間と有効期限のフィールドを使用すると、カスタム オーディエンスを事前に指定した時間内にのみオークションの対象にするというユースケースに対応できます。有効化時間を遅らせることができる時間と、有効化から有効期限までの時間の差には、一定の制限があります。たとえば、次のような場合があります。

  • 休眠ユーザー（例: 過去 7 日間に広告主のアプリを利用したことがないユーザー）
    • ユーザーがアプリを開くたびに、購入者は joinCustomAudience を呼び出して、activation_time を先の 7 日後のタイムスタンプになるように設定できます。
    • ユーザーがアプリを最後に起動してから 7 日間が経過すると、オーディエンスは入札の対象となります。
  • 季節限定オーディエンス（近い将来の特定の期間のみ有効なオーディエンス）
    • 購入者は、（近い）将来の事前に定義した期間内にのみ入札の対象となるカスタム オーディエンスをあらかじめ定義しておくことができます。
    • たとえば、広告主が 2022 年に米国で夏の終わりのキャンペーンを実施する場合、購入者は joinCustomAudience を呼び出し、activation_time が 2022 年 8 月 20 日土曜日になるように設定できます。キャンペーンを 1 週間のみ実施する場合、購入者は有効期限を 2022 年 8 月 27 日に設定できます。その後、カスタム オーディエンスは広告選択中にプラットフォームによって除外され、最終的にガベージ コレクションで回収されます。

購入者と販売者: 広告選択

広告選択には、購入者と販売者の連携が必要になります。これは、次の 4 つのステップからなるプロセスと考えられます。

  1. 販売者がメディエーション戦略を定義します。
  2. 販売者がオークションを設定し、広告選択を開始します。
  3. 販売者が設定したオークションに購入者が招待されます。購入者の入札ロジックが実行され、広告候補と入札単価が選択されます。
  4. 販売者の決定ロジックが実行されて、広告候補のスコアが決まり、落札広告が選択されます。

開発の便宜上、入札やスコアリングのロジックなど、購入者と販売者のサービス レスポンスをモック化することができます。そうすることで、ユースケースに関連する開発に集中できます。モックのエンドポイントをセットアップする手順については、GitHub の FledgeServerSpec ディレクトリをご覧ください。また、JavaScript のリモート取得をオーバーライドする方法については、デベロッパー ガイドをご覧ください。

販売者: メディエーション戦略の定義

FLEDGE は、ウォーターフォール メディエーションに対応することを目指しています。この分野は現在開発中であり、利用可能になったときに詳しい情報を提供いたします。当面の間は、FLEDGE のウォーターフォール メディエーションの設計案を参照してください。

販売者: オークションの設定

販売者はオークションの設定を行い、広告選択プロセスに情報を提供する必要があります。販売者は、すべてまたは選択した当事者のみに情報を提供することができます。ここでの情報には、自分が持っている情報や購入者に代わって保持している情報などが含まれます。

セットアップとプロトタイピング

  • 販売者は、AdSelectionConfig オブジェクトをセットアップし、AdSelection API を使用することで、オークションを設定し、開始できます。そのオークションを、selectAds() を呼び出してトリガーします。
  • 実装と API の使用方法については、デベロッパー ガイドをご覧ください。

設計に関する注意事項

このセクションでは、広告選択設定の主要なフィールドに値を設定したり、それを使用したりする場合の設計上の注意事項について説明します。

  • プライベート実行環境には、デバイス上のカスタム オーディエンス広告しか含まれていないため、事前にコンテキスト広告のリクエストを発行することで、追加需要を考慮できます。

  • 広告選択のワークフローを開始する前に、広告リクエストを行って購入者から情報を収集します。情報を取得したら、その情報に基づいて広告選択を設定します。

  • デバイス上で多数の購入者がカスタム オーディエンスを作成している場合があるため、販売者はカスタム オーディエンス購入者フィールドを使用して、このプロセスに含める購入者を指定する必要があります。このリストはさまざまな方法で作成できますが、以下にいくつか例を示します。

    • 販売者がこのプロセスに常に参加させたい購入者の静的リスト。
    • 広告レスポンスへの参加を希望している購入者のリスト。この方法は、販売者がアド エクスチェンジを利用しているが、すべての購入者について十分な知識がない場合に有用です。

  • 販売者がこのプロセスに情報を渡す方法には次のものがあります。

    • 広告選択シグナル フィールドは、プライベート ランタイムでオークションに参加するすべての購入者と販売者が利用できます。広告サイズや広告フォーマットなど、広告配信機会に関する情報を提供するために使用します。
    • 購入者ごとのシグナル フィールドは、特定の購入者に転送され、その購入者の入札プロセスで使用されます。この情報は購入者が提供します。販売者は、この情報を広告選択の際に利用するためにデバイス上で取得する方法を検討する必要があります。
    • 販売者シグナル フィールドが、このプロセスに販売者が情報を渡す最後の方法です。販売者は、広告のスコアリングやフィルタリング（ブランド保護の確認など）を行うときに、これらのシグナルを使用します。

購入者: 広告スロットの入札

セットアップとプロトタイピング

  • 購入者は、CustomAudience の構築時に設定された biddingLogicUrl パラメータから得られる generateBid() JavaScript 関数に入札ロジックを追加できます。提供された仕様でモックのサービスをセットアップすることも可能ですし、実際のサーバーにこのエンドポイントを実装することもできます。
  • 実装と API の使用方法については、デベロッパー ガイドをご覧ください。

設計に関する注意事項

  • 入札ロジックはデバイス上で実行され、オークションで使用されるシグナルの一部はリアルタイムでクエリされます。制約については、制限事項をご覧ください。
  • 一部の広告ユースケースでは、販売者と協力して、複数の広告候補とその入札単価をデバイス上で検討することが重要です。

入札ロジックの設計

購入者の入札ロジックは、JavaScript で実装する必要があり、デバイス上で実行されます。デベロッパー ガイドに、要求されるシグネチャと、オークション時に渡されるさまざまなパラメータの詳細が記載されています。また、デバイス上の入札ロジックは、generateBid() 関数にパラメータとして渡された追加情報にアクセスできます。

入札データの提供

Key-Value サービスによるリアルタイムの入札シグナル

購入者は、自身の Key-Value サービスからオークション時にリアルタイム シグナルを取得できます。このサービスの初期実装は、一般公開されているプライバシー サンドボックス リポジトリにあります。また、独自のサービスを作成することもできます。このサービスの URL はカスタム オーディエンスの trustedBiddingUrl として指定され、プラットフォームはこのデータを取得して trusted_bidding_signals parameter で generateBid 関数で利用できるようにします。キー構造は独自のものを作る必要があります。

コンテキスト シグナルとユーザー シグナル

generateBid 関数は、デバイス上でオークションを実施する際に、追加のユーザー シグナルにアクセスできます。これらのシグナルは、contextual_signals フィールドと per_buyer_signals フィールドで渡されます。これらのフィールドはすべて JSON オブジェクトであり、その形式は購入者と販売者が定義する必要があります。

contextual_signals フィールドには、ユーザーとの関連性が高い可能性のある情報が含まれます。これらのシグナルを保持するオブジェクトは、FLEDGE 自体によって作成され、入札ロジックを通じて渡されます。これは現在、空のオブジェクトとして渡されています。ユーザーに関するコンテキスト シグナルでご自身のユースケースに適していると思われるものがある場合は、検討材料としてフィードバックをお送りください。

per_buyer_signals フィールドは、入札ロジックで使用できるようになります。販売者は、これらの値を、オークション設定の作成時に設定します。購入者と販売者は協力して、このデータがデバイス上に保持され、入札ロジックに渡されるようにする必要があります。このフィールドの使用例としては次のものがあります。

  • ブランド保護のためのフィルタ。販売者は、広告をリクエストしているアプリの分類情報を購入者に知らせることができ、購入者は、この情報を使用して特定の広告を除外できます。
  • コンテキスト情報を考慮する ML モデルにエンベディングを送信する。

販売者: 落札広告のスコアリングと選択

セットアップとプロトタイピング

  • 販売者は、AdSelectionConfig の作成時に設定された scoringLogicUrl パラメータから提供される scoreAd() JavaScript 関数にスコアリング ロジックを追加できます。提供された仕様でモックのサービスをセットアップすることも可能ですし、実際のサーバーにこのエンドポイントを実装することもできます。
  • 実装と API の使用方法については、デベロッパー ガイドをご覧ください。

スコアリング ロジックの設計

販売者は、デバイス上で実行されるスコアリング ロジックを JavaScript で実装します。デベロッパー ガイドに、要求されるシグネチャと、オークション時に渡されるさまざまなパラメータの詳細が記載されています。また、デバイス上のスコアリング ロジックは、scoreAd 関数にパラメータとして渡された追加情報にアクセスできます。

スコアリング データの提供

Key-Value サービスによるリアルタイムのスコアリング シグナル

販売者は、自身の Key-Value サービスからオークション時にリアルタイム シグナルを取得できます。このサービスの初期実装は、一般公開されているプライバシー サンドボックス リポジトリにあります。このサービスの URL はオークション設定の trustedScoringUri として指定され、プラットフォームはこのデータを取得して trusted_scoring_signals パラメータで scoreAd 関数で利用できるようにします。キー構造は独自のものを作る必要があります。

コンテキスト シグナルとユーザー シグナル

scoreAd 関数は、デバイス上でオークションを実施する際に、追加のユーザー シグナルにアクセスできます。これらのシグナルは、contextual_signal フィールドを介してスコアリング関数に渡されます。このフィールドには、購入者と販売者によって形式を定義された JSON オブジェクトが格納されます。

contextual_signal フィールドには、ユーザーとの関連性が高い可能性のあるコンテキスト情報が含まれます。これらのシグナルを保持するオブジェクトは、FLEDGE 自体によって作成され、スコアリング ロジックを通じて渡されます。これは現在、空のオブジェクトとして渡されています。ユーザーに関するシグナルでご自身のユースケースに適していると思われるものがある場合は、検討材料としてフィードバックをお送りください。

販売者: 広告のレンダリング

販売者は、落札広告をレンダリングする必要があります。落札広告のレンダリングの仕組みについて詳しくは、設計案をご覧ください。この領域は、まだ設計中です。

インプレッション結果のレポート

セットアップとプロトタイピング

  • 購入者と販売者は、それぞれ biddingLogicUrl パラメータまたは scoringLogicUrl パラメータから提供される reportWin() JavaScript 関数にレポート ロジックを追加できます。提供された仕様でモックのサービスをセットアップすることも可能ですし、実際のサーバーにこのエンドポイントを実装することもできます。
  • 実装と API の使用方法については、デベロッパー ガイドをご覧ください。

設計に関する注意事項

購入者と販売者は、設定済みのエンドポイントから返される JavaScript コードに reportWin 関数を実装する必要があります。このメソッドによってサーバーにデータを返すことができます。

プライバシー サンドボックスには、イベントレベル レポートと集計レポートを管理するための Attribution Reporting API も用意されています。詳しくは、統合ガイドをご覧ください。