IAB Tech Labは、この春、OpenRTB 2.6を公開しました。これは、コネクテッドTV（CTV）のインベントリ取引方法を改善するために設計された、OpenRTBプロトコルの注目すべき更新版です。
IAB Tech Labは、Index Exchangeやその他業界をリードするいくつかの企業と共に、今日よく見られるCTVの課題を解決する業界標準を策定するために、1年余りを費やしました。その結果がOpenRTB 2.6であり、デジタル広告にとって大きな前進となりました。この仕様は、プログラマティック環境におけるテレビの複雑性を考慮したものであり、CTVの拡張において重要な役割を果たすことでしょう。
私たちは、すべてのメディアオーナー、バイヤー、テクノロジープロバイダーがOpenRTB 2.6を利用することをお勧めします。ここでは、最もエキサイティングな10の新機能を紹介します。
1. 広告ポッド(ad pod)のサポート
長年、私たちの業界では、CTVやその他のオーバー・ザ・トップ（OTT）ビデオにおける広告ポッド型在庫の有無や分量を示すための、標準的なアプローチが欠けていました。広告ポッドは、次々と流れる複数の広告のグループで、従来のリニアテレビのアドブレイクに似ており、CTVでよく使用されています。しかし、テレビのアドブレイクの体験をCTVで再現する明確で簡単な方法はないことから、CTVとリニアテレビを別のものとして扱いつつ、広告ポッド内での重複を避けることが必要でした。
OpenRTB 2.6では、バイヤーが広告ポッド内の様々なポジションに対し、入札レスポンスをターゲットできるようになっており、メディアオーナーが秒単位のCPM入札フロアが設定できる機能が導入されています（静的なフロアではなく）。
メディアオーナーやバイヤーは、消費者が慣れ親しんだテレビ広告の体験をさらによく再現できるとともに、プログラマティックだからこそ提供できるターゲティングや、メジャメントの恩恵を受けることができます。
2. 柔軟な広告ポッド導入手引き
OpenRTB 2.6にも、広告ポッドの概念としてストラクチャード型、ダイナミック型、ハイブリッド型があり、多様なビデオやオーディオの事例に柔軟に対応することができます。
- ストラクチャードポッド: 一定の長さの広告を固定数で表示する。
- ダイナミックポッド：広告ブレイクの時間は固定で、広告枠の数と長さは柔軟に変更可能
- ハイブリッドポッド：ストラクチャードポッドとダイナミックポッドの組み合わせ
OpenRTB 2.6ドキュメントでは、CTVの入札リクエスト（Bid request）とレスポンスの実例を示して、それぞれのシナリオと新しいフィールドの使い方を説明しています。この導入ガイドは、メディアオーナーとバイヤーが仕様を一貫して解釈できるようにすることで、CTVとOTTのマネタイズのための標準的なアプローチを作成する上で、大きな役割を果たすでしょう。
3. インプレッションカウントの導入手引き
OpenRTBは入札リクエスト（Bid request）とレスポンスのための充実した機能を提供していますが、バイヤーとセラーが課金通知をどのように扱うべきかについては、強い立場をとっていません。標準化されたアプローチがないため、メディアバイヤーが（多くの場合MRCの指導のもと）、いつインプレッションを配信し課金対象としてカウントするかという条件を設定する傾向にあります。このため、インプレッションの通知とカウントの方法が断片的になっています。
OpenRTB 2.6は、メディアオーナーがDSP、SSP、メディアバイヤーに対して、クライアントサイドとサーバーサイドの両方のビーコンシナリオで、課金対象イベントをどのように表示すべきかについてのベストプラクティスを提供します。また、VAST 4.Xやads.certなど、他のIAB Tech Lab標準からの手引きも含まれており、詐欺や悪質行為に対する耐性を向上させます。この手引きにより、期待値が標準化され、相互運用性の向上と、メディアオーナーとバイヤー間のインプレッションの相違が減少します。
4. 新しいタクソノミの採用
以前のOpenRTBのバージョンでは、メディアオーナーやバイヤーはIABのコンテンツ・カテゴリー・タクソノミをいくつもの場所で使用していました（例えば、サイトやアプリのカテゴリー、そのサイトやアプリ内の特定のセクションやページ、または禁止されたクリエイティブ・カテゴリーを提供する際などです）。元々ウェブ用に設計されたこのタクソノミは、コンテンツ、広告、オーディエンスのための特定の記述子が使えないため、制限されていました。
OpenRTB 2.6では、入札リクエスト（Bid request）とレスポンスで使用されるタクソノミを明確にする新しい「cattax」フィールドによって、この分類が強化されています。メディアオーナーとバイヤーは、カスタムのタクソノミに同意するか、IAB Tech Labが提供するタクソノミを使用することができます。
- アド・プロダクトのタクソノミ
- オーディエンス・タクソノミ
- コンテンツ・タクソノミ
5. CTV用の豊富なメタデータ
入札リクエスト（Bid request）にネットワーク（例えば、A+E Networksのようなコンテンツのライセンサーやオーナー）とチャンネル（The HISTORY ChannelやLifetimeなど）の概念を表す新しいオブジェクトがあり、CTV在庫を明確化するのに役立ちます。この追加されたコンテキストは、バイヤーが広告を掲載するコンテンツを理解するのに役立ち、ブランドにとって最適であることを確認できます。
6. ストラクチャード・ユーザーエージェント情報のサポート
Google ChromeやMicrosoft EdgeなどのChromiumベースのブラウザは、デバイスのフィンガープリントを防止し、消費者のプライバシーを改善するために、User-Agent文字列を凍結し始めています。ブラウザは、従来のUser-AgentをHTTPヘッダとJavascript APIで置き換えることで、User-Agent Client Hintsを提供するようになりました。
その結果、RTBバイヤーは、デバイスのメーカー、モデル、オペレーティングシステムなどのデバイスレベルの情報をターゲットとする従来のUser-Agent文字列を、信頼できなくなりました。OpenRTB 2.6では、Deviceオブジェクト内に「sua (Structured User-Agent)」フィールドを導入し、メディアオーナーがこの新し User-Agent Client Hintsから得られるデバイスレベルの情報を、バイヤーに送信できるようにしました。
7. SSAIへのより深い理解
サーバーサイド広告挿入（SSAI）技術は、コンテンツと広告の間に中断がないシームレスな視聴体験を提供するため、CTVストリームの配信に一般的に使用されています。しかし、SSAIの実装によって、メジャメントおよび課金通知（ビーコンとして知られる）の処理方法が異なっています。
OpenRTB 2.6では、Impオブジェクト内に新しい「ssai」フィールドが導入され、メディアオーナーは、クリエイティブアセットスティッチングと、ビーコンがクライアントサイドと、サーバーサイドのどちらで行われるかを、SSPとDSPに通知できるようになりました。
この信号は、視聴者体験の質を示すだけでなく、不正行為の可能性も示しています。たとえば、メディアオーナーがビーコンをクライアントから発信するように指示している場合、SSPとDSPはサーバー、またはデータセンターIPから発信される課金通知に対して懐疑的であるべきです。
8. リワード広告のサポート
メディアオーナーとバイヤーは、消費者がゲーム内通貨のような報酬と引き換えに広告に関与するリワード広告の機会を示すために、多くの非標準的な拡張機能に依存していました。OpenRTB 2.6仕様では、Impオブジェクトに「rwdd」フィールドを追加することで、どんなタイプのインプレッションであってもリワード広告であると認識するための、標準的な方法が導入されました。
9. オーディオの入札レスポンス
OpenRTBの以前のバージョンでは、メディアオーナーは入札レスポンスのクリエイティブタイプを決定するために、広告マークアップ（adm）フィールドの内容を確認する必要がありました。これは、バナー、ビデオ、またはネイティブ入札レスポンスの対象となるマルチフォーマット・リクエストにとって、特に困難なことでした。ビデオやオーディオのクリエイティブの場合、メディアオーナーはそのマークアップ（VASTドキュメント、多くの場合は別のVASTへのWrapper）を解析して、クリエイティブの期間を決定する必要がありました。
OpenRTB 2.6のBidオブジェクトには2つの新しいフィールドがあり、バイヤーがメディアオーナーに代わってその推論作業をすべて取り除き、新しいクリエイティブをすぐに提供できるよう支援します。
- dur: バイヤーが入札したビデオ、またはオーディオクリエイティブの再生時間を示します。
- mtype: バイヤーの入札に含まれるクリエイティブの種類（バナー、ビデオ、オーディオ、ネイティブ）を表します。
10. リストがAdCOM 1.0を基準に
OpenRTB 2.6のオブジェクトのアトリビュートに関するすべてのリストは、AdCOM 1.0 GitHubを指し示すようになりました。2.5の問題の1つは、古くなったリストを更新するために、スペックの全く新しいバージョンを発行する必要があったことです。AdCOM GitHubをリストに使用することで、OpenRTB仕様が更新されるかどうかに関わらず、時間の経過とともに値を追加、修正することができます。
CTVの成長は、業界標準やテレビの特性を念頭に置いて設計されたプログラマティックツールの欠如によって妨げられてきました。OpenRTB 2.6はこれを解決し、将来のCTV広告の道を切り開く多くの新機能の標準化を実現します。
標準規格が定められた今、一刻も早くそれをサポートし、採用する時が訪れました。
2022年にOpenRTB 2.6の仕様が導入されて以来、ストリーミングTVにどのような影響があったのでしょうか？最新情報をご確認ください。
