Microsoft 収益化 - 検出

検出は、広告申込情報が目標を達成するのに役立つ最適化コンポーネントです。これは、パフォーマンスの良い在庫に費やし、目標を達成していない在庫をすばやく削減することで、可能な限り迅速に目標を達成するのに役立ちます。

広告申込情報が提供できる在庫のプールは、海洋性であっても、中程度にターゲットを絞った広告申込情報であっても、"海を沸騰させる" リスクやすべてをテストしようとするリスクがあるためです。 海を沸かすと、お金が無駄になるだけでなく、時間もかかります。"良い"または"悪い"と呼ぶのに十分な意味のあるデータが蓄積されるまでに時間がかかる場合があります。場合によっては、悪い在庫を削減するのに非常に時間がかかるため、トレーダーは代わりに最適なドメインと配置の許可リストに頼ります。 これは短期的なパフォーマンスに役立つ場合がありますが、長期的には新しいパフォーマンスの高い在庫ソースが広告申込情報で検出されるのも防ぎます。

検出では、インベントリを異なるセクションに分割し、履歴データに基づいてセクションをランク付けし、最もパフォーマンスの高いセクションを最初にテストすることで、この問題を解決します。

結果として：

• テストに費やすお金が少ないため、広告主のドルは遠くに行きます。
• トレーダーは手動による最適化に費やす時間を減らし、影響の大きいタスクやキャンペーン管理の範囲を広げる時間が長くなります。
• トレーダーは、うまく機能している在庫に関する割り当ての決定に費やす時間を短縮します。
• 人の労力を減らし、より速く目標を達成します。

検出のしくみ

検出のしくみは次のとおりです。

1. 広告申込情報のターゲティングの対象となるインプレッションが表示されたら、許可リストのようなランク付けされたテスト リストに並べ替えますが、動的に生成され、各広告申込情報にカスタムされます。 広告申込情報の目標を達成する可能性が最も高いインベントリはリストの一番上に表示されますが、目標を達成する可能性が最も低いインベントリは下位に落ちるか、まったく追加されません。
2. 検出はリストの一番上でテストを開始し、広告申込情報がコストを費やすとインベントリを渡したり失敗したりします。これは、"axing" と呼ばれるプロセスです。
3. 目標を満たしていないためにインベントリが失敗した場合、Discovery はリストの次の項目を動的に追加します。

ランク付け

検出テストが "探索ノード" と呼ばれるインベントリのセクション。 ノードはタグとインベントリ URL の組み合わせによって定義されます。ただし、CPA プロスペクティングを除き、ノードはインベントリ URL によってのみ定義されます。 検出ノードに対して 1 つのインプレッションが提供されたことを確認するとすぐに、ランク付けシステムでその検出ノードを検索して、広告申込情報でテストを続ける必要があるかどうかを判断できます。

パフォーマンスは広告申込情報の設定によって異なるため、Discovery では、広告申込情報の広告の種類 (バナー、ネイティブ、またはビデオ) と広告申込情報のターゲット国によって履歴データもフィルター処理されます。

そこから、RTB インベントリを 5 つのバケットにランク付けします。超良い、良い、あまり良くない、悪い、不明です。 (マネージド インベントリはランク付けされません)。ランク付けは、CPC を含む広告申込情報の CPC とクリック後の CPA 目標に基づいており、CTR 目標を持つ広告申込情報の CTR に基づいています。 CPA プロスペクティングの場合、ノードは "ユーザーの重複" に基づいてランク付けされます。つまり、ユーザー トラフィックが、過去に大量の変換ユーザーを生成したノードのトラフィックとどの程度類似しているかに基づいてランク付けされます。 両方のノードのユーザー トラフィックが全体的に似ている場合は、コンバージョン率が似ていると想定されます。

• スーパーグッド - このバケット内のすべてのものがインベントリプールに追加され、広告申込情報が開始されるとすぐにテストされます。
• 良い - テスト プールにノードを追加する必要がある場合は、最初にこのバケットから適格なノードを取得します。
• あまり良く ありません - テストするノードをさらに追加する必要があり、最初の 2 つのバケットが使い果たされた場合は、次にこのバケットから追加します。
• 無効 - これらはテストを許可されません。
• 不明 - 長いテール ノード。 このバケットからテストするノードは、広告申込情報が良好なバケットまたは低いバケットからすべてのインベントリを使い果たした場合にのみ追加します。

