ヘッダービティングのリーディングカンパニー FLUX・平田CPOにきく、パブリッシャーのマネタイズの現在と未来

誰もがテクノロジーをカンタンに利用できるようになるSaaSプロダクトを開発提供し、ヘッダービティングの提供会社でリーディングカンパニーの株式会社FLUX CPOの平田 慎乃輔 氏に、ヘッダービティングのこれまでと未来について教えていただきました。

株式会社FLUX CPO 2015年株式会社カカクコム入社。価格.COM、食べログ、WEBCGなどのメディアマネタイズ業務を3年半担当し、ヘッダービディングの導入やPMP販売などを担当。2018年カカクコムを退職し、メディアマネタイズの最先端プロダクトをサポートする企業として株式会社FLUXを創業しCPOに就任。現在はヘッダービディングを中心にメディアマネタイズのサポート、プロダクト開発/販売を行う。


ヘッダービッティングの変遷などについて教えていただけますか?

画像に alt 属性が指定されていません。ファイル名: image-9-1024x506.png

ピアラベンチャーズ中(以下、PV・中):ヘッダービディングって今はかなり普及している印象ですが、FLUX創業時ってそれほどでもなかったですよね?

FLUX・平田:ヘッダービッティングは今でこそ一定規模以上のパブリッシャーはほとんど実装してますが、日本国内だと2016年明けから大手媒体のごく一部が採用し出して、当時はまだ10-20ドメイン程度の普及状況でした。

画像に alt 属性が指定されていません。ファイル名: image-11-1024x530.png
*TAM(Transparent Ad Marketplace) HPより

私自身も起業前のカカクコム時代に他に遅れを取るまいと思い、担当してる中で比較的小規模なドメインでテスト的に導入しましたので、かなり早い段階から関わっていると自負しています。2018年頃になると朝日新聞社に在籍していた弊社の柳田さんがイベントに登壇した際にTAM(*1)のお話をしたりヘッダービディング活用の啓蒙が始まった様な状況です。

PV・中:それでもまだまだ2018年の起業当初は実装媒体少なかったですよね?

FLUX・平田:そうですね、それでもやっと100ドメインあったかどうかという印象です。

画像に alt 属性が指定されていません。ファイル名: image-10-1024x530.png
ヘッダー・ビディングにおけるオープンソースのクライアント側ラッパーソリューション「Prebid」のHPより

PV・中:当時はPrebid.js(*2)が主流でしたか?

FLUX・平田:最初prebid.jsから始まってTAMが出てきてという状況だったので当時はPrebid.jsだけ・TAMだけ・両方やるっていうそれぞれ出てきた様な状況でした。その当時2018年頃だとTAMとPrebid.js両方入れたら不具合が出るということをテーマに他の媒体の担当と一緒に体験談として語るような場面があって、まだまだこれからという感じでしたね。

PV・中:Wrapper(*3)って当時すでにあったんですよね?

FLUX・平田:ありました。でも、当時だとまだかなり出始めだったかと思います。2017年頃にPrebid.jsが出てくる前は、国内ではPubMaticやOpenXやRubiconなど、各社のヘッダービディング用のScriptを入れるという状況で、それがPrebid.jsに置き換わっていった様な流れです。

FLUXを立ち上げたのは2018年の5月で、ヘッダービッティングに振り切ったのが2019年からです。我々のタイミングは非常に良かったなと思っていて、2017年にYahoo!がヘッダービディングに対応したあたりから、大手の実装が一巡してきて、いよいよ今後標準になる流れが出てきたのがその頃でした。

当時FLUXとしてチャンスだと見ていたのは、大手が一巡して各社がヘッダービディングを実装しようというタイミングで、Prebidの実装サポート企業にパブリッシャーが殺到して順番待ちという様な状況でした。このタイミングでFLUXがヘッダービディングを提供することができたので、今でも多くのパブリッシャー様とご一緒させていただいています。2019年にFLUX Header Bidding Solutionをリリースし、現在では最大手パブリッシャーを中心に500ドメイン程度で導入していただいています。

