トレーニング
ラーニング パス
FastTrack サービス、データ管理などを使用して、財務と運用アプリの実装を成功させるためのプロジェクト方法論を計画および設計します。
このブラウザーはサポートされなくなりました。
Microsoft Edge にアップグレードすると、最新の機能、セキュリティ更新プログラム、およびテクニカル サポートを利用できます。
検出は、広告申込情報が目標を達成するのに役立つ最適化コンポーネントです。これは、パフォーマンスの良い在庫に費やし、目標を達成していない在庫をすばやく削減することで、可能な限り迅速に目標を達成するのに役立ちます。
ヒント
検出は、CPA リターゲットまたは vCPM、CPCV、または VCR の目標を持つ広告申込情報には適用されません。
広告申込情報が提供できる在庫のプールは、海洋性であっても、中程度にターゲットを絞った広告申込情報であっても、"海を沸騰させる" リスクやすべてをテストしようとするリスクがあるためです。 海を沸かすと、お金が無駄になるだけでなく、時間もかかります。"良い"または"悪い"と呼ぶのに十分な意味のあるデータが蓄積されるまでに時間がかかる場合があります。場合によっては、悪い在庫を削減するのに非常に時間がかかるため、トレーダーは代わりに最適なドメインと配置の許可リストに頼ります。 これは短期的なパフォーマンスに役立つ場合がありますが、長期的には新しいパフォーマンスの高い在庫ソースが広告申込情報で検出されるのも防ぎます。
検出では、インベントリを異なるセクションに分割し、履歴データに基づいてセクションをランク付けし、最もパフォーマンスの高いセクションを最初にテストすることで、この問題を解決します。
結果として:
検出のしくみは次のとおりです。
注意
広告申込情報の目標を変更した場合、Discovery は広告申込情報の既存のデータを使用して、新しい目標に対してインベントリを再評価します。
検出テストが "探索ノード" と呼ばれるインベントリのセクション。 ノードはタグとインベントリ URL の組み合わせによって定義されます。ただし、CPA プロスペクティングを除き、ノードはインベントリ URL によってのみ定義されます。 検出ノードに対して 1 つのインプレッションが提供されたことを確認するとすぐに、ランク付けシステムでその検出ノードを検索して、広告申込情報でテストを続ける必要があるかどうかを判断できます。
パフォーマンスは広告申込情報の設定によって異なるため、Discovery では、広告申込情報の広告の種類 (バナー、ネイティブ、またはビデオ) と広告申込情報のターゲット国によって履歴データもフィルター処理されます。
そこから、RTB インベントリを 5 つのバケットにランク付けします。超良い、良い、あまり良くない、悪い、不明です。 (マネージド インベントリはランク付けされません)。ランク付けは、CPC を含む広告申込情報の CPC とクリック後の CPA 目標に基づいており、CTR 目標を持つ広告申込情報の CTR に基づいています。 CPA プロスペクティングの場合、ノードは "ユーザーの重複" に基づいてランク付けされます。つまり、ユーザー トラフィックが、過去に大量の変換ユーザーを生成したノードのトラフィックとどの程度類似しているかに基づいてランク付けされます。 両方のノードのユーザー トラフィックが全体的に似ている場合は、コンバージョン率が似ていると想定されます。
現在の広告申込情報がノード内のインプレッションを購入していない場合、ノードは "インベントリの探索" と見なされます。 広告申込情報は、新しい、潜在的にパフォーマンスの高い在庫ソースを検出し、適格性リストにフィードするために、常に少なくとも 1% の探索在庫で機能します。 行項目が配信目標を達成していない場合は、その割合を増やします。
"Axing" は、探索ノードを不パフォーマンスとして排除するプロセスを記述するために使用する用語です。 Axing の決定は、次の組み合わせに基づいています。
機能しない在庫を削減するには、まず、広告申込情報の不合格基準、または在庫が不良と見なされるしきい値を決定する必要があります。 クリックベースの目標に対する広告申込情報の CPC 目標、または CPA プロスペクティングの CPA 目標という、非常に単純なベンチマークを使用します。 つまり、広告申込情報の目標が $1.00 の場合は、目標を達成するために、在庫のスライスに費やされた 1 ドルあたり 1 回のクリックを取得する必要があります。 検出ノードがクリックを達成していないのに、行項目が失敗基準 ($1.00) に達した場合、ノードはすぐに失敗します。 マネージド ノードの場合、インベントリが既知であるため、リスクが少ないため、失敗条件が高くなります。
クリックベースのGoals (CPC、CTR、クリック後のコンバージョン単価) | CPA プロスペクティング | |
---|---|---|
RTB ノード | 1x 項目のクリック単価目標 | 広告申込情報のコンバージョン単価目標 1 倍 |
マネージド ノード | 1.8x アイテムの CPC 目標 | 広告申込情報のコンバージョン単価目標 1 倍 |
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 では上記の既定の合格基準と失敗条件が使用されます。 [配信] を選択すると、動的な失敗条件の計算が実装され、アダプティブ ペーシング修飾子 (2.0 まで) を使用して条件も変更されます。 つまり、行項目が配信目標を達成していない場合、検出は失敗基準のしきい値を段階的に増やし続けます。
目標の優先順位 | 失敗条件 |
---|---|
配信 | 行項目の目標の最大 10 倍 (x アダプティブ ペーシング修飾子) |
余地 | 行項目の目標の 1 倍 |
パフォーマンス (既定値) | 行項目の目標の 1 倍 |
誤検知は、検出ノードであり(行項目のクリック単価目標以下で 3 回以上のクリックが達成されました)、目標をはるかに上回る累積クリック単価が設定されました。 言い換えると、これらは一度うまく実行されたが、もはやうまく動作しないノードです。 評価アルゴリズムでは、これらのノードの一部を評価によって排除することがありますが、しばらく時間がかかる傾向があるため、明細の全体的なパフォーマンスが低下する可能性があります。
クリックベースの目標を持つ広告申込情報がパフォーマンスの低いインベントリを削除し、その目標をより速く達成できるように、Discovery では、CPC を目標の 2 倍以上使用してインベントリを軸にします。 CPA のプロスペクティングの場合、もう少し複雑になります。検出軸のインベントリは、次の数式に基づいています。
ノード > 2 の予約収益 (失敗基準) * (コンバージョン + 1)
トレーニング
ラーニング パス
FastTrack サービス、データ管理などを使用して、財務と運用アプリの実装を成功させるためのプロジェクト方法論を計画および設計します。