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

フィードバックを送信

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

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

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

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

**図 1.** Android 版プライバシーサンドボックスにおけるカスタムオーディエンス管理と広告選択のワークフローを示すフローチャート。

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

SportingGoodsApp は、ユーザーが 2 日以内に購入処理を完了しなかった場合、カートに残っている商品の購入を促します。SportingGoodsApp が、Custom Audience API を使用して、ユーザーを「商品がカートに入っている」オーディエンスリストに追加します。プラットフォームはこのオーディエンスリストをデバイス上で管理、保存し、第三者との共有を制限します。SportingGoodsApp は広告テクノロジープラットフォームと連携して、オーディエンスリストのユーザーに広告を表示します。広告テクノロジープラットフォームは、オーディエンスリストのメタデータを管理し、広告候補を提供します。これは広告選択ワークフローでの検討に使用できます。プラットフォームは、バックグラウンドで更新されたオーディエンスベース広告を定期的に取得するように構成できます。これによりオーディエンスベースの広告候補リストが最新の状態に保たれ、広告を出す機会が訪れた際に、第三者広告サーバーに送信されるリクエスト（コンテンツターゲット広告リクエスト）と相関しない状態に保たれます。
ユーザーが FrisbeeGame をプレイすると、同じデバイス上にある SportingGoodsApp のショッピングカートに残るアイテムの購入処理を促す広告が表示される場合があります。これを実現するには、FrisbeeGame（統合広告 SDK を使用）で Ad Selection API を呼び出し、ユーザーが属している可能性のあるオーディエンスリスト（この例では SportingGoodsApp が作成するカスタムの「商品がカートに入っている」オーディエンスリスト）に基づいて落札広告を選択します。広告選択ワークフローは、カスタムオーディエンスや他のデバイス上のシグナルに関連付けられたデバイス上の広告に加え、広告テクノロジープラットフォームのサーバーから取得した広告を考慮するように設定できます。このワークフローは、適切な広告掲載の目標を達成するために、カスタム入札やスコアリングロジックを使用して、広告テクノロジープラットフォームと広告 SDK によってカスタマイズすることもできます。このアプローチでは、ユーザーの興味またはアプリ操作データを広告の選択に反映させ、第三者とのデータの共有を制限できます。
広告配信アプリまたは広告テクノロジープラットフォームの SDK が、選択された広告をレンダリングします。
プラットフォームにより、インプレッションと広告選択結果のレポートが容易になります。このレポート機能は Attribution Reporting API を補完するものです。広告テクノロジープラットフォームはレポートのニーズに応じてカスタマイズできます。

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

カスタムオーディエンス

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

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

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

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

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

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

次のコードスニペットに示すように、アプリは joinCustomAudience() を呼び出してカスタムオーディエンスへの参加をリクエストできます。

CustomAudience audience = new CustomAudience(
    "com.sporting-goods.app",      // Owner. Defaults to the calling app's
                                   // package name.
    "com.example-dsp",             // Reader.
    "running-shoes",               // A logical name for the custom audience.
    currentTime,                   // Creation time.
    expirationTime,                // Expiration time.
    Uri.parse("https://..."),      // Daily update URL.
    biddingData,                   // Trusted Bidding Data key/value pairs.
    candidateAdsList,              // List of candidate ads related to
                                   // this custom audience.
    biddingLogicUrl
);

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

joinCustomAudience() を呼び出すアプリは、そのカスタムオーディエンスのオーナーです。このメソッドを呼び出す際、アプリは次の情報を指定する必要があります。

リーダー: カスタムオーディエンスにアクセスし、関連する広告情報を取得する当事者を表します。

名前: このカスタムオーディエンスの名前。

日次更新 URL: 広告候補リストの URL。

広告候補: カスタムオーディエンスのオーナーがカスタムオーディエンスに参加すると、バイサイドプラットフォームから広告候補を取得できます。プラットフォームは、広告を定期的に取得するように設定することもできます。

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

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

// Define a custom audience populated with key fields.
CustomAudience audience = new CustomAudience(
    "com.sporting-goods.app",     // Owner. Defaults to
                                  // the calling app's package name.
    "com.example-dsp",            // Reader.
    "running-shoes"               // A logical name for the custom audience.
    ...
);

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

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

ユーザーコントロール

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

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

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

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

アプリはカスタムオーディエンスとの関連付けを管理できます。
アプリは、第三者の広告テクノロジープラットフォームに、アプリに代わってカスタムオーディエンスの管理権限を付与できます。

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

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

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

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

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

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

メタデータ: バイサイドの広告テクノロジー固有の広告メタデータ。たとえば、広告キャンペーンに関する情報や、地域や言語などのターゲティング条件が含まれる場合があります。
レンダリング URL: 広告クリエイティブをレンダリングするためのエンドポイント。

