OpenRTB 仕様 v3.0（日本語訳）OpenRTB Specification v3.0

OpenMedia プロジェクトのミッションは、広告主である買い手と配信在庫を抱える売り手との間のコミュニケーションを実現するオープンな業界標準の提供によって、プログラマチック広告市場の成長を加速させることです。この標準には、実際のリアルタイム入札プロトコル、情報分類、オフライン構成同期といった内容が含まれますが、これらに限定されるものではありません。

本ドキュメントは、リアルタイム入札（Real-Time Bidding; RTB）のインタフェイス標準を規定しています。これらのプロトコル標準は、配信在庫の供給者（つまり、取引所、配信者と連携しているネットワーク、売り手サイドのプラットフォーム）と競争的なその在庫の買い手（つまり、入札者、買い手サイドのプラットフォーム、もしくは広告主と連携しているネットワーク）の間の繋がりをシンプルにすることを目的としています。

OpenRTB の全体目標は、買い手と売り手の間のコミュニケーションにおける「リンガフランカ (訳注：共通言語)」 を作成することです。 その目的は、各当事者がどのようにビジネスを行うかを正確に規制することではありません。プロジェクトとして私たちは、技術革新が「水道管よりも」深いレベルで起こるように当事者間の接続を容易にすることを目指しています。

OpenRTB は、2010年11月に3つの買い手側プラットフォーム（dataxu、MediaMath、Turn）と3つの売り手側プラットフォーム（Admeld、PubMatic、Rubicon プロジェクト）による、パイロットプロジェクトとして立ち上げられました。当初の目標は、ブロックリストを取引するための当事者間通信を標準化することでした。そうして、OpenRTB ブロックリスト仕様のバージョン 1.0 が 2010年12月にリリースされました。

業界からのポシティブな反応を経て、Nexage は実際のリアルタイム入札要求・応答プロトコルに焦点を当て、さらにモバイル広告をサポートする点に特筆した OpenRTB の API 仕様を作成するという提案を、OpenRTB プロジェクトに持ち込みました。そしてモバイル小委員会が、買い手サイドを代表する企業（dataxu、Fiksu、[X+1]）と売り手サイドを代表する企業（Nexage、Pubmatic、Smaato、Jumptap）の間で結成されました。このプロジェクトによって、OpenRTB v1.0 モバイル仕様が生まれ、2011年2月にリリースされました。

モバイル仕様のリリースに続いて、dataxu と ContextWeb が協業する動画広告取引所（BrightRoll、Adap.tv）のための、動画小委員会が結成されました。 その目標は、ディスプレイ、動画、モバイルのサポートを一つに統合することでした。 この取り組みによりOpenRTB 2.0 が生まれ、これが2011年6月に統一規格としてリリースされました。

OpenRTB は業界で非常に幅広く採用されたため、2012年1月のバージョン 2.1 のリリースに併せて IAB 標準として発行されました。仕様の技術的内容に関する意思決定は、OpenRTB コミュニティとそのガバナンスルールに基づきます。

それ以来、プログラマチック広告は業界で支配的な強制力を持つようになりました。 しかし、これによってサプライチェーンがますます複雑化し、不正行為やその他のリスクが増加する可能性があります。これが OpenRTB v3.0 を推進する鍵となる動機の一つです。

3.0 複雑なサプライチェーン、階層化仕様アーキテクチャ、在庫信頼性のためのデジタル署名

2.5 ヘッダービディング、請求および敗北通知、フレックス広告、請求 ID、戦略 ID、インプレッションメトリック、アウトストリームビデオ、その他多くの軽微な機能拡張をサポート。

2.4 オーディオ広告枠のサポートと、2.x バージョンで最も多くの軽度から中程度の機能拡張。

2.3 ネイティブ広告枠のサポートと、複数の軽微な機能拡張。

2.2 非公開市場直接取引、動画、モバイル、および規制信号に関する新しい機能拡張。

2.1 IQG コンプライアンス、軽微な機能拡張、および訂正のための改訂。

2.0 ディスプレイ、モバイル、動画の標準を統一仕様へ統合。

1.0 OpenRTB モバイルの初回リリース。

1.2 配信者設定 API (提案済み)。

1.1 クリエイティブ属性のリアルタイム取引を含める軽微な変更。

