RTB（リアルタイムビディング）はプログラマティック広告の基盤となるオークションプロトコルです。各広告インプレッションは50〜150ミリ秒でオークションされます — SSPが入札リクエストを発火し、複数のDSPが評価して入札で応答し、オークションが解決し、落札クリエイティブがレンダリングされます。OpenRTB仕様（IAB Tech Lab管理）はプロトコルを定義します：入札リクエストの形式、含まれるフィールド、入札が返さなければならないもの。
50〜150ミリ秒のオークションタイムライン
- 0ms — ユーザーがパブリッシャーのアプリ/ページを開く。アプリ/ページがSDKに広告リクエストを送信。
- 5〜20ms — SSPがリクエストを受け取り、オーディエンスデータでエンリッチし、アドエクスチェンジにブロードキャスト。
- 20〜100ms — アドエクスチェンジが接続されたDSPに入札リクエストをブロードキャスト。各DSPは広告主のターゲティングルールに照らしてリクエストを評価し、入札価格を算出して応答。
- 100〜130ms — エクスチェンジが入札を集め、オークションを実施し、落札者を選出。
- 130〜150ms — 落札クリエイティブURLが返され、広告がレンダリングされる。
約150ミリ秒以上のレイテンシは広告スロットの放棄を引き起こします（インプレッションがタイムアウトしてフォールバックをレンダリングします）。応答が遅い入札者はペナルティを受けます — エクスチェンジは遅いDSPをオークションから除外します。
オークションの種類
- ファーストプライスオークション：落札者が自分の入札額を支払う。2026年の業界標準 — Google AdXとほとんどの主要SSPが2017〜2019年の間にセカンドプライスからファーストプライスに移行。広告主にとって戦略的な入札が必要（入札したものを支払う、落札に必要な金額ではない）。
- セカンドプライスオークション：落札者が次点入札額に1セント上乗せした額を支払う。クラシックなeBay型メカニズムで、2010年代後半のシフトまでプログラマティックで広く使用されていた。理論的には正直な入札を促す（最大額で入札しても過払いなし）；実際には、不透明なメカニクス＋ヘッダービディングで不安定になることが判明。
モバイルアプリでのRTB
- SDKベース：アプリに組み込まれたSDK（通常パブリッシャーのメディエーションSDK — AppLovin MAX、ironSource LevelPlay、Google Admob）が入札リクエストをローカルで処理。SDKがリクエストを発火し、入札を受け取り、落札クリエイティブをレンダリング。
- サーバー間（s2s）：パブリッシャーのバックエンドが入札リクエストを処理し、サーバーからエクスチェンジを呼び出す。パブリッシャーが入札ロジックをより細かく制御したいヘッダービディング型オークションで使用。
モバイルの入札リクエストペイロードにはアプリID、広告フォーマット、ユーザーシグナル（利用可能な場合）、デバイスシグナル、ジオロケーション（許可がある場合）、コンテンツコンテキストが含まれます。iOS のポストATT後はユーザーレベルのシグナルが大幅に制限されており — AndroidやプリATT iOSと比べて入札リクエストのリッチさが大幅に低下しています。
RTBのよくある落とし穴
- 入札タイムアウト：応答が遅いDSPはオークションから除外される。応答時間を100ms未満に維持すること。
- 古いオーディエンスデータ：5分前は新鮮だったが今は古いオーディエンスシグナルで入札する。リアルタイムのオーディエンス更新が重要。
- オークション談合：複数の入札者がデータソースを共有すると、入札が怪しく相関することがある。成熟したDSPには談合防止分析がある。
- ビッドシェーディング：ファーストプライスオークションでは、高度なDSPが過去のクリア価格に基づいて入札を下方調整します — 最大額ではなく落札予想額で入札します。素朴な入札は過払いになります。