PV・中:ということは、当時FLUXが無かったら日本のヘッダービディングの普及は遅れていた様な状況じゃないですか?

FLUX・平田:以前は、ヘッダービッティングはサプライサイドのアドテク事業者のエンジニアが時間をかけて導入しなければいけなかったですが、そこら辺の部分は上手く仕組化できました。日本でヘッダービッティングを普及させたのは、私たちFLUXだと自負しています。

ヘッダービッティングを導入するのにコストがかかるとのことですが、導入の基準などはありますか?

PV・中:ヘッダービディングって一定ボリューム以上のページビュー/インプレッションが無いと恩恵薄いと思うんですがどのぐらいからやるべきですか?

FLUX・平田:Imp(インプレッション)数がどれくらいならやったほうがいいか、という相談をよくされますが、どの数値でも基本的にはやったほうがいいです。

しかし、エンジニアの工数や運用の手間などを考えると、コストが見合わないところも出てきてしまうので、売上と工数を考えて導入すべきかどうか考えたほうがいいでしょう。例えば月間30万の広告収益がヘッダービディングで35万になる、年間60万が収益寄与になるわけですが、エンジニアの工数がそれを上回ってしまうと本末転倒です。

PV・中:ヘッダービディングって実装は技術的なハードルあると思うんですが、運用面ではどうですか?ウォーターフォールと比較して工数や難易度は上がるんですか?

FLUX・平田:実装は結構テクニカルですが、運用自体は今までのウォーターフォールと比較してパブリッシャーのコストも下がってきています。

PV・中:それはFLUXに運用もお願いしてるから?それともヘッダービディング自体の運用が軽い?

*GAM(Google Ad manager Google)のHPより

FLUX・平田:FLUXのダッシュボードによる部分もありますが、後者の要因が大きいです。ウォーターフォールの順番をGAM(*4)の中で変更する運用は非常に手間がかかっていました。一つ順番を変えるだけでも影響する設定が多く複雑な調整が必要です。ウォーターフォールは手間がかかり、広告ユニットを細かく運用しているケースではレポートを作るだけで1時間かかる様な状況もありました。

しかしヘッダービッティングでは、買いたい人が買いたい単価で入札をしてくるためRTBを回すだけでよくなりました。ヘッダービディングで調整項目を付けるならGoogleの配信,ヘッダービディングとその他ヘッダービディング非対応事業者の間でツマミを設けるという具合ですかね。

FLUXの場合はパブリッシャーに対してヘッダービディングの収益はまとめて見せるということになるので、GoogleとFluxのダッシュボードの数値を見て、ヘッダービディング非対応事業者で入れてる非RTBの広告のCPMを見れはフロアプライスをいくらにすればいいかと言うのは瞬時にわかります。

PV・中:ということは多くのパブリッシャーがGAMとヘッダービディングを並列に置いているケースが多いということですか?

FLUX・平田:そうですね、細かいこと言うとGAMが出してくるCPMとヘッダービディングの入札で競う形でオークションする設計は主流といっていいと思います。

PV・中:ヘッダービディングって導入時のテクニカルなところとかで難しい印象がありますが、やってしまえばあとは楽になるってことですね。各媒体社の特性もあると思うので一概には言えないと思いますが、一般論としてヘッダービディングの導入でどの程度収益あがるものですか?

FLUX・平田:AdSense貼りっぱなしで運用何もやってないとか、買い切りが多いなどを特殊ケースとして除けば、20%以上の収益性向上は自信を持って実現できます。一部の主要SSPのサイト審査落ちがあると15%を切ってしまうこともありますが、そういったことさえ無ければFLUXで手掛けた導入はその水準は超えてきます。

PV・中:ここまでの話だとやらない理由無い様な話だと思うんですが、やったほうがいいのにやらない媒体社ってまだ居るんですか?

FLUX・平田:ちゃんと担当がついていて、理解している人たちの中でやれていない場合はほとんどありません。
やらないパターンだとしっかりアドテクに理解のある担当者がいない場合や、単価を固定で事業者の方々買い切ってしまっているパブリッシャーでは実装しないケースがあるなという印象です。