1.0 OpenRTB ブロックリスト仕様の初回リリース。

この章は、詳細な OpenRTB のトランザクションレイヤの仕様を含んでいます。明示的に指定されている、任意であるという注釈がある、もしくはベストプラクティスから参照されている場合を除いて、この章の全ての事柄が OpenRTB 準拠に必須となります。

次の UML クラス図は、リクエストおよびレスポンスオブジェクトが含むペイロードの全体構造を図示しています。ペイロードは Openrtb という名前のついたオブジェクトをルートとし、Openrtb オブジェクトは Request と Response の共通のルートになります。そして、Request と Response はペイロードのタイプを決める２番目のルートです。

この章を通して、属性を「必須」もしくは「推奨」として指定することがあります。その属性を省略してしまうことでプロトコルが壊れてしまい、ビジネス価値の指標として保証できなくなる属性を「必須」と指定します。また、その属性を省略してもプロトコルは壊れないものの、ビジネス価値が大きく損なわれる属性を「推奨」と指定します。

仕様準拠の観点から見れば、「推奨」か否かに関わらず「必須」と示されていない全ての属性は任意になります。任意の属性は、省略された場合にそれとみなすことができるデフォルト値を持つことがあります。デフォルト値が指定されていない場合、慣習的には値の省略を「不明」として解釈するべきです。また、空の文字列やヌル値が指定されている場合、省略されている場合と同じように解釈するべきです。（指定されていればデフォルト値、そうでなければ「不明」）

ベストプラクティス： 取引所とデマンドソースは、それがもつ拡張仕様上でどういったオブジェクトや属性を任意のオブジェクトとしてサポートしているかを、パートナーに公開することを勧めます。

このトップレベルオブジェクトは、リクエストとレスポンス両方のペイロードにとってのルートです。バージョン情報と、トランザクションのベースとなるレイヤ４ドメインモデルへの参照を含みます。OpenRTB で使われるドメインモデルは、デフォルトで広告共通オブジェクトモデル（AdCOM）となります。

注釈：このドキュメント上でのルールとして、Java のようなプログラム言語のクラス名の共通ルールに沿い、定義されるオブジェクトは大文字の頭文字で示されます。一方で、オブジェクトの実インスタンスと、ペイロード上のそこへの参照は小文字で示されます。

属性の中には、任意指定のものも含まれます。例えば ver 属性は、このペイロードで用いられる OpenRTB 仕様のバージョンを指定します。これは HTTP ヘッダを介して、レイヤ１上でも伝えられます。実行時トランザクション情報外でペイロードをより自己文書化することで、特定の手助けとなるために有用です。

しかし domainver 属性は、レイヤ４の構造がそのバージョンの間で変わるかもしれないので、実行時ユーティリティを持ちません。この属性は、ドメインオブジェクトのパーサもしくはアンマーシャリング実装を、正しく呼び出すのに役立つものです。

リクエストオブジェクトは、最低限の高レベル属性（例：ID、テストモード、オークションタイプ、最大オークション時間、買い手の制限など）と、リクエスト元および実際の販売提供をカバーする下位オブジェクトを含みます。下位オブジェクトは、提供されている商品とそれに該当する取引全てを含みます。

このモデルには、レイヤ４ドメインオブジェクトとの橋渡しとなる二つのポイントがあります。それは、Request オブジェクトと Item オブジェクトです。Request オブジェクト配下のドメインオブジェクトは、提供の全体情報を保持するオブジェクトを含むでしょう。これらは、サイト／アプリ、デバイス、ユーザなどを記したオブジェクトを含むでしょう。一方 Item オブジェクト配下のドメインオブジェクトは、提供されている商品の詳細（例：インプレッション機会）と、入札と関係するメディア上での仕様・制限を指定しているでしょう。

Request オブジェクトは、グローバルにユニークな入札リクエスト ID を含みます。これは ID 属性と呼ばれる必須なもので、一つ以上のオブジェクトを含む Item 配列（例：一つ以上の販売商品）です。そして、その他の属性は提供されている全商品に適用されるルールと制限を示しています。このオブジェクトは、ユーザ、デバイス、サイト／アプリなどといった情報を持つ、レイヤ４ドメインオブジェクトとの橋渡しもしています。

このオブジェクトはトランザクションの送信元についてのデータを保持していて、トランザクション自体のユニーク ID、送信元認証情報、CoC を含んでいます。

