Android 版プライバシー サンドボックス ベータ版がリリースされました。ご利用方法についてご確認のうえ、引き続きフィードバックをお寄せください。

FLEDGE を使用してカスタム オーディエンス ターゲティングをサポートする

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

フィードバックを送信

モバイル広告で一般に広告主が期待するのは、ユーザーが過去に広告主のアプリで行った操作に基づいて、興味を持ちそうなユーザーに広告が配信されることです。たとえば、SportingGoodsApp のデベロッパーは、ショッピング カートにアイテムが残っているユーザーに広告を表示して、購入手続きの完了を促そうとします。このような考え方は、業界ではよく「リマーケティング」、「カスタム オーディエンス ターゲティング」などの用語で表現されます。

現在のところ、このようなユースケースは、広告の表示方法に関するコンテキスト情報（アプリ名など）やオーディエンス リストなどの個人情報を、広告テクノロジー プラットフォームと共有して実装することが一般的です。このような情報を使用することで、広告主は自身のサーバー上で関連性の高い広告を選択できます。

Android 版 FLEDGE には次の API が含まれており、広告テクノロジー プラットフォームと広告主が、アプリ間の識別子とユーザーのアプリ操作情報の第三者との共有を制限して、インタラクション ベースの一般的なユースケースをサポートします。

  1. Custom Audience API: 広告主が指定する共通の意図を持ったオーディエンスを表す「カスタム オーディエンス」の抽象化を主な役割としています。オーディエンス情報はデバイス上に保存され、オーディエンスに関わる広告候補や、入札シグナルなどの任意のメタデータと関連付けることができます。この情報は、広告主の入札、広告のフィルタリング、レンダリングに関する通知に使用できます。
  2. Ad Selection API: 広告テクノロジー プラットフォームのワークフローを調整するフレームワークを提供します。このフレームワークでは、ローカルに保存されている広告候補の検討や、広告テクノロジー プラットフォームがデバイスに返す広告候補への追加処理によって、デバイス上のシグナルを活用した広告の「落札」判定を行います。
図 1. Android 版プライバシー サンドボックスにおけるカスタム オーディエンス管理と広告選択のワークフローを示すフローチャート。

統合作業の概要は次のとおりです。

  1. SportingGoodsApp は、ユーザーが 2 日以内に購入処理を完了しなかった場合、カートに残っている商品の購入を促します。SportingGoodsApp が、Custom Audience API を使用して、ユーザーを「商品がカートに入っている」オーディエンス リストに追加します。プラットフォームはこのオーディエンス リストをデバイス上で管理、保存し、第三者との共有を制限します。SportingGoodsApp は広告テクノロジー プラットフォームと連携して、オーディエンス リストのユーザーに広告を表示します。広告テクノロジー プラットフォームは、オーディエンス リストのメタデータを管理し、広告候補を提供します。これは広告選択ワークフローでの検討に使用できます。プラットフォームは、バックグラウンドでアップデートされたオーディエンス ベース広告を定期的に取得するように構成できます。これによりオーディエンス ベースの広告候補リストが最新の状態に保たれ、広告を出す機会が訪れた際に、第三者広告サーバーに送信されるリクエスト（コンテンツ ターゲット広告リクエスト）と相関しない状態に保たれます。

  2. ユーザーが FrisbeeGame をプレイすると、同じデバイス上にある SportingGoodsApp のショッピング カートに残るアイテムの購入処理を促す広告が表示される場合があります。これを実現するには、FrisbeeGame（統合広告 SDK を使用）で Ad Selection API を呼び出し、ユーザーが属している可能性のあるオーディエンス リスト（この例では SportingGoodsApp が作成するカスタムの「商品がカートに入っている」オーディエンス リスト）に基づいて落札広告を選択します。広告選択ワークフローは、カスタム オーディエンスや他のデバイス上のシグナルに関連付けられたデバイス上の広告に加え、広告テクノロジー プラットフォームのサーバーから取得した広告を考慮するように設定できます。このワークフローは、適切な広告掲載の目標を達成するために、カスタム入札やスコアリング ロジックを使用して、広告テクノロジー プラットフォームと広告 SDK によってカスタマイズすることもできます。このアプローチでは、ユーザーの興味またはアプリ操作データを広告の選択に反映させ、第三者とのデータの共有を制限できます。

  3. 広告配信アプリまたは広告テクノロジー プラットフォームの SDK が、選択された広告をレンダリングします。

  4. プラットフォームにより、インプレッションと広告選択結果のレポートが容易になります。このレポート機能は Attribution Reporting API を補完するものです。広告テクノロジー プラットフォームはレポートのニーズに応じてカスタマイズできます。