PV・中:ヘッダービッティングを導入することで対DSPへのリクエストが増えることになると思いますが、こういった影響はどう考えますか?

*SPO(サプライパス最適化)についてPubMatic HPより

FLUX・平田:DSP側の体力が必要だと思われることが多いですが、この辺は2017年くらいには海外で議論が終わっていて、ヘッダービッティングが増えることでDSPに厳しい影響があるなどの話はもう決着しています。SPO(Supply Path Optimization)とかがそれに当たります。SPOもありますが、DSP側でも入札率の低い枠のリクエストを止めるなどの対応を自動化したりといた対応もしているので大きな影響ではないというか、各社対応してるという印象です。

FLUXとしてはパブリッシャーに向き合っているのでパブリッシャーにメリットのあるヘッダービディングが存在する以上はDSPもSSPもそれをニューノーマルとして対応するべきと考えています。

Prebid・OpenBidding・TAMとあるけどどうやって選べばいいの?

PV・中:いろいろあるというかこの3つがあるという状況だと思いますが、どれやればいいんだろうっていう疑問持つ方多いと思うんですよね。

FLUX・平田:結論から言うと、全てやったほうがいいです。

PV・中:その3つ全部やる場合ってどういう運用になるんですか?

FLUX・平田:オークションとしてはPrebid.jsとTAMでそれぞれ行われるオークションが一回戦です。その勝者が戦って買ったほうがOpen Biddingと決勝戦を行うような流れになります。厳密に細かく言うともっとあるんですが。

で、これはオフレコなんですが………………………

<<おもしろいお話だったんですが企業秘密なので伏せます。>>

PV・中:へーーー!そうなんだ!おもしろい。ということはヘッダービディングの実装/運用の話をいままでしてきましたが、ヘッダービディングは活用状況踏まえた設計で導入するのがめちゃくちゃ大事ですね。

FLUX・平田:そうなんですけど、これってあんまり媒体社の状況とか、接続先をどうするとかを個別設計するような話じゃなくて、業界的な構造捉えると勝ちパターンが分かるんですよね。なのでそれを実装するのがFluxで貢献できる価値だと考えています。

IDFA取得がオプトイン制に?iOS14.5でどうなるのか

PV・中:iOS14.5で大きな仕様変更が入ると言われていますがどういったことが起きますか?

FLUX・平田:iOS14.5の問題は、IDFAに関することなので主な影響範囲はアプリの領域です。IDFAを利用して広告配信をしているアプリはユーザーからオプトインを取る必要があります。

オプトインしているユーザーは今まで通りのコミュニケーションが取れるわけなんですが、オプトアウトされてしまうとアプリのユーザーがどの広告経由で入ってきたかがわからなくなります。これに対応するのがSK AdNetworkなんですが、SK AdNetworkは正しい情報に一部ノイズとして誤った情報を混ぜて個人を特定できないようにした情報を渡してくれるので、それをベースにアプリ事業者は判断していくことになります。

SK AdNetworkの対応はまだできていない広告ベンダーは多く、Prebidはまだ未対応です。GoogleとAmazon、Facebookもお手上げ状態で、日本の1事業者で対応できるレベルではないと思っています (取材時2021年4月段階)

iOSを出している国内アプリ事業者についてもお手上げで、最近一部のコンテンツ系のパブリッシャーがアプリ廃止するのはその影響かなと見ています。IDFAを使わないで広告配信をしようとすると広告単価は著しく下がるので収益性が大きく下がります。こうなるとアプリを配信していても採算が合わなくなってしまうので、アプリをやめる意思決定をしているのではないかと見ています。あくまで憶測ではありますが。

PV・中:iOS14.5の話をしてきましたが、Safariではクッキー使えなくなるし、今後ChromeやMozillaも同様にプライバシーは強化される方向性だと思いますが、今後どうなっていくと思いますか?