注意：ds、dsmap、cert、digest 属性は、 Ads.cert: 署名済み入札リクエスト仕様（訳注：原文よりリンク先を修正） として定義された、デジタル署名済みの入札リクエストをサポートしています。Ads.cert 仕様はまだベータ段階であり、これらの属性についてもそれに近い段階であるということを考慮すべきです。

このオブジェクトは、公開市場もしくは非公開市場取引のいずれの上でも販売提供されている商品の枠を表します。同じ入札リクエストの中に複数の提供商品が存在してもかまいませんが、各入札は興味のある特定の商品を参照しなければならないので、id 属性が必須となります。このオブジェクトは、提供商品のより深い仕様（例：インプレッション）におけるレイヤ４ドメインオブジェクトとの橋渡しを担っています。

このオブジェクトは、売り手と買い手の間で事前に取り決められた特定の取引を構成します。取引が存在する場合、この商品がその取引の協約事項の元で有効であることを示します。

このオブジェクトは、メトリックの配列として商品に関連づけられています。これらのメトリックは最近の平均ビューアビリティや CTR などの、意思決定を支援するための洞察を提供します。各メトリックはそのタイプによって識別され、メトリックの値を報告し、値を計測した送信元もしくはベンダーを任意で識別します。

レスポンスオブジェクトは、最低限の高水準属性（例：リクエスト ID への参照、入札通貨など）とシート入札の配列を含みます。シート入札とは、それぞれが入札の集合である買い手シートに代わるものです。

個々の入札は、リクエスト内の関連商品と購入情報を参照します。購入情報とは、価格、適用可能である場合には取引 ID、通知 URL といったものを指します。入札に関連するメディアは、各入札に含まれるレイヤ４ドメインオブジェクト（広告クリエイティブ、マークアップ）を介して伝えられます。

このオブジェクトは、Openrtb ルートの下にある入札レスポンスオブジェクトです。オブジェクトの id 属性は、入札リクエスト ID と同一になります。bidid 属性は、入札者のための任意レスポンストラッキング ID です。指定されている場合、それをマークアップや通知 URL 内に置かれる置換マクロで使用可能になるでしょう。少なくとも一つの Seatbid オブジェクトが必須であり、ある商品を表す Bid を少なくとも一つ含みます。そして、それ以外の属性は任意指定になります。

最もコンパクトに「非入札」を表すには、HTTP 204 と空レスポンスを返してください。その一方で入札者が入札しない理由を伝えたい場合は、nbr 属性に理由を表すコードを指定した Response オブジェクトを返すことが可能です。

入札レスポンスは、複数の Seatbid オブジェクトを含むことが可能です。それぞれが別の買い手シートを表していて、それぞれが個々の入札を複数含んでいます。そして、複数の商品がリクエスト上にある場合に、シートは勝利できるインプレッションを全て受け付けたいか（デフォルト）、それともグループとして全ての商品で勝利できる場合にのみ興味があるのかを指定するのに、package 属性が使われます。

Seatbid オブジェクトは、一つ以上の Bid オブジェクトを含んでいます。それぞれが入札リクエストで提供される特定の商品と item 属性を介して関連しており、所与の価格による商品の購入提供を構成しております。

このオブジェクトは、動的な値をメディアマークアップに挿入するのに使われる、買い手定義のキーバリューペアを構成します。どのように伝えられるかに関わらずどんなメディアマークアップにも適用されますが、基本的には、トランザクションと入札で参照される以前（例：クリエイティブ品質レビューのために事前登録された）に取引所にアップロードされたメディアで使うためのものです。そして、実行時に置換されるマクロの完全な形式は ${CUSTOM_KEY} で、「KEY」 は key 属性で与えられる名前です。OpenRTB 標準マクロとのコンフリクトは、起こらないことが確約されています。

イベント通知 URL とその形式は、デマンドソースによって定義されています。そして、取引所が特定の情報（例：清算価格）を伝えられるように、多くのマクロをこれらの URL に挿入することが出来ます。取引所にはその URL を呼び出す前に、マクロを解決する責任があります。置換処理はシンプルで、正しいマクロが見つかるいかなる箇所において、シンタックスが正しいかどうかに関係なく行われます。さらに、元となる値が任意指定のパラメータで、かつそれが指定されていないとき、マクロは単に削除（長さ０の文字列との置換）されるでしょう。

