OpenRTB 2.6 已準備好實施。 這個版本的協議有什麼新內容？
已發表: 2022-04-22- 央視廣告位競價
- 買家的更多背景
- 用戶代理內容結構
- AdCOM 列表更靈活
- Admixer 已經支持 OpenRTB 2.6
4 月 12日，IAB Tech Lab 宣布完成 OpenRTB 2.6 草案，並報告稱新標準已準備好實施。 這對所有行業參與者來說都是一個好消息，因為當前版本的 OpenRTB 協議已經完全過時，降低了程序化交易的效率。 有了新版本，供需雙方都獲得了更大的靈活性，尤其是在 CTV 和 Context 領域。
讓我們看看變化的主要領域以及 AdTech 參與者將如何從中受益：
- 購買和銷售 Ad Pod 的新屬性和指南
- 描述內容頻道和網絡的新對象
- 結構化的 User-Agent 對象支持即將凍結到 User-Agent 字符串
- 使用 AdCOM 1.0 列表加快更新速度
央視廣告位競價
由於電視內容和其中的商業插播的性質，需要在每個廣告插播內提供多個廣告。 連播請求/響應的概念在一段時間前開始發揮作用，但有一個很大的限制——能夠競標和填充廣告連播中的各個廣告位，但不能在整個廣告時段投放。 此外，單獨競價廣告位通常會導致廣告時段出現重複廣告，並且不允許品牌競爭分離。
使用 OpenRTB 2.6，廣告商可以獲得廣告插播的完整長度，並選擇最佳方式來填充多個不同長度的廣告視頻。 此功能可以顯著提高發布商從每個廣告連播中獲得的收益。
新版標準中出現的另一個重要參數是“mincpmpersec”——視頻廣告每秒的底價。 鑑於視頻的持續時間不同，此參數允許買家相互比較不同廣告的出價，並在廣告塊中形成最有利可圖的視頻集。
這兩項變化都將增加 CTV 廣告程序化交易的靈活性，並將使各方受益：出版商、廣告商甚至用戶。
買家的更多背景
在典型的工作場所動態變化的世界中，如何找到、激勵和留住頂尖人才 由於電視內容可以非獨家分發並通過多個不同的賣家進行交易，因此買家了解該廣告非常重要請求中的展示位置屬於某個電視網絡或頻道。 在 OpenRTB 2.6 標準發布之前，廣告商沒有這樣的機會。 在新版本中出現了兩個新的上下文對象“Network”和“Channel”。
現在買家可以獲得電視網絡的名稱和人類可讀格式的確切頻道名稱。 這一變化將極大地擴展特定內容定位和品牌安全選項。
用戶代理內容結構
在可預見的將來，在處理用戶代理信息時使用指紋方法的舊方法將被淘汰。 這可能會影響向用戶設備正確投放廣告。 所以，這類信息的重要性還是很緊張的。
OpenRTB 2.6 提供了一種以結構化對象的形式傳達用戶代理內容的替代方法。 用戶的瀏覽器、設備平台和型號，甚至體系結構和位數等參數都可以通過適當的對象屬性進行傳輸。 當客戶端支持用戶代理客戶端提示時，會提供結構化用戶代理信息。 改進將有助於保持正確的廣告顯示。
AdCOM 列表更靈活
由於缺乏描述分類、創意格式、展示位置等的統一標準，導致行業參與者開發了自己的這些參數的特定列表。 在單一程序化生態系統的背景下，規範的差異會導致重大的技術損失以及欺詐和非法活動的機會。 這就是為什麼將這些多種格式歸為一個共同點對於製定行業標準而言是一項非常重要的工作。
廣告通用對像模型或 AdCOM 是分層規範，旨在應對這些挑戰並有助於標準化許多選項。 由於 AdCOM 是一個動態規範並且不斷更新，因此在 OpenRTB 2.6 標準中使用該規範中的列表創造了必要的靈活性。 編程環境的快速發展需要標準的快速變化。 隨著 AdCOM 1.0 Lists 的引入，我們將能夠更接近必要的效率。
Admixer 已經支持 OpenRTB 2.6
Admixer 與標準的持續變化保持同步，並積極參與程序化供應鏈工作組內新協議的開發。 在技術方面，所有新的 OpenRTB2.6 功能都可以在 Admixer SSP 上使用。 需求和供應合作夥伴都可以利用這些創新。
OpenRTB 2.6 與最新版本的內容分類法一起將加強從經典電視購買模式到程序化電視購買的轉變。 當然，CTV平台標記廣告連播和視頻內容還需要時間。 因此，電視廣告將獲得更好的可尋址性和問責性，並且更容易為本地、中小型廣告商所接受。
Admixer 程序化主管 Yaroslav Kholod
