海外の媒体社の間で普及が進んでおり、日本においても注目を集めている「Header Bidding（ヘッダービディング）」。
今回は噂の「ヘッダービディング」の実態に迫るべく、広告マネタイズの最新事情にマニア的に詳しく、それらをいち早く取り入れる実行力を兼ね揃えることから一部で「アド異常者」（※褒めてます）と呼ばれているパンチの効いたメンバーの方々にお集まりいただき、「ヘッダービディング」について実際どうなのか、赤裸々にぶっちゃけていただいた対談会の様子をレポートいたします。

8/27追記：ヘッダービディングレポート、アプリ編②も公開しましたこちら

（イベント取材日2018年5月24日）

＜スピーカー＞

カカクコム株式会社
マーケティング本部 ビジネスマーケティング部
平田　慎乃輔　様

株式会社ソシオコーポレーション
メディア事業部 Manager
瓦野　晋治　様

株式会社オールアバウト
メディアビジネス本部 ガイドプロデュース部
企画グループ
中村　友弥　様

＜モデレーター＞

Supership株式会社
サプライ事業部　事業部長
ジ・アドジェネ
池田　寛

以下、敬称略で記載させていただきます

池田　ヘッダービディング導入前はどのようにディスプレイ枠をマネタイズしてました？

平田　従来のウォーターフォール方式で運用していました。DoubleClick for Publishers（以降：DFP）のなかでDoubleClick Ad Exchange（以降：AdX）を流して仮想単価、フロアプライスを切って、入札がなければパスバックでフィラーネットワークに流す、という運用です。

※DoubleClick Ad Exchange（AdX）と DoubleClick for Publishers（DFP）は、「Google アド マネージャー」という1つのブランドに統合されました。（編集部追記）

瓦野　うちもほぼ同じ運用でした。パスバックを重ねるとインプレッションが消失する可能性が高まるので、多段階にするのは最後は避けていました。具体的には、DFPでAdXとSSPを競わせて勝ったSSPに、もしフロアプライス以上で配信するものがなかった場合にはDFPにパスバックして、再度AdXと他のSSPやアドネットワークで競わせて、それ以上はパスバックしない、という構造にしていました。

池田　お約束の構成ですね。

中村　うちもほぼ同じ運用です。広告枠によってはオークションの優先度が通常の構造と異なるなど、そもそもどのような配信設定になっているかを把握して、もったいない設定があればそれを見直すことで売上の改善もできました。

池田　なぜヘッダービディングを入れようと思ったんですか？

中村　All Aboutのサイトには既に広告枠の数が多く設置されているので、これ以上読者の記事体験を損なわずに売上を伸ばしたい。そのためには枠を増やすのでなく枠単価をあげたくて、そのソリューションを模索していたところ、ヘッダービディングに至ったと言う経緯があります。

瓦野　私はめんどくさかったんですよ、色々（笑）。一番めんどくさかったのが、AdXのフロアプライス調整ですね。これをちゃんとマメに調整して最適化すれば収益が上がるのはわかってはいるんですが、正直それをやるのがめんどくさくて仕方がない。そこでヘッダービディングという便利なソリューションに飛びついたという感じですね。

池田　いまの伝わりました？ちょっと補足すると、「めんどくさい」っていうのは、AdXにはフロアプライスが２つあって、ブランドと匿名っていうのがあるんです。CPMを極限まで最適化しようとなると、これを毎日こねくり回さなくてはいけないわけです。それがめんどくさかったという話ですね。さて、これを一番こねくり回してた平田さんはどうでしたか？

平田　我々も、当時はAdXのタグだけで百何十本あって、そのフロアプライスを週３で変更したりしていましたが辛すぎましたね。。。ただ、これによってオークションプレッシャーがかかって単価が上がるという仕様については理解していました。そんななかで、ヘッダービディングは、AdXに対して自動でオークションプレッシャーをかけるシステムだと耳にしまして、これはやらないわけにはいかないっていうのではじめました。

池田　なぜヘッダービディングでオークションプレッシャーをかけると単価が上がるのか？ってところを少し解説すると、今までは各SSP（Ad Exchange）の広告配信はウォーターフォール形式での配信が通常なので、いくら高い単価で買付けることができても、自分に順番が回ってこないと配信することができなかったんですよね。けど、ヘッダービディングでの配信だと、その順番を待たずに一斉に競争できるようになるんです。
まず各Ad Exchangeの中で競争して、一番単価の高い広告を決定する。さらにそのAd Exchangeの一番高い単価同士でも競争して一番を決める。そして、AdXの広告とも価格競争する。とてつもない競争にさらされるので当然単価も上がる。
各Ad Exchangeの競争を無理矢理サッカーのリーグに例えると、リーガ・エスパニョーラ、セリエA、プレミアリーグ、このそれぞれの優勝者達がチャンピオンズリーグで戦って優勝したものが広告として表示されるイメージなんですよね。つまり、ドラゴンボールで言うと「天下一武道会」です（わかる人にはわかる）。

もちろん、バイサイドのDSP事業者は今までのウォーターフォール方式だと、本当は高い値段で入札してたのに構造的に買うことができなかった。そんな機会損失もなくなる。

