ライブイベントと24時間365日チャンネルを収益化するためのベストプラクティス

Picture of bsp-admin-1
bsp-admin-1

当社は日々、世界中のお客様にライブイベントや24時間365日のリニアチャンネルを提供しています。私たちは、ライブを大規模に配信するだけでなく、ライブを大規模に収益化することの意味について多くを学びました。ライブにとって、収益化は今や達成可能で、しばしば必要な要件ですが、成功とは、コンテンツの発生から消費までのエンド・ツー・エンドのワークフローを考えることを意味します。

この記事では、当社のお客様にとって最も一般的なマネタイズ手法である広告の利用に焦点を当てます。しかし、これらのベストプラクティスは、トランザクションモデルやサブスクリプションモデルの文脈でも有用です。

ダイナミック広告挿入(「DAI」)という包括的な用語は、動画コンテンツとともにインストリーム広告を表示する機能を説明するためによく使われる。技術的な観点から、DAIはクライアントサイド広告挿入(「CSAI」)とサーバーサイド広告挿入(「SSAI」)という2つの異なるアプローチで実装することができる。CSAIとSSAIを区別することは、ライブコンテンツでどのようにマネタイズするのが最も効果的かを理解する上で重要である。

CSAIは非常に一般的で、VODの "デファクト "スタンダードです。CSAIのワークフローを見てみましょう:

  • 広告の中断が検出されると、クライアント・デバイスは広告サーバーに次の要求を行う。
  • レスポンスは、複数の広告リクエストからなるウォーターフォールを含むことができる。
  • 最初の広告リクエストの結果、複数の広告ラッパーが生成され、追加のリダイレクトリクエストが必要になる場合があります。
  • これらのリクエストがエラー(タイムアウト、空白のレスポンス、HTTPエラーなど)または利用できないフィルにより広告を返さない場合、最初の広告リクエストはその後の追加広告リクエストにフォールバックすることがある。
  • クライアントデバイスに正常なレスポンスが提供されたと仮定すると、広告クリエイティブがデバイスと視聴体験に適切であることが前提となる。
  • さらに悪いことに、1回の広告の間に何度も広告が表示されることもある。デスクトップの場合、広告ブロッカーが広告リクエストの邪魔をしていないことが前提だ。

広告リクエスト、そしてそれに続く広告ラッパーや広告ウォーターフォールへのリクエストには時間がかかる。遅延が増加し、そのチェーンのどのステップでもエラーやタイムアウトの可能性が増加します。広告クリエイティブが互換性のあるフォーマットで利用できない場合がある(iOSのFLVなど)。互換性のあるフォーマットであっても、最適とは限りません:

  • 4MbpsのプログレッシブMP4を3Gネットワーク経由でアクセスするiOSデバイスに送信
  • 低解像度と低ビットレートのレンダリングを、接続されたテレビで家庭内の視聴体験に送る。
  • あるいは、当社が「深夜の地元中古車販売店の広告」と呼んでいるものは、広告のボリュームがコンテンツに対して正規化されていないものであります。

これらのいずれかが発生した場合、広告、そしてコンテンツ全体の体験の質が低下し、視聴者、コンテンツ配信者、広告主にとっての価値も低下する。

サーバーサイド広告挿入によるライブ収益化の最適化

SSAIは、ライブ番組コンテンツとターゲット広告の操作を舞台裏で処理します。その結果、メディア企業は、従来の放送と同じシームレスな品質で、視聴者にライブ・コンテンツを配信することができる。広告の挿入はフレームに正確で、広告体験はコンテンツと同じ品質です。このアプローチでは、クライアント側SDKを使用してクライアントの動作を管理する高度なロジックに依存しないため、ライブ配信(コンテンツと広告)は、基本フォーマット(多くの場合、HLSまたはDASH)をサポートするあらゆるデバイスで再生できます。

SSAIのメリットは、コンテンツのエコシステム全体に及ぶ:

  • 広告主にとって、SSAIは、「世帯」や「パネル」を使うという古臭いモデルから脱却するのに役立つ。その代わりに、広告主は、特定の時間に特定の地域の特定のデバイスで視聴している特定のユーザーにターゲットを絞って広告を配信することができる。
  • SSAIは、広告とコンテンツの間のバッファリングをなくします。
  • メディア企業にとって、配信と消費のデジタル世界におけるSSAIは、広告がアクション可能な視聴体験をもたらし、広告主にとっても視聴者にとっても価値を高める双方向のコミュニケーション・モードを開く。

計算する

SSAIのメリットの1つは、ユーザーごと、セッションごと、広告の区切りごとのターゲティングをサポートできることです。これは非常に強力で価値のある機能です。もはや、世帯レベルで測定やアトリビューションを行うことはありません。DMAやRON単位だけでなく、視聴者単位でのターゲティングが可能になりました。しかし、これは広告パートナーが広告ブレイク中に何十万ものリクエストに対応できるスケーラビリティを持たなければならないことを意味する。