入札システムの実装担当者の判断で、カスタムマクロがサポートされることもあります。事前アップロード済みの広告を参照することで入札が行われる場合、動的にデータ挿入を行うカスタムマクロのサポートは一般的に必要になるでしょう。カスタムマクロは ${CUSTOM_KEY} という形式で使用され、「KEY」は大文字小文字などの変更なしに「Macro」オブジェクトで指定される特定の文字列を表します。詳細は「Macro」オブジェクトを見てください。なお、取引所はカスタムマクロをサポートするか否かを選ぶことが出来ますが、事前アップロード済み広告の配信機能を提供する取引所ではサポートされることが期待されます。

こういった置換マクロと同じものを、広告マークアップ上にも置くことが出来ます。取引所は、前述の通知 URL で行われたのと同じようなデータ置換を行うでしょう。これはマークアップをどのように取得するかに依らず行われます。例えばユースケースの一つとして、清算価格といったデータをマークアップ上に埋め込まれたトラッキング URL に挿入することがあります。

次の表では、標準的な置換マクロを定義しています。OpenRTB に準拠する取引所は、データが利用可能な全マクロをサポートしなければならず、さらにマークアップと通知 URL どちらに対する置換もサポートしなければなりません。

試験あるいは広告品質目的でマークアップが描画される場合、マクロによって値がわからないことがあります（例：清算価格）。こういった場合は、マクロ値として AUDIT を置換してください。

マクロ値は事前に様々な難読化・暗号化アルゴリズムを使って、セキュリティ目的でエンコードされていても構いません。これは特に、価格情報が取引所から配信者を通じて送られ、マークアップ内のトラッキングピクセルを介してデバイスのブラウザに届くようなユースケースで興味深いでしょう。

特定のマクロはエンコードされた状態で指定されています。:X というサフィックスがマクロ名に付いているはずで、X は使用されているアルゴリズムを指し示す文字列です。アルゴリズム選択についてこの仕様で定義されていることはありませんが、当事者間で相互に合意されていなければなりません。例えば、価格マクロは Base64 でエンコードされており、B64 というコードで合意されているとします。その時、マクロは次に書かれたようになるでしょう：

本仕様内において後述のイベントを定義します。これとは別に、ドメインオブジェクト固有のレイヤ４でイベントが定義されることがあります。イベント URL を呼び出す全主体は、まず先に OpenRTB 標準の全置換マクロの解決を確認しなければなりません。

保留通知は、ある入札が OpenRTB 準拠のサプライチェーン内で勝者として選ばれていることを示します。これは、一つの取引所が唯一の意思決定者であるようなシンプルなサプライチェーンでは、オークションに勝利したことと同義になります。複雑なサプライチェーンにおいては、このイベントはまず、OpenRTB を介してその結果を伝えていないパブリッシャーに最も近い取引所から開始されます。しかし、OpenRTB に準拠していない（例：ヘッダービディング）上流の意思決定が未だ存在するかもしれないので、このイベントを必ずしも勝利とみなすことは出来ません。取引所はこのイベントを伝えるために、bid.purl 属性でデマンドソースから提供される URL を呼び出します。

注意： このイベントは案内（入札がサプライチェーン上の全ての OpenRTB 準拠の関門をパスした）としてのみ解釈されるべきです。決して、いかなる形のフルフィルメントや請求を示すものではありません。

請求イベントは、トランザクション結果として、取引所もしくはその他の仲介者からデマンドサイドパートナーの一つへ金銭的請求が発生する場合を指します。このイベントには取引所が決めているビジネスポリシーが適用され、ビジネスポリシーはデマンドパートナーに対して明確に伝えられるべきです。さらに DSP にとって、このイベントは関連キャンペーンに対する支出を減らすことが出来ることを示します。取引所はこのイベントを伝えるために、bid.burl 属性でデマンドソースから提供される URL を呼び出します。

注意： 清算価格マクロは、マークアップ上の DSP トラッカーと同じように他のイベントで解決されても構いませんが、この URL が正しく実装されていれば、OpenRTB プロトコル上で請求イベントを伝える唯一の公式手段になります。

