Home 技術記事 サーバーサイド広告挿入(SSAI)の透明性とトラブルシューティングの向上
Applications

サーバーサイド広告挿入(SSAI)の透明性とトラブルシューティングの向上

About The Author

Outline

OTT広告のソーシング、再生、検証の改善

OTTは、放送局やコンテンツ制作者にとって、視聴者の興味に応じて動画ストリームをパーソナライズできるようにすることで、リニアTVの体験を超えた優れた機会 です。 この高度なパーソナライゼーションは、ターゲットを絞った広告をプレミアムCPMレートで配信できるようにすることで、OTTストリームへの広告収益を引き付ける重要な要素でもあります。

しかし、この機会は、広告のソーシング、再生、検証の課題によって妨げられています。 OTT広告に関する標準の多くは、初期段階であり、現在も進化しています。 さらに、Quality of Service(QoS)に関する詳細なデバッグと分析は、多くの場合制限されます。 また、広告が一貫した音量レベルで再生されたかどうかなど、体験の質(QoE)を理解することも重要です。

これらの課題を念頭に置き、拡張性の向上とレイテンシーの削減に向けた継続的な取り組みを行っている当社では、プラットフォームの一部として専用の広告プロキシサービスを開発しました。 元々は、ストリーミングプラットフォームのスケーラビリティを向上させるバックエンドの強化として設計されていましたが、広告のソーシングと配信ワークフローの可視性と制御性が大幅に向上するなど、いくつかの管理上の利点もあります。 これらのツールを使用すると、パブリッシャーは適切な視聴者に適切な広告を配信し、QoSとQoEのさまざまな側面の両方を監視できます。

マニフェストサーバーを使用したパーソナライズされたストリーム

以前のブログ記事では、カスタマイズされた広告コンテンツを組み込むためにストリームをパーソナライズする際のマニフェストサーバーの役割について詳しく説明しました。 その記事で説明したように、マニフェストサーバーは、他のコンテンツと同様に、広告リクエストを作成し、応答を解析し、広告クリエイティブをダウンロードして処理する責任があります。 次に、マニフェストサーバーは統合されたストリームをプレーヤーに送信し、視聴者に一貫性のあるエクスペリエンスを提供し、デバイスの互換性を最大限に高め、広告ブロッカーを回避します。

マニフェストサーバーは、再生とパーソナライゼーションの部分を処理するために十分な装備を備えていますが、広告の調達と検証に関連する作業は、さらに複雑さと新しい課題をもたらします。 数百万人の同時視聴者にパーソナライズされた体験を提供するストリーミングアーキテクチャの最適化を継続していく中で、これらのアクティビティをサポートする広告プロキシサービスの開発につながりました。

調達と検証の課題

ストリームに挿入される広告を取得するには、広告コンテンツをFreeWheelやGoogle Ad Managerなどの広告決定サーバー(広告)から取得する必要があります。 このプロセスでは、広告をリクエストし、ストリームとそのすべての情報を渡して、正しい広告が配置されるようにします。 課題は、特定のサーバー上の多くの広告が、別のサーバー上の実際の広告を指すラッパーにすぎないことです。

たとえば、4つの広告スロットがある場合、そのうちの2つは直接挿入されますが、残りの2つは広告アセットを持たず、「広告はここにありません。どこか他の場所にありますので、ここにアクセスする必要があります」とラッパーになっている可能性があります。 私たちは、表示されるすべての広告応答に対して再生可能な動画アセットを解凍してソースするように努めています。 解答を検証しながら解答を検証し、再生可能な広告アセットがストリームに挿入される準備ができていることを確認します。 私たちのアーキテクチャは、各視聴者にパーソナライズされたマニフェストを提供するように設計されているため、このプロセスはセッションごとに繰り返され、かなりの負荷になる可能性があります。

広告検索の待ち時間

複数のラッパーを介してアセットを追跡することは、並行して処理しないとレイテンシーの主な原因になる可能性があります。 ラッパーの中には、実際の広告アセットに解決しないものもあります。 これが動画体験を低下させないようにするため、次の広告を取得する前に、この「ウォーターフォール」を制限しています。 このワークフローでデータとインサイトを公開することで、パブリッシャーは広告が配信されない需要源を特定して解決し、視聴者が中断のない視聴体験を得られるようにしながら、広告収益を最大化することができます。

レスポンシブ広告体験を確保することは、マニフェストサーバーでの広告検索の影響を確認することも意味します。これは、パーソナライズされたストリームを最小限のレイテンシで構築することに忙殺されています。 マニフェストサーバーには、広告パフォーマンスデータの生成と保存専用のリソースが無制限にありません。 マニフェストの生成に必要な広告情報のみを保存するため、問題のある広告呼び出しや再生をデバッグするためのデータの可用性が制限される可能性があります。

ADプロキシサービスが引き継ぐ

今日のパブリッシャーは、ますます複雑化する広告挿入プロセスと相互作用して管理し、ワークフローと広告パートナーとの関係を可視化するスケーラブルなプラットフォームを必要としています。