運用も楽になるし、収益はあがるし、みんながハッピーになれるのがヘッダービディングなんじゃないでしょうか？

さあ３つ目の質問に移ります。ヘッダービディング実装にあたって難しかったことなどはありましたか？

中村 オープンソースのPrebid.jsと、AmazonのServer-to-server (S2S)ヘッダービディングのTAM（Transparent Ad Marketplace）を一緒に実装しましたが、Prebid.jsとTAMの共存問題に苦しみました。。。

TAMの実装前はDFP内でオークションが完結してましたが、TAMを実装後は、これまで最初に呼んでいたDFPを止めてTAM内のオークションを走らせ、その後DFPを再稼働させて、勝者となった広告を表示する、という構造になりました。

そこでさらにPrebid.jsを導入して、きちんとオークションを成立させるには各広告枠につき、「DFP再稼働してください」と指示をするrefresh関数の設定をひとつにしないといけないんです。

この設定を間違えると、インプレッションがrefresh関数の数だけ倍カウントされてしまって、それが枠単価にも影響してしまったり、色々苦労しました。ということで、実装の中身をエンジニアとしっかり認識をあわせておくことで、こうした失敗は回避できるので注意しなければならないと反省しました。

▲中村さまご提供資料より抜粋

池田　AmazonのTAMはS2S方式のヘッダービディングラッパーで、PubmaticさんにしろRubiconさんにしろ、オープンソースであるPrebid.js方式がほとんどなんですよ。ヘッダービディングは、ラッパーによって配信できない事業者もいるので、媒体社さんは基本複数のヘッダービディングラッパーを併用するわけです。ただ、ラッパー提供事業者側は複数のラッパーを併用する前提ではなく、自社だけを導入する前提でマニュアルを作っていたりするので、事業者の実装マニュアルにしたがって普通に入れたら事故っちゃった、って話ですよね。

瓦野　競馬でいうところのスタートゲートにTAMなりPrebid.jsなりいろんなヘッダービディングをとにかくみんな並べて、「はいスタート！」ってして、各ヘッダービディングから返ってきた情報をDFPに渡した後、DFPに「広告を表示してね」っていうリクエストを１回だけ投げなきゃいけないんです。が、各ヘッダービディングがそれぞれ１回ずつ表示リクエスト投げようとするので、実際には１人しか見てないのに、例えばヘッダービディングを４つ導入した場合には４回広告表示しようとしてしまう。そうすると、ビューアブルインプレッション率も下がってしまうことで枠の評価が下がってしまったり、色々な問題が起きる。なので、素直に実装しちゃ危ないですよ、ってことです。

池田　事業者側は並列で使う前提でプロダクトをつくっているわけじゃないから問題が起きるわけですね。ここはパブリッシャーさんは気を付けないとマズいですね。
では次の質問にいきます。ヘッダービディング導入後、どのような結果が得られましたか？

平田　２つあります。１つはAdXへのオークションプレッシャーをかけられたことで収益が20%あがったこと。AdXだけで5〜10％くらいは上がりましたし、AdXよりも高い単価で入札してくれる業者もいたのでそれも後押しして、20％UPという結果になっています。
もう１つは運用の手間が省けたこと。月末月初の月の切り替わりの時期など、市場の動きにあわせてこれまではDFP側のフロアプライスの調整をしないと大きな損失になってしまってたのがヘッダービディングならオークションプレッシャーが自動的にかかるので週に3回くらい必要だったフロアプライス調整が今では週に1回くらいになりました。

池田　AdXをごりごりにいじり倒している彼に、ちょっとだけ運用テクニックを教えてもらいましょう。

平田　これまでやっていた通常のウォーターフォール方式の場合、例えばAdX側のブランドのフロアプライスと、DFPのダイナミックアロケーションのフロアプライス（つまり匿名のフロアプライスと考えてください）の２つを設定して、AdXの下にSSP「A」、その下にSSP「B」、さらに下にアドネットワーク、といった構造で設計していました。これだと、チューニングしないといけないフロアプライスの要素が４つもあって、これを何百という広告枠数でこなすのは結構きついというのが正直なところでした。
ヘッダービディングを取り入れてからは、全RTBの最低入札価格を一度決めて、あとはAdXのブランドのフロアプライスだけ設定すればこの２要素だけでチューニングが完了します。いままでやっていた４要素にくらべて、チューニングする箇所も頻度もだいぶ減ったのでよかったですね。

▲平田さまご提供資料より抜粋

池田　そんなに楽になると平田さんのマニアックな技が出しづらくなるのが心配です。つづいて瓦野さんいかがですか？

▲瓦野さまご提供資料より抜粋（※具体的な数値などは伏せております）

瓦野　こちらは運用型広告のRPM（1,000PVあたりの収益）、直近３年ほどの推移です。ヘッダービディングの導入を開始したのは2016年11月からで、AmazonのTAMでない前のタイプのものを使っていました。そこから、2017年9月にTAMに切り替えて、いかにAdXにオークションプレッシャーをかけられるか色々と試行錯誤していった結果、導入前と比較して収益性は２倍くらいになっています。PVは基本的には変わってないです。