システムの観点からこれが何を意味するのかを理解するために、6秒のセグメントでエンコードされたHLSコンテンツを使用して、同時視聴者数が100万人に達するライブ・ストリーム(当社の顧客からの一般的なリクエスト)について、簡単に計算してみましょう。

  • 各ユーザーはユニークなセッションとして扱われる。
  • 各セッションには一意のマニフェストが必要 - セグメントの持続時間と典型的なリフレッシュに基づいて、~166K リクエスト/秒
  • 各セッションは、状態を維持するために読み込みと書き込みを必要とする。
  • 各セッションは独立した広告リクエストをトリガーする(ラッパーやフォールバックにより追加リクエストが発生する可能性がある) - ~166Kリクエスト/秒
  • 各広告には5つのトラッキング・イベント(例:開始、完了、firstQuartile、midpoint、thirdQuartile)がある。

パートナーに依存するということは、信頼できる、スケーラブルなパートナーということである。

最後の点をさらに詳しく見てみると、120秒の広告枠の場合、広告サーバーがリクエストごとに30秒の広告を4つ表示すると、その広告枠の30秒間のインプレッション数は2,000万インプレッションになる。しかし、広告サーバーがリクエストごとに8つの15秒広告で応答した場合、その30秒間のインプレッションは4,000万回になる。

収益化には広告パートナーとの緊密な連携が必要です。また、パブリッククラウドのインフラが世界中で同じように作られているわけではないように、広告パートナーも同様のインフラを利用している可能性が高く、地域ごとの能力を分析する必要がある。

ある注目度の高いスポーツイベントの際、ある顧客から広告の埋まり具合が予想より低いという報告があった。イベント後にこの問題を診断するためには、複数のデータセットを集約して関連付け、タイムゾーンやセッション情報を照合し、「自然な」エラーや予想されるエラーを排除する必要がありました。当社は次のことを調べました:

  • ドリフトやエラーを引き起こした可能性のある貢献フィードの摂取
  • 広告の区切りが適切にマークされ、広告リクエストがトリガーされたことを確認するための帯域内シグナル
  • インメモリーキャッシュレイヤーでデータ損失がないことを確認するためのセッション情報。
  • 再生エラーの有無を確認するためのクライアント側プレーヤーのログ
  • 広告サーバーが成功したレスポンスを返しているか、エラーを返しているかを判断するための広告リクエスト

すべてのデータは合理的な範囲内にあるように見えたが、最終的には、広告ビーコンを受信しているサードパーティがインプレッションの急増に対応できず、短時間に正当なリクエストが大量に行われたためにタイムアウトやエラーが発生していることが判明した。

その結果、タイミングを損なうことなく効果的なリクエスト数を配信しながらピークスループットを下げるために、広告リクエストとビーコンの両方をどのように配分するかを考えることになる。その結果、顧客の広告パートナーの能力に合わせて「スケールダウン」するようにシステムを調整する必要があることがわかった。これは、ピークスループットを下げるために、広告をプリフェッチする(つまり、広告の区切りが明示的にわかる前に広告リクエストを行う)アプローチと、インプレッションをより長い時間枠で配信するアプローチの両方を評価することを意味する。

コア・インフラを常に再評価する

パブリック・クラウド・インフラは、地域最適化を維持しながらグローバル・アーキテクチャを実現するための、コスト効率と時間効率の高い手法である。しかし、すべてのパブリック・クラウド・インフラのリージョンがパフォーマンスとコストにおいて同等であるとは限らないという課題があります。その結果、あるリージョンのコンピュート、ストレージ、デリバリー能力を需要とバランスさせる必要があり、パフォーマンスを最大化したりコストを最小化したりするために、他のリージョンにオーバーフローさせる必要があるかもしれません。

コンテンツや広告のグローバルな配信を可能にするためにCDNをワークフローの重要な一部として活用している当社では、CDNパートナーがスケールに応じて一貫したパフォーマンスを発揮していることを確認するために、CDNパートナーに目を光らせる必要があります。日常的な運用測定と事後のトラブルシューティングの両方において、以前はエッジケースであったが、現在では一般的な状況となっている状況を特定し、監視することに多大な労力を費やし、特定のCDNパートナーだけでなく、CDNのPOP、サブネット、さらには個々のエッジサーバーに固有の問題があるかどうかを判断しています。

ライブ・ストリーミングが、企業が収益を伸ばし、エンゲージメントを高め、視聴者を増やす上で重要な役割を果たし続けることを期待している。

Back in July 2025, Brightcove unveiled an ambitious roadmap with a dual focus on innovation and quality of experience...
Our teams have been hard at work making the Brightcove platform more powerful, more reliable, and more insightful for...
Vertical Videos Experience lets you deliver a TikTok/Reels-style vertical feed on the web, powered by Brightcove. It’...

動画コンテンツの管理・活用はできていますか?

御社の動画マーケティング活動を強化し、必要な結果とROIを生み出すお手伝いをする方法については、
弊社までお問い合わせください。