ベストプラクティス： 請求イベント URL の呼び出しは、取引所とそのデマンドパートナー間のビジネストランザクションのフルフィルメントを表します。クライアント用ピクセルを含んでいるので他の当事者へ委譲されるべきではありませんが、ピクセルをもって取引所が請求の開始を伝えることがあります。

ベストプラクティス： 請求可能なイベントが発生したと判断したら（例：クライアント側で発生した描画信号の受信）、取引所とそのデマンドソース間の不一致を出来るかぎり抑えるために、取引所が収益を計上する最もサーバサイドから近い箇所で請求通知を呼び出すべきです。

ベストプラクティス： 潜在的に複数のオークション決定ポイントが存在するような、複雑なサプライチェーンにおいて最も一貫性のあるアプローチとして、取引所はクライアント側で発生した描画イベント、もしくは請求イベントを元にしたそれに相当するもので標準化されることが強く勧められます。

ベストプラクティス： インターネットはノイズが多いものですが、このイベントは会計上非常に重要です。請求通知を呼び出す主体が HTTP 200 もしくは 204 以外のレスポンスを受け取った場合、リトライ方式（例：10 秒ごとに 1 分間）を検討すべきです。その逆に請求通知を受け取る主体は、二重計算を避けるためにエンドポイントを冪等になるように努めるべきです。

VAST 動画においては、IAB が VAST インプレッションイベントを、インプレッションを請求可能とする公式の信号として規定しています。bid.burl 属性が指定されている場合、取引所がこのポリシーに従うのであれば同じタイミングでそれも呼び出されるべきです。しかし、小さな技術的問題で不一致が生まれるかもしれませんので、入札者はこういったシナリオを避けるために注意してください。一つのオプションは、動画のサプライソースに最も近い取引所が請求シグナルとしてインプレッショントラッカーを使い、それからさらに前述の請求通知を使うべきです。

敗北イベントは、取引所が入札に対して勝利の可能性がないと決定した場合を指します。取引所はここで、bid.lurl 属性でデマンドソースから提供された URL を呼び出すことがあります。

注意： 敗北通知がなかったからといって、勝利したことにはなりません。

取引所による敗北通知実行のサポートは、OpenRTB 準拠に必須ではありません。デマンドパートナーはサプライサイドパートナーに確認することを勧めます。さらに、取引所固有のポリシーによって敗北通知のサポートもしくは勝利した清算価格の開示が排除されることがあり、その結果 ${OPENRTB_PRICE} マクロは削除（長さ０の文字列との置換）されます。

複雑なサプライチェーンの例では、仲介者はこれらのイベントに参加するか（受信、処理して受け渡す）、もしくは迂回させるかを選ぶことができます。例えば、入札リクエストのトラフィックシェイパーのような仲介者は、イベントを直接下流に迂回させるかどうかを選択しますし、レベニューシェアに携わる完全な取引所では介入の必要があるかもしれません。

迂回に対して介入を行う動機は、イベントタイプによっても変わることがあるでしょう。例えば、ある仲介者はほぼ常に請求通知に対して介入を行います。しかし敗北通知については、介入を行う仲介者も行わない仲介者もいます。ある取引所が、ある入札を放棄し（フロアプライス以下、ブロックリスト違反など）、入札レスポンスに含まれる残りの入札を含めるように決定することを検討すると、上流を負かすものもあるでしょう。これらの敗北を本質的に宣言しているので、その入札を放棄するもののために敗北通知を呼ぶべきですが、次の入札のサブセットを放棄すると決定した時、上流の主体が敗北通知を直接下流に呼び出せるように選んでも構いません。

所与の入札に対するイベントへの介入を行う場合、仲介者は元 URL 上のマクロを解決して、潜在的に新しいマクロのセットと合わせて（例：上流の清算価格を学ぶため）それ自身を差し戻すように、その URL を新しい URL のパラメータとしてエンコードします。、上流に返却された入札でこの新しい URL を指定します。このイベント URL を受信すると、仲介者はイベントを処理して、受信、デコード、そして元 URL の呼び出しを行います。イベントを迂回するようにした場合、仲介者は単純に上流から返された入札に含まれる元 URL を維持するでしょう。