現在の広告申込情報がノード内のインプレッションを購入していない場合、ノードは "インベントリの探索" と見なされます。 広告申込情報は、新しい、潜在的にパフォーマンスの高い在庫ソースを検出し、適格性リストにフィードするために、常に少なくとも 1% の探索在庫で機能します。 行項目が配信目標を達成していない場合は、その割合を増やします。

Axing

"Axing" は、探索ノードを不パフォーマンスとして排除するプロセスを記述するために使用する用語です。 Axing の決定は、次の組み合わせに基づいています。

• 失敗条件
• 合格基準
• 目標の優先順位との対話
• 誤検知チェック

失敗条件

機能しない在庫を削減するには、まず、広告申込情報の不合格基準、または在庫が不良と見なされるしきい値を決定する必要があります。 クリックベースの目標に対する広告申込情報の CPC 目標、または CPA プロスペクティングの CPA 目標という、非常に単純なベンチマークを使用します。 つまり、広告申込情報の目標が $1.00 の場合は、目標を達成するために、在庫のスライスに費やされた 1 ドルあたり 1 回のクリックを取得する必要があります。 検出ノードがクリックを達成していないのに、行項目が失敗基準 ($1.00) に達した場合、ノードはすぐに失敗します。 マネージド ノードの場合、インベントリが既知であるため、リスクが少ないため、失敗条件が高くなります。

CPM、Cost Plus、動的 CPM、表示可能な CPM 予約収益の種類については、予約された収益ドルに基づいて計算されます。 CPC 収益タイプの場合、予約収益の予測が少ないため、メディアコストドルに基づいて計算されます。

合格基準

前述のように、広告申込情報に $1.00 の CPC 目標がある場合、在庫のスライスに $1.00 を費やし、0 回のクリックを達成すると、インベントリの失敗は簡単です。 CPA プロスペクティングの場合、インベントリの受け渡しは簡単です。その $1 の支出の後にコンバージョンが発生した場合、ノードは成功します。変換が行われなかった場合、ノードは失敗します。

クリックベースの目標の場合、インベントリの受け渡しは少し複雑になります。 たとえば、在庫が 1.00 ドルを費やし、1 回のクリックを達成した場合、インベントリが現在目標を達成していることを確認できますが、在庫が将来一貫して目標を達成するかどうかはわかりません。

このリスクを考慮するために、検出ノードのパス条件は、クリック数に応じて変化します。

ノードの 1 回のクリックが $1 未満の場合、パス条件は $2 に増加します。 ノードの 2 回のクリックが $2 の支出以下の場合、パス条件は $3 に増加します。 ノードのクリック数が 3 ドル以下の場合、明細の CPC 目標が変更されない限り、ノードは渡されます。 (その場合、目標に対する変更と同様に、Discovery は新しい条件に対してノードを自動的に再評価します)。

Axing が目標の優先順位と対話する方法

行項目で、目標の優先順位 (配信、パフォーマンス、または余白) を選択します。 [パフォーマンス] (既定値) を選択すると、axing では上記の既定の合格基準と失敗条件が使用されます。 [配信] を選択すると、動的な失敗条件の計算が実装され、アダプティブ ペーシング修飾子 (2.0 まで) を使用して条件も変更されます。 つまり、行項目が配信目標を達成していない場合、検出は失敗基準のしきい値を段階的に増やし続けます。

誤検知チェック

誤検知は、検出ノードであり(行項目のクリック単価目標以下で 3 回以上のクリックが達成されました)、目標をはるかに上回る累積クリック単価が設定されました。 言い換えると、これらは一度うまく実行されたが、もはやうまく動作しないノードです。 評価アルゴリズムでは、これらのノードの一部を評価によって排除することがありますが、しばらく時間がかかる傾向があるため、明細の全体的なパフォーマンスが低下する可能性があります。

クリックベースの目標を持つ広告申込情報がパフォーマンスの低いインベントリを削除し、その目標をより速く達成できるように、Discovery では、CPC を目標の 2 倍以上使用してインベントリを軸にします。 CPA のプロスペクティングの場合、もう少し複雑になります。検出軸のインベントリは、次の数式に基づいています。

ノード > 2 の予約収益 (失敗基準) * (コンバージョン + 1)