Yield Analytics の概要

このページでは、Yield Analytics の概念について説明します。

Yield Analytics について

Yield Analytics は、パブリッシャーが収益を最大化するために広告インベントリを適切に予測、管理、価格、販売するのに役立つデータ分析ツールです。

Yield Analytics テクノロジの基本

これは、Yield Analytics がバックグラウンドでどのように機能するかです。

統合

広告サーバーや他の多くのシステムと統合しています。 保持されるデータには以下が含まれます。

• 注文管理システム
• DMP (データ管理 プラットフォーム)
• ファースト パーティのデータ システム
• サード パーティのデータ システム
• その他の広告サーバー (例: Video Ad Server)

分析

Yield Analytics は、上記のシステムと統合され、情報をシステムに取り込みます。 ログ レベルのデータを取得します。 つまり、Yield Analytics は、データの特定のセットや "サンプリング" を見るのではなく、広告サーバー、ビデオ サーバー、または上記の箇条書きで説明したシステムを介して実行されたすべてのインプレッションを分析します。 データに対して分析を実行し、予測とエミュレートを行います。

予測

クライアントのシステムの予測 - Yield Analytics はサイトを分析するだけでなく、その情報をシステム内の特定の製品に関連付けます。 特定のサイト、セクション、さまざまな対象ユーザーなどを調べて、それらの場所で必要となるインプレッションの数をより適切に見積もります。

エミュレーション

キャンペーン配信のエミュレート – Yield Analytics は、実行中のサーバー内のすべての広告申込情報を分析します。 結果に基づいて、次の項目を見積もります。

• サービスを提供する可能性が最も高い
• 配信に問題がある可能性があります (配信不足)
• 財務上の影響を引き起こす可能性のある問題

多くの広告サーバーは、キャンペーンの管理、ライン配信、予測に関する限り、Yield Analytics が実行できるあらゆることを実行できます。 では、Yield Analytics の方が優れているのはなぜですか?

方法

一般的な広告サーバーでは、データのサンプル セットを確認します。 つまり、システムを通過するすべての印象を見る代わりに、ほんの一握りしか見ないということです。 そこから、予測、キャンペーンの競合などを見積もります。

Yield Analytics は、国勢調査ベースのアプローチを採用しています。つまり、システムを通過するすべての印象を探して分析しています。 これは、次の 2 つのことを支援します。

• 高度にターゲットを絞った広告申込情報の予測

広告サーバー内では、データのサンプル セットを使用しているため、高度にターゲットを絞ったインプレッションの一部が見逃される可能性があります。 しかし、Yield Analytics では、すべてのインプレッションを見ています。 歴史的に、その特定の広告申込情報で配信されたインプレッションの量が正しく表示され、正確に予測されます。

• 将来の予測

将来の予測を行う場合、Yield Analytics は、サイトの動作をより深く理解できるように、より大きなデータ セットを検討しています。 3 か月から 6 か月前に予測する場合 – Yield Analytics では、その予測情報を要求する際の正しい数値を判断するために、システムの理解が深まります。

ルックバック ウィンドウ

一般的な広告サーバーでは、わずか 28 日間を振り返り、予測が実行されている期間についてその情報を推定します。 Yield Analytics は、お客様がアクセスできる限り情報を保持するため、その時点まで遡ることができます。

例: キャンペーンの開始日は 9 月 1 日です。 1 月 1 日に戻って、Yield Analytics にデータへのアクセスを許可しました。 そのため、履歴データを 1 月 1 日に "振り返る" ことができます。

手動調整

場合によっては、広告サーバーが誤って予測される可能性があることがわかっている場合があるため、実際の動作に関するインサイダー知識に基づいて、Yield Analytics 内で手動で調整して正確な数値をより正確に予測できるようにすることが重要です。

この機能を適用できる便利な方法の 1 つは、サイトが 1 日のトラフィックの急増を起こしていることがわかっている場合です。 例: トラフィックの多いニュースストーリーが発生するか、大規模なイベントが近づいているため、特定の期間にインプレッション容量を上げたいと考えています。 これは Yield Analytics 内でも実現できます。

季節モデル

トラフィックに季節的な変動が生じることがわかっている場合は、Yield Analytics 内でこれらの変更を表すことができます。 例: 休日の間、サイトのトラフィックが通常 10% 増加していることがわかります。 その割合を追加できます。 システムは、デフォルトの利回りが履歴データに基づいているものを確認し、特定のサイトまたは特定の領域で発生するインプレッションの量を正確に表現できることがわかっているものに合わせて調整できます。

スパイク軽減策