以下に、広告プロキシサービスのフローアーキテクチャを示します。 フローのフロントエンドでは、広告から広告をリクエストするのに十分な情報が得られるまで、プレーヤーはマニフェストサーバーを要求します。 その場合、広告自体に手を差し伸べる代わりに、マニフェストサーバーはそのタスクを広告プロキシサービスに渡します。 このオフロードはマニフェストサーバーから機能するだけでなく、レイテンシの短縮やより多くのデバッグデータのキャプチャなど、他のいくつかの利点も可能になります。

広告の取得と検証の作業は、広告プロキシサービスによって処理されます。これにより、マニフェストサーバーのリソースが解放され、広告をストリームにつなぎ合わせて再生し、シームレスな視聴体験を提供できます。

  1. プレーヤーはマニフェストを要求します。
  2. コンテンツは広告プロキシに広告を取得するように要求します。 作業の一意の識別子を受信すると、コンテンツはマニフェスト生成の他のステップに移動します。
  3. ADプロキシが要求された作業を開始します。
    1. 作業はキューに入れられ、処理される順番を待ちます。
    2. 「ワーカー」サーバーはキューからジョブを取得し、広告から広告アセットをリクエストし、実行中の作業のステップと結果のデータの両方をデータベースに保存します。
  4. コンテンツは、一意の識別子を参照して、「ジョブxの広告はどこにありますか」広告プロキシに尋ねます。 広告プロキシは広告をコンテンツに返し、コンテンツは広告をマニフェストに入れてプレーヤーに返します。

広告ルックアップの拡大

広告プロキシサービスは、リクエストを受信すると、新しいリクエストを受信し続けるためにそれらをキューに入れ、スケーラビリティを向上させます。 また、広告が追跡される間、マニフェストサーバーにプレースホルダーとしてジョブIDが提供されるため、マニフェストサーバーは広告プロキシを待たずに移動できます。 次に、広告ワーカーは、広告を呼び出して、取得したすべてのプレーヤーデータとその他のストリーム情報を送信し、広告が適切な広告を提供できるようにすることで、キュー内の「広告ジョブ」を噛み始めます。 このプロセスの主な利点は、ADSワーカーが並行して広告をフェッチし、潜在的なボトルネックを排除してレイテンシーを削減できることです。

ADSデータの標準化

プロセス全体を通して、広告代理店と広告の間の通信は広告と共に記録され、データベースに保存されます。 データはプロバイダによって異なる場合があり、一貫した命名規則に従って解析および正規化されます。 これにより、分析またはデバッグ中にADSデータを使用する方がはるかに効率的になります。

広告の配信

マニフェストサーバーが広告を必要とするポイントに到達すると、プロセスが完了します。 広告代理店に電話して、「これがあなたが私に与えた仕事IDです。広告を渡してください」と言います。 その後、ADプロキシはデータベースからそれらをフェッチして送信します。

広告ビーコンアクティビティのインデックス作成と保存

また、広告代理サービスは、適切な収益化を確実にするための鍵となる、プレーヤーからのビーコン情報をキャプチャして保存する責任もあります。 ビーコンは、主キーを持つ個々のオブジェクトとして格納されます。 このため、マニフェストサーバーがADSを要求すると、Ad Proxyサービスもビーコン情報を提供します。 次に、プレイヤーが特定のチェックポイントに到達すると、マニフェストで行うように指示された内容に基づいてビーコンを発射します。 その後、ビーコンワーカーはデータベースからオブジェクトをフェッチし、この時点で起動したことを通知する適切な更新を行います。ADSから返された応答はxで、エラーがあったか、エラーがなかったか、すべての情報を保存します。

広告再生のトラブルシューティング

追跡と分析はプロセスに含まれています。 広告プロキシアーキテクチャは、API、GUI、プッシュログを使用して、広告のパフォーマンスと視聴率に関する広範な情報を提供します。 広告に問題があるかどうかと理由がわかっているため、広告がロードされない場合でも指し示す必要はありません。データを指し示すことができます。 すべてのセッションは追加の設定なしで含まれ、データには最大14日間アクセスできます。

APIを使用して、コンテンツパブリッシャーは次のような情報を分析できます。

  • 外部広告からの生のリクエストおよびレスポンスデータ
  • 応答時間とサイズ
  • 返品された広告の数
  • 広告ポッドの場所
  • デバイスタイプ
  • ラッパーの数
  • エラー(広告が表示されない、解析エラー、接続エラーなど)
  • 広告プロバイダーからの警告(オプションだが推奨されるパラメータがないなど)
  • 要求の失敗(VPAIDなど)

結論

個々の視聴者にパーソナライズされた動画体験を提供しようとするパブリッシャーは、ストリーミングワークロードを拡張できるように設計する必要があります。 広告処理専用のサービスを作成することで、個々の視聴者向けにパーソナライズされた広告、コンテンツ、停電を強化するエンジンであるマニフェストサーバーのパフォーマンスが向上するだけでなく、広告がサポートするビデオストリームのトラブルシューティングに強力なツールを作成し、テレビのような高品質の視聴体験を保証します。

広告代理サービスの問題の根本原因をよりよく理解することで、 コンテンツパブリッシャーと放送局は広告運用ワークフローを可視化できます。 他のデータと相関させることで、視聴者の維持率を高め、広告収益を最大化できます。