OTT広告のソース、再生、検証の改善
OTTは、放送局やコンテンツ制作者が、視聴者の興味に基づいて動画ストリームをパーソナライズできるようにすることで、リニアTV体験を超えた優れた機会である。 このような高度なパーソナライゼーションは、ターゲットを絞った広告をプレミアムCPMレートで配信できるようにすることで、OTTストリームに広告収入を引き付ける重要な要素でもある。
しかし、この機会は、広告のソーシング、再生、検証の課題によって妨げられている。 OTT広告を取り巻く標準の多くは初期段階であり、現在も進化している。 さらに、サービス品質(QoS)に関する詳細なデバッグと分析はしばしば制限される。 また、広告が一貫したボリュームレベルで再生されているかどうかなど、エクスペリエンスの質(QoE)を理解することも重要である。
これらの課題を念頭に置き、スケーリングの改善とレイテンシーの削減に継続的に取り組んでいることから、プラットフォームの一部として専用の広告プロキシサービスを開発した。 元々は、ストリーミングプラットフォームのスケーラビリティを向上させるためのバックエンドの拡張として設計されていたが、広告ソーシングと配信ワークフローの可視性と制御性を大幅に向上させるなど、管理上の利点もいくつかある。 これらのツールにより、パブリッシャーは適切な広告を適切な視聴者に最適化し、QoSとQoEの多くの側面の両方を監視することができる。
マニフェストサーバーを使用してストリームをパーソナライズ
前回のブログ記事では、カスタマイズされた広告コンテンツを組み込むためにストリームをパーソナライズする際のマニフェストサーバーの役割について詳しく説明した。 この記事で議論されているように、マニフェストサーバは広告リクエストを行い、レスポンスを解析し、広告クリエイティブを他のコンテンツと同じようにダウンロードして処理する責任がある。 マニフェストサーバーはプレイヤーに統合されたストリームを送り、視聴者により一貫したエクスペリエンスを提供し、デバイスの互換性を最大化し、広告ブロッカーをバイパスする。
マニフェストサーバーは再生とパーソナライゼーションの部分を処理するための十分な設備を備えているが、広告の調達と検証に伴う作業は、さらなる複雑さと新たな課題をもたらしている。 数百万人の同時視聴者にパーソナライズされた体験を提供するストリーミングアーキテクチャの最適化を続ける中で、これらの活動をサポートすることに焦点を当てた広告プロキシサービスの開発につながった。
調達と検証の課題
ストリームに挿入される広告を取得するには、広告コンテンツはFreewheelやGoogle Ad Managerなどの広告決定サーバー(ADS)からフェッチされなければならない。 このプロセスはadsを要求し、正しいadsが置かれるように流れおよびすべての情報に沿って渡すことを含む。 課題は、特定のサーバー上の多くの広告が、別のサーバー上の実際の広告を指すラッパーであることである。
例えば、4つの広告枠が埋められる場合、そのうち2つは直接挿入されるが、残りの2つは広告アセットを持たず、代わりに「あなたの広告はここにはない、それはどこかにあり、あなたはここにそれを得る必要がある」というラッパーである。 私たちは、私たちが見るすべての広告レスポンスについて、再生可能な動画アセットを解凍して調達しようとする。 再生可能な広告アセットがストリームにステッチされる準備ができていることを確認するために、それらをアンパックするときに応答を検証する。 我々のアーキテクチャは、個々の視聴者にパーソナライズされたマニフェストを提供するように設計されているため、このプロセスは、かなりの負荷になる可能性があるセッションごとに繰り返される。
広告検索の待ち時間
複数のラッパーを介して資産を追跡することは、並行して処理されない場合のレイテンシーの主要な原因となる可能性がある。 あるラッパーは実際の広告資産に決して解決しない。 これが動画体験を低下させるのを防ぐために、次の広告を取得する前に、この「ウォーターフォール」を制限する。 このワークフローでデータとインサイトを公開することで、パブリッシャーは広告が配信されない需要源を特定して解決し、視聴者が中断のない視聴体験を得られるようにしながら、広告収益を最大化することができる。
レスポンシブな広告体験を保証するには、マニフェストサーバーでの広告ルックアップの影響を調べることも必要である。マニフェストサーバーは、パーソナライズされたストリームを最小限のレイテンシで組み立てているため、 マニフェストサーバーには、広告パフォーマンスデータの生成と保存専用のリソースが無制限にない。 マニフェストの生成に必要な広告情報のみを保存するため、問題のある広告呼び出しや再生をデバッグするためのデータの可用性を制限することができる。
広告代理サービスが引き継ぐ
今日のパブリッシャーは、ますます複雑化する広告挿入プロセスをやり取りして管理し、ワークフローと広告パートナーとの関係を可視化するスケーラブルなプラットフォームを必要としている。
以下に示すのは、広告プロキシサービスのフローアーキテクチャである。 フローのフロントエンドでは、広告から広告を要求するのに十分な情報が得られるまで、プレイヤーはマニフェストサーバーを要求する。 そのような場合、広告自体に手を差し伸べる代わりに、マニフェストサーバーはそのタスクを広告代理サービスに渡す。 このオフロードはマニフェストサーバから機能するだけでなく、遅延の削減やデバッグデータの収集など、他のいくつかの利点も可能にする。
広告の取得と検証の作業は、広告代理サービスによって処理され、マニフェストサーバーが再生のために広告をストリームにステッチし、シームレスな視聴体験を提供するためのリソースを解放する。
- プレイヤーはマニフェストを要求する。
- コンテンツは広告代理店に広告を取得するように要求する。 作品の一意の識別子を受け取った後、コンテンツはマニフェスト生成の他のステップに移動する。
- アドプロキシが要求された作業の実行を開始する。
- 作業はキューに入れられ、処理される順番を待つ。
- 「ワーカー」サーバはキューからジョブを取り出し、広告から広告アセットを要求し始め、作業のステップと結果のデータの両方をデータベースに保存する。
- コンテンツは、一意の識別子を参照して、広告代理店に「ジョブxの広告はどこにあるか」と尋ねる。 Ad Proxyはコンテンツに広告を返し、コンテンツはそれらをマニフェストに入れてプレイヤーに返す。
広告ルックアップを拡大/縮小する
Ad Proxy Serviceはリクエストを受信すると、新しいリクエストを受信し続けるためにそれらをキューに入れ、スケーラビリティを向上させる。 また、マニフェストサーバーにプレースホルダとしてジョブIDを提供し、広告は追跡されるため、マニフェストサーバーはAd Proxyを待たずに続行できる。 adsの作業者はadsに呼出し、adsが適切なadsを供給できるように捕獲されたすべてのプレーヤーデータおよび他のストリーム情報に沿って送信することによってキューの「adjobs」をかじり始める。 このプロセスの主な利点は、ADSワーカーが並行してADSをフェッチすることで、潜在的なボトルネックを排除し、レイテンシを短縮できることである。
ADSデータを標準化する
プロセス全体を通じて、広告代理店と広告の間の通信は広告とともに記録され、データベースに保存される。 データはプロバイダによって異なる場合があり、一貫した命名規則に従って解析および正規化される。 これにより、分析やデバッグ時にADSデータを使用する方がはるかに効率的になる。
広告の配信
マニフェストサーバーがADSを必要とするポイントに到達したときにプロセスが完了する。 それは広告代理店を呼び出し、「ここにあなたが私に与えた仕事ID、私にadsを」言う。 広告代理店はデータベースからそれらを取得し、一緒に送信する。
広告ビーコンアクティビティのインデックス作成と保存
広告代理サービスはまた、プレイヤーからビーコン情報を取得して保存する責任もあり、適切な収益化を確保するための鍵となる。 ビーコンは主キーを持つ個々のオブジェクトとして格納される。 このため、マニフェストサーバがADSを要求すると、Ad Proxyサービスはビーコン情報も提供する。 次に、プレイヤーが特定のチェックポイントにヒットすると、マニフェストで指示されたことに基づいてビーコンを発射する。 次にビーコンワーカーはデータベースからオブジェクトを取得し、適切な更新を行い、この時点でこれが発生したと通知する。広告から返された応答はxであり、エラーがあったかエラーがなかったか、その情報をすべて保存する。
広告再生のトラブルシューティング
追跡と分析はプロセスに含まれる。 広告プロキシアーキテクチャは、API、GUI、プッシュログを通じて広告パフォーマンスと視聴者数に関する広範な情報を提供する。 「もし」と「なぜ」広告の問題があるのかがわかっているので、広告がロードされなければ指をさすことはできない——データを指し示すことができる。 すべてのセッションは追加の設定なしで含まれ、データには最大14日間アクセスできる。
APIを通じて、コンテンツパブリッシャーは次のような情報を分析できる。
- 外部広告からの未加工のリクエストおよびレスポンスデータ
- 応答時間とサイズ
- 返された広告の数
- 広告ポッドの場所
- デバイスタイプ
- ラッパーの数
- エラー(広告が返されない、解析の失敗、接続エラーなど)
- 広告プロバイダーからの警告(オプションだが推奨されるパラメータがないなど)
- 要求の失敗(VPAIDなど)
結論
各視聴者にパーソナライズされたビデオ体験を提供しようとするパブリッシャーは、ストリーミングワークロードを設計して拡張する必要がある。 広告処理専用のサービスを作成することで、個々の視聴者のためにパーソナライズされた広告、コンテンツ、停電を強化するエンジンであるマニフェストサーバーのパフォーマンスが向上するだけでなく、広告がサポートされているビデオストリームのトラブルシューティングのための強力なツールを作成し、高品質のテレビのような視聴体験を保証する。
広告代理サービスの問題の根本原因をより深く理解することで、コンテンツパブリッシャーと放送局は広告運用ワークフローを可視化できる。 他のデータとの相関性を高めることで、視聴者の定着率を高め、広告収益を最大化できる。