アプリ収益化の世界にしばらくいれば、「open bidding」と「header bidding」という言葉がほぼ同じ意味で使われているのを聞いたことがあるはずです。両者は同じ目標を共有しています — デマンドソース間のリアルタイム競争を生み出してeCPMを引き上げること — しかし内部の仕組みは異なります。これらの違いを理解することが、アプリに適したアプローチを選ぶ鍵となります。
Header biddingとは
Header biddingはウェブ広告から始まりました。パブリッシャーはページの「ヘッダー」にJavaScriptコードを追加し、メインのad serverへの広告呼び出し前に複数のデマンドパートナーから同時に入札をリクエストしていました。最高入札が勝ち、真の競争が生まれ、デマンドソースを一つずつ呼び出す順次waterfallの問題を解消しました。
モバイルアプリの文脈では、header biddingはクライアントサイドSDKを通じて機能します。参加する各デマンドパートナーはアプリにSDKが統合されています。広告機会が発生すると、すべてのSDKが同時に呼び出され、各々が入札を返し、最高入札が勝ちます。AppLovin MAXとUnity LevelPlayは、in-app bidding機能を通じてこのモデルをサポートしています。
Open biddingとは
Open bidding（旧Exchange Bidding）はGoogleのサーバーサイドの代替手段です。複数のSDKを通じてユーザーのデバイス上でオークションを実行する代わりに、open biddingはGoogleのサーバー上でオークションを実行します。デマンドパートナーはGoogleのインフラに接続し、server-to-serverで入札を送信するため、クライアント側での個別SDK統合が不要になります。
Open biddingはGoogle Ad Managerを通じて利用でき、Googleの広範なデマンドエコシステムに加え、プログラムに参加しているサードパーティのexchangeへのアクセスを提供します。
主な違い
レイテンシ
これが最も重要な実用上の違いです。クライアントサイドのheader biddingでは、各SDKがネットワーク呼び出しを行い、オークションを処理し、入札を返す必要があります — すべてユーザーのデバイス上で。SDKが多いほど処理時間が長くなります。Open biddingはserver-to-serverで動作し、通常より高速で、デバイスリソースを消費しません。広告のロード速度がユーザー体験に直接影響するアプリにとって、これは重要です。
SDKの複雑さ
各header biddingパートナーはアプリへのSDK統合を必要とします。SDKが多いほどアプリのバイナリが大きくなり、SDK間の競合の可能性が増え、SDKの更新が必要になった際のメンテナンスコストも増加します。Open biddingはGoogle Mobile Ads SDKのみを必要とし、デマンドパートナーはサーバー側で接続します。これにより技術的複雑さが大幅に減少します。
デマンドの多様性
AppLovin MAXのようなプラットフォームを通じたheader biddingは、それぞれ独自の広告主関係とデマンドを持つ幅広い広告ネットワークへのアクセスを提供します。Open biddingはGoogleのデマンドと参加するexchangeへのアクセスを提供しますが、参加パートナーのプールはクライアントサイドの入札で利用できるものよりも小さくなります。最適なアプローチには、多くの場合両方が含まれます。
透明性
クライアントサイドのheader biddingでは、各パートナーの入札をリアルタイムで完全に可視化できます。どのネットワークがいくら入札したか、誰が勝ったか、その理由を正確に見ることができます。Open biddingはGAMを通じてレポートを提供しますが、オークションはGoogleのサーバーで行われるため、入札プロセスへのリアルタイムの可視性はやや粒度が粗くなります。
どちらを選ぶべきか？
正直な答え：成功しているほとんどのパブリッシャーは両方を使用します。実用的なフレームワークは次のとおりです：
GAMを通じたopen biddingをメインのオークションメカニズムとして使用します。最小限のSDKオーバーヘッドと高速な広告ロードで強力なデマンドを提供します。次に、メディエーションプラットフォーム（AppLovin MAXまたはUnity LevelPlay）を通じて、2〜3のトップパフォーマンスネットワークからのクライアントサイド入札で補完し、最大のデマンド多様性を確保します。
最高の広告収益を生み出しているパブリッシャーは、open biddingとheader biddingの間で選択しているのではなく、技術的複雑さを管理可能に保ちながら競争を最大化するハイブリッドアプローチで両方を組み合わせています。
実践におけるハイブリッドアプローチ
典型的なハイブリッド設定では、waterfallは次のようになります：GAMを通じたopen biddingが2〜3のin-app biddingネットワークと並んで競合します。その下には、リアルタイム入札をサポートしないネットワーク用の従来のwaterfallエントリがあります。マネージドデマンドパートナーはこのスタックの任意のレベルに配置でき、使用されているオークションメカニズムに関係なく、全体的なイールドに利益をもたらす追加の競争を提供します。
鍵は過度に複雑にしないことです。GAMを通じたopen biddingから始め、メディエーションプラットフォームのトップ入札パートナーを追加し、マネージドパートナーと協力してギャップを埋めます。その後、データが示すものに基づいて最適化します。