Topics API によるインタレスト ベース広告

フィードバックを送信

Topics API について

モバイル広告では、広告主はユーザーの興味との関連性が高い広告を配信したいと考えます。たとえば、料理関連の情報に興味を持っているユーザーであれば、自分の興味と関係のない広告よりも、料理に関連する広告により関心を示すでしょう。

インタレスト ベース広告(IBA)はパーソナライズド広告の一種であり、ユーザーが過去に使用したアプリから得られた興味に基づいて、ユーザーに表示する広告を選択します。これは、現在表示されているコンテンツから得られる興味だけをベースとする、コンテンツ ターゲット広告とは異なります。IBA の利点は、コンテンツ ターゲット広告よりも関連性の高い魅力的な広告をアプリでユーザーに表示できるという点です。

Topics API は、デバイス上でのユーザーのアプリ使用状況に基づいて、興味に関する大まかなシグナルを推定します。これらのシグナルはトピックと呼ばれ、広告主と共有されます。トピックを使用することで、アプリ間で個々のユーザーを追跡することなく IBA のユースケースがサポートされます。

主な概念

  • トピックは、ユーザーの興味を示すもので、人が読める形式になっています。Topics 分類に含まれます。
  • エポックは、トピックの算出を行う期間です(例: 1 週間)。
  • トピックは、呼び出し元(アプリ、またはアプリで使用されているサードパーティ SDK)によって参照されます。呼び出し元が、3 エポックの間に、トピックに関連付けられたアプリから Topics API リクエストを行った場合に参照されます。

仕組み

今回の提案では、Topics API を使用して、ユーザーのアプリ使用状況に基づいた興味に関する大まかな広告トピックを、呼び出し元に提供することを目的としています。これらのトピックを使用すると、広告を表示するアプリに関連するコンテキスト情報を補完でき、組み合わせることでユーザーに適した広告を見つけられます。

説明のため、インタレスト ベース広告を取得するためのトピックの使用方法を次のコード スニペットに示します。使用されている 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.
            ...
        }
});

トピックは事前に定義された分類から選択されます。

プラットフォームは分類器モデルを使用してトピックを推定します。Topics API の実装と分類器の使用方法は Android オープンソース プロジェクトの一部となり、今後改善される予定です。

Topics API を呼び出す際には、API から受信したキャッシュ内のレスポンスの使用は控えます。これは、トピック情報の使用についてユーザーによる制御を優先するためで、API リクエストはトピックが使用されるたびに実行する必要があります。トピックを広告のパーソナライズに使用する場合は、現在の API レスポンスから受信したトピックのみをアプリで使用します。以前の Topics API の呼び出しで取得された戻り値と結合すべきではありません。

詳細

  • ユーザーの上位 5 つのトピックが、週 1 回などのエポックごとに、デバイス上の情報を使用して計算されます。

    • プラットフォームでは、Topics API が呼び出された際に、API を呼び出しているアプリにトピックが割り当てられているか確認されます。割り当てられているトピックがない場合には、以下のルールに沿って選択が行われます。選択されたトピックが、エポックの残り期間中にアプリに割り当てられます。
      • 95% の確率で、エポック中に算出された上位 5 つのトピックリストから、ランダムにトピックが選択されます。
      • 5% の確率で、分類からランダムにトピックが選択されます。
    • アプリごとに複数のトピックからいずれかを取得する仕組みとなっているのは、アプリが異なればトピックも異なるようにするためです。同じユーザーに関する情報を複数のアプリで関連付けることが難しくなるようにしています。
      • たとえば、アプリ A ではユーザーのトピックとして T1 が示され、アプリ B では T2 が示されます。この場合、情報が同じユーザーに関連するものかどうかを判別するのは、双方のアプリにおいて難しくなります。
  • Topics API では、3 つまでのトピックのリストが返されます。トピックは、過去の 3 つのエポックのそれぞれから 1 つが選ばれます。

    • トピックが 3 つまで提供されると、使用頻度の低いアプリの場合は、関連性の高い広告を見つけるうえで十分なトピック数になります。一方で、使用頻度の高いアプリの場合は、最大で 1 週間に 1 つのトピックを新たに学習します。
    • 返されるトピック情報には、トピック名(文字列)、分類のバージョン、分類器モデルのバージョンが含まれます。
    • 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 エポックの間に返されたトピックのリストからトピックが削除されることはありません。これは、アンインストールに関する情報が開示されることを避けるためです。