サイトに大量のトラフィックをもたらす "1 回限りのイベント" が発生することがわかっている場合は、広告サーバーにアラートを送信できます。 広告サーバーは、それがいくつかの素晴らしい物語、またはすべてのトラフィックを駆動したいくつかのウイルスビデオだったことを知るつもりはありません。 広告サーバーは、システムから循環するまでスパイクが発生すると想定します。 Yield Analytics では、履歴データを確認し、その大きさの急上昇が発生することはほぼ不可能であり、再び発生しない可能性が最も高いと判断できます。 Yield Analytics は、これらのインプレッションの一部を考慮して、再び発生する可能性が高くなります。 ただし、完全なスパイクは考慮されません。 この機能は、セールス チームが正確に販売するのに大きく役立ちます。 Yield Analytics がスパイク軽減策を適用した今、その 1 回限りのスパイクに基づいて売り過ぎようとはしません。正しい金額を販売できるようになります。

予定表ビュー

スポンサープランを予約していて、特定の製品の利用可能な場所を決定しようとしている場合は、カレンダー ビューを確認できます。 これにより、使用可能なもの (色コード = 緑)、およびそうでないもの (色コード = 赤) が表示されます。 広告サーバーでは、この情報を特定するために日単位で確認する必要があります。

一括クエリ

何千もの行項目を含む Yield Analytics 内でクエリが実行された場合、通常、システムで分析と処理が完了するまでに数分かかります。 結果を一括クエリ フォルダーに保存できます。 これにより、システムがクエリ結果を生成している間も作業を続行できます。

予測

Yield Analytics の主な目的は予測です。 保持されるデータには以下が含まれます。

• 在庫容量の理解
• インプレッションを使用できるさまざまな方法を理解する
• カスタム製品と定義済み製品の可用性

配信管理

配信管理は、販売後に発生するすべてのことを妨げる。 Yield Analytics は広告サーバーの配信をエミュレートして、配信不足のリスクを把握します。 キャンペーンの競合を分析し、配信される可能性が最も高い広告、優先度が高い広告ライン、収益を最適化するさまざまな方法をより適切に予測しています。

価格分析

価格分析は、クライアントが Yield Analytics から最大の価値を得る場所です。 この情報を使用すると、気づかなかったさまざまな対象ユーザーを明らかにできる可能性があります。 これは、歴史的に次の内容を調べることによって実現されます。

• 収益の配信
• アイテムの価格
• 価格の不一致
• Yield Analytics によって特定の製品の可能性が高まる

KPI レポート (主要業績評価指標)

Yield Analytics はさまざまなプラットフォーム間でデータをマージしているため、ディメンションの配列全体で結合された分析情報を作成します。

プログラムによる管理

さまざまな CSP と統合されている場合、Yield Analytics はその情報をシステムに取り込むことができます。 フィル レート、eCPM、CPM、RPM などのメトリックに基づいて、需要の高いポケットがある場所を決定できます。さまざまなプログラム チャネルを通じて収益を獲得するために、収益を管理します。

Yield Analytics の機能と結果として得られた情報は、多くのセクターに役立ちます。 次の内容が含まれます。

営業

売上は、クライアント ソリューションを通じて収益を促進する方法を調べます。 販売計画を立て、クライアントから RFP を受け取り、それに応答しています。 また、クライアント関係も管理します。

広告操作

Ad Ops チームは、すべての収益が確実に配信されるようにします。 また、クライアント プランを実装し、技術的な問題を基本的なレベルで解決します。

Yield Analytics 管理

これはワークフローの主要なチームです。 Yield Analytics 管理の責任は次のとおりです。

• 収益の最適化
• 管理
• 価格設定
• キャンペーン配信の優先順位付け
• KPI レポートの所有権

財務

ほとんどのクライアントは注文管理システムを使用していますが、Yield Analytics には、収益の管理、細かい請求書の処理、不正なデビットの追跡、およびその他の関連機能が用意されています。 これは、サード パーティのデータ システムを介して実行される場合があります。 (例: Adjuster)

管理

管理は、"収益に対する責任" と定義でき、戦略的な意思決定を担当する担当者と定義できます。 概要レポートで使用できる一般的な情報の例を次に示します。

• 上位の広告主は誰ですか?
• 広告主の eCPM は一通り何ですか?
• 広告主 1 人あたりの eCPM は何ですか?
• 営業担当者はどのように作業していますか?
• 上位の製品はどのように動作していますか?

レポートが実行されている場合、コンテンツは履歴データ ポイントと予測データ ポイントに分割されません。 レポートに履歴データを表示する場合は、過去の日付を選択していることを確認します。 日付が履歴と予測の間で重複する場合は、そのデータがブレンドされます。

Yield Analytics システムの製品は、広告サーバーからのターゲット属性の組み合わせです。 広告サーバーには、広告が配信される場所とタイミングを決定するためのロジックが組み込まれています。 利便性として、当社のシステムでは、さまざまな製品の種類があります。

