デジタル広告に対するユーザーの反応を予測するクライアントの機能をサポートするために、Xandr はデシジョン ツリーに基づくカスタム モデルを提供します。 ユーザーが意思決定ツリーを作成して行項目パラメーターを動的に入力できるようにする Bonsai という使いやすいプログラミング言語を開発しました。
デシジョンツリーは、従来のターゲティングベースの形式の予測にマッピングする単純な離散モデルに適していますが、多くの次元と大きなカテゴリ特徴の疎な行列に相当するものを効果的にモデル化するには苦労しています。 Bonsai は理解しやすく使いやすいですが、機能間の関係を効率的に表現できないため、機械やデータ サイエンティストにとって必ずしも十分ではありません。 これらのより複雑なニーズに対して、Xandr はロジスティック回帰モデルを使用します。
ロジスティック回帰は、複数のシグナルの組み合わせからバイナリ応答 (クリックまたはクリックしない、購入または購入しない) の確率を予測するための基本的なアプローチです。 ロジスティック回帰データを利用することで、サイエンティストは、より正確な予測を生成し、大規模に迅速にトレーニングできる、より表現力豊かなモデルを実行できます。 カスタマイズされたアルゴリズムを構築することで、高度なデータ サイエンス ツールを備えたクライアントは、Xandr が提供する組み込みの最適化よりも優れたパフォーマンスを達成し、複雑なオフライン モデルをリアルタイムで実行できます。
ロジスティック回帰の式
ロジスティック回帰は分類アルゴリズムです。 これは、一連の独立変数に基づいてバイナリ結果 (クリックする、クリックしないなど) を予測するために使用されます。
ロジスティック回帰の式は次のとおりです。
ここで、モデル化される確率 (p) は、イベント = 1 またはイベント = 0 のバイナリ結果の確率です。 オンライン広告の場合、イベントはクリック、ピクセル ファイア、または別のオンライン アクションです。 確率は、予測変数 x1 から xn と、入札要求内の機能を表す変数の暗黙のセットの両方によって条件付きです。 ベータ係数は、モデルがさまざまな予測変数に割り当てる重みです。
この確率にイベントの値 (クリック予測の eCPC 目標など) を掛け、推定値に加法オフセットを追加してから、最小/最大期待値の制限を適用して、誤予測の影響を減らすことで、イベントが発生する確率を予想値に変換します。
イベントが発生する確率からインプレッションの期待値を導き出す式は次のとおりです。
オフセットは通常 0 です。 ただし、負の値は、パフォーマンスの低い在庫での出荷を犠牲にしてパフォーマンスを確保するためのセキュリティ要素として役立つ場合があります。 これにより、広告主は、非常に少ない入札単価で固定料金が発生する可能性がある代わりに、入札することがなくなります。
オンライン広告のカテゴリ化された特徴量の使用例
オンライン広告には、カテゴリ固有の特徴が数多く存在します。つまり、多くの値を持つことができる特徴です。 たとえば、ブラウザー、ドメイン、曜日などがあります。 これらの機能は通常、"one-hot" エンコーディング ("ダミー変数" を使用) で表されます。つまり、x1 は "browser = safari" の場合は 1、そうでない場合は 0、x2 は "browser = firefox" の場合は 1 になります。
これをロジスティック回帰式に入れると、次のようになります。
ブラウザはカテゴリ機能であるため、係数を表で表すことができます。
| ブラウザー | 係数 |
|---|---|
| safari | 1.2 |
| Firefox | 0.8 |
このテーブルの各行はロジスティック回帰式の項に変換されるため、"browser = safari" の場合は x1 = 1、β safari = 1.2 および "browser = firefox" の場合は x2 = 1、β Firefox = 0.8 です。 これにより、全体的な方程式は次のようになります。
他のカテゴリの特徴もこのように表現できます。 次の値を係数として次のドメインに割り当てたとします。
| ドメイン | 係数 |
|---|---|
| cnn.com | 2.1 |
| nytimes.com | 0.8 |
| yahoo.com | 0.3 |
これらの値は、数式内で増分項になり ("domain = cnn.com" の場合は x3、β 3 は 2.1)、全体的な数式は次のようになります。
広告インプレッションが配信されると、Xandr はブラウザーを Safari として、ドメインを nytimes.com として識別します。 対応する変数を browser = Safari と domain = nytimes.com に設定し、他の変数を 0 に設定すると、式が次のようになります。
高次予測器
Xandr は高次予測器 (特徴の組み合わせ) をサポートしているため、カスタム モデルで予測器間の複雑な相互作用を処理できます。 前の例から始めて、ドメインとブラウザーのカテゴリ値に基づいて値を計算します。 ここで、ドメインとブラウザは独立しておらず、それらの間の関係をモデル化する必要があると想像してください。 これを行うには、次の表で指定された値を使用して、特徴の各ペアの係数を持つ双方向カテゴリ特徴を作成できます。
| ブラウザー | ドメイン | 係数 |
|---|---|---|
| Safari | cnn.com | 1.1 |
| Safari | nytimes.com | 1.3 |
| Safari | yahoo.com | 1.2 |
| Firefox | cnn.com | 3.3 |
| Firefox | nytimes.com | 0.7 |
| Firefox | yahoo.com | 0.1 |
これらの一対の予測因子はそれぞれ、ロジスティック回帰式の項になります。
ハッシュ予測器
複数のカテゴリ予測器を組み合わせると、リアルタイム システムのメモリに簡単にマップできない非常に大きなテーブルが作成されます。 このようなテーブルから値を取得する代わりに、特徴の組み合わせをハッシュして衝突を作成できます。これにより、リアルタイムでメモリにマッピングする必要がある組み合わせの数を減らすことができます。
ハッシュされた予測器の例
簡単な例として、2 ビットのハッシュ関数を使用して、前の例のブラウザーとドメインの組み合わせをハッシュできます。
| ブラウザー | ドメイン | 係数 |
|---|---|---|
| Safari | cnn.com | 0 |
| Safari | nytimes.com | 1 |
| Safari | yahoo.com | 3 |
| Firefox | cnn.com | 2 |
| Firefox | nytimes.com | 0 |
| Firefox | yahoo.com | 1 |
次に、各ハッシュ値の係数を計算します。 前の例よりも特徴量が少ないため、多くのメモリを必要とせずに機能間の相互作用の一部をキャプチャできる可能性があることに注意してください。
| Browser-Domain ハッシュ | 係数 |
|---|---|
| 0 | 1.3 |
| 1 | 0.7 |
| 2 | 1.5 |
| 3 | 0.9 |
変数をこれらの値に置き換えると、ロジスティック回帰式は次のようになります。
特定のインプレッションに対する応答を予測するために、Xandr は検出された特徴をハッシュします (モデルのトレーニングとオンライン推論の両方で特徴エンジニアリング中に適用されるのと同じハッシュ関数を使用します)。 一部の特徴量では、ハッシュ関数を使用して生の特徴量値を上記の式で使用されている値にハッシュし、予測を実行します。 ブラウザが Safari でドメインが nytimes.com (または同じ値にハッシュする他のブラウザとドメインのペア) 場合、これらをハッシュして値 1 を見つけ、ロジスティック回帰式に代入します。
ワンホット エンコードおよび重みベクトルからテーブルへの変換
カテゴリ特徴のエンコードにより、カテゴリ特徴量ごとに、最大で 1 つの変数が値 1 を受け取り、それ以外のすべてが値 0 を受け取るようになります。 したがって、ブラウザ機能の重みとブラウザ変数のドット積は、入札要求でブラウザのあらかじめ決められた重みをアクティブにするための回り回い方法です。 Digital Platform API では、標準の Sigmoid 関数である以下の式を使用します。
次の広告要求があった場合:
ブラウザーの種類が Firefox の場合、ワンホット エンコードの x_firefox は 1、 x_safari は 0 に設定されます。 Firefox タイプでアクティブ化された重みは、あらかじめ決められた重み 0.8 にエンコードされた値 1 を掛けた値になります。 したがって、 x_firefox は 0.8 に等しくなります。 Safari タイプに対してアクティブ化された重みは 0 で、事前に定義された重みであり、1.2 に x_safari 設定 0 を掛けたものです。
次の重み付けの方程式が得られます。
カテゴリ特徴から重みへのマッピングを定義するために、Xandr は API 呼び出しを使用してルックアップ テーブルを作成および更新します。 ロジスティック回帰モデル自体は、ワンホットにエンコードされた変数のベクトルではなく、これらのテーブルを参照します。 このモデルでは、広告主、クリエイティブ、または品目のセグメント年齢、セグメント値、頻度または最新性情報などの基本値または実際の値を直接参照することもできます。
サンプル プロセスの概要
上記の情報を使用して、サンプル ワークフローを作成しましょう。
少ない予算でトレーニング データを収集するために、探索的キャンペーンを設定したとします。 特定のリターゲティング ライン アイテムを最適化して、クリック単価を最小限に抑えたいと考えています。 インプレッションを獲得するたびに、is_click列が false に設定された行がログ レベルのデータ フィードに生成されます。 最終的にクリックが生成されると、 is_click 列が true に設定された同一の行がデータ フィードに生成されます。 トレーニング セット、検証セット、テスト セットの間でデータを分割するには、 user_id_64の最後の数ビットを確認します。
user_id_64によって、データが割り当てられる部分が決まります。 最終的に、主要な変数が次のと判断されます。
- ユーザーのブラウザー (カテゴリ別)
- ユーザーの国/地域と曜日 (上位カテゴリ)
- パブリッシャーとユーザーの国/地域の組み合わせ (上位カテゴリ別)
- その広告主の広告がそのユーザーに最後に表示されてからの時間 (広告主の最新性、カーディナル値)
ブラウザーの数はそれほど多くないので、トレーニング セットのブラウザーごとに 1 つの重みを持たせるのが妥当です。 クロス製品、国/地域、曜日もかなり小さいです。 ただし、発行元と国/地域の組み合わせではカーディナリティが高くなるため、4096 エントリのハッシュ テーブルを使用してトレーニングすることを任意に決定します。 最後に、広告申込情報の 1 日の頻度が基本値です。
LLD の各行について、まずトレーニング キャンペーンからではない行をフィルター処理します。 目的のイベントを定義したので、次の変数を抽出できます。
- ブラウザー ID
- 国/リージョン ID
- ユーザーの曜日 (タイムゾーン オフセットをインプレッションのタイムスタンプに追加し、それを週 7 日間にマッピング)
- パブリッシャー ID
- 広告主の最新期間。最大 1 時間 (このユーザーに対して初めて表示する広告の場合、最新期間の既定値は 1 時間です)
最新性用に 1 つの機能 ID、ハッシュされた (発行元:国/地域) 用に 4096 ID を予約し、ブラウザーごとおよび (国/地域: 曜日) ペアごとに機能 ID を動的に生成します。 ハッシュ化機能では、もう 1 つ追加の手順が必要です。2 つの ID (発行元と国/地域) を取得し、それらを 8 つの 32 ビット整数のリトル エンディアン ベクトルに書き出し、MurmurHash3_x86_32(ベクター、32、0xC0FFEE) % 4096 (0xC0FFEE は任意のシード) の バケット を見つけます。 これにより、各行の特徴値の (スパース) ベクトルが得られるので、各ベクトルのインプレッション数とクリック数をカウントできます。
ゆっくりとインプレッションを買った 1 日後、LLD (のサブセット) でトレーニングしたロジスティック回帰モデルを試します。 特徴値のスパース ベクトルは、特徴空間のワンホット エンコーディングです。 このエンコーディングから、カテゴリ値から重み (ルックアップ テーブル) にもっと論理的な関数に変換する必要があります。 これを行うには、フィーチャのテーブルをフィーチャ ID と重みのベクトルに結合して、次のようにします。
| 機能 | インデックス | 太さ |
|---|---|---|
| 広告主の最新性 | 0 | -0.2 |
| publisher:country/region-bucket 0 | 1 | 1.4 |
| publisher:country/region-bucket 1 | 2 | -2.1 |
| ... | ... | ... |
| publisher:country/region-bucket 4095 | 4096 | -0.5 |
| browser=safari | 4097 | 5.2 |
| country/region:day-of-week=US:monday | 4098 | 0.7 |
| ... | ... | ... |
各フィーチャーの重みを決定します。
- 広告主の最新性: トレーニングされたモデルから直接重みを読み取ります。
- ハッシュ テーブル: 4096 の特徴量の重みを読み取り、それらを配列に入れます。
- ブラウザー: 動的マップをフィーチャーから ID へと移動し、フィーチャーはキー、ID は値であり、ブラウザー ID から 0 以外の重み (デフォルトはゼロ) へのルックアップ テーブルを作成して、ブラウザーから重みへのマッピングのリストを作成します。
- 国/地域:曜日: 機能から ID への動的マップをたどり、ブラウザー ID から 0 以外の重み (デフォルトはゼロ) へのルックアップ テーブルを作成して、ブラウザーと重みのマッピングの一覧を作成します。
AppNexus API を呼び出すために必要なすべてのデータは次のとおりです。
オークション時間プロセスの概要
ライン アイテムがターゲティングに合格すると、Xandr はロジスティック回帰モデルを使用して入札価格を決定します:
- Xandr は、説明内のルックアップ テーブルごとに、入札要求からフィールドの値を抽出し、テーブル内のエントリを検索します。 エントリがある場合、その値はロジスティック関数の線形引数に加算されます。 それ以外の場合は、テーブルの既定値 (通常は 0) が使用されます。
- ハッシュ テーブルについても同じことが行われますが、Xandr が値をハッシュしてバケットを見つけ、ハッシュ テーブルのバケット> 値マッピングのリストでそのバケットを探すことが異なります。 ここでも、指定した値がテーブルに表示されない場合は、既定値が使用されます。
- 最後に、Xandr は Bonsai の機能を探します。 各機能の参照を実行し、重みを掛けて、最小/最大制限を適用します。
- 次に、Xandr はコンポーネントと Beta0 を合計し、それをロジスティック関数に渡して、クリックの推定確率を計算します。 推定確率に目標値を掛けて期待値を求め、その後、1 から 100 CPM の範囲にクランプして、非現実的に高いバリュエーションを抑制します。
- 次に、Xandr は予想値と使用可能なインベントリの量を使用して入札単価を計算します。 正確な計算は明細行品目の設定によって異なりますが、その結果、Xandr は、入札単価が、明細項目が毎日の終わりに 1 日の予算を費やすのに十分なほど高くなるまで、期待値を自動的にスケールダウンします。 このスケーリングの詳細については、ドキュメントの 「アダプティブ ペーシング (ログインが必要)」を参照してください。