広告選択ワークフロー

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

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

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

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

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

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

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

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

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

アプリで広告を表示する必要がある場合、広告テクノロジープラットフォーム SDK は runAdAuction() メソッドを呼び出して広告選択ワークフローを開始します。

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

販売者: セルサイド広告プラットフォームの識別子。

判断ロジック URL: 広告オークションが開始されると、プラットフォームはこの URL を使用してセルサイドプラットフォームから JavaScript コードを取得し、落札広告を評価します。

カスタムオーディエンス購入者: このオークションについてカスタムオーディエンスに基づく需要があるバイサイドプラットフォームのリスト。

オークションシグナル: オークションに関する情報（広告サイズ、広告フォーマットなど）。

販売者シグナル: サプライサイドプラットフォーム固有のシグナル。

信頼できるスコアリングシグナル URL: クリエイティブ固有のリアルタイム情報を取得できる、セルサイドの信頼できるシグナルの URL エンドポイント。

購入者ごとのシグナル: 参加しているデマンドサイドは、このパラメータを使用してオークションのための入力を提供できます。たとえば、このパラメータに、入札単価の決定に役立つ包括的なコンテキスト情報を含めることができます。

次のコードスニペットに、広告テクノロジープラットフォーム SDK が広告選択ワークフローを開始する例を示します。

AuctionConfig myAuctionConfig = new AuctionConfig {
    "com.example.app",         // Package name for the calling app.
    Uri.parse("https://..."),  // Decision logic URL.
    customAudienceBuyerList,   // List of package names
                               // for custom audience buyers.
    auctionSignals,            // Auction signals
    sellerSignals,             // Seller signals
    perBuyerSignals,           // Per buyer signals
    ...
};

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

バイサイド入札ロジック

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

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

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

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

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

広告: バイサイド入札コードで検討される広告。カスタムオーディエンスからの広告や、コンテキストに基づくレスポンスで返された広告などがこれに該当します。

オークションシグナル: セルサイドのプラットフォーム固有のシグナル。

信頼できる入札シグナル: 広告テクノロジープラットフォームは、リアルタイムデータに基づいて広告の取得とスコアリングを行います。たとえば、ある広告キャンペーンが予算を使い果たし、すぐに配信を停止する必要が生じることがあります。広告テクノロジーは、このリアルタイムデータを取得できる URL エンドポイントと、リアルタイム検索を行う必要があるキーのセットを定義できます。このリクエストを処理する広告テクノロジープラットフォームが管理するサーバーが、広告テクノロジープラットフォームが管理する信頼できるサーバーになります。

コンテキストシグナル: おおまかなタイムスタンプやおおよその位置情報が含まれることがあります。

ユーザーシグナル: 利用可能なインストール済みパッケージ情報などの情報が含まれることがあります。

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

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

バイサイドフィルタリングロジックは、入札ロジックの後に実行されます。

filterAd(ad, per_buyer_signals, trusted_bidding_signals, contextual_signals,
        user_signals) {
    // ...
    return is_filtered;
}

この JavaScript 関数は、入札ロジック関数と同様の入力パラメータを想定しています。

セルサイド判断ロジック

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

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

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

広告: 評価する広告。generateBid() 関数と filterAd() 関数の出力。

入札単価: generateBid() 関数から出力される入札単価。

オークション設定: runAdAuction() メソッドへの入力パラメータ。

信頼できるスコアリングシグナル: 広告テクノロジープラットフォームは、リアルタイムデータに基づいて広告のフィルタリングとスコアリングを行います。たとえば、アプリのパブリッシャーは、アプリで広告を表示しないように広告キャンペーンをブロックすることがあります。このデータは、オークション構成の信頼できるスコアリングシグナル URL パラメータから取得されます。このリクエストを処理するサーバーは、広告テクノロジーが管理する信頼できるサーバーである必要があります。

コンテキストシグナル: おおまかなタイムスタンプやおおよその位置情報が含まれることがあります。

ユーザーシグナル: アプリのインストールを開始したアプリストアなどの情報が含まれることがあります。

カスタムオーディエンスシグナル: スコアリングする広告がデバイス上のカスタムオーディエンスからのものである場合は、カスタムオーディエンスのリーダーや名前などの情報が含まれます。

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

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

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

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

プログラミング言語

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

落札広告のレンダリング

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

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

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

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

セルサイドレポート
バイサイドレポート

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

セルサイドレポート

プラットフォームは、runAdAuction() 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 型サーバーを使用できます。

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

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

カスタム オーディエンス

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

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

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

ユーザー コントロール

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

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