Topics API について
モバイル広告では、広告主はユーザーの興味との関連性が高い広告を配信したいと考えます。たとえば、料理関連の情報に興味を持っているユーザーであれば、自分の興味と関係のない広告よりも、料理に関連する広告のほうに関心を示すでしょう。
インタレスト ベース広告(IBA)はパーソナライズド広告の一種であり、ユーザーが過去に使用したアプリから得られた興味に基づいて、ユーザーに表示する広告を選択します。これは、現在表示されているコンテンツから得られる興味だけをベースとする、コンテンツ ターゲット広告とは異なります。IBA の利点は、コンテンツ ターゲット広告よりも関連性の高い魅力的な広告をアプリでユーザーに表示できるという点です。
Topics API は、デバイス上でのユーザーのアプリ使用状況に基づいて、興味に関する大まかなシグナルを推定します。これらのシグナルは「トピック」と呼ばれ、広告主と共有されます。トピックを使用することで、アプリ間で個々のユーザーを追跡することなく IBA のユースケースがサポートされます。
主な概念
- トピックは、ユーザーの興味を示すもので、人が読める形式になっています。Topics 分類に含まれます。
- トピックは、呼び出し元(アプリ、またはアプリで使用されているサードパーティ SDK)によって参照されます。呼び出し元が、3 エポックの間に、トピックに関連付けられたアプリから Topics API リクエストを行った場合に参照されます。
- エポックは、トピックの算出を行う期間です(例: 1 週間)。
仕組み
今回の提案では、Topics API を使用して、ユーザーのアプリ使用状況に基づいた興味に関する大まかな広告トピックを、呼び出し元に提供することを目的としています。これらのトピックを使用すると、広告を表示するアプリに関連するコンテキスト情報を補完でき、組み合わせることでユーザーに適した広告を見つけられます。
インタレスト ベース広告のためのトピック取得機能をセットアップする方法を示すコード例については、Topics API デベロッパー ガイドをご覧ください。注: API はまだ最終版ではありません。
トピックは事前に定義されたオープンソースの分類から選択されます。
プラットフォームは分類器モデルを使用してトピックを推定します。Topics API の実装と分類器の使用方法は Android オープンソース プロジェクトの一部となり、今後改善される予定です。
説明のため、インタレスト ベース広告を取得するためのトピックの使用方法を次のコード例に示します。ここで使用されている API は最終版ではありません。
// Initialize the Topics API.
…
topicsFuture = AdvertisingTopicsClient.getTopics();
// Retrieve Topics and use them in Ad request.
Futures.addCallback(
topicsFuture,
new FutureCallback<AdvertisingTopicsInfo>() {
@Override
public void onSuccess(@Nullable AdvertisingTopicsInfo topicsInfo) {
// Sanitize Topics result.
...
// Initialize ad request with Topics obtained.
AdRequest adRequest = AdRequest.initialize(topicsInfo);
}
@Override
public void onFailure(Throwable t) {
// Handle error.
...
}
});
分類器モデルの仕組みをより深く理解するために、Android Topics Classifier Colab を使用して、システム内での各種アプリデータに対する反応をテストしてみてください。
Topics API へのアクセス権を取得する
Topics API にアクセスするには、アドテック プラットフォームの登録が必要です。詳しくは、プライバシー サンドボックス アカウントの登録をご覧ください。
詳細
ユーザーの上位 5 つのトピックが、週 1 回などのエポックごとに、デバイス上の情報を使用して計算されます。
- プラットフォームでは、Topics API が呼び出された際に、API を呼び出しているアプリにトピックが割り当てられているか確認されます。割り当てられているトピックがない場合には、以下のルールに沿って選択が行われます。選択されたトピックが、エポックの残り期間中にアプリに割り当てられます。
- 95% の確率で、エポック中に算出された上位 5 つのトピックリストから、ランダムにトピックが選択されます。
- 5% の確率で、分類からランダムにトピックが選択されます。
- 呼び出し元は、
shouldRecordObservation = false
パラメータを使用してgetTopics
を呼び出すことで、状態を変更せずにトピックを取得するよう指定できます。つまり、トピックは返されますが、呼び出しは週ごとのエポック計算に含まれず、呼び出し元に対して確認されたトピックのリストも更新されません。
- アプリごとに複数のトピックからいずれかを取得する仕組みとなっているのは、アプリが異なればトピックも異なるようにするためです。同じユーザーに関する情報を複数のアプリで関連付けることが難しくなるようにしています。
- たとえば、アプリ A ではユーザーのトピックとして T1 が示され、アプリ B では T2 が示されます。この場合、情報が同じユーザーに関連するものかどうかを判別するのは、双方のアプリにおいて難しくなります。
- プラットフォームでは、Topics API が呼び出された際に、API を呼び出しているアプリにトピックが割り当てられているか確認されます。割り当てられているトピックがない場合には、以下のルールに沿って選択が行われます。選択されたトピックが、エポックの残り期間中にアプリに割り当てられます。
Topics API では、3 つまでのトピックのリストが返されます。トピックは、過去の 3 つのエポックのそれぞれから 1 つが選ばれます。
- トピックが 3 つまで提供されると、使用頻度の低いアプリの場合は、関連性の高い広告を見つけるうえで十分なトピック数になります。一方で、使用頻度の高いアプリの場合は、最大で 1 週間に 1 つのトピックを新たに学習します。
- 返されるトピック情報には、分類のエントリに対応するトピック ID(int)、分類のバージョン、分類器モデルのバージョンが含まれます。
- 3 エポックの間に、該当するトピックに関連付けられたアプリをユーザーが使用したことが確認された場合にだけ、呼び出し元はトピックを受信できます。
- 返されるトピックは、すべてユーザーの興味に該当するものであるため、広告リクエストではこれらのいずれか、またはすべてのトピックを広告のパーソナライズに使用できます。
トピックが Topics API を呼び出すアプリに割り当てられると、呼び出し元がこのトピックを受け取れるかどうかがプラットフォームで判断されます。
- 3 エポックの間に、該当するトピックに関連付けられたアプリのユーザー エンゲージメントが確認された場合にだけ、呼び出し元はトピックを受信できます。
- 呼び出し元がアプリ上のユーザーのトピックについて API を呼び出したことがない場合は、API の返すリストにそのトピックは含まれません。
- 3 エポックの間に、呼び出し元がトピックを受け取っていない場合、Topics API は空のリストを返します。
たとえば、ユーザーがデバイスに 7 つのアプリ(A、B、C、D、E、F、G)をインストールしているとします。アプリのトピック分類とアプリの広告テクノロジー SDK が、次のようになっているとします。
アプリ トピック分類 アドテック SDK A T1、T5 ad-sdk1、ad-sdk2 B T2 ad-sdk2 C T3、T6 ad-sdk3、ad-sdk4 D T1、T4 ad-sdk1 E T5 ad-sdk4、ad-sdk5 F T6 ad-sdk2、ad-sdk3、ad-sdk4 G T7 ad-sdk2 - 第 1 週の終わりに、Topics API がこのエポックの上位 5 つのトピックを生成します。
上位のトピック トピックの学習が可能な呼び出し元 T1 ad-sdk1、ad-sdk2 T2 ad-sdk2 T3 ad-sdk3、ad-sdk4 T4 ad-sdk1 T5 ad-sdk1、ad-sdk2、ad-sdk4、ad-sdk5 - 第 2 週にいずれかのアプリの呼び出し元が API を呼び出すと、該当するエポック、トピック、アプリについて、呼び出し元が「トピックの学習が可能な呼び出し元」の列にあるトピックのみを含んだリストが返されます。
- トピックの算出に際し、各呼び出し元が利用できる履歴ウィンドウは、3 エポック(3 週間)です。
- 使用できるトピックは、Topics API を直接、または広告 SDK を通じて呼び出しているアプリに関連付けられたもののみです。つまり、アプリに Topics API を呼び出す広告 SDK が含まれておらず API 自体を呼び出さない場合には、そのアプリに関連付けられたトピックは、他のアプリや広告 SDK と共有されるトピックに影響を及ぼしません。
- アプリで新しいマニフェストと XML 要素を介して Topics API のオプトアウトを宣言し、広告 SDK がそのアプリで API を使用できないようにすることもできます。オプトアウトしたアプリに関連付けられたトピックは、週ごとのトピックの算出には影響を及ぼしません。このドキュメントは、関連する実装の詳細を含むように更新される予定です。
プラットフォームで 5 つのトピックを推測できるほどアプリが使用されていない場合は、残りのトピックをランダムに生成するなどのオプションが検討される可能性があります。
分類
- 現在の提案では、最初の分類には数百から数千のトピックが含まれます。このドキュメントの今後の更新で、最初の分類案が共有されます。
- この分類は、プライベートなトピックが含まれないように、人の手を経てキュレートされます。
- この分類は、Android のモバイルアプリでの表示が可能な広告のカテゴリに合わせてカスタマイズされます。
- 分類はオープンソースであり、変更される可能性があります。ページ上部のフィードバック ボタンを使用して提案を提出できます。
トピック分類器
興味に関するトピックは、一般公開されているアプリ情報(アプリ名、説明、パッケージ名など)でトレーニングされた分類器モデルから得られます。
- 推論に分類器モデルを使用して所定のエポックのトピックを算出すると、使用されたシグナルのセットがデバイスに残ります。このシグナルのセットには、インストール済みのアプリまたは最近使用されたアプリを含めることができ、後で他のシグナルを含むように拡張される場合があります。
- 初期モデルは Google がトレーニングします。トレーニング データには、一般公開されているアプリ情報について人の手を経てキュレートしたラベルが含まれます。このモデルは、アプリでのトピック分類のテストを行うために自由に利用することができます。
- 初期モデルは、Google Play ストアなどの一部のアプリストアで公開されているアプリの情報を使用してトレーニングされます。
- アプリが複数のトピックにマッピングされる、トピックにマッピングされない、またはユーザーのトピック履歴に追加されない可能性があります。分類の際にアプリが複数のトピックにマッピングされる場合、アプリに対して選択されるトピックの数が上位 3 つに制限されます。
ユーザー コントロール
- 今回の設計では、アプリの使用状況に関連するトピックをユーザーが表示、削除できるようにしています。このユーザー コントロール機能の実装は現在進行中であり、今後のアップデートに反映される予定です。
- 3 エポックの間に推定されたトピックの選択に関係するアプリを、ユーザーがアンインストールする場合、3 エポックの間に返されたトピックのリストからトピックが削除されることはありません。これは、アンインストールに関する情報が開示されることを避けるためです。
エンドユーザー エクスペリエンスがどのようになるかをテストするには、アプリ内インテントを起動して、エンドユーザーが目にする外観に近いトピックの設定 UI を表示します。以下に、この呼び出しの例を示します。
//Button that launches settings UI
private Button mSettingsAppButton;
private static final String RB_SETTING_APP_INTENT = "android.adservices.ui.SETTINGS";
//Does setup for button on screen that will launch settings UI to observe Topics
private void registerLauchSettingsAppButton() {
mSettingsAppButton.setOnClickListener(
new View.OnClickListener() {
@Override
public void onClick(View view) {
Context context = getApplicationContext();
Intent activity2Intent = new Intent(RB_SETTING_APP_INTENT);
activity2Intent.setFlags(Intent.FLAG_ACTIVITY_NEW_TASK);
context.startActivity(activity2Intent);
}
});
}