「State of AdOps」は、現在急速に伸びている運用型広告の成長を支え、実際の現場で価値をつくりだしている広告運用(AdOps)のスペシャリストたちに焦点を当てるインタビューシリーズです。広告運用の最前線にいる方々が感じていることを語って頂くことで、運用型広告の輪郭を少しでも捉えることができればと考えています。
※過去の記事はこちらから。
第10回目は、DSP(MarketOne®)、DMP(AudienceOne®)、SSP(YIELD ONE®)など、プログラマティックに関わるプラットフォームを一元的に導入、推進しているプラットフォーム・ワンで執行役員を務められている田辺雄樹(たべ ゆうき)さんに、パブリッシャーサイドでの広告運用やマネタイズの現状について、忌憚のないお話をお聞きしました。
# インタビューは 2014年3月某日に行われました。
サプライサイドの広告運用、3つの機能。
●まずは、田辺さんが現在のお仕事に就かれるまでの経緯と具体的な業務内容を教えて下さい。
新卒ではシンクタンクである日本総合研究所に入り、製造業向け基幹システムの導入コンサルティングや、プロジェクトマネジメントを行っていました。いくつかのプロジェクトを経験する中で、誰かのサービスではなく、自分たちが作ったサービスを広めていきたいという思いが強くなり、ご縁があって2007年に DAC(デジタル・アドバタイジング・コンソーシアム)に転職しました。
当時は、現在の MarketOne® の前身である「アドマーケットプレイス」構想が出ていた時期で、タイミング良くその開発に携わるようになり、2009年にリリースされるまで製品がゼロから産まれていくさまを経験することができました。
その後、2011年より、DAC のアドプラットフォーム事業開発会社であるプラットフォーム・ワンに出向し、プラットフォーム推進統括マネージャーとして、MarketOne® だけでなく SSP の YIELD ONE® を含めた両サービスの運営・事業開発を担当しています。
●デマンドサイドとサプライサイド、両方を経験したことがある人は少ないですよね。
そうかもしれません。メディア企業以外で双方を扱う企業が少ないですし、マーケットの仕組みを理解する上で得難い経験だと思っています。取引を媒介するプラットフォームとして、双方のお客様の利益をどうやったら最大化できるのかを日々考えています。
●アドテクノロジーというとデマンドサイドの視点が多いですが、SSPという視点から見て、現在の運用型広告市場はどう見えていますか?
近年の DSP、RTB などの環境が整ってきた中で、デマンドサイドでの広告運用の重要性は十分に認識されてきていると思いますが、サプライサイドから見ると、デマンドサイドほどには運用という観点で語られることはないように思います。
広告運用という軸でお話すると、サプライサイドでは3つの機能があると考えています。
1つ目はアドサーバーです。ディスプレイ広告のビジネスの基本は広告商品開発、乱暴に言ってしまえば枠づくりですので、純広告であれば予約されたインプレッションをアドサーバーでしっかり管理し、ルールにのっとって正しく確実に広告を配信するというのが「運用」でした。「管理・保守」の意味合いに近い運用です。
その場合、運用で注視するポイントは、収益管理の前提となる配信のスケジューリングです。曜日や一日の中でのピークタイムなど、自社のコンテンツの表示回数の波を捉えながら、広告インプレッションを適切に配信するという役割ですね。
2つ目はサプライサイドプラットフォーム(SSP)です。2000年代後半に、レムナントと呼ばれるような純広告としては取り扱いにくいインプレッションを収益化するためにアドネットワークが出現し、イールドマネジメントという概念がだんだん浸透するようになりましたが、SSP とは、アドサーバーが管理する純広告やアドネットワークなど、さまざまな経路から行われる広告取引を仲介してメディアの収益性を高めるためにイールドマネジメントを担う機能になります。
3つ目はパブリッシャートレーディングデスク(PTD)です。メディアの持つトラフィックのデータというのは非常に資産価値が高く、かつセンシティブなデータですから、それを単純に DMP に預けるのではなく、プライベートDMP を構築して自らそのデータを活用し、クライアントの与件を達成するために DSP などを運用していく機能です。
すべてのパブリッシャーが PTD に向いているわけではないかもしれませんが、デマンドサイドで言われる「広告運用」と非常に近い意味の運用が、パブリッシャーでも少しづつですが始まっているのではないかと思います。
「プログラマティック」の4段階
●今挙げていただいた3つのうち、特に2番目の SSP は多くのパブリッシャーに導入されています。SSP の運用について詳しく教えて下さい。
SSP の運用を考える前に、「プログラマティック(Programmatic)」という概念について改めて整理する必要がありますので、少し説明させて下さい。
下の図は MAGNA GLOBAL が出した調査資料を元に eMarketer が2013年の10月に発表したグラフですが、赤丸で囲った部分を見ていただくと、2013年にアメリカの RTB の市場規模は33億ドル強($3.32B)だと推計されています。
参考:Programmatic Ad Spend Set to Soar - eMarketer (http://www.emarketer.com/Article/Programmatic-Ad-Spend-Set-Soar/1010343)
一方で、同資料の別の図を見てみると、アメリカのプログラマティックディスプレイ(Programmatic Display Ad)の市場規模は75億ドル($7.5B)になり、RTB の市場規模の2倍以上になります。
つまり、一般に RTB と Programmatic は混同されがちですが、上の図の注釈(赤い下線部)に「includes both RTB and other programmatic/automated platforms」とわざわざ分けて記載してあることからも、RTB と Programmatic は似て非なる概念だということが分かります。
●その流れで質問しますが、RTB と Programmatic の具体的な違いは何でしょうか?
Programmatic は、RTB を内包する概念ととらまえています。その範囲は、パブリッシャーのディスプレイ広告取引から見た時、RTB をはじめアドネットワークや時にアフィリエイトで広告枠が埋められる中で、配信される広告がデマンドサイドのデータを活用したターゲティングなど、なんらかの論理を以って取引が制御・自動化される状態を指します。つまり日本市場で言うところの純広告取引以外のすべてが Programmatic と言えるのではないでしょうか。
その Programmatic ですが、取引のやり方として4種類、IAB が定義しています。下の図は、その定義をプラットフォーム・ワンが日本語訳したものの抜粋です。具体的には パブリッシャーから見た Programmatic は以下の4つに分けられます。
参考:
Programmatic and RTB
プログラマティックと自動取引 -媒体社の視点から
順番に見ていきますと、一番下は「オープン制オークション取引(Open Auction)」と呼ばれるものです。レムナントをリアルタイムで販売する、これがいわゆる狭義の RTB ですね。SSP の視点では、最低販売許容価格(フロアプライス)を設定して、それ以上の価格の入札に対してオークション形式でインプレッションを販売します。オークション形式なのでインプレッション保証はなく、接続されている DSP やアドネットワークと複数繋がっていることからも、オープンな取引形態と言えます。
その次が「招待制オークション取引(Invitation Only Auction)」です。仕組み自体は前述の Open Auction と同じですが、特定の広告主や広告代理店にだけ入札を許可するような、クローズドの形式です。リアルタイムで取引することは一緒ですが、取引先が限定されるため「プライベートマーケットプレイス」や「プライベートオークション」などと呼ばれます。
次に「余剰在庫型固定単価取引(Unreserved Fixed Rate)」です。あるパブリッシャーのある枠のインプレッションを、特定の広告主や広告代理店に対して販売する形式です。Invitation Only Auction との違いは、取引が1対1であるため、オークションではなくあらかじめ決められた価格によって取引される点です。固定CPM がいくらと決めて、優先的に取引する形態ですね。
最後が、一番上の「在庫予約型固定単価取引(Automated Guaranteed)」です。純広告に非常に近い形態です。Unreserved Fixed Rate との違いは、Guaranteed(保証) という言葉のとおり、予約型の取引なので、インプレッションが保証されている点です。「プログラマティックプレミアム」や「プログラマティックダイレクト」などとも呼ばれ、取引形態としては純広告に非常によく似ていますが、「手売り」と表現されるような取引に関わる様々な作業をシステムによって自動化するところが従来の純広告との違いです。
この4つの定義によってプログラマティック取引のグラデーションが表現されています。まとめると、プログラマティックとは、一番下の RTB (Open Auction) も含めた、プログラム化された様々な広告取引を包括する概念だと言えると思います。
ちなみに、先日共同でリリースさせて頂いた日本マイクロソフト様向けの取組み(※PDF:http://www.platform-one.co.jp/pdf/release_20140313.pdf)は、4つの定義の中の上2つ「余剰在庫型固定単価取引(Unreserved Fixed Rate)」と「在庫予約型固定単価取引(Automated Guaranteed)」と DMP とを活用して進めた事例となっており、他の広告主様でのご活用も増え始めてきています。
パブリッシャーサイドの広告運用としての SSP
●最初の質問に戻ると、プログラマティック取引の中で SSP の運用はどのような位置を占めるのでしょうか?
SSP は、これまでお話ししたプログラマティック取引のすべてを対象にできるプロダクトであるべき、と考えています。純広告以外の取引を管理し、収益の最大化を目的としますので、ただ単に「RTB取引できます」といったネットワークやアドサーバーのことを指すわけではありません。
個人的には、SSP とは「パブリッシャーのマネタイズを最大化し、業務効率改善を支援する業務・収益管理運用ツール」だと考えています。だからこそ、SSP はその名のとおりサプライサイドのプラットフォームとして、プログラマティック取引を一元的に管理する役割を担う必要があります。
ですので、媒体社様のご都合があることは理解しながらも、アドサーバーで優先順位をつけて SSP を数珠つなぎにし、フロアプライスごとに切っていくというような運用(メディエーション)がベストだとは思っていません。私は「Programmatic for Publisher」と言っていますが、サプライサイドのプラットフォームは、1つのインプレッション毎に入札される DSP やアドエクスチェンジ、アドネットワーク、プレミアムなどを一律に評価する体制を整えることで、レムナントの RPM の向上だけでなく、プレミアム広告のブランドセーフティ、保証型のインプレッションの管理など、プログラマティック取引を統合的に行える機能として位置すべき、と考えています。
図にすると、SSPの役割は最低限、この赤で囲った部分になると思います。
●そういった先進的なイールドオプティマイズを行っている企業はどれくらい存在しているのでしょうか?
2014年初頭の時点では、今申し上げたような SSP を使った統合的なイールドオプティマイゼーションを行っているパブリッシャーはまだ少ないと思います。また、スケジュール型の純広告は純広告として最優先で配信し、レムナントはレムナントとして運用するという体制が当然かと思います。
RTB のみならず、プログラマティックへのホリスティックな対応は、今後避けられない流れだと思います。パブリッシャーでの広告運用は、これまでの保守としての意味合いから、インプレッションのマネタイズ構造の変化に合わせてメディア企業内での組織運営の変化に至るまで、今までより広く重要な機能へと変わっていっているように思います。
●一方で、ドラスティックに変化することが難しい場合も多いと思います。
ですので、段階を追って変化する必要があると思います。これも IAB の資料になってしまうのですが、パブリッシャーがプログラマティックに対応するための段階を示した図があります。
この図ではプログラマティック対応を3段階に分けて提示しています。
1. は、「Operation Focused (運用にフォーカスせよ)」です。パブリッシャーにおける広告運用とは何か、プログラマティック取引では何が求められるのかを知ろうということですね。このビジネスモデルをまずは理解しようということです。
2. は、「Developing Internal Sales Capabilities(社内組織を立ち上げよ)」です。ビジネスモデルの次に、プログラマティック取引に対応する組織を立ち上げ、社内的なコンフリクトがない組織体制にしていくという段階です。純広告で収益をあげていた歴史のあるメディアでは、社内的に純広告営業とプログラマティックで組織が分かれていて部門間で対立が起こっていることがあります。それはやめましょうということですね。
3. は、「Internal Consultants for Programmatic(社内のコンサルタントになれ)」です。プログラマティック取引の担当者が社内のあらゆる広告メニューのハブ的役割を担うようになるということです。プログラマティックはプログラマティック・ダイレクトなどの純広告的な取引も含む概念なので、広告営業担当とチームを組んで、プログラマティックに対応した広告パッケージを作るなど、オペレーションを前提にした広告在庫をいかにデマンドサイドにとって価値あるものにパッケージしていくか、営業組織が一丸となって動ける体制をつくり、その中心になりましょうということです。
●そうなると、そういった役割が担える人材や組織の問題にもつながっていきますね。
そう思います。先ほどの3段階の図で言えば、1の段階の企業は多いものの、2や3の段階にいる企業はまだ少ないです。それがダメだという意味ではなくて、まずは1の段階でアドサーバーの保守だけではない、RPM を上げるための運用を行って知見をためていく必要があると思います。
メディアの特性によってパブリッシャーサイドの広告運用の最適解は変わるはずです。例えば、単純に高単価で約定するネットワークを優先しても、フィルレートが低ければマネタイズできるインプレッションは増えませんから全体の RPM は上がりません。オークションを活発にするためにどのように SSP の設定を変えていけばいいのか、オーディエンスや枠ごとにフロアプライスを切り替えたらどう収益が変化するのかなど、データをためていきながらそのメディアなりやり方を見つけていくことが、結果的に次の段階に進むドライバーになるのだと思います。
そして、それを実際に現場で担える人材をどう確保し、組織として伸ばしていくかが今後の課題かもしれません。
●デマンドサイドの課題ともつながっていきますね。
立場は違えど、構造としては似ているのかもしれません。テクノロジーの進化によってパブリッシャーにとっての武器はだんだん揃ってきていると思います。それをどう活用するのかはパブリッシャー次第といいますか。
SSP の選び方や設計の仕方、動画や広告サイズの変更などのフォーマットの拡大もありますし、需要に合わせて広告商品の開発をすることにもつながっていくかもしれません。メディアの特性に合わせてビジネスが変化していくなかで、その中心に広告運用者の価値があると思いますし、パブリッシャーこそテクノロジーを活用すべきだと思います。
プラットフォーム・ワンとしては、パートナーとして選ばれるよう、それらをきっちりフォローさせて頂ければと考えております。
YIELD ONE® が担っていく役割
●ありがとうございます。そのような流れの中で、YIELD ONE® としての方向性などがあればぜひ。
「YIELD ONE®」のポジショニングとしては、パブリッシャーと伴走するイールドオプティマイズプラットフォームです。下の図で表現すると、縦軸にイールドマネジメントとエクスチェンジ、横軸にプレミアムか否かで四象限を作ると、現状お付き合いさせて頂いているシェアの大半が法人優良媒体社様であることもあって、我々は右上に位置し、特にイールドマネジメント機能を提供するサービスに位置付けている、と考えています。
SSP と一言で言ってもイールドマネジメントとエクスチェンジャーがあると思っていまして、単純にレムナントをまとめてバルクでお金に変えるという機能ではなく、パブリッシャーに向き合いながらイールドマネジメント機能を提供していくのが SSP の本来の役割です。そこはブレないようにしていきます。
話しは少し逸れますが、おそらく、ちょうどこのインタビューがオープンになる頃にはDACから新たなリリース(http://www.dac.co.jp/press/2014/flexone.html)を発表できていると思います。その内容は、ここまでお話しさせて頂いたようなレムナント領域に限ったプログラマティック取引のフルサポートをするのみならず、媒体社様にとっての手売り、即ち純広告の配信領域まで含めたイールドオプティマイゼーションをフルサポートするプロダクトに関連するものです。名前は、FlexOne® と言います。ここまででも触れた4段階の「プログラマティック」に純広告の領域まで含め、媒体社様にとってのイールドオプティマイゼーションを、ワンストップで実現できるよう尽力していく次第です。
こういったリリースや日々の活動を通じて、狭義の RTB のみならず、プライベートエクスチェンジサービスなど、パブリッシャー向けのプログラマティック取引プラットフォームとして、高単価で収益性の高い広告販売ができる環境を提供し続けていきたいと考えています。
手前味噌ですが、2014年の1月に発表したリリースでは、2013年10月~12月の3ヶ月間における RTB平均取引単価が前年同期比で約55%向上するなど、結果も明らかに目に見える形で出てきていますので、引き続きプログラマティックの環境を整備し、デマンドサイド・サプライサイド双方の収益が向上するよう支援していきたいと思います。
(PDF)プラットフォーム・ワンの SSP「YIELD ONE®」の媒体社収益は 前年比 55%アップ、DSP「MarketOne®」の取引単価はステイ
●本日は貴重なお話、ありがとうございました!
プラットフォーム・ワン (http://www.platform-one.co.jp/)
コメント