広告サーバーからプルされるターゲティング属性を確認する、いくつかの異なる製品タイプを作成しました。 これらのターゲット属性は Yield Analytics にインポートされます。 最も一般的なものは、サイズ、サイト、ページ、位置、対象ユーザーのセグメント、地理的な場所などです。

レポートを実行するときは、通常、探しているものに基づいて特定の製品の種類にフィルター処理する必要があります。 以下に説明する 3 種類の製品があります。

レートカード

Rate Card Product は、製品カタログを表す販売チームによって頻繁に販売される製品です。 これには、価格カードレートが関連付けられている場合があります。

Reporting

これは、レポートのために特別に作成された製品です。 これらは、クライアントが実行するレポートの目的の種類に基づく製品です。 Yield Analytics では、レポート製品が何であるかを確認し、ターゲット属性を確認します。 次に、広告サーバーにアクセスして、そのターゲティング属性の何らかの側面を持つ広告申込情報を見つけます。 次に、情報をプルし、レポートに反映します。 次に例を示します。

• さまざまなサイト/セクションのパフォーマンス
• モバイル アプリとモバイル Web の比較
• すべてのモバイル製品

Custom

カスタム製品は、広告サーバー内の注文明細行によって参照される一意の製品です。 通常は販売可能な製品ですが、一般的には販売されていません。 特定の正確な製品に関する特定の情報にアクセスする場合、カスタム製品は主に便利として使用されます。

Yield Analytics では、収益は 2 つの異なる方法で分割されます。 インプレッションは、契約、スケジュール、消費の 3 つの異なる方法で分割されます。 以下に、各種類の印象の簡単な説明を示します。

契約

契約は、注文管理システムから来るものです。

スケジュール済み

広告サーバーは注文管理システムから分割されます。 情報が広告サーバーにプッシュされると、スケジュールどおりに表示されます。 注文管理システムを持つクライアントは、スケジュールされたインプレッションの "バッファー" を組み込み、完全に配信されるようにします。

消費

消費されたインプレッションは、実際に実行されたもの、配信されたもの、または広告サーバーで実行されると予測されるインプレッションです。

従量課金型は、販売率を分解するもう 1 つの方法です。 従来の販売率の基本的な例として、100 万インプレッションのうち、900,000 件が販売されました。 これは、90% のセルスルー レートに相当します。

従量課金の種類では、基本的な質問が表示されます。特定の製品に対して直接または間接的に何かが販売されましたか? (例に戻る)900,000件のインプレッションのうち、実際に広告はその特定の製品をターゲットにしていたのか、それともその製品の容量は豊富でしたか?

直接消費

直接消費は非常に簡単です。 注文明細行では、アイテムのターゲットが設定され、まったく同じ場所で提供されます。

例: ニュース 300 x 250 ホーム ページという名前の製品がシステムに存在します。 ターゲット特性は Site=News、Size=300x250、Page=Homepage です。 注文明細行は、そのまったく同じ文字列をターゲットにしています。 これらの広告はニュース300x250ホームページに表示されます。 広告が配信されるたびに、直接消費と見なされます。 この特定の製品を購入した場合、広告はその製品で直接配信されます。

包含消費

包含消費は直接消費と相関します。 すべてのサイトには階層があります。 たとえば、新聞の場合は、ニュース、政治、スポーツ、地元など、さまざまなサイト/セクションを作成します。これらの各セクション内では、その特定のサイト/セクションに対して "トリクルダウン" するサブセクションがさらに追加されます。

例: この例はホーム ページではなくなりましたが、ニュース 300x250 のサイト実行を見ています。 広告がニュースに該当する特定のサイトを対象としている場合は、含まれている消費と見なされます。 私はニュース/政治300 x 250に行く注文ラインを持っています 。 その 1 つの広告 (またはインプレッション) は、包含消費として表示されます。 ニュースを直接ターゲットにしているわけではありませんが、その特定の製品に対して "関連" と見なされるサブセクションをターゲットにしています。

間接消費

間接消費の概念は、例で最もよく示されています。

例: 私はニューヨークにあり、ニュースセクションにアクセスしています。 "サイトの実行" を対象とする広告申込情報と、DMA=New York があります。 この広告は自動車広告であり、DMA=ニューヨークも対象です。

その印象は考慮され、広告を通じて販売され、提供されました。 私がニュースや政治をしていたので、それは役に立たなかった。 私がニューヨークにいたので、それは役に立った。 これは間接消費と呼ばれます。 それは基本的に質問に答えます:その広告はその特定の製品に配信され、ターゲットでしたか、それともそこに配信された別の広告申込情報に他のターゲティング特性があったのですか?