Android API 用 FLEDGE にアクセスする

Android API 用 FLEDGE にアクセスするには、広告テクノロジー プラットフォームの登録が必要です。詳しくは、プライバシー サンドボックス アカウントの登録をご覧ください。

カスタム オーディエンス管理

カスタム オーディエンス

カスタム オーディエンスは、共通の意図や興味を持つユーザーのグループを表します。アプリや SDK はカスタム オーディエンスを使用して、特定のオーディエンス（「ショッピング カートにアイテムが残っている」、ゲームの「初級レベルをクリアした」など）を示すことができます。プラットフォームは、デバイス上でオーディエンス情報をローカルに維持し、保存します。ユーザーがどのカスタム オーディエンスに属するかは表示されません。カスタム オーディエンスは、Chrome の インタレスト グループでの FLEDGE とは異なり、ウェブやアプリ間で共有することはできません。これにより、ユーザー情報の共有を制限できます。

広告主アプリまたは統合 SDK は、アプリでのユーザー エンゲージメントなどに基づいてカスタム オーディエンスへの参加、またはカスタム オーディエンスからの脱退を選択できます。

カスタム オーディエンス メタデータ

カスタム オーディエンスには次のメタデータが含まれます。

  • オーナー: オーナーアプリのパッケージ名。暗黙的に、呼び出し元アプリのパッケージ名に設定されます。
  • 購入者: このカスタム オーディエンスの広告を管理する購入者の広告ネットワーク。また購入者は、カスタム オーディエンスにアクセスし、関連する広告情報を取得する当事者を表します。購入者は eTLD+1 形式で指定されます。
  • 名前: カスタム オーディエンスの任意の名前または識別子（「ショッピング カートを放棄した」ユーザーなど）。この属性は、たとえば、広告主の広告キャンペーンにおけるターゲティング条件の一つとして、または入札コードを取得するための URL のクエリ文字列として使用できます。
  • 有効化時刻と有効期限: これらのフィールドでは、カスタム オーディエンスが有効になる期間を定義します。プラットフォームはこの情報を使用して、カスタム オーディエンスのメンバーシップを取り消します。有効期限は、カスタム オーディエンスの存続期間を制限する最大期間を超えることはできません。
  • 日次更新 URL: 「ユーザー入札シグナル」フィールドで定義された広告候補またはその他のメタデータを、プラットフォームが定期的に取得するために使用する URL。詳細については、カスタム オーディエンスの広告候補を取得する方法についてのセクションをご覧ください。
  • ユーザー入札シグナル: リマーケティング広告の入札のための、広告テクノロジー プラットフォーム固有のシグナル。シグナルの例としては、ユーザーの大まかな位置情報、優先する言語 / 地域などがあります。
  • 信頼できる入札データ: 広告テクノロジー プラットフォームは、リアルタイム データに基づいて広告の取得とスコアリングについて通知します。たとえば、ある広告が予算を使い果たし、すぐに配信を停止する必要が生じることがあります。広告テクノロジーは、このリアルタイム データを取得できる URL エンドポイントと、リアルタイム検索を行う必要があるキーのセットを定義できます。このリクエストを処理するサーバーが、広告テクノロジー プラットフォームが管理する信頼できるサーバーになります。
  • 入札ロジック URL: デマンドサイド プラットフォームから入札コードを取得するためにプラットフォームが使用する URL。広告オークションが開始されると、このステップが実施されます。
  • 広告: カスタム オーディエンスの広告候補のリスト。これには、広告テクノロジー プラットフォーム固有の広告メタデータと、広告をレンダリングするための URL が含まれます。カスタム オーディエンス向けにオークションが開始されると、この広告メタデータのリストが考慮されます。この広告のリストは、可能な場合は日次更新 URL エンドポイントを使用してアップデートされます。モバイル デバイスではリソースの制約があるため、カスタム オーディエンスに保存できる広告の数には制限があります。

カスタム オーディエンスに参加する