FLUX・平田:GoogleはFLoCを開発していますが、これも使えるのはChromeに限定されています。プライバシー強化はこの数年で急激に進んでいてまだ一巡していないので読めない要素が大きいですね。

PV・中:ヘッダービディングでRTBの効率が上がってきた状況ですが、今後こういったプライバシー規制で厳しい時代になってきてますよね。

FLUX・平田:これオフレコなんですけど……………

<<記事化できない内容のことを色々とお話いただきました。>>

PV・中:めちゃくちゃおもしろいですね。Digitrust IDとUnified IDってこういった規制に対する対策として活かせるんですか?

FLUX・平田:Digitrust IDは2019年2月に閉じてます。これはクッキーをベースにしているからです。Unified IDはメールアドレスと紐付けてハッシュしているのでまだ活用できますが、メールアドレスを伴う会員登録がベースになるので限定的ですし、今までのターゲティングのUser IDから比較すると数も限られます。

PV・中:すごいスピードで色々変わっていますね。

FLUX・平田:変化がかなり早いので1年経つとだいぶ違いますね。

プライバシー規制を踏まえた今後のアドテクノロジーの方向性は?

PV・中:今後こういった市場環境の中でパブリッシャーはどうやって生き残っていくと考えていますか?

FLUX・平田:RTBの出現で”枠から人へ”という変化が起きましたが、人へのターゲティングが規制されることによって”人から枠へ”という動きが出てくると考えています。”枠から人へ”というRTBの初期から、ビューアビリティなども加味した”枠と人”になってきたのがこれまでの進化だったと考えています。

立場的には言うのが勇気要るんですが、Googleが推し進めるFLoC(Federated Learning of Cohorts)の対応も今後どうなるかわからない以上、この規制の中だと”人から枠へ”という変化が起きる環境になっているのは間違いないです。今後FLUXとしてパブリッシャーと取り組んでいかなければいけないこととしては、枠の理解を深めるということだと考えています。位置・サイズ・CTR・ビューアビリティはもちろんですが、どういった広告が流れているのか、どういったコンテキストで枠とユーザーが接触するのか、といったことがこれまで以上に重要になってきます。

meta要素をリクエストに載せることができるので、コンテキストターゲティングの精度を高めるためにページコンテンツの情報をmetaタグに仕込んでおくといったことも一つの手段かもしれません。こういった施策をしっかりとやっておくことで、例えば代理店からこういったセグメント、という与件があった際にはmeta要素のパッケージを用意しておけばプライベートディールなどで販売しやすいといったことも考えられます。もちろんこれは除外ターゲティングにも使えますので対策をしておくことで付加価値を付けられるポテンシャルが高まります。

FLUXが目指す必要としている人材要件とは

flux_lineup

PV・中:今日はいろいろと面白いお話聞かせていただきありがとうございました。折角なので最後になにか告知事項あれば是非。

FLUX・平田:本日はありがとうございました。FLUXでは引き続きビジネス職、エンジニア職共に募集の拡大中です。『Header Bidding』、『AdSecurity』などの広告収益最大化プラットフォームである『AutoStream』や、Cookieレスの時代に向けたデータソリューションの『ID Solution』、CMS事業『SiteFlow』など、広告事業以外にも展開しており、3期で100人規模の会社まで成長しています。

もちろん業界からのベテランの転職もありますが、比較的若くて将来起業をするうえで学びも含めて在籍しているメンバーも多く見られます。興味があれば下記から是非ご応募ください。

・採用応募の希望の方はこちらまで

また、ヘッダービディングをご対応されていないパブリッシャー様やオフレコ部分を聞きたいなどございましたら下記よりご連絡お待ちしております。

・お問い合わせがおありの方はこちらまで

*1 TAM-Transparent Ad Marketplace Amazonが提供しているヘッダービディング。
*2 Prebid.js オープンソースで提供されているヘッダービディングの共通規格。
*3 複数のヘッダービディングのプラットフォームをひとつのタグで束ねることができるソリューション
*4 GAM-Google Ad manager Googleが提供している広告枠の運用管理ツール。