最近の更新
- Attribution Reporting と Protected Audience の統合を追加しました
- Protected Audience 機能のタイムラインを公開しました。
- FLEDGE は Protected Audience API に名称変更されました。
- カスタム オーディエンス委任のプロポーザルを追加しました。
- 日次更新 URL の k-匿名性の要件を削除しました。
Protected Audience はベータ版であり、公共のデバイスでテストできます。
Protected Audience のメリット
- 過去のユーザー行動に基づいてカスタム オーディエンスを管理します。
- 単一販売者またはウォーターフォールのメディエーションのサポートを使用して、オンデバイスのオークションを開始できます。
- 広告選択後のインプレッション レポートを行う。
詳しくは、Protected Audience デベロッパー ガイドをご覧ください。皆様からのフィードバックは Protected Audience の開発に役立てさせていただきます。
タイムライン
今後数か月以内に新機能をリリースする予定です。正確なリリース日は機能によって異なります。この表は、利用可能になり次第、ドキュメントへのリンクで更新されています。
機能 | デベロッパー プレビューで利用可能 | ベータ版で利用可能 |
---|---|---|
イベントレベルのレポート | 2023 年第 1 四半期 | 2023 年第 3 四半期 |
ウォーターフォール メディエーション | 2023 年第 1 四半期 | 2023 年第 4 四半期 |
アプリ インストール広告のフィルタリング | 2023 年第 2 四半期 | 2023 年第 3 四半期 |
フリークエンシー キャップ フィルタリング | 2023 年第 2 四半期 | 2023 年第 3 四半期 |
コンテキスト広告を広告選択ワークフローに渡してフィルタする | 2023 年第 2 四半期 | 2023 年第 3 四半期 |
インタラクション レポート | 2023 年第 2 四半期 | 2023 年第 3 四半期 |
カスタム オーディエンス委任に参加する | 2023 年第 3 四半期 | 2023 年第 4 四半期 |
非 CPM 課金 | 2023 年第 3 四半期 | 2023 年第 4 四半期 |
入札とオークション サービスの統合 | 2023 年第 3 四半期 | 2023 年第 4 四半期 |
デバッグ レポート | 2023 年第 3 四半期 | 2023 年第 4 四半期 |
Attribution Reporting の統合 | なし | 2023 年第 4 四半期 |
Open Bidding メディエーション | 2023 年第 4 四半期 | 2023 年第 4 四半期 |
通貨の管理 | 2024 年第 1 四半期 | 2024 年第 2 四半期 |
k-匿名性の統合 | なし | 2024 年第 2 四半期 |
集計レポートの統合 | 2024 年第 3 四半期 | 2024 年第 4 四半期 |
概要
モバイル広告で一般的に広告主が必要とするのは、ユーザーが過去に広告主のアプリで行った操作に基づいて、興味を持ちそうなユーザーに広告が配信されることです。たとえば、SportingGoodsAppSportingGoodsApp のデベロッパーは、ショッピング カートにアイテムが残っているユーザーに広告を表示して、購入手続きの完了を促そうとします。業界では、このような考え方を一般的に「リマーケティング」、「カスタム オーディエンス ターゲティング」などの用語で表現します。
現在のところ、このようなユースケースは、広告の表示方法に関するコンテキスト情報(アプリ名など)やオーディエンス リストなどの個人情報を、広告テクノロジー プラットフォームと共有して実装することが一般的です。このような情報を使用することで、広告主は自身のサーバー上で関連性の高い広告を選択できます。
Android 版 Protected Audience API(旧称 FLEDGE)には、広告テクノロジー プラットフォームと広告主向けの以下の API が含まれ、一般的なインタラクション ベースのユースケースを、アプリ間の識別子とユーザーによるアプリとのインタラクション情報の両方を第三者と共有することを制限しつつ、サポートします。
- Custom Audience API: 広告主が指定する共通のインテントを持ったオーディエンスを表す「カスタム オーディエンス」の抽象化を主な役割としています。オーディエンス情報はデバイス上に保存され、オーディエンスに関わる広告候補や、入札シグナルなどの任意のメタデータと関連付けることができます。この情報は、広告主の入札、広告のフィルタリング、レンダリングに関する通知に使用できます。
- Ad Selection API: 広告テクノロジー プラットフォームのワークフローを調整するフレームワークを提供します。このフレームワークでは、ローカルに保存されている広告候補の検討や、広告テクノロジー プラットフォームがデバイスに返す広告候補への追加処理によって、デバイス上のシグナルを活用した広告の「落札」判定を行います。
統合作業の概要は次のとおりです。
SportingGoodsApp は、ユーザーが 2 日以内に購入を完了しなかった場合に、カートに残っている商品を購入するようユーザーにリマインドしたいと考えています。SportingGoodsApp は、Custom Audience API を使用してユーザーを「カート内の商品」オーディエンス リストに追加します。プラットフォームはこのオーディエンス リストを管理してデバイスに保存し、第三者との共有を制限します。SportingGoodsApp は広告テクノロジー プラットフォームと提携し、オーディエンス リストのユーザーに広告を表示しています。広告テクノロジー プラットフォームは、オーディエンス リストのメタデータを管理し、広告候補を提供します。これは、広告選択ワークフローで検討して利用できます。このプラットフォームは、更新されたオーディエンス ベース広告を定期的に取得するようにバックグラウンドで設定できます。これにより、オーディエンス ベースの広告候補リストが常に最新の状態に保たれ、広告配信の機会中に第三者広告サーバーに送信されたリクエスト(コンテキスト広告リクエスト)と相関がなくなります。
ユーザーが FrisbeeGame をプレイすると、同じデバイス上にある SportingGoodsApp のショッピング カートに残るアイテムの購入処理を促す広告が表示される場合があります。これを行うには、FrisbeeGame(統合広告 SDK を使用)で Ad Selection API を呼び出し、ユーザーが属している可能性のあるオーディエンス リスト(この例では SportingGoodsApp が作成した「商品がカートに入っている」カスタム オーディエンス リスト)に基づいて落札広告を選択します。広告選択ワークフローは、広告テクノロジー プラットフォームのサーバーから取得した広告に加え、カスタム オーディエンスや他のデバイス上のシグナルに関連付けられたデバイス上の広告を考慮するように設定できます。このワークフローは、カスタム入札とスコアリング ロジックを使用して、広告テクノロジー プラットフォームと広告 SDK がカスタマイズし、適切な広告掲載の目標を達成するようにすることもできます。このアプローチでは、ユーザーの興味またはアプリ操作データを広告の選択に反映させつつ、第三者とのこのようなデータの共有を制限できます。
広告配信アプリまたは広告テクノロジー プラットフォームの SDK が、選択された広告をレンダリングします。
プラットフォームにより、インプレッションと広告選択結果のレポートが容易になります。このレポート機能は Attribution Reporting API を補完するものです。広告テクノロジー プラットフォームはレポートのニーズに応じてカスタマイズできます。
Android 版 Protected Audience API にアクセスする
広告テクノロジー プラットフォームが Protected Audience API にアクセスするには登録が必要です。詳しくは、プライバシー サンドボックス アカウントの登録をご覧ください。
カスタム オーディエンス管理
カスタム オーディエンス
カスタム オーディエンスとは、共通の意図または興味に基づき広告主が特定したユーザーのグループを表します。アプリまたは SDK はカスタム オーディエンスを使用して、特定のオーディエンス(「ショッピング カートにアイテムが残っているユーザー」、ゲームの「初級レベルをクリアしたユーザー」など)を指定できます。プラットフォームは、デバイス上でオーディエンス情報をローカルに保持して保存します。ユーザーがどのカスタム オーディエンスに属するかは表示されません。カスタム オーディエンスは、Chrome の Protected Audience のインタレスト グループとは異なり、ウェブやアプリ間で共有することはできません。こうすることにより、ユーザー情報の共有を制限できます。
広告主アプリまたは統合 SDK は、アプリでのユーザー エンゲージメントなどに基づいて、カスタム オーディエンスへのjoin、またはカスタム オーディエンスからの脱退を選択できます。
カスタム オーディエンス メタデータ
カスタム オーディエンスには次のメタデータが含まれます。
- オーナー: オーナーアプリのパッケージ名。暗黙的に、呼び出し元アプリのパッケージ名に設定されます。
- 購入者: このカスタム オーディエンスの広告を管理する購入者の広告ネットワーク。また購入者は、カスタム オーディエンスにアクセスし、関連する広告情報を取得する当事者を表します。購入者は eTLD+1 形式で指定されます。
- 名前: カスタム オーディエンスの任意の名前または識別子(「ショッピング カートを放棄した」ユーザーなど)。この属性は、たとえば、広告主の広告キャンペーンにおけるターゲティング条件の一つとして、または入札コードを取得するための URL のクエリ文字列として使用できます。
- 有効化時刻と有効期限: これらのフィールドでは、カスタム オーディエンスが有効になる期間を定義します。プラットフォームはこの情報を使用して、カスタム オーディエンスのメンバーシップを取り消します。有効期限は、カスタム オーディエンスの存続期間を制限する最大期間を超えることはできません。
- 日次更新 URL: 「ユーザー入札シグナル」フィールドで定義された広告候補またはその他のメタデータを、プラットフォームが定期的に取得するために使用する URL。詳細については、カスタム オーディエンスの広告候補を取得する方法についてのセクションをご覧ください。
- ユーザー入札シグナル: リマーケティング広告の入札のための、広告テクノロジー プラットフォーム固有のシグナル。シグナルの例としては、ユーザーの大まかな位置情報、優先する言語 / 地域などがあります。
- 信頼できる入札データ: 広告テクノロジー プラットフォームは、リアルタイム データに基づいて広告の取得とスコアリングについて通知します。たとえば、ある広告が予算を使い果たし、すぐに配信を停止する必要が生じることがあります。広告テクノロジーは、このリアルタイム データを取得できる URL エンドポイントと、リアルタイム検索を行う必要があるキーのセットを定義できます。このリクエストを処理するサーバーが、広告テクノロジー プラットフォームが管理する信頼できるサーバーになります。
- 入札ロジック URL: デマンドサイド プラットフォームから入札コードを取得するためにプラットフォームが使用する URL。広告オークションが開始されると、このステップが実施されます。
- 広告: カスタム オーディエンスの広告候補のリスト。これには、広告テクノロジー プラットフォーム固有の広告メタデータと、広告をレンダリングするための URL が含まれます。カスタム オーディエンス向けにオークションが開始されると、この広告メタデータのリストが考慮されます。この広告のリストは、可能な場合は日次更新 URL エンドポイントを使用してアップデートされます。モバイル デバイスではリソースの制約があるため、カスタム オーディエンスに保存できる広告の数には制限があります。
カスタム オーディエンス委任
従来のカスタム オーディエンスの定義と構成は、通常、広告テクノロジーが代理店、広告主クライアント、パートナーと連携して主導するサーバーサイドの技術と統合に依存しています。Protected Audience API は、カスタム オーディエンスの定義と構成を、ユーザーのプライバシーを保護しつつ可能にします。カスタム オーディエンスに参加するには、アプリに SDK がない購入者の広告テクノロジーが、モバイル測定パートナー(MMP)やサプライサイド プラットフォーム(SSP)などのデバイス上のプレゼンスがある広告テクノロジーと連携する必要があります。Protected Audience API は、購入者に代わってカスタム オーディエンスの作成をデバイス上で呼び出せるようにして、柔軟性のあるカスタム オーディエンス管理のソリューションを提供し、このような SDK をサポートすることを目指しています。このプロセスはカスタム オーディエンス委任と呼ばれます。カスタム オーディエンス委任を設定する手順は以下のとおりです。
カスタム オーディエンスに参加する
カスタム オーディエンスへの登録は、次の 2 つの方法でできます。
joinCustomAudience()
アプリまたは SDK は、想定されるパラメータで 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);
fetchAndJoinCustomAudience()
アプリまたは SDK は、想定されるパラメータで fetchAndJoinCustomAudience()
を呼び出すことで、デバイス上のプレゼンスがない広告テクノロジーに代わって、カスタム オーディエンスへの参加をリクエストできます。次の例をご覧ください。
FetchAndJoinCustomAudienceRequest fetchRequest = new FetchAndJoinCustomAudienceRequest(
// Example: Optional verification token passed inside the fetch URL
FetchURI = Uri.parse("https://example-dsp.com/...?mytoken=arbitrary1234"),
// All the following parameters are optional
Name = "running-shoes",
ActivationTime = now(),
ExpirationTime = ActivationTime.plus(30 days),
UserBiddingSignals = new JSONObject("{...}")
);
fetchAndJoinCustomAudience(fetchRequest);
購入者が所有する URL エンドポイントは、レスポンスの本文で CustomAudience
JSON オブジェクトを返します。カスタム オーディエンスの購入者とオーナーのフィールドは無視されます(API によって自動入力されます)。また、この API は日次更新 URL が購入者の eTLD+1 にも一致するようにします。
{
"name": "running-shoes",
"activation_time": 1680603133000,
"expiration_time": 1680803133000,
"user_bidding_signals" : {"signal1": "value"},
"trusted_bidding_data": {
"trusted_bidding_uri": "https://example-dsp.com/.."
"trusted_bidding_keys": ["k1", "k2"],
},
"bidding_logic_uri": "https://example-dsp.com/...",
"daily_update_uri": "https://example-dsp.com/...",
"ads": [
{
"render_uri": "https://example-dsp.com/...",
"metadata": {},
"ad_filters": {
"frequency_cap": {
"win": [
{
"ad_counter_key": 1,
"max_count": 2,
"interval_in_seconds": 60
},
],
"view": [
{
"ad_counter_key": 2,
"max_count": 10,
"interval_in_seconds": 3600
},
]
},
"app_install": {
"package_names": [
"package.name.one",
"package.name.two", ...
]
}
}
},
...
]
}
fetchAndJoinCustomAudience()
API は fetchUri
の eTLD+1 から購入者の ID を特定します。CustomAudience
購入者の ID は、joinCustomAudience()
が行うのと同じ登録チェックとアプリの認証チェックに使用されます。取得レスポンスによって変更することはできません。CustomAudience
オーナーは、呼び出し元アプリのパッケージ名です。eTLD+1 チェック以外に fetchUri
の検証はありません。具体的には k-匿名性のチェックはありません。fetchAndJoinCustomAudience()
API は fetchUri
に HTTP GET リクエストを発行し、カスタム オーディエンスを表す JSON オブジェクトを想定します。レスポンスには、カスタム オーディエンス オブジェクト フィールドと同じ必須、オプションの制約、デフォルト値が適用されます。現在の要件と制限事項については、デベロッパー ガイドをご覧ください。
購入者から HTTP エラーが返されると、fetchAndJoinCustomAudience
が失敗します。特に、HTTP ステータス レスポンスが 429(リクエストが多すぎる)の場合、現在のアプリケーションからのリクエストを定義される期間ブロックされます。また、購入者からのレスポンスの形式が正しくない場合も、API 呼び出しが失敗します。障害は API 呼び出し元に報告され、一時的な障害(サーバーが応答していないなど)による再試行や、永続的な障害(データ検証の失敗、サーバーとの通信に関する他の一時的でないエラーなど)の処理を行う責任があります。
CustomAudienceFetchRequest
オブジェクトを使用して、API 呼び出し元は上記の例で示すオプションのプロパティを使用してカスタム オーディエンスの情報を指定できます。リクエストでこれらの値が設定されている場合、プラットフォームが受信した購入者のレスポンスで上書きすることはできません。Protected Audience API はレスポンスのフィールドを無視します。これらのフィールドはカスタム オーディエンスの作成に必要なため、リクエストで設定されていない場合は、レスポンスで設定する必要があります。API 呼び出し元によって部分的に定義された CustomAudience
のコンテンツの JSON 表現は、特別なヘッダー X-CUSTOM-AUDIENCE-DATA
の fetchUri
への GET リクエストに含まれます。カスタム オーディエンスで指定されるデータのシリアル化された形式のサイズは、8 KB に制限されています。サイズがこれを超えると、fetchAndJoinCustomAudience
API 呼び出しは失敗します。
k-匿名性のチェックがないため、購入者の検証に fetchUri
を使用して、購入者と SDK との間で情報共有ができます。カスタム オーディエンスの検証を容易にするため、購入者は確認トークンを提示できます。デバイス上の SDK では、このトークンを fetchUri
に含める必要があります。これにより、購入者がホストするエンドポイントがカスタム オーディエンスのコンテンツを取得し、確認トークンを使用して、fetchAndJoinCustomAudience()
オペレーションが購入者に対応し、信頼できるオンデバイス パートナーから行われたことを確認できます。情報を共有するため、購入者は、カスタム オーディエンスの作成に使用される情報の一部がクエリ パラメータとして fetchUri
に追加されることについて、デバイス上の呼び出し元と合意できます。これにより、購入者は呼び出しを監査し、悪意のある広告テクノロジーで確認トークンが使用されたかどうかを検出し、複数のカスタム オーディエンスを作成できます。
確認トークンの定義と保存に関する注意事項
確認トークンは Protected Audience API の目的では使用されず、オプションです。
- 確認トークンは購入者が作成されているオーディエンスが購入者の代わりに実行されていることを確認するために使用します。
- Protected Audience API プロポーザルでは、確認トークンの形式や、購入者が確認トークンを呼び出し元に転送する方法は指定していません。たとえば、確認トークンをオーナーの SDK またはバックエンドに事前に読み込むことも、オーナーの SDK が購入者のサーバーからリアルタイムで取得することもできます。
カスタム オーディエンスから脱退する
カスタム オーディエンスのオーナーは、次のコード スニペットに示すように、leaveCustomAudience()
を呼び出して脱退することもできます。
// Invoke ad services API to leave a custom audience.
leaveCustomAudience(buyer, name);
カスタム オーディエンスは、ストレージやその他のデバイス リソースの使用量を節約するために、所定の期間が経過すると期限切れとなり、デバイス上のストアから削除されます。デフォルト値は未定です。オーナーはこのデフォルト値をオーバーライドできます。
ユーザー コントロール
- このプロポーザルは、カスタム オーディエンスを 1 つ以上作成したインストール済みのアプリのリストをユーザーが確認できるようにすることを目的としています。
- ユーザーはこのリストからアプリを削除できます。削除すると、アプリに関連付けられているカスタム オーディエンスがすべて消去され、アプリが新しいカスタム オーディエンスに参加できなくなります。
- ユーザーは Protected Audience API を完全にリセットできます。リセットした場合、デバイス上の既存のカスタム オーディエンスはすべて消去されます。
- ユーザーは Protected Audience API を含む Android 版プライバシー サンドボックスから完全にオプトアウトできます。ユーザーがプライバシー サンドボックスをオプトアウトしている場合、Protected Audience API は通知なく失敗します。
この機能の設計は現在進行中であり、詳細については今後のアップデートに反映される予定です。
アプリの権限とコントロール
このプロポーザルは、アプリがカスタム オーディエンスを管理できるようにすることを目的としています。
- アプリはカスタム オーディエンスとの関連付けを管理できます。
- アプリは、第三者の広告テクノロジー プラットフォームに、アプリに代わってカスタム オーディエンスの管理権限を付与できます。
この機能の設計は現在実施中であり、詳細については今後のアップデートに反映される予定です。
広告テクノロジー プラットフォームによるコントロール
このプロポーザルでは、広告テクノロジーがカスタム オーディエンスをコントロールする方法の概要を説明します。
- 広告テクノロジーはプライバシー サンドボックスに登録し、カスタム オーディエンスのすべての URL と一致する eTLD+1 ドメインを指定します。
- 広告テクノロジーはアプリまたは SDK と連携し、確認トークンを使ってカスタム オーディエンスの作成を検証できます。このプロセスがパートナーに委任する場合、カスタム オーディエンスの作成において、広告テクノロジーによる承認を必須とするよう設定できます。
- 広告テクノロジーに代わって
joinCustomAudience
の呼び出しを無効にし、fetchAndJoinCustomAudience
API のみすべての呼び出しカスタム オーディエンスの有効化ができるようにすることもできます。コントロールはプライバシー サンドボックスの登録時に更新できます。コントロールではすべての広告テクノロジーを許可するか、一切許可しないかを選択できます。プラットフォームの制限により、委任権限を広告テクノロジーごとに指定することはできません。
広告候補とメタデータのレスポンス
バイサイド プラットフォームから返される広告候補とメタデータには、次のフィールドが含まれている必要があります。
- メタデータ: バイサイドの広告テクノロジー固有の広告メタデータ。たとえば、広告キャンペーンに関する情報や、地域や言語などのターゲティング条件が含まれる場合があります。
- レンダリング URL: 広告クリエイティブをレンダリングするためのエンドポイント。
- フィルタ: Protected Audience がデバイス上のデータに基づいて広告をフィルタするために必要なオプションの情報。詳細はバイサイド フィルタリング ロジックのセクションをご覧ください。
広告選択ワークフロー
このプロポーザルでは、広告テクノロジー プラットフォームのオークションの実施を調整する Ad Selection API を導入することで、プライバシーを向上させることを目的としています。
現在の広告テクノロジー プラットフォームは、入札と広告の選択を自社サーバーのみで行うことが一般的です。このプロポーザルでは、カスタム オーディエンスと、利用可能なインストール済みパッケージ情報などのその他の機密性の高いユーザー シグナルには、Ad Selection API を介してのみアクセスできます。また、リマーケティングのユースケースでは、候補広告は帯域外(つまり、広告が表示されるコンテキストで取得されません)で取得されます。広告テクノロジー プラットフォームは、現在のオークションと広告選択ロジックの一部をデバイスにデプロイして実行するための準備を行う必要があります。広告テクノロジー プラットフォームでは、広告選択ワークフローに対して次の変更を検討する場合があります。
- インストール済みパッケージ情報がサーバーで利用できない場合、広告テクノロジー プラットフォームは、複数のコンテンツ ターゲット広告をデバイスに送り返し、関連性の高い広告が表示される可能性を最大化するために、広告選択ワークフローを呼び出してアプリのインストール ベースのフィルタリングを有効にします。
- リマーケティング広告は範囲外で取得されるため、現在の入札モデルをアップデートする必要が生じる場合があります。広告テクノロジー プラットフォームは、広告機能とコンテキスト シグナルを別々に処理し、デバイス上のサブモデル出力を組み合わせて入札単価を予測できる入札サブモデル(Two-Tower モデルと呼ばれるパターンに基づく実装)を作成することが必要な場合があります。これにより、サーバーサイド オークションと、任意の広告配信機会のオークションの両方にメリットが生じます。
このアプローチでは、ユーザーのアプリ操作データを広告の選択に利用しつつ、第三者とのデータ共有を制限できます。
この広告選択ワークフローは、以下の順に沿って、広告テクノロジーが提供する JavaScript コードのデバイス上における実行を調整します。
カスタム オーディエンスが関係する広告選択の場合、プラットフォームは、カスタム オーディエンスの「入札ロジック 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 エンドポイントと、リアルタイム検索を行う必要があるキーのセットを定義できます。このリクエストを処理する広告テクノロジー プラットフォームが管理するサーバーが、広告テクノロジー プラットフォームが管理する信頼できるサーバーになります。
- コンテキスト シグナル: あいまいなタイムスタンプ、おおよその位置情報、広告のクリック単価など。
- ユーザー シグナル: 利用可能なインストール済みパッケージ情報などの情報が含まれることがあります。
広告費用
バイサイド プラットフォームには、入札に加え、generateBid()
の一部としてクリック単価を返すこともできます。次に例を示します。
generateBid(ad, auction_signals, per_buyer_signals, trusted_bidding_signals,
contextual_signals, user_signals, custom_audience_signals) {
// ...
return {'bid': ..., 'adCost': ...,};
}
この広告が落札した場合、adCost
はプライバシーを確保するために 8 ビットに確率論的に丸められます。adCost
の丸められた値は、インプレッション レポートの際に reportWin
の contextual_signals
パラメータに渡されます。
バイサイド フィルタリング ロジック
バイサイド プラットフォームでは、広告選択フェーズで利用できる追加のデバイス上のシグナルに基づいて、広告をフィルタできます。たとえば、広告テクノロジー プラットフォームはここでフリークエンシー キャップ機能を実装できます。フィルタリング プロバイダが複数ある場合、プロバイダ間の実行順序は保証されません。
バイサイド フィルタリング ロジックは、入札ロジックの一部として、特定の広告の入札単価 0
を返す形で実装できます。
さらに、バイサイド プラットフォームは Protected Audience で利用できる、デバイス上の追加のシグナルに基づいて特定の広告をフィルタする必要があるということを通知できます。デバイスを離れることはありません。追加のフィルタリング ロジックの設計が固まれば、バイサイド プラットフォームは同じ構造に従って、フィルタリングが行われることを通知します。
セルサイド スコアリング ロジック
通常、スコアリング ロジックはセルサイド プラットフォームが提供します。このコードの目的は、入札ロジックの出力に基づいて落札広告を決定することです。結果を判断するために、追加のビジネス ロジックが適用される場合があります。判断ロジックのプロバイダが複数ある場合、プロバイダ間の実行順序は保証されません。プラットフォームは、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 のプロポーザルと同様)。
インプレッションとイベントに関するレポート
広告がレンダリングされると、参加しているバイサイド プラットフォームとセルサイド プラットフォームに落札インプレッションをレポートできます。これにより、購入者と販売者は、落札インプレッション レポートに、入札単価やカスタム オーディエンス名などのオークションの情報を含めることができます。また、セルサイド プラットフォームと落札したバイサイド プラットフォームは、落札広告に関する追加のイベントレベル レポートを受け取ることができます。これにより、クリック数や視聴回数などの広告イベントを含むオークションに関する情報(入札単価、カスタム オーディエンス名など)を含めることができます。プラットフォームは、次の順序でレポート ロジックを呼び出します。
- セルサイド レポート
- バイサイド レポート
これにより、バイサイド プラットフォームとセルサイド プラットフォームはデバイス上の重要な情報をサーバーに送り返し、リアルタイムの予算編成、入札モデルの更新、正確な請求ワークフローなどの機能を実現できます。このインプレッション レポートのサポートは、Attribution Reporting API を補完するものです。
イベント レポートをサポートするには、2 つのステップがあります。セルサイドとバイサイドの JavaScript は、イベント レポートを受け取るべきイベントを登録する必要があります。セルサイドは、イベントレベルの情報をレポートします。
Protected Audience は、ビーコンを登録することで、落札したオークションに関連する将来のイベントをサブスクライブするメカニズムを提供します。販売者の reportResult()
JavaScript 関数では、セルサイド プラットフォームはプラットフォームの registerAdBeacon()
関数を使用してビーコンを登録できます。同様に、バイサイド プラットフォームは reportWin()
JavaScript 関数から registerAdBeacon()
メソッドを呼び出すことができます。
registerAdBeacon(beacons)
入力:
event_key
: 登録するインタラクションのタイプを示す文字列。これは、オークションの結果をレポートしながら、プラットフォームが ping するエンドポイントを検索するためのキーとして使用されます。reporting_url
: イベントを処理するために広告テクノロジー プラットフォームが所有する URL。
イベントキーは、オークションの結果を報告するセルサイドの SDK が所有する文字列識別子です。コールバックが行われるように、広告テクノロジーは、イベントの報告時にセルサイドが使用するキーと一致するキーでビーコンを登録します。k-匿名性を持つ必要はありませんが、特定のカスタム オーディエンスに登録できるキーの数と長さには制限があります。reportEvent()
が呼び出されると、オークションを実施したセルサイド プラットフォームは常に、これらのイベント レポートを受け取ることができます。落札したバイサイド プラットフォームのみがこれらのレポートを受け取ることができます。
セルサイド レポート
プラットフォームは、selectAds()
API の販売者の判断ロジック URL パラメータからダウンロードしたサプライサイド提供のコードで reportResult()
JavaScript 関数を呼び出します。
reportResult(render_url, bid, auction_config, contextual_signals) {
// ...
beacons = {"click":clickUri}
registerAdBeacon(beacons)
return {
"status": 0,
"results": {"reporting_url": reporting_url,
"signals_for_buyer": signals_for_buyer}};
}
出力: JSON オブジェクト。
- ステータス:
0
(成功の場合)、その他の値(失敗の場合)。 - レポート URL: プラットフォームは、関数から返されたこの URL を呼び出します。
- 購入者へのシグナル: 購入者の
reportWin
関数に渡される JSON オブジェクト。
サプライサイドは、レポート URL で関連性の高いシグナルをエンコードすることで、オークションや落札広告についてさらに詳しい分析情報を得ることができます。たとえば、次のようなシグナルが該当します。
- 広告レンダリング URL
- 落札単価
- アプリ名
- クエリ識別子
- 購入者へのシグナル: サプライサイドとデマンドサイドの間でのデータ共有をサポートするために、プラットフォームはこの戻り値を入力パラメータとしてデマンドサイドのレポートコードに渡します。
バイサイド レポート
プラットフォームは、オークションに関連付けられたカスタム オーディエンスの入札ロジック URL メタデータからダウンロードされたデマンドサイド提供コードで reportWin()
JavaScript 関数を呼び出します。
reportWin(render_url, bid, auction_signals, per_buyer_signals,
signals_for_buyer, contextual_signals, custom_audience_signals) {
// ...
beacons = {"click":clickUri}
registerAdBeacon(beacons)
return {
"status": 0,
"results": {"reporting_uri": reporting_uri}};
}
入力:
auction_signals
とper_buyer_signals
はAuctionConfig
から取得されます。バイサイド プラットフォームがレポート URL に渡す必要がある情報は、このデータから取得される可能性があります。signals_for_buyer
は、セルサイドの reportResult の出力です。これにより、セルサイド プラットフォームはレポートのためにバイサイド プラットフォームとデータを共有できます。contextual_signals
にはアプリ名などの情報が含まれ、custom_audience_signals
にはカスタム オーディエンス情報が含まれます。今後、その他の情報が追加される可能性があります。
出力:
- ステータス:
0
(成功の場合)、その他の値(失敗の場合)。 - レポート URL: プラットフォームは、関数から返されたこの URL を呼び出します。
イベントの報告
イベントのレポートは、オークションのインプレッション レポートが完了した後にのみ可能になります。セルサイド SDK はイベントの報告を行います。プラットフォームは、最近開催されたオークション、報告されたイベントキー、そのキーに関連付けられたデータ、レポートを購入者と販売者(またはその両方)に送信するかどうか、および広告イベントのオプションの入力イベントを指定する ReportEventRequest
を受け取る API を公開します。クライアントは、イベントキーとレポートするデータの収集を定義します。
ReportEventRequest request = new ReportEventRequest(
AdSelectionId = ad_selection_id,
event_key = "view"
event_data = "{ "viewTimeInSeconds" :1 }",
reporting_destinations =
FLAG_REPORTING_DESTINATION_SELLER |
FLAG_REPORTING_DESTINATION_BUYER,
input_event = clickInputEvent // or null for view
)
reportEvent(request)
入力:
ad_selection_id
は、AdSelectionOutcome
から取得した、最近実施されたオークションのAdSelectionId
である必要があります。event_key
は、インタラクション イベントを説明するセルサイドで定義された文字列です。event_data
は、event_key
に関連付けられたデータを表す文字列です。reporting_destinations
は、プラットフォームが提供するフラグを使用して設定されるビットマスクです。FLAG_REPORTING_DESTINATION_SELLER
とFLAG_REPORTING_DESTINATION_BUYER
のいずれか、または両方を指定できます。input_event
(省略可)は、Attribution Reporting API との統合に使用されます。これは、InputEvent
オブジェクト(クリック イベントの場合)または null(ビューイベントの場合)のいずれかです。このパラメータの詳細については、Attribution Reporting API の統合をご覧ください。
セルサイド SDK が reportEvent
を呼び出した後、プラットフォームは、reporting_destinations
フラグに応じて、event_key
と、reportWin
および reportResult
JavaScript 関数で購入者と販売者が登録した鍵とのマッチングを試みます。一致する場合、プラットフォームは関連する reporting_url
に event_data
を POST します。リクエストのコンテンツ タイプは書式なしテキストで、本文は event_data
です。このリクエストはベスト エフォートで行われ、ネットワーク エラー、サーバーエラー レスポンスが発生した場合、または一致するキーが見つからなかった場合、通知なく失敗します。
Attribution Reporting API の統合
Protected Audience オークションに参加する購入者をサポートするために、Protected Audience API と Attribution Reporting API(ARA)にクロス API 機能を提供しています。この機能により、広告テクノロジーはさまざまなリマーケティング戦術でアトリビューションのパフォーマンスを評価し、どのタイプのオーディエンスが最も ROI が高いかを把握できます。
このクロス API 統合により、アドテックは次のことが可能になります。
- 1)広告インタラクション レポートと 2)ソース登録の両方に使用する URI の Key-Value マップを作成します。
- Protected Audience オークションのオークション データを集計サマリー レポートのソース側のキーマッピングに含めます(Attribution Reporting API を使用)。詳しくは、ARA 設計案をご覧ください。
ユーザーが広告を表示またはクリックすると、次のようになります。
- Protected Audience を使用して、このようなイベントのインタラクションをレポートするために使用される URL は、必要なデータを提供します。この URL は、Attribution Reporting API でビューまたはクリックを適格ソースとして登録する際に必要となるデータを提供します。
- 広告テクノロジーは、その URL を使用して
CustomAudience
(または広告の配置や視聴時間など、広告に関するその他の関連するコンテキスト情報)を渡すこともできます。これにより、広告テクノロジーがキャンペーンの集計パフォーマンスを確認しているときに、このメタデータを概要レポートに伝播できます。
ソース登録の有効化
reportEvent()
は、新しい省略可能なパラメータ InputEvent
を受け入れます。広告ビーコンを登録して落札した購入者は、どの reportEvent レポートを登録ソースとして Attribution Reporting API に登録するかを選択できます。リクエスト ヘッダー Attribution-Reporting-Eligible は、reportEvent()
から送信されたすべてのイベント レポート リクエストに追加されます。適切な ARA ヘッダーを含むレスポンスは、他の通常の ARA ソース登録レスポンスと同じ方法で解析されます。ソース URL を登録する方法については、Attribution Reporting API の説明をご覧ください。
Android の ARA ではビューイベントとクリック イベントがサポートされているため、この 2 種類のイベントを区別するために InputEvents
が使用されます。ARA ソース登録と同様に、reportEvent()
API はプラットフォーム検証済みの InputEvent
をクリック イベントとして解釈します。InputEvent
が欠落しているか、null または無効な場合、ソース登録はビューと見なされます。
オークション後の eventData
には機密情報が含まれる可能性があるため、プラットフォームはリダイレクトされるソース登録リクエストで eventData
を除外します。
エンゲージメントとコンバージョンのレポートの例
この例では、オークション、レンダリングされた広告、コンバージョン アプリのデータを関連付けたいと考えている購入者の視点から見てみましょう。
このワークフローでは、購入者は販売者と連携して一意の ID をオークションに送信します。オークション中に、購入者がオークション データとともにこの一意の ID を送信します。レンダリング時とコンバージョン時に、レンダリングされた広告のデータも同じ一意の ID で送信されます。後で一意の ID を使用して、これらのレポートを関連付けることができます。
ワークフロー: オークションを開始する前に、購入者はプログラマティック リアルタイム ビッダー(「RTB」)入札レスポンスの一部として一意の ID を販売者に送信します。ID は auctionId
のような変数として設定できます。ID は auctionConfig
で perBuyerSignals
として渡され、購入者の入札ロジックで使用できるようになります。
reportWin
の実行中に、広告のレンダリング時と特定のインタラクション イベント(registerAdBeacon()
)でトリガーされる広告ビーコンを登録できます。広告イベントにオークション シグナルを関連付けるには、ビーコン URL のクエリ パラメータとしてauctionId
を設定します。- 広告のレンダリング中は、オークション時に登録したビーコンをトリガーしたり、イベントレベルのデータで拡張したりできます。販売者は
reportEvent()
をトリガーし、イベントレベルのデータを渡す必要があります。プラットフォームは、トリガーされたreportEvent()
に対応する購入者の登録済み広告ビーコン URL を ping します。 - 購入者は、
Attribution-Reporting-Register-Source
ヘッダーを使用して広告ビーコンのリクエストに応答することで、Attribution Reporting API に広告を登録します。コンバージョン イベントにオークション シグナルを関連付けるには、[ソース URL を登録] でauctionId
を設定します。
上記の手順を終えると、購入者はオークション レポート、インタラクション レポート、コンバージョン レポートを取得し、一意の ID を使用して相互に関連付けることができます。
販売者がアトリビューション データにアクセスする必要がある場合は、同様のワークフローが適用されます。販売者は、一意の ID を使用して registerAdBeacon()
で送信することもできます。reportEvent()
呼び出しには、購入者と販売者の両方にレポートを送信するために使用できる宛先プロパティが含まれます。
広告テクノロジー プラットフォームが管理する信頼できるサーバー
現在の広告選択ロジックでは、広告候補をオークション用に選択すべきかどうかを判断するために、予算の枯渇ステータスなどのリアルタイムの情報が必要です。バイサイド プラットフォームとセルサイド プラットフォームの両方が、それぞれが運用するサーバーからこの情報を取得できます。これらのサーバーを介した機密情報の漏洩を最小限に抑えるため、提案では次の制限を要求するようになっています。
- これらのサーバーの動作(このセクションで後述)によってユーザー情報が漏洩しない。
- サーバーが、参照するデータに基づいて仮名化されたプロファイルを作成しない(つまり「信頼できる」必要がある)。
バイサイド: バイサイドがバイサイド入札ロジックを開始すると、プラットフォームは、信頼できるサーバーから信頼できる入札データの 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 型サーバーを使用できます。