池田　へーすごいね。PVはほぼフラットで、収益だけは２倍？

瓦野　そうです。もちろんプログラマティック広告市場が業界的に盛り上がっているので、ヘッダービディングだけの効果とは言い切れませんが、収益額が上がったのと、運用も楽になったのでよかったなと思いますね。

中村　All Aboutでもヘッダービディングの導入で実際に数字が上がった事例があり、例えばこれはPCのページ右下にあるBTF枠（Below the Fold：スクロールしなければ見えない位置にある枠のこと）のRPMの推移をグラフにしたものですが、AdX単体の運用からTAMを導入してみたところ、導入前と比べてRPMが53%上がっていました。

▲中村さまご提供資料より抜粋

池田　本当に53％も上がるの？Amazonさんにお金もらったりしてないよね？（笑）

中村　してないです！（笑）導入するならサイバーマンデーとかプライムデーとかAmazonのセール前を狙うと売上がその時期に上がっている印象です。あと、もう１つ変わったこととして、SSPの担当さんとポジティブなお話ができるようになったのはうれしいですね。アドジェネさんとは今回TAMの導入にあたって最初から結構ポジティブなお話をさせてもらっていましたが、それまではSSPさんと話すとどうしてもウォーターフォール構造なので十分なトラフィックを送れていなかったのが、ヘッダービディングの導入によって、収益を上げるためのお話ができる機会が増えたのは個人的にもうれしかったです。

池田　全体的に３ついいことがありましたということですね。
１個は儲かりました。もう１個は運用が楽になった。もう１個はSSPさんとの会話が弾んだ、と（笑）。
ちなみに今はディスプレイ枠でTAMのヘッダービディング経由でアドジェネもビッダーとして配信させてもらっていますが（プレスリリース参照）、今後はオーバーレイの枠でアドジェネをアドサーバーにしてAmazonのTAMでヘッダービディングが実装可能になる予定です。もちろん、下部にピッタリ固定した320×50サイズの真面目なやつです。オーバーレイ広告自体はユーザビリティ的には微妙なので、背に腹は変えられない場合はご用命ください（宣伝）。

では次の質問です。クライアントサイドのヘッダービディング、サーバーサイドのヘッダービディングについて、実装時、また得られる結果について感じられている違い等について教えてください。
Prebid.js方式だったり、AmazonのTAMの場合はS2S方式だったり、いろんな事業者がヘッダービディングのラッパーを用意しているなかで、全部のタグを組み込むのは大変ですよね？実際のところはやってみないとわからないので、正直、この構成が最強って結論はまだて出てないと思いますが、いかがでしょう？

中村　All Aboutは、Prebid.jsをこれからあらためて入れるところなので、また検討してお話しできればと思います。

平田　うちはまだS2S方式は試していないので、AmazonのTAMからはじめてみようかなと思っています。
サーバーサイドのほうが最終的にはサイトにいっぱいコードを書かなくていいですし、レイテンシーも少ないので最終的にはサーバーサイドにしたほうがいいとは思います。ただ、実際に検証してみないとわからないですが、サーバーサイドのヘッダービディングではまだCookieのシンク率が低いのでDSPからのBidがクライアントサイドに比べて減ってしまうという話を聞きます。ですので、今は売り上げとの兼ね合いで、両方一緒にやりながら進めていったほうがいいのかなと思っています。

瓦野　同じく、将来的にはサーバーサイドでやったほうが安定はするだろうなとは思うので、今後に期待ですね。

池田　サーバーサイドのヘッダービディングの技術は、これからどんどん進化していくはずだから、楽しみですね。
では最後の質問。将来的なプログラマティックへの取り組みについて、現在のお考えを聞かせてください。

中村　ヘッダービディングに関してはPrebid.jsを入れたいなっていうのはもちろんと、あとAmazonさんのTAMでのCookieシンク率のアップに期待しています。
今後はカテゴリーごとに異なる読者の属性にあわせて広告の内容だけでなく種類も含めてプログラマティック化と、収益最適化を進めていきたいなと思っています。

瓦野　できるだけ運用の手間を省きつつ、収益性を上げる方法を、状況に応じてしっかりと見極めて取り入れていきたいです。広告主側とのコミュニケーションによっても、さらに底上げは図れるかなと思っています。

平田　２つありまして、１つはディスプレイ枠だけでなくネイティブ枠のヘッダービディングにも対応しはじめているという話を聞くので日本でも早くできるようになってくれるとさらに運用が楽になるので期待しています。
もう１点が、アメリカでは去年話題になっていた、サプライパスオプティマイゼーション（サプライパス最適化）にも取り組みたいと思っています。
同じDSPでもSSPとの相性で効果が違ってくるようなので、そこもヘッダービディングを通じてしっかり見極めて収益をさらに最適化していきたいです。結論として、ヘッダービディングは最高だと思います！

池田　やっぱり皆さん気持ち悪いですね。アド異常者の皆さま、ありがとうございまーす！

8/27追記：ヘッダービディングレポート、アプリ編②も公開しましたこちら