入札リクエストを署名することで「在庫枠が主張通りのものである」ということを買い手に保証することが出来ます（例えば、domain-spoofer.com が domain.com に見せ掛けることを出来なくします）。そしてこの方法は、複雑なサプライチェーンにおいて買い手が全ての仲介者と信頼関係を持っているとは限らないような場合に特に重要になります。「ads.cert」として参照されるこの機能は単独で使用することも可能ですが、IAB ads.txt 仕様と組み合わせるのが最も効果的です。（iabtechlab.com/ads-txt を参考のこと）

併せて使用することで、取引所は「私は domain.dom の配信者の在庫を売ることを許可されていて、この在庫枠は本当に domain.com のものです」という保証とともに、入札リクエストを各買い手に送信することが出来ます。

デジタル署名は、配信者もしくはそれに信頼された代理人のいずれかによって、生成されなければなりません。以降、署名者は単に配信者と記すものとします。在庫認証を行うには、事前に配信者が公開鍵と秘密鍵のペアを生成しておく必要があります。秘密鍵は署名を行うために配信者によって使用されますが、秘匿にしておかなければなりません。公開鍵は ads.text 標準の指定にしたがって、アクセスを公開した同一 Web ディレクトリ上に配置する必要があります。

正当なユースケースとして仲介者によってリクエストの一部が書き換えられること（例：在庫に対する追加データ、プライバシーポリシーに基づいた IP アドレスや地理情報のボヤかし）があるので、入札リクエスト全体を署名することは出来ません。代わりに、どの仲介者によっても変更されることのないはずの在庫認証にとって重要な属性（例：配信者のサイトドメインやアプリのバンドル情報）が選択されます。そしてこれらの属性は、シンプルながら非常に特殊な方法で「ダイジェスト」と呼ばれる文字列へ変換されます。

さらに、ダイジェストはリプレイ攻撃を避けるために、これとこのトランザクションのみをデジタル署名に関連づけるための要素を含んでいなければなりません。したがって、ダイジェストはトランザクション ID （Source.tid 属性）と／もしくは少なくとも、リクエストの開始時間（Source.ts 属性）を含まなければなりません。

いずれのインプレッションリクエストにおいても配信者はダイジェストを作成し、秘密鍵と併せて使用することでデジタル署名文字列を生成します。この署名は取引所、より一般的には Source.ds 属性の存在する最初のサプライチェーンにおいて、使用可能となります。Source オブジェクトはさらに、ads.txt ディレクトリ上に置かれている配信者の公開鍵名（Source.cert 属性）と、署名済み文字列を生成するために使用したダイジェスト構造のマップ（Source.dsmap 属性）を含んでいなければなりません。

この情報を使用することで、リクエストの認証を望んでいる買い手もしくは下流の仲介者は、ダイジェストマップの規定に基づいて入札リクエスト上のフィールドからダイジェストを再生成し、その公開鍵を使ってデジタル署名を検証することが出来ます。

この属性を持つ入札リクエストを受信した仲介者は、下流の全入札リクエストにおいて不変なこの署名を、構成する全ての重要な属性とともに含めることを義務付けられています。これが出来なかった場合、在庫枠が認証できず買い手の拒否対象となるでしょう。

これらの概念を実践するためには、配信者もしくはそれが信頼する代理人が、どのように公開鍵・秘密鍵のペアを生成するか、トランザクションをダイジェスト文字列に署名するか、ダイジェストと関連する情報を直接の取引パートナーに伝えるかを知っていなければなりません。リクエストの認証を希望する配信者とそのベンダーの両方が、入札リクエストの属性からダイジェスト文字列を生成する正確な方法と、どのように与えられた公開鍵から署名を検証するかを知っていなければなりません。

詳細については、ads.cert ベータ仕様 を参照してください。

以降のリストでは、ペイロードオブジェクト内の各属性が参照する列挙子を定義します。

次の表では、商品への入札を行わなかった理由を、入札者が取引所へ知らせるために使用する選択肢を挙げます。

次の表では、商品を勝ち取ることが出来なかった理由を、取引所が入札者へ知らせるために使用する選択肢を挙げます。

JSON を使って表現されたリクエスト・レスポンスペイロードのレイヤ３の例は、次の通りです。

