デジタル広告枠の買い手と売り手の双方は、長年にわたり、パブリッシャーが自社の直販チームで売れ残ったインプレッションを埋めるために依存してきた「ウォーターフォール方式」に不満を抱いてきました。近年、ヘッダービディングがこのエコシステムに導入され、以来、主流となっています。現在、Alexa 2000にランクインするサイトの約20％がヘッダービディングを導入しています。
GumGumがヘッダービディングを採用したのは、これが当社のパブリッシャーパートナーに多大なメリットをもたらすだけでなく、ウォーターフォール方式では獲得が困難なインプレッションについても、クライアントに代わって競り合うことができるためです。
ヘッダービディングという言葉をよく耳にするものの、その詳細がまだよく分からないという方は、ぜひこの記事をお読みください！このブログ記事では、この極めて重要な動向について、基礎から解説します。
ヘッダービディングとは何ですか？
ヘッダービディングを最も簡単に説明すると、パブリッシャーが訪問者のブラウザ上で「スーパーオークション」を実施する方法です。これにより、パブリッシャーのすべてのデマンドソース（RTBバイヤー、アドネットワーク、ダイレクトキャンペーンなど）が、利用可能なインプレッションを同時に競り合うことが可能になります。パブリッシャーのヘッダービディング・ラッパーに準拠しているデマンドパートナー（例：GumGum）であれば、どのパートナーもインプレッションの獲得を競うことができます。
それは滝とどう違うのでしょうか。そして、もっと重要なのは、なぜ滝よりも優れているのでしょうか？
ウォーターフォール方式では、すべての意思決定はパブリッシャーの広告サーバー内で行われます。インプレッションが利用可能になると、広告サーバーは通常、そのインプレッションがダイレクトキャンペーンで必要かどうかを確認します。必要でない場合、別のバイヤーを探しますが、そのためのツールはかなり大雑把なものです。 一般的に、アドサーバーはリアルタイム入札（RTB）バイヤーに入札を依頼し、その入札額をウォーターフォール内の最上位広告ネットワークのコストと比較します。RTBの入札額の方が高ければ、そのバイヤーがインプレッションを獲得します。広告ネットワークの価格の方が高ければ、そのインプレッションは広告ネットワークに割り当てられます。この時点で、広告ネットワークのデフォルト設定やウォーターフォール処理にまつわる悪夢が始まるのです。
広告ネットワークは、インプレッションを拒否して広告サーバーに返送（いわゆる「デフォルト」）することを自由に選択できます。その場合、広告サーバーは別のバイヤー、つまりウォーターフォール内の次の広告ネットワークを探す必要があります。もしそのネットワークもデフォルトとなった場合、広告サーバーはさらに次のネットワークにインプレッションを送り、というように繰り返されます。 その結果、ユーザーがページの読み込みを待ちきれずにページを閉じてしまうと、大きな遅延と収益の損失が生じます。さらに悪いことに、ある広告ネットワークから次のネットワークへと移行するたびに、不一致により最大10％のインプレッションが失われます。これは莫大な収益の損失となります。
一般的に言えば（もちろん例外もありますが！）、技術的な理由から、広告サーバーがアドネットワークのウォーターフォールから一度外れてしまうと、通常はその位置にとどまることになります。つまり、ネットワークがデフォルト状態になった後は、RTBに戻って再度広告枠を提供することはできないのです。
そして、収益の損失がさらに拡大してしまう理由はここにあります。広告サーバーには知らされていないものの、RTBの初期入札額が、最初の広告ネットワークが実際に支払う意思のある金額よりも高い可能性が十分にあるからです。ご存知のように、広告サーバーは、トラフィックを配信するために、パブリッシャーに対して各広告ネットワークごとに固定のCPMを入力するよう求めることがよくあります。そのコストは仮の値であり、通常はそのネットワークが支払う平均CPMを表しています。 しかし実際には、広告ネットワークは、その時点で進行中のキャンペーンに応じて、インプレッションごとに異なる単価を支払っています。例えば、ネットワークAが支払う平均CPMが5.00ドルで、その金額が広告サーバーに入力されているとします。ここで、あるインプレッションが利用可能になり、広告サーバーが5.25ドルのRTB入札を受け取ったとします。 広告サーバーは、その入札額がネットワークAが支払う意思のある金額より0.25ドル高いと判断し、そのインプレッションをRTBバイヤーに割り当てます。しかし、もしネットワークAが、高級自動車メーカーのリターゲティングキャンペーン向けにインベントリを取得しており、15ドルのCPMを支払う意思がある場合はどうでしょうか？これは決してあり得ないシナリオではなく、実際、かなり一般的なケースです。
月間数十億インプレッションに及ぶことを考えれば、ウォーターフォール方式がパブリッシャーに多額のコストを強いていることは容易に想像がつきます。一方、ヘッダービディングは、パブリッシャーが各バイヤーが支払う意思のある価格を同時に評価し、最も高い価格を提示したバイヤーに広告枠を割り当てることができるため、パブリッシャーの収益化活動を大幅に効率化します。
また、ページの読み込み遅延や表示のばらつきも大幅に軽減されるため、ページから離れてしまうユーザーが少なくなり、収益化の機会を完全に逃すこともなくなります。
ヘッダービディングがパブリッシャーにとってメリットがあることは理解できますが、バイヤーにとってはコストがかさむことになるのに、どのようなメリットがあるのでしょうか？
ヘッダービディングは、ウォーターフォール方式では通常入札対象外となるインプレッションを競り落とせるという点で、バイヤーに極めて重要なメリットをもたらします。例えば、GumGumは、ウォーターフォール方式ではダイレクトキャンペーン用に確保される可能性が高いスーパープレミアムのインプレッションを競り落とすことができます。また、たとえそれらのインプレッションがサードパーティのデマンドソースにも公開されていたとしても、前述の理由により、たとえより高い金額を支払う意思があったとしても、入札に参加できない場合があります。
ヘッダービディングにはデメリットはあるのでしょうか？
広告が表示される際には常にレイテンシの問題が生じますが、ヘッダービディングも例外ではありません。オークションの開催、買い手の選定、広告の配信には時間がかかります。とはいえ、ヘッダービディングによって生じるレイテンシは、ウォーターフォール方式によるものに比べればごくわずかなものです。
比較として、いくつかの研究によると、ヘッダービディングによる取引の78％は200ミリ秒未満で完了しているのに対し、ウォーターフォール方式の取引ではわずか12％にとどまっています。その理由は、すべての参加者が同時に入札を行っているからです。
パブリッシャーがラッパーさえ持っていれば、ヘッダービディングが可能だとおっしゃいましたが、それとはどういうものですか？
ラッパーとは、パブリッシャーのヘッダービディングにおけるすべてのデマンドパートナーのタグを格納するコードのことです。このラッパーにより、パブリッシャーは継続的にパートナーを追加することが容易になります。 また、ラッパーには重要な技術的および運用上の機能も含まれています。AdOpsInsiderが説明しているように、「ラッパーの典型的かつ期待される機能には、すべてのパートナーの入札リクエストが同時にトリガーされるようにする非同期コンテナ、ブラウザが入札者の応答を待つ時間を管理するためのユニバーサルタイムアウト設定、およびラッパーがすべての入札を広告サーバー向けの共通キー値に変換できるようにするパートナー固有の『アダプター』などが含まれます。」3
購入者は、オークションに参加するためには、発行者が実装したラッパーに準拠している必要があります。
ヘッダービディングのラッパーは誰が作成するのでしょうか？
以前はパブリッシャーが独自のラッパーを作成していましたが、現在ではAppNexusやOpenXといったテクノロジー企業によって開発された、ヘッダービディング用ラッパーのオープンソースシステムが数多く存在します。ラッパーの継続的な管理はパブリッシャーにとって負担となっていたため、テクノロジー企業が参入し、そのプロセスを効率化するラッパーを開発したのです。4 AppNexusは次のように説明しています。 「ラッパーとは、パブリッシャーのすべてのヘッダービディング・デマンドパートナーのタグを格納する単一のコードであり、これによりパブリッシャーはニーズに応じてパートナーを簡単に追加し、統合を継続的に管理できるようになります。」5
GumGumはどのヘッダービディングを採用していますか？
GumGumは、AppNexusが開発・育成した無料のヘッダービディングラッパーであるprebid.jsに準拠したプレビッドラッパーを構築しました。これにより、prebid.jsを使用しているあらゆるパブリッシャーに対して、デマンドを配信すること、すなわちスーパーオークションで競合することが可能になります。 prebid.jsに関する詳細はこちらをご覧ください。ヘッダービディングはどのような種類のインベントリに対応していますか？ ヘッダービディングは、ウェブページ上に存在するあらゆるインベントリの競合に使用できますが、現時点では主にディスプレイ広告ユニットに使用されています。しかし、パブリッシャーがヘッダービディングに慣れてくるにつれて、状況は変化しつつあります。2018年には、デジタル動画やアプリ内広告ユニットでもヘッダービディングが導入されると予測する声もあります。6
-------------------------------------------------
1https://dev.serverbid.com/v1.0/docs/hbix-sept-2017
3http://www.adopsinsider.com/header-bidding/guide-header-bidding-wrappers/
4https://blog.appnexus.com/2017/real-time-real-talk-prebid-js/
5https://blog.appnexus.com/2017/real-time-real-talk-prebid-js/
6https://performancein.com/news/2017/10/17/header-bidding-next-evolution/