アプリは、想定されるパラメータで CustomAudience オブジェクトをインスタンス化した後に joinCustomAudience() を呼び出すことで、カスタム オーディエンスへの参加をリクエストできます。次にコード スニペットの例を示します。

CustomAudience audience = new CustomAudience(
    Buyer = "example-dsp.com",
    Name = "running-shoes",
    ActivationTime = now(),
    ExpirationTime = ActivationTime.plus(30 days),
    DailyUpdateURL = Uri.parse("https://..."),
    UserBiddingSignals = new JSONObject("{...}"),
    TrustedBiddingURL = Uri.parse("https://..."),
    TrustedBiddingKeys = {'key1","key2", ...,"key n"},
    BiddingLogicURL =  Uri.parse("https://..."),
    Ads = [new AdData(renderUrl = Uri.parse("https://..."),
           metadata = new JSONObject("{...}"), ...];

// Invoke ad services API to join a custom audience.
joinCustomAudience(audience);

カスタム オーディエンスから脱退する

カスタム オーディエンスのオーナーは、次のコード スニペットに示すように、leaveCustomAudience() を呼び出して脱退することもできます。

// Invoke ad services API to leave a custom audience.
leaveCustomAudience(buyer, name);

カスタム オーディエンスは、ストレージやその他のデバイス リソースの使用量を節約するために、所定の期間が経過すると期限切れとなり、デバイス上のストアから削除されます。デフォルト値は未定です。オーナーはこのデフォルト値をオーバーライドできます。

ユーザー コントロール

  • このプロポーザルは、カスタム オーディエンスを 1 つ以上作成したインストール済みのアプリのリストをユーザーが確認できるようにすることを目的としています。
  • ユーザーはこのリストからアプリを削除できます。削除すると、アプリに関連付けられているカスタム オーディエンスがすべて消去され、アプリが新しいカスタム オーディエンスに参加できなくなります。

この機能の設計は現在進行中であり、詳細については今後のアップデートに反映される予定です。

広告テクノロジー プラットフォームの権限と管理

このプロポーザルは、アプリがカスタム オーディエンスを管理できるようにすることを目的としています。

  • アプリはカスタム オーディエンスとの関連付けを管理できます。
  • アプリは、サードパーティの広告テクノロジー プラットフォームに、アプリに代わってカスタム オーディエンスの管理権限を付与できます。
  • このプロポーザルは、ユーザーが FLEDGE を完全にリセットできるようにすることを目的としています。その場合、デバイスで生成された既存のカスタム オーディエンスはすべて消去されます。
  • このプロポーザルには、ユーザーが FLEDGE を含む Android のプライバシー サンドボックスから完全にオプトアウトできるようにすることも含まれています。この場合、FLEDGE API は通知なしで処理を停止します。

この機能の設計は現在進行中であり、詳細については今後のアップデートに反映される予定です。

カスタム オーディエンスの広告候補を取得する

バイサイド プラットフォームは、ユーザー インタラクション ベースの広告候補をデバイスに保存していることがあるため、カスタム オーディエンスのオークションを実施する際に評価できます。カスタム オーディエンスの広告候補と関連するメタデータは、2 つの補完的な方法で取得できます。

  1. システム日次取得: アプリがカスタム オーディエンスに参加する際に、プラットフォームが毎日クエリする日次更新 URL を指定できます。広告テクノロジー プラットフォームはこの機能を使用して、広告リストを最新の状態に保ち、有効でなくなった広告や予算が残っていない広告を削除できます。
  2. カスタム オーディエンスのオーナー主導の取得: オーナーがカスタム オーディエンスにユーザーを追加すると、バイサイド プラットフォームから広告候補を取得できます。返された広告とメタデータは、カスタム オーディエンスの「ads」フィールドに格納できます。広告テクノロジー プラットフォームが、このユーザーへの広告配信をすぐに始めたい場合に、この機能を使用できます。

広告候補とメタデータのレスポンス

バイサイド プラットフォームから返される広告候補とメタデータには、次のフィールドが含まれている必要があります。

  • メタデータ: バイサイドの広告テクノロジー固有の広告メタデータ。たとえば、広告キャンペーンに関する情報や、地域や言語などのターゲティング条件が含まれる場合があります。
  • レンダリング URL: 広告クリエイティブをレンダリングするためのエンドポイント。
  • フィルタ: FLEDGE がデバイス上のデータに基づいて広告をフィルタするために必要なオプションの情報。詳細については、バイサイド フィルタリング ロジックをご覧ください。

広告選択ワークフロー

このプロポーザルでは、広告テクノロジー プラットフォームのオークションの実施を調整する Ad Selection API を導入することで、プライバシーを向上させることを目的としています。

現在の広告テクノロジー プラットフォームは、入札と広告の選択を自社サーバーのみで行うことが一般的です。このプロポーザルでは、カスタム オーディエンスやプライベートなユーザー シグナル（利用可能なインストール済みのパッケージ情報など）に対して Ad Selection API 経由でのみアクセスできます。さらに、リマーケティングのユースケースでは、広告候補が範囲外（広告が表示されるコンテキスト以外）で取得されます。広告テクノロジープラットフォームは、現在のオークションと広告選択ロジックの一部をデバイスにデプロイして実行できるように準備する必要があります。広告テクノロジー プラットフォームは、広告選択ワークフローに対し次の変更を検討できます。

  • インストール済みパッケージ情報がサーバーで利用できない場合、広告テクノロジー プラットフォームは、複数のコンテンツ ターゲット広告をデバイスに送り返し、関連性の高い広告が表示される可能性を最大化するために、広告選択ワークフローを呼び出してアプリのインストール ベースのフィルタリングを有効にします。
  • リマーケティング広告は範囲外で取得されるため、現在の入札モデルをアップデートする必要が生じる場合があります。広告テクノロジー プラットフォームは、広告機能とコンテキスト シグナルを別々に扱い、デバイス上でサブモデルの出力を組み合わせて入札を予測できる、入札サブモデルを作成できます（実装はツータワー モデルというパターンに基づくことがあります）。これにより、サーバーサイド オークションと、任意の広告配信機会のオークションの両方にメリットが生じます。

このアプローチでは、ユーザーのアプリ操作データを広告の選択に利用しつつ、第三者とのデータ共有を制限できます。

図 2. 広告選択ワークフローの開始を示すフローチャート。

この広告選択ワークフローは、以下の順に沿って、広告テクノロジーが提供する JavaScript コードのデバイス上における実行を調整します。

  1. バイサイド入札ロジックの実行
  2. バイサイドの広告フィルタリングと処理
  3. セルサイド判断ロジックの実行

カスタム オーディエンスが関係する広告選択の場合、プラットフォームは、カスタム オーディエンスの「入札ロジック URL」メタデータで定義された公開 URL エンドポイントに基づいて、バイサイドによって提供される JavaScript コードを取得します。セルサイド判断コードの URL エンドポイントも、広告選択ワークフローを開始するための入力として渡されます。

カスタム オーディエンスが関係しない広告選択については、現在設計中です。

広告選択ワークフローを開始する

アプリで広告を表示する必要がある場合、広告テクノロジー プラットフォーム SDK は、想定されるパラメータを指定して AdSelectionConfig オブジェクトをインスタンス化した後、selectAds() メソッドを呼び出して広告選択ワークフローを開始します。

  • 販売者: eTLD+1 形式のセルサイド広告プラットフォームの識別子。
  • 判断ロジック URL: 広告オークションが開始されると、プラットフォームはこの URL を使用してセルサイド プラットフォームから JavaScript コードを取得し、落札広告を評価します。
  • カスタム オーディエンス購入者: このオークションについてカスタム オーディエンスに基づく需要があるバイサイド プラットフォームのリスト（eTLD+1 形式）。
  • 広告選択シグナル: オークションに関する情報（広告サイズ、広告フォーマットなど）。
  • 販売者シグナル: サプライサイド プラットフォーム固有のシグナル。
  • 信頼できるスコアリング シグナル URL: クリエイティブ固有のリアルタイム情報を取得できる、セルサイドの信頼できるシグナルの URL エンドポイント。
  • 購入者ごとのシグナル: 参加しているデマンドサイドは、このパラメータを使用してオークションのための入力を提供できます。たとえば、このパラメータに、入札単価の決定に役立つ包括的なコンテキスト情報を含めることができます。

次のコードスニペットに、広告テクノロジー プラットフォーム SDK が広告選択ワークフローを開始する例を示します。まず AdSelectionConfig を定義してから、selectAds を呼び出して落札広告を取得しています。

AdSelectionConfig myAdSelectionConfig = new AdSelectionConfig {
    Seller = "example-ssp1.com",
    DecisionLogicURL = Uri.parse("https://..."),
    CustomAudienceBuyerList = Arrays.asList("example-dsp1.com","bexample-dsp2.com"),
    AdSelectionSignals = "{"min_price": 10,"auction_attempts": 3}"
    SellerSignals = "{"seller_type": "news", "content_category": "sports","mature_ads_accepted" :"false"}"
    PerBuyerSignals = " {"buyer1Name": {"key1" : "value1"},
                         "buyer2Name": {"key1" : "value1", "key2" : "value2" }"
};

// Invoke ad services API to initiate ad selection workflow.
Ad winningAd = selectAds(myAdSelectionConfig);

バイサイド入札ロジック

通常、入札ロジックはバイサイド プラットフォームが提供します。このコードの目的は、広告候補の入札単価を決定することです。結果を判断するために、追加のビジネス ロジックが適用される場合があります。

プラットフォームは、カスタム オーディエンスの「入札ロジック URL」メタデータを使用して、次の関数シグネチャを含む JavaScript コードを取得します。

generateBid(ad, auction_signals, per_buyer_signals, trusted_bidding_signals,
        contextual_signals, user_signals, custom_audience_signals) {
    // ...
    return {'bid': ...};
}

generateBid() メソッドは、算出された入札単価を返します。プラットフォームは、すべての広告（コンテンツ ターゲット広告またはリマーケティング広告）に対してこの関数を順次呼び出します。入札ロジックのプロバイダが複数ある場合、プロバイダ間の実行順序は保証されません。

関数には次のパラメータが必要です。

  • 広告: バイサイド入札コードで検討される広告。対象となるカスタム オーディエンスからの広告です。
  • オークション シグナル: セルサイドのプラットフォーム固有のシグナル。
  • 購入者ごとのシグナル: 参加しているデマンドサイドは、このパラメータを使用してオークションのための入力を提供できます。たとえば、このパラメータに、入札単価の決定に役立つ包括的なコンテキスト情報を含めることができます。
  • 信頼できる入札シグナル: 広告テクノロジー プラットフォームは、リアルタイム データに基づいて広告の取得とスコアリングについて通知します。たとえば、ある広告キャンペーンが予算を使い果たし、すぐに配信を停止する必要が生じることがあります。広告テクノロジーは、このリアルタイム データを取得できる URL エンドポイントと、リアルタイム検索を行う必要があるキーのセットを定義できます。このリクエストを処理する広告テクノロジー プラットフォームが管理するサーバーが、広告テクノロジー プラットフォームが管理する信頼できるサーバーになります。
  • コンテキスト シグナル: おおまかなタイムスタンプやおおよその位置情報が含まれることがあります。
  • ユーザー シグナル: 利用可能なインストール済みパッケージ情報などの情報が含まれることがあります。

バイサイド フィルタリング ロジック

バイサイド プラットフォームは、広告選択フェーズで利用できる、デバイス上の追加のシグナルに基づいて広告をフィルタできるようになります。たとえば、広告テクノロジー プラットフォームは、ここでフリークエンシー キャップ機能を実装できます。フィルタリングのプロバイダが複数ある場合、プロバイダ間の実行順序は保証されません。

バイサイド フィルタリング ロジックは、入札ロジックの一部として、特定の広告の入札単価 0 を返す形で実装できます。

さらに、バイサイド プラットフォームは、FLEDGE で利用できる、デバイス上の追加のシグナルに基づいて特定の広告をフィルタする必要があるということを通知できます。デバイスを離れることはありません。追加のフィルタリング ロジックの設計が固まれば、バイサイド プラットフォームは同じ構造に従って、フィルタリングが行われることを通知します。

セルサイド スコアリング ロジック

通常、スコアリング ロジックはセルサイド プラットフォームが提供します。このコードの目的は、入札ロジックの出力に基づいて落札広告を決定することです。結果を判断するために、追加のビジネス ロジックが適用される場合があります。判断ロジックのプロバイダが複数ある場合、プロバイダ間の実行順序は保証されません。プラットフォームは、selectAds() API の「判断ロジック URL」入力パラメータを使用して、次の関数シグネチャを含む JavaScript コードを取得します。

scoreAd(ad, bid, auction_config, trusted_scoring_signals,
        contextual_signals, user_signals, custom_audience_signals) {
    // ...
    return score_for_this_ad;
}

関数には次のパラメータが必要です。

  • 広告: 評価する広告。generateBid() 関数の出力。
  • 入札単価: generateBid() 関数から出力される入札単価。
  • オークション設定: selectAds() メソッドへの入力パラメータ。
  • 信頼できるスコアリング シグナル: 広告テクノロジー プラットフォームは、リアルタイム データに基づいて広告のフィルタリングとスコアリングについて通知します。たとえば、アプリのパブリッシャーは、アプリで広告を表示しないように広告キャンペーンをブロックすることがあります。このデータは、オークション設定の信頼できるスコアリング シグナル URL パラメータから取得されます。このリクエストを処理するサーバーは、広告テクノロジーが管理する信頼できるサーバーである必要があります。
  • コンテキスト シグナル: おおまかなタイムスタンプやおおよその位置情報が含まれることがあります。
  • ユーザー シグナル: アプリのインストールを開始したアプリストアなどの情報が含まれることがあります。
  • カスタム オーディエンス シグナル: スコアリングする広告がデバイス上のカスタム オーディエンスからのものである場合は、カスタム オーディエンスのリーダーや名前などの情報が含まれます。

広告選択コード ランタイム

このプロポーザルでは、広告テクノロジー プラットフォームが提供するオークション コードが、設定可能な URL エンドポイントから取得され、デバイスで実行されます。モバイル デバイスのリソース制約を考慮して、オークション コードは以下のガイドラインを遵守する必要があります。

  • コードは、事前に定義した時間内に実行を終了する必要があります。この制限は、すべての購入者広告ネットワークに対して一律に適用されます。この制限の詳細については、今後のアップデートで共有される予定です。
  • コードは自己完結している必要があり、外部との依存関係があってはなりません。

入札ロジックなどのオークション コードは、アプリのインストール元などの非公開のユーザーデータにアクセスする必要が生じる場合があるため、ランタイムはネットワークやストレージへのアクセスを提供しません。

プログラミング言語

広告テクノロジー プラットフォームが提供するオークション コードは、JavaScript で記述する必要があります。これにより、たとえば広告テクノロジー プラットフォームは、プライバシー サンドボックスをサポートするプラットフォーム間で入札コードを共有できます。

落札広告のレンダリング

スコアが最も高い広告がオークションの落札者と見なされます。この最初のプロポーザルでは、落札広告が SDK に渡され、レンダリングされます。

今後はソリューションを進化させて、ユーザーのカスタム オーディエンス メンバーシップに関する情報やアプリの操作履歴を、落札広告に関する情報を通じてアプリまたは SDK から判断できないようにする予定です（Chrome の Fenced Frames のプロポーザルと同様）。

インプレッション レポート

広告がレンダリングされると、落札インプレッションは、参加しているバイサイドとセルサイドのプラットフォームにレポートされます。プラットフォームは、レポート ロジックを次の順序で呼び出します。

  1. セルサイド レポート
  2. バイサイド レポート

これにより、バイサイドとセルサイドのプラットフォームは、入札情報やカスタム オーディエンス名など、デバイス上の重要な情報をサーバーに送信し、リアルタイムの予算設定、入札モデルのアップデート、正確な支払いワークフローなどの機能を実現できます。このインプレッション レポートのサポートは Attribution Reporting API を補完するものです。

セルサイド レポート

プラットフォームは、selectAds() API の販売者の判断ロジック URL パラメータからダウンロードしたサプライサイド提供のコードで、reportResult() JavaScript 関数を呼び出します。

reportResult(render_url, bid, auction_config, contextual_signals) {
    // ...
    return reporting_url, signals_for_buyer;
}

出力:

  • レポート URL: プラットフォームは、関数から返されたこの URL を呼び出します。

サプライサイドは、レポート URL で関連性の高いシグナルをエンコードすることで、オークションや落札広告についてさらに詳しい分析情報を得ることができます。たとえば、次のようなシグナルが該当します。

  • 広告レンダリング URL
  • 落札単価
  • アプリ名
  • クエリ識別子
  • 購入者向けシグナル: サプライサイドとデマンドサイドでのデータ共有をサポートするために、プラットフォームはこの戻り値を入力パラメータとしてデマンドサイド レポートコードに渡します。

バイサイド レポート

プラットフォームは、オークションに関連付けられたカスタム オーディエンスの入札ロジック URL メタデータからダウンロードしたデマンドサイド提供のコードで、reportResult() JavaScript 関数を呼び出します。

reportResult(render_url, bid, auction_signals, per_buyer_signals,
        signals_for_buyer, contextual_signals, custom_audience_signals) {
    // ...
    return reporting_url;
}

入力:

  • auction_signals と per_buyer_signals は AuctionConfig から取得されます。バイサイド プラットフォームがレポート URL に渡す必要がある情報は、このデータから取得される可能性があります。
  • signals_for_buyer は、セルサイドの reportResult の出力です。これにより、セルサイド プラットフォームは、レポートのためにバイサイド プラットフォームとデータを共有できます。
  • contextual_signals にはアプリ名などの情報が含まれ、custom_audience_signals にはカスタム オーディエンス情報が含まれます。今後、その他の情報が追加される可能性があります。

出力:

  • レポート URL: プラットフォームは、関数から返されたこの URL を呼び出します。

広告テクノロジー プラットフォームが管理する信頼できるサーバー

現在の広告選択ロジックでは、オークション向けに広告候補を選択するかどうかを判断するために、予算の枯渇状況など、リアルタイムの情報が必要です。バイサイドとセルサイドのプラットフォームはいずれも、自社の運用するサーバーからこの情報を取得できます。これらのサーバーを経由した機密情報の漏洩を最小限に抑えるために、このプロポーザルでは以下の制限を求めています。

  • これらのサーバーの動作（このセクションで後述）によってユーザー情報が漏洩しない。
  • サーバーが、参照するデータに基づいて仮名化されたプロファイルを作成しない（つまり「信頼できる」必要がある）。

バイサイド: バイサイドがバイサイド入札ロジックを開始すると、プラットフォームは、信頼できるサーバーから信頼できる入札データの HTTP 取得を行います。URL は、処理されるカスタム オーディエンスの信頼できる入札シグナルのメタデータに存在する URL とキーを付加することで構成されます。この取得は、デバイス上のカスタム オーディエンスの広告を処理する場合にのみ行われます。この段階で、バイサイドによる予算の執行、キャンペーンの一時停止 / 一時停止解除状態の確認、ターゲティングの実施が可能となります。

カスタム オーディエンスからの信頼できる入札シグナルのメタデータに基づいて、信頼できる入札データを取得する URL の例を次に示します。

https://www.kv-server.example/getvalues?keys=key1,key2

サーバーからのレスポンスは、キーが key1 や key2 などであって、値を購入者の入札機能に利用できる JSON オブジェクトである必要があります。

セルサイド: 前述のバイサイド フローと同様に、セルサイドが、オークションで考慮されるクリエイティブについての情報取得を望む場合があります。たとえば、パブリッシャーは、ブランド保護の観点から、特定のクリエイティブがアプリに表示されないように強制したい場合があります。この情報を取得して、セルサイド オークション ロジックで利用できるようにすることができます。バイサイドの信頼できるサーバーの検索と同様に、セルサイドの信頼できるサーバーの検索も HTTP 取得によって行われます。URL は、信頼できるスコアリング シグナル URL と、データを取得する必要があるクリエイティブのレンダリング URL を付加することで構成されます。

クリエイティブのレンダリング URL に基づいて、オークションで考慮するクリエイティブについての情報を取得する URL の例を次に示します。

https://www.kv-server.example/getvalues?renderUrls=render_url1,render_url2

サーバーからのレスポンスは、リクエストで送信されたレンダリング URL をキーとする JSON オブジェクトである必要があります。

これらのサーバーが信頼できる方法で動作することで、セキュリティとプライバシーに関して、次の利点をもたらします。

  • 各キーに対するサーバーの戻り値がそのキーのみに基づいているということを信頼できる。
  • サーバーがイベントレベルのロギングを行わない。
  • サーバーに、これらのリクエストに基づくその他の副作用がない。

一時的なメカニズムとして、購入者と販売者は、自社で運営するサーバーを含め、どのサーバーからも入札シグナルを取得できます。ただし、リリース バージョンでは、信頼できる Key-Value 型サーバーにのみリクエストを送信します。

購入者と販売者は、Android 版プライバシー サンドボックスと互換性のあるプラットフォームとウェブ用に、共通の信頼できる Key-Value 型サーバーを使用できます。