販売提供された単一商品とそれに関連する単一非公開市場取引を含んだ、入札リクエストのレイヤ３の例です。簡潔にするために、一部の任意指定の属性は省略されています。spec と content は AdCOM 指定のドメインオブジェクトへのインタフェイスとなっています。spec オブジェクトは、この商品において提供されているインプレッションの詳細を運ぶ placement オブジェクトを一つ持つべきです。context オブジェクトは、device、user、regs、restrictions のいずれか複数と、site（例で示されている）、app、dooh のいずれかを多くとも一つ持つことができます。

{
   "openrtb": {
      "ver": "3.0",
      "domainspec": "adcom",
      "domainver": "1.0",
      "request": {
         "id": "0123456789ABCDEF",
         "tmax": 150,
         "at": 2,
         "cur": [ "USD", "EUR" ],
         "source": {
            "tid": "FEDCBA9876543210",
            "ts": 1541796182157,
            "ds": "AE23865DF890100BECCD76579DD4769DBBA9812CEE8ED90BF",
            "dsmap": "...",
            "cert": "ads-cert.1.txt",
            "pchain": "..."
         },
         "package": 0,
         "item": [
            {
               "id": "1",
               "qty": 1,
               "private": 0,
               "deal": [
                  {
                     "id": "1234",
                     "flr": 1.50
                  }
               ],
               "spec": {
                  "placement": {   }
               }
            }
         ],
         "context": {
            "site": {  AdCOM 仕様を参考のこと。 },
            "user": {  AdCOM 仕様を参考のこと。 },
            "device": {  AdCOM 仕様を参考のこと。 },
            "regs": {  AdCOM 仕様を参考のこと。 },
            "restrictions": {  AdCOM 仕様を参考のこと。 }
         }
      }
   }
}

入札レスポンスのレイヤ３の例です。response.id が request.id と一致していることで、先述の入札リクエストの例を参照しており、bit の下にある bid.item 属性はリクエストの item.id を参照しており、bid.deal が含む取引の参照は、リクエスト内で提供される取引 deal.id を指しています。なお、media は AdCOM で指定されたドメインオブジェクトへのインタフェイスです。「media」オブジェクトは、入札が勝利した場合に配信される広告の詳細を保持する ad オブジェクトを一つ持つべきです。

この例では説明のために、動的な値を与えるマクロを含んだ事前アップロード済みメディアを参照する mid パラメータと、domain オブジェクトによる参照の両方を示しています。実際に、メディアは値（詳細をドメインオブジェクトに含んで）もしくは参照（メディア ID と任意指定のマクロを用いて）のいずれかの方法で受け渡されます。

{
   "openrtb": {
      "ver": "3.0",
      "domainspec": "adcom",
      "domainver": "1.0",
      "response": {
         "id": "0123456789ABCDEF",
         "bidid": "0011223344AABBCC",
         "seatbid": [
            {
               "seat": "XYZ",
               "bid": [
                  {
                     "id": "yaddayadda",
                     "item": "1",
                     "deal": "1234",
                     "price": 1.50,
                     "tactic": "...",
                     "purl": "...",
                     "burl": "...",
                     "lurl": "...",
                     "mid": "...",
                     "macro": [
                        {
                           "key": "TIMESTAMP",
                           "value": "1127987134"
                        },
                        {
                           "key": "CLICKTOKEN",
                           "value": "A7D800F2716DB"
                        }
                     ],
                     "media": {
                        "ad": {  AdCOM 仕様を参考のこと。  }
                     }
                  }
               ]
            }
         ]
      }
   }
}

インタラクティブ広告局テクノロジーラボ（IAB テックラボ）
www.iabtechlab.com

クリエティブコモンズ・帰属ライセンス
creativecommons.org/licenses/by/3.0

GitHub の AdCOM プロジェクト
https://github.com/InteractiveAdvertisingBureau/AdCOM

OpenRTB v3.0 仕様
https://github.com/InteractiveAdvertisingBureau/openrtb

ads.cert 仕様
ads.cert ベータ仕様

ads.text 仕様
iabtechlab.com/ads-txt

JavaScript オブジェクト記法（JSON）
www.json.org/

Apache Avro
Avro.apache.org

Protocol Buffers (Protobuf)
github.com/google/protobuf

この付録では、現行から過去のバージョンにおける仕様変更の索引を提供します。仕様の実質的な変更を対象としていて、定常的な文書整形、情報構成や技術的なインパクトのない内容に関する変更は含みません。

OpenRTB v3.0 は大幅な改訂のため、変更